[haiku-development] Re: Appearance change system message

  • From: looncraz <looncraz@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 20 Sep 2015 09:08:23 -0500

On 9/20/2015 02:44, Adrien Destugues wrote:

Only the FirstBootPrompt application will use the message to refresh all its text when you select a different language.

Oh, awesome! I forgot about that, that will give me a place to look to see how it has been done before.

There is no locale library anymore (it is all included in libbe now).

I knew that... then promptly forgot it, LOL! Might explain why I haven't had to keep adding the library in... :p

The lookup in the catalogs being somewhat slow, the Locale Kit is designed to do it only once when B_TRANSLATE is called (usually when setting the label of a view). Then, the localized string is passed to the BView or whatever uses it. Handling locale changes in a way that's transparent to the application would mean storing the english string in the BControl, alongside with a handle to the BCatalog to use (which is usually the application MIME type, but can be something else if the application uses custom catalogs or the text comes from a library). Since the handle to the BCatalog would be shared between all views used in the application, I'm not sure when the old catalog could be safely destroyed. And finally, the application may still need to refresh other things: the window layout, any loaded resources (let's say if the app also has localized sound or pictures), and any instances of BCollator (for sorting text), B*Format, etc. And I'm not even talking about switching between RTL and LTR languages, which we don't support yet, or changing between languages which need different fonts to display properly.
We can, however, have generic solutions for color and font changes. For
color, of course, we will have to ensure each view is using the previous
view color - no such worries for controls :p.
I'm not sure it's possible to make this transparent to the app.

We could only do fonts automatically when using layouts without potentially messing things up.

Colors, though, we can do for controls without regard to the application. For view color, though, we have the added issue, as you said, of knowing when a view wants the system view color versus their own color. So, we're either left with comparing the existing view color with the outgoing view color, only updating if they are the same, or implementing SetViewUIColor(color_which), which is what Be did with 5.1.

Both have a similar enough overhead, but using SetViewUIColor() is potentially more flexible as, in theory, we could also allow a tint to be applied at the same time as a second parameter, which should address 99% of all use cases. Then we will need to go through every app and replace SetViewColor(ui_color(B_PANEL_BACKGROUND_COLOR)) to SetViewUIColor(B_PANEL_BACKGROUND_COLOR)... which is easy enough.

I am willing to go either route, neither are a perfect solution (SetViewUIColor means older apps will not take advantage of it automatically, a color comparison might make problems in quite a few different ways), but I prefer SetViewUIColor().


In BControl views, there are also cases where
custom drawing is used. I'm thinking of a BList with custom subclasses
of BListItem (examples in Media and Locale prefs to add icons to the
items, and in Paladin to colorize items depending on their compilation
state), a BMenu with custom BMenuItems (Tracker adds icons to its menu
item, I have a work in progress app using a BSlider inside a BMenuItem,
and other combinations can be created). In these cases the app, or maybe
the custom controls, will have to take care of adjusting to the changes.

Well, the great thing, is that a user will be watching the color changes they make, so they will choose a color that makes sense. In PhOS I chose a medium-dark tan color, for example, because it didn't cause any problems. For system drawing, we will need to go through and ensure every color is based upon a system color constant in some way. That might be time consuming, but I really enjoy working on things when I can actually see the impact right away ;-)


So, +1 to having a notification message when the settings are changed (I
think a single message with bitmask is a good compromise, because an app
can decide to refresh its whole UI only once when several settings are
changed at the same time). +1 to having the UI auto-adjust to it in the
cases where there aren't compatibility problems with doing so (at least
changing the decorator color will be fine - for the other changes I'm
not so sure, it will require some testing).



I have already done some of the work to send B_*_UPDATED to each window and view (I think sending to both makes for the most flexibility - and I'm all about flexibility). I have no idea what needs to be done to get layout-enabled views and controls to update automatically aside from the colors (where the code will not change), I will have to investigate that (I am not much of a fan of using the layout kit, though I love the results when I fight it enough to get it to work...)... hints are welcome! :p

--The loon

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 09-2015