[haiku-commits] Re: BRANCH looncraz-github.setviewuicolor [7f350151385b] in src: apps/haikudepot/ui apps/haikudepot/ui_generic kits/interface
- From: looncraz <looncraz@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 22 Oct 2015 12:55:26 -0500
On 10/22/2015 12:20, Stephan Aßmus wrote:
Have a look at MarkupParser...
https://github.com/looncraz/haiku/blob/master/src/apps/haikudepot/textview/MarkupParser.h
... which you can optionally pass a CharacterStyle and ParagraphStyle
(which are references to CharacterStyleData and ParagraphStyleData, as
you found out) in the constructor. It should already be trival to
store these two styles in the list view, or even just the
CharacterStyle, and set the text and background color on that style to
adopt the system color. It would update *all* styles used in the
TextDocument, since the MarkupParser will make CharacterStyle
instances (for "bold" for example), which will have the initial
CharacterStyle as parent and override *only* some properties (i.e.
bold). They inherit the same text and background color.
Tried that first (and again last night), was a total no-go, which led me
to believe the style wasn't being shared, but what I think is that the
changes are creating a new data and the local CharacterStyle becomes
modified and nothing propagates. Methods which can change the data
in-place may do the trick, but that seems to violate what you were going
for, design-wise... I'll give it a try anyway and see what you think.
I also tried to iterate through all of the TextSpans and even that
didn't work (also has the problem of creating a whole bunch of allocations).
I don't see why the data has been separated at all, seems mostly
counterproductive. It seems that always passing a reference to a
CharacterStyle, which holds its own data, would be better.
ParagraphStyle has the same design and would seem to also be better
served by consolidation with its data and universal referencing to a
ParagraphStyle, then you change the ref when you want to change the
style of a span. That is not needed to solve the current issue of
having effectively immutable style data, though, just simple Modify* vs
Set* methods could do it... Or making MarkupParser a friend of
CharacterStyle & CharacterStyleData... which is less pleasant, IMHO.
I am wondering how that would work using BTextView. Does that support
style inheritence and overriding only certain style properties? Maybe
I should have a look at your patch again what you had to do in
AboutSystem. But maybe that doesn't use bold or italic and only
different colors, I don't remember. Then it wouldn't be a good
comparison.
I got rid of the unnecessary use of BTextView in AboutWindow :p
BStringView was just a much better fit for the time. The text colors in
the credits view don't change, however, they are hard-coded. I debated
ensuring the text view background was always white as well, and probably
should actually do that.
I also started having HaikuDepot using hard-coded colors, with the list
background always white, the text always black, and then using some
blending effects for the about packages area, but it just felt out of
place, which is not good for such an essential application.
--The loon
Other related posts:
