[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Trolltech, Qt 4.2 and KDE 4.0
From:       Hamish Rodda <rodda () kde ! org>
Date:       2006-03-13 10:49:39
Message-ID: 200603132149.41493.rodda () kde ! org
[Download RAW message or body]


On Monday 13 March 2006 19:53, Thiago Macieira wrote:
> Hamish Rodda wrote:
> >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;
>
> QList of pointers sounds ugly...

Why?  It's common in Qt4.

> >2) Determining the toolbar breaks present
> >
> >suggestion: bool QMainWindow::toolBarBreakPresentAfter(QToolBar* bar)
> > const;
>
> Even more ugly.

In Qt 3, this property was attached to the QToolBar.  It's been moved to the 
layout class but in the process has been made write-only.  Perhaps a bool 
QToolBar::breakAfter() function?

> >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.
>
> In all three cases, you want a description of which toolbars/dockwindows
> are present, where they are and how they relate to nearby
> toolbars/dockwindows.
>
> I think a nicer API for that is in order...

Maybe some sort of iterator design.  I don't know.  Whatever the api, getting 
to the data is what i'm interested in.

Cheers,
Hamish.

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]