Qt 3.2 requirement

[Maksim Orlovich]

On Mon, 28 Jul 2003, Matthias Ettrich wrote:

> On Monday 28 July 2003 13:25, Chris Howells wrote:
> [snip]
> > > The question is, what do we gain by introducing a requirement on Qt 3.2
> > > and
> >
> [snip]
> > * Bug fixes
> 
> Let me elaborate a bit on this point, because some of those bug fixes are 
> rather important ones. In fact, they all are, because they all got reported 
> by at least one person. Take printing as an example. Printing of non-unicode 
> fonts (like Wingdings) did not work in Qt 3.1. Fixing this properly, however, 
> wasn't trivial. It basically required a new font engine in Qt, which is why 
> you get the fix in 3.2 and not in 3.1.
> 
> Now, it may very well be possible that some styles have some smaller issues 
> when you just replace one Qt dll with the other. This is a bit the nature of 
> styles. KDE's styles stretch Qt's styleability beyond its limit by making all 
> sorts of assumptions about its internals (the same is true for some of the 
> other subclasses in the KDE libraries, unfortunately). Qt's powerful 


Ironically it's Qt styles that mostly don't/didn't work with Qt3.2 and
KToolBar (which did have a latent bug in its sizeHint..) :-) What would
help, however, is a bit more information about the contract about styles
and the apps -- since some bits/conventions are implicit (and some are
just agreements inside KDE), and there are really confusing spots like
CC_SpinBox and CC_TitleBar which receive pointers to private widgets in a
public API. 

And also, symmetric to your (fair) point, there are also some cases where
the Qt code now makes all sorts of assumptions that make doing reasonable
things inside KDE classes very hard. A good example in Qt3.2 is the flat
toolbar (i.e. DockMinimized) support, which is really quite brittle
internally (*cough* making toolbars 1x1 windows, reparenting them to
QHideDock, and moving them outside the parent's frame *cough*) and breaks
as soon as KToolBar tries to add/remove/update things in the publically
accessible BoxLayout. (/me goes to look for Waldo to think of a
workaround).


> Looking ahead I do believe we have good news for style authors in future Qt 
> versions (Reference NoveHrady again).

Very interesting; however note that ATM it's quite likely that none of the
style developers will be there unless someone can convince Fredrik, or
unless Chris suddenly becomes wealthy.