I recently added highlighting support tp my simple markdown editor, but the coloring behaves in a funny, unexpected way.
The initial color is taken from the hash of the highlight label (so it is always the same color for same highlight types), and I calculate a color offset from that hash like so:
Then, in the derived custom BTextView itself, I do the actual highlighting and redraw, which works just fine when scrolling:
However, on resize, the colors change (!), which makes absolute 0 sense to me.
I tried all possible variations of blending and drawing modes, but since it works in normal circumstances e.g. for scrolling, the drawing itself is OK.
Also, I checked that the entire area is prepared correctly by BTextView before I redraw the highlight, so it cannot be a wrong overdrawing of the blending or such.
I donāt think the ColorForIndex method really makes any sense to use when not in indexed (e.g. 256-color) mode, it may just return bogus data in that case.
Yeah thatās what I feared. However it does work and return suitable colors, the color is only derived once and working fine, also during redraw (on scrolling), just not on resizingā¦ how can that redraw be different?
I was just searching for a quick and easy way to retrieve some standard colors without the need to configure my own - is there an alternative way to do that? Like a default Haiku palette/color scheme beyond the ui_colors?
A glance at the source code shows that if no palette is defined, it may just return bogus data from the stack, and perhaps resizing alters the stack frames here. Either way we should fix this and probably have it return a constant black instead.
There arenāt any colors beyond the āui_colorsā, but of course you can use ātint_colorā and āmix_colorā with these to get some more variants.
This allows to get a set of colors with consistent visual lightness and saturation, but different hues. So you just pick two fixed values (depending on light/dark mode for example) and let the algorithm determine the third.
The HSL color space does not work as well for that, this is why XEP-0392 went with yet another colorspace.
Cool let me try that. I guess Iām just missing the indexed color palettes of my old and golden Amiga daysš
Seriously though Iām still puzzled as to why the perfect valid color I derive with my algorithm is distorted although itās copied into a new color and never changed againā¦
Update: ok thatās a really interesting proposal but way too much code for this simple task, Iāll stick with a good set of default colors from a free Sublime theme:) Gonna pick this one probably:
If your hex code is #AABBCC, use make_color(0xAA, 0xBB, 0xCC). Does that really need a separate constructor? What would it construct from? An uint32? Then we need to worry about channel order and endianness. A string? Seems quite inefficient when the conversion is direct with just a bit of reformatting.
Ah thanks didnāt know about that one!
Yes it would be a convenience when working with outside values from templates etc., esp in the web world.
Anyway thereās a handy stdlib function for that with std::hex or std::ul, see: https://en.cppreference.com/w/cpp/io/manip/hex
Given that BString is also streamable, this should be good.
hmmm as I have feared this did not help. Please @PulkoMandy or @nephele if you have any idea Iād be very delighted to fix this once and for all and leave the frustration in the old year
You can reproduce also with hiding the window and bringing it into view again, so it is a redraw issue. However, I do exactly the same thing in the only redraw method and the updated region is definitely correct, so Iām out of ideas currentlyā¦
tackled this issue again today and I have more and more suspection that this might be a bug in Haikuās TextView rendering on Window resize or something with BView redraw.
I even tried posting a B_WINDOW_RESIZED message with the correct Window bounds and it was still behaving differently when resizing manually:
Itās just looking more and more like a bug in BWindow/BView redraw on resize in combination with alpha drawing modes, as I have pretty much done everything I can from my side to rule out any bugs in my custom viewā¦
You donāt want to subtract 1 there (or in the current code, that does the same).
On redraw, you call BTextView::Draw, which draws the text and the caret or selection if necessary. Then you do your own highlighting, possibly over a selection. In fact, the only way Iāve found to have appās highlights now is to add them to selected text.
So you have some color C. Selecting draws that part as 1-C. Highlighting with color H draws it as (1-C+H)/2. If you now unselect it, it becomes 1-(1-C+H)/2 (thereās no full redraw, just an inversion of the affected area). If a part highlighted but not selected is redrawn, it shows the expected (C+H)/2. If that is selected now, it becomes 1-(C+H)/2.
You can workaround it with:
void EditorTextView::Draw(BRect updateRect) {
int32 start, end;
GetSelection(&start, &end);
Select(start, start);
BTextView::Draw(updateRect);
// redraw text highlights if any inside updateRect
[...]
Select(start, end);
}
I donāt know if that would have ill effects, though.
Thereās probably also a problem in BTextView or the scroll. Iāve noticed the āmarginā changing on first vertical resize or scroll, causing the appās highlights to be slightly off.
