RFC: KToolBox

[Matt Broadstone]

On 9/3/06, Benjamin Meyer <ben at meyerhome.net> 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
>
I was going to put it into playground but apparently neither of our
playgrounds are cmake-ready yet so I just placed it in
branches/work/ktoolbox. Perhaps we should get the
branches/work/kde4/playground cmakeified?


> 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)
>
Do you have any examples of this? I was going to add that
functionality, but ran out of time on my day off :)

> - There are no docs or autotests
Yes this is obvious, it's in a beta stage so these will obviously be
worked out soon enough.


> API:
>
> - use Q_SIGNALS and Q_SLOTS
OK.

> - 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.
I would like the keep these, at least in the projects I'm currently
using the widget in it's very nice to have a title.

> - 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)
>
I think thats not so good an idea.. very confusing to the user, a
setTitle and setIcon, as opposed to setItemTitle setItemIcon makes for
very clear API.. I actually find it very confusing when making a
QTreeWidget or something of the sort where there is no clear head item
- too much abstraction.

> - The addItem and insertItem functions could have QIcon default values.  Text
> is required, icons aren't.  This removed two more functions.
>
Hrm, is text really required either? You could have a bare widget
theoretically...

>    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.
Yes these aren't really needed, there are two protected funtions for
this in QTB I figured I'd move them over - but I agree.

>
> - minor: showEvent and changeEvent (change the variable e -> event)
> - minor: "if(" -> "if ("
> - minor: don't forget to delete your private
check, check, check

>
> - 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)
Will take a look at this (though Qt generally handles this by having
q_func, are you sure its different in QTE?) I had originally made the
Private class a QObject so I could just link it there, maybe thats the
way to go.

> 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.
>
Well of course it is! It _is_ a Qt API after all, I only wanted to
make it look prettier :)


As for the QPL stuff, can someone speak to that? Is it enough to throw
a GPL license on it as opposed to the LGPL I threw on at the last
minute.. I'm not really interested in  personal ownership of the code
as much as I am getting it out there and useable and I am somewhat
unfamiliar with what is possible under the GPL (I read it a little bit
earlier but couldn't get a clear picture of what happens in this
case).

Cheers,
    Matt