RFC: KToolBox

[Matt Broadstone]

On 9/4/06, Simon Hausmann <hausmann at kde.org> wrote:
> On Monday 4. September 2006 18:06, Matt Broadstone wrote:
> > On 9/4/06, Olaf Jan Schmidt <ojschmidt at kde.org> wrote:
> > > [ Frans Englich ]
> > >
> > > > Isn't it a usability and accessibility concern that font and styles are
> > > > hard coded in a class?
> > >
> > > Yes, hard coding colours, fonts, sizes or styles leads to accessibility
> > > and usability problems. The upcoming HIG will contain clear guidelines
> > > for this.
> > >
> > > All existing instances of such hard coding need to be removed for KDE4.
> > > The idea is to extend the colour schemes and to provide new convenience
> > > widgets for application appearance configuration to help enforce this.
> > >
> > > If you need an additional colour role, then please tell me what exactly
> > > you need and I will add it to my list.
> > >
> > > Olaf
> > >
> > > --
> > > Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards
> > > accessibility networker, Protestant theology student and webmaster of
> > > http://accessibility.kde.org/ and http://www.amen-online.de/
> >
> > Yeah the hardcoded stuff will not be there in a later version, the
> > idea though is that its built of more widgets that allow styling of
> > the toolbox that was not previously possible. Instead of being made up
> > of just a single tab its created with a header, base, and footer all
> > which theoretically can be styled. The idea initially was to have
> > something like CE_ToolBoxTab CE_ToolBoxTabLabel PE_ToolBoxBase
> > PE_ToolBoxFooter - or whatever, so you can actually have control over
> > the look of the toolbox. Remember, the reason I made this in the first
> > place was because I simply couldn't do this with the current way
> > things work (though I theoretically could have done it if I made a
> > QStyle JUST for the toolbox - but this is not ideal imho, styles
> > should be made to be applied to the whole application).
>
> That is btw exactly the reason why Qt 4.2's QWidget has a styleSheet property
> that transparently enables the style sheet style to permit the use of CSS
> (with images, etc.) to change the look of an entire widget.
>
> I hope we'll have enough documentation and example code ready for 4.2 to
> show :)
>
> Simon

Hrm could I still make the round frame around the qtoolbox this way?
I'm not sure it would be scalable, and it would certainly be slower
than painting, correct? I can imagine how much it would suck to have
all the various web/css tricks people use for rounded corners inside
Qt (yuck), and we would still have to have a few added classes in
QToolBox for this to be feasible: we already have a way to style the
toolbox tab (though not the color of the text, only the boldness of
the text[I find it so weird that this was provided before other more
basic functionality], in that tab unless you change the whole palette
for the widget) so that's OK, but if we were to use CSS tricks in my
rounded box idea we'd need a way to place a scalable graphic of the
sides of the box in the middle/viewport section, and then a scalable
graphic of the bottom of the box in the footer section. See the
problem is that QToolBox does not provide any access to the widget
that the children of each tab are parented to, so there is no way to
style that section (and therefore I can't put the lines for the side
of the box there). I think the only way to really handle this issue in
the most generic and powerful way is for Trolltech to add the style
elements I was talking about a few posts back. I understand its not a
huge priority (another reason I made this class) because most people
don't use the toolbox in the first, but once again if we're really
looking for the most powerful/generic solution that is it.

Matt