[haiku-development] Re: Appearance change system message
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 20 Sep 2015 09:44:56 +0200
On Sat, Sep 19, 2015 at 04:56:57PM -0500, looncraz wrote:
On 9/19/2015 15:46, Axel Dörfler wrote:
Do we already have a B_LOCALE_CHANGED so the application can change its
language? It would pretty much be the same work involved to relayouting it
(thanks to the stupidity of how we handle our B_USE_SPACING_* constants).
That's the easy part, guess no one has worked on a default action in
response to the message (I could have sworn this actually worked in the
past, though).
Only the FirstBootPrompt application will use the message to refresh
all its text when you select a different language.
I'll play around see about getting a simple preflet to respond to the
language preference, maybe a nice generic solution will work, but the
application directs the translation, so we can't just translate the contents
and reflow the layout without the app changing the text/labels... or linking
to the locale library. If the system would have worked on translating the
labels from an always assumed English source, though, then that would be
possible with much less work.
There is no locale library anymore (it is all included in libbe now).
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.
For font changes: these will make the size of all controls different and
the layout needs to be recomputed. There are some examples in Haiku code
of using BView::StringWidth("WWWWWWWWWWWW") or similar to get a
font-sensitive size, and in that case it is up to the app to recompute
its layout. So it may not be that easy to make this transparent to apps.
For color changes: in generic views, you will have the problem that apps get the
system colors using ui_color, but then set the view colors as an
rgb_color and not by giving them the constant. So, a view on its own
does not know if it should be using a system color and adjust as it
changes (it is probably not a good idea to change colors without the app
being aware anyway). 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.
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).
--
Adrien.
--The loon
Other related posts:
