RFC: KToolBox

[Gary L. Greene Jr.]

On Sunday 03 September 2006 17:45, Benjamin Meyer wrote:
> On Saturday 02 September 2006 11:06 pm, Matt Broadstone wrote:
> > Right - would probably help if I actually attached the class :)
> >
> > On 9/2/06, Matt Broadstone <mbroadst at gmail.com> wrote:
> > > Attached is a replacement for the QToolBox that I have written. It's
> > > mainly intended to look MUCH better than the old tool box, but it has
> > > a few differences. Notably, there is no longer a concept of a "current
> > > page," as we had in QToolBox, also there is no longer a QScrollArea
> > > for each individual page in the toolbox, but instead one large one for
> > > the whole box. Lastly, you can choose a title and icon for the
> > > toolbox. Beyond that (sorry if I've forgotten anything) it tries to
> > > maintain as much of the api of the original QToolBox as possible so as
> > > to be somewhat of a drop-in replacement for it (not like ANYONE uses
> > > the QToolBox in kdelibs and kdebase, hopefully because it was too ugly
> > >
> > > :) ). Anyway - hope you all dig it, please let me know what you think
> > >
> > > can be improved, and hopefully we can get this in kdeui sooner than
> > > later.
> > >
> > > Matt Broadstone
>
> It looks cool, can you please make a directory in playground/base for your
> code.  Something like:
>
> ktoolbar/src
> ktoolbar/autotests
> ktoolbar/example
>
> This way it can be very easily evaluated and the code has revision history
> as it is improved and when it is ready to move in it will be really easy.
>
> - Animations, using QTimeLine to have animations as things are opened and
> closed.   I have created this widget myself to show off the timeline class
> (not as fully fleshed out of course).  Check out OS X's Finder information
> dialog for an example or Windows XP's Explorer.  (I am assuming it doesn't
> animate, but I haven't tried running it in an example)
>
> - There are no docs or autotests
>
> API:
>
> - use Q_SIGNALS and Q_SLOTS
>
> - Is it common to have a header for the widget?  Guess this goes with the
> docs to other example implementations.  If not you could remove two of the
> constructors.
>
> - Rather then having setIcon and setTitle just have index 0 be the widget
> itself that you can set the text and icon. (removing four functions)
>
> - The addItem and insertItem functions could have QIcon default values. 
> Text is required, icons aren't.  This removed two more functions.
>
>    int addItem(QWidget *widget, const QString &text, const QIcon icon =
> QIcon() );
>
> - Is there a need for itemInserted() and itemRemoved() signals?  It can't
> be done from the user and looking at QToolBox I don't see those signals
> there either.

While this isn't in the current Qt implementation of QTB, I could see a use 
for this. If say the app designer wants to do a triggered action on the 
appearance of a specified item in the view of the KTB, they'd need a set of 
signals like this.

> - minor: showEvent and changeEvent (change the variable e -> event)
> - minor: "if(" -> "if ("
> - minor: don't forget to delete your private
>
> - The private slots can use the moc trip to put them in the Private class
> so when you don't want to use a toolbar internally you can remove/change
> those slots without breaking BC.  (see qtextedit.h for an example usage)
>
> At least for the API it looks pretty good and simple, need to play with an
> example to get a better feel for it and see example code usage of it.
>
> -Benjamin Meyer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060904/c17bb3b6/attachment.sig>