\colorbox renders root index invisible

[ForNeVeR]

This is okay:

But this is not (\sqrt{2} doesn't show 2 anymore):

The same problem could be encountered with the new formula box selection mode (see #123): e.g. the root index \sqrt[4] isn't visible when the formula part is selected:

[B3zaleel]

That happened because the radical was visually in front of the root, so i had to reorder the arrangement in the Radical Atom. Here it is

[ForNeVeR]

@B3zaleel I'm sorry but your contributions are getting increasingly hard to follow. I would appreciate very much if you stop pushing everything to your master branch. Please 😭😭😭

[B3zaleel]

Ok, sorry about that

[B3zaleel]

I just fixed an arrangement issue with the Radical, should I create a new branch for that? Even though it's like 2 SLOCs?

[ForNeVeR]

Yes, please. Create a branch from the current master from this repository and send a separate PR.

We haven't merged anything from your repository yet for this exact reason: you have tons and tons of changes there, and nobody had the time to review all of that.

On the other hand, small accurate PR could be reviewed and merged almost instantly.

Thanks!

[ForNeVeR]

Alright, the issue here is that the root index gets drawn first, and then it gets overdrawn by the colored background of the whole radical sign and everything.

We should either rearrange the items in the radical atom's box, or change the background rendering strategy (that it only set the background once per atom, and don't transitively touch all the atoms inside of a child one).

[ForNeVeR]

Currently, the best idea seems to be to create a new container — LayeredBox — that will place one box directly on top of another. This should help us to remove the negative-sized-atom hackery currently placed in the Radical atom, and also will allow to set the proper rendering order for the subboxes while keeping the background rendering code.

[ForNeVeR]

While LayeredBox is a good idea, it will have to wait for another time. It won't solve the issue: the background for the stuff on the top layer still will override the stuff on the bottom layer.

Having thought about that for some time, I don't think it's even an issue anymore: if the boxes decided they need their background to be drawn over some other boxes, so be it.

The issue is the selection background: we shouldn't draw it in the way that changes the items' background (or hides any elements of the formula).

Let's instead draw the selection background on the topmost or on the bottom-most layer of the image, or even at a separate graphics element (while preserving the proper coordinates), or invent some other smart solution for the problem.

Check how selection works in other editing tools: maybe our behavior is even the right one?

[ForNeVeR]

I am probably overthinking the task, so I'll postpone it a bit.

Current solution I am coming up with (probably overengineered) is to store a List<Primitive> inside of the WPF renderer, and reorder them in the IRenderer.FinishRendering method (moving all the background primitives to the beginning of the list to draw them before anything else).

This is because the WPF DrawingContexts aren't composable and it is no easy way to create any sort of "layers" in the DrawingContext.