Trolltech, Qt 4.2 and KDE 4.0

[Hamish Rodda]

On Monday 13 March 2006 04:12, Thiago Macieira wrote:
> Hello everyone
>
> Trolltech is aware that KDE 4.0 will require many features present in Qt
> that are currently not there or not even scheduled for Qt 4.2. And we're
> also aware of discussions going on about extending our classes to provide
> that functionality and of patches being made against qt-copy in hope of
> being rolled into Qt in the future.
>
> While we have our own set of priorities and features for Qt 4.2, we are
> committed to seeing KDE 4.0 happen and using an unpatched Qt 4.2, without
> the need for crude hacks or unnecessary subclassing. Therefore, Trolltech
> is placing one resource to interact with the KDE developer community and
> finding out what such needs are.
>
> This point of contact will be me: I want to hear from the developers what
> changes to Qt as it currently stands is required in order to produce KDE
> 4.0. However, I won't be implementing those changes myself. I'll merely
> relay the information to our developers and make sure it gets the
> necessary and timely attention.
>
> I'm already collecting such issues, like the QDate range extending or the
> QAction necessary modifications. And apparently we have one more for
> menus, being discussed right now on kde-devel.
>
> I'd like to hear from the developer community what those features are,
> what their use-cases are and how they affect Qt. I'd also like to know
> what the solution would be if Trolltech were to not accept the feature:
> how much impact would it have on KDE code.

Thanks for taking this on.

I've found that there is a lack of functionality in the QMainWindow class.  In 
order to fit in with XMLGUI and KConfig saving of toolbar and dockwidget 
settings, we would like to be able to accomplish the same as saveState() 
without having to use a binary blob.  The following are not possible without 
hacks, or using QMainWindowLayout (a private class):

1) Determining the order of toolbars

suggestion: QList<QToolBar*> QMainWindow::toolBars(Qt::ToolBarArea area = 
Qt::TopToolBarArea) const;

2) Determining the toolbar breaks present

suggestion: bool QMainWindow::toolBarBreakPresentAfter(QToolBar* bar) const;

3) Determining the order and layout of dock windows

This one is quite a bit more complex, given that they are not a linear 
sequence.  Ideas for API would be welcome.


I think there may even be more data that we need, but if so I haven't 
identified it yet.

If this info cannot be provided, KDE will be forced to use a binary blob for 
saving + loading of mainwindow settings (which I am currently doing, but it's 
not optimal).

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060313/48def895/attachment.sig>