[Panel-devel] Separate QGraphicsItems for applet border/background and content?

[Aaron J. Seigo]

On Friday 31 August 2007, Robert Knight wrote:
> When working on the tasks and clock applet this past week  to make it
> possible to use them in the panel layout I ran into a problem that the
> applets cannot provide useful implementations of sizeHint() ,
> minimumSize() and maximumSize() because they don't know about the
> applet's borders.

shouldn't those be based on contentSize() and if needed we can add 
minimumContentSize() and maximumContentSize()? 

maybe we should change "content" to "applet" to avoid future confusion? 
appletSize(), minimumAppletSize(), etc...?

> There is a contentSize() method which is mis-named, because the
> existing implementations return a size hint for the contents which
> might be different from the actual applet size.

so contentSize is mis-named because ... it returns the size of the contents? 
perhaps the issue is the word "contents", which currently refers to, well, 
the contents of the applet versus the stuff that plasma puts around those 
contents.

> I suggest using a design like QMainWindow where the applet consists of
> an outer 'shell' which renders the border and background and handles
> input events to the border area, and a central Widget which fills the
> entire content area of the applet.  This allows the central widget
> which displays the content of interest to have its own sizeHint(),
> minimumSize() , maximumSize() , expandingDirections() etc.  The applet
> shell then provides its own sizeHint() , minimumSize() etc..

this gains us an extra object and another item on the canvas that needs to be 
managed with the nearly identical pattern in the actual code. i'm not sold, 
yet =)

> This should also fix problems where the content area of an applet
> needs to re-implement some input handing event (eg. mouse handling)
> and then forgets to call the base implementation which would break
> input handling in the border area.

this is a good reason, however it holds true whether or not we have the border 
as there are (or will be) cases where we want to do things on events such as 
hover of the applet.

> This would also simplify the painting of applets and 

the painting would still happen somewhere, we'd just get rid of the use of 
negative numbers. not a huge win in my book.

> remove the need for the paintInterface() method.

no it wouldn't because we still need to be able to override painting in cases 
such as zooming, failure to load or when needing first configuration.

> There are different ways in which the API could work, some ideas:
>
> 1.  Each applet library provides a sub-class of Applet (as it does
> now) which is the main exported plugin class.  This sub-class would
> become very small and most of the code would be transferred to a
> Widget class which is not exported.  In the applet's constructor,
> there would be something like this:
>
> MyApplet::MyApplet(QObject *parent , const QVariantList& args)
>
> : Plasma::Applet(parent,args)
>
> {
>    ClockWidget *widget = new ClockWidget(this,args);
>    setCentralWidget(widget);
> }

so ... we shuffle code between Applet and a custom Plasma::Widget that every 
applet needs to make, with every applet duplicating the above lines of code 
probably nearly verbatim. i don't like this approach.

> 2.  Each applet library just provides the central widget class and the
> Plasma library loads this and creates an Applet shell into which the
> central widget is placed. 

at first this sounds sane. however:

> There is a question then of how the applet 
> could control properties of the shell, such as turning the standard
> background and border on or off.

which is why i don't like the seperate QGraphicsItem approach.

i really don't see the problem you are trying to solve, at least not one that 
isn't easily solvable by adding to the contentSize() (or appletSize() if you 
prefer) pattern.

the solutions presented here would result in a huge amount of work on existing 
applets and gain very little as far as i can see in terms of actual benefit. 
what am i missing here?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- 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/panel-devel/attachments/20070831/adac1974/attachment.pgp