Re: scrollbar display options

[Havoc Pennington <hp redhat com>]

Drazen Kacar <dave arsdigita com> writes: 
> Another possible problem are three buttons on the right. At first they had
> equal width, but I didn't like that, so I changed the appearance to the
> present situation: the "Mute" button is smaller than the "Pause" and that
> one is smaller than the "Channels..." button. In case the application is
> translated and the translation for "Mute" takes more space than the
> translation for "Pause", I think I wouldn't like the result. The program
> can do something about this situation, but it's not trivial in case one
> has many buttons and one doesn't want them to have equal size.
> 
> What's the point of all this? I think it doesn't matter much how the
> scrollbar looks for itself. What matters is how it looks in the
> application, ie. with all other widgets around it. And I don't know how to
> approach that situation in general, if the look & feel of widgets can be
> arbitrarily changed.
> 
> Is there a tutorial for UI design with themes in mind?
> 

As you point out yourself, this isn't really just about themes - i18n
introduces at least two issues, namely UI flipping for right-to-left
locales, and text changing sizes. Then accessibility introduces the
concept of everything changing size, so that people with low vision or
limited mouse precision can use it. So really you have these
challenges for perfectly legitimate, serious reasons, quite aside from 
the frivolous cosmetic themes. I'm just saying this since maybe it
makes you feel better. ;-)

And also because this is the main reason programmers shouldn't be
hardcoding things that hose up themes; they are also hosing these
serious pieces of functionality in most cases.

Anyway, no I don't know of a tutorial. :-( In these two cases:

  - with the scale widget, part of the issue is that
    GtkRange/GtkScale/GtkScrollbar seem to have been a test bed for 
    the first iteration of GtkObject back in the pre-1.0 days, and 
    they are absolutely ridiculous in implementation and difficult 
    to usefully derive from. But aside from that...

    The tick marks you want should be part of the widget, as Paul
    says. That's the best solution I can come up with. I think the 
    only way the scale will change size though is for the text 
    at either end to change... which brings us to the buttons:

 - with the buttons, you are just stuck with the reality that 
   you don't know how big that text will be. So any UI that involves 
   knowing that is doomed. Conceivably you could call gettext(), sort
   the strings by length, then order the buttons accordingly, but 
   that sounds like a Really Bad Idea. Here I think the issue 
   is really i18n, not themes.

   Anyway, I see no way to always get the effect you want there.

Basically you can't ever assume any sizes are constant... we try to
provide lots of containers to help avoid hardcoding sizes, but it's an
inherently hard problem.

Havoc