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

[Robert Knight]

> so contentSize is mis-named because ... it returns the size of the contents?

Let me try to clarify.  Items in a layout have an actual size and an
'ideal' size.  The actual size is returned by geometry().size() (
QWidget also provides a size() method ).  The 'ideal' size is that
returned by sizeHint() may differ from the actual size if there is not
enough space available or excess space.

The name 'contentSize()' implies that it returns the actual size of
the contents, however the current implementation returns an ideal size
(or 'size hint' in Qt terminology), which might not be the same as the
actual size of the contents when the applet is used in a layout.

What I did temporarily to make things work is to make contentSize()
non-virtual and add a virtual 'contentSizeHint()' method to allow the
applets to provide a hint as to what size they would like their
content to be - and the logical extension of this is to add
minimumContentSize() , maximumContentSize() etc. methods as you
suggest.  This however makes the API inconsistent as you would use
minimumContentSize() , maximumContentSize() in the main Applet class
and then minimumSize() , maximumSize() , sizeHint() etc. in the
applet's child widgets.

I'd have to talk to the Trolls, but I also wonder whether such a
change might make the migration to Qt's own layout classes easier when
Qt 4.4 comes around.

> 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.

That is a fair comment.  Although the constructor might be useful as a
place to set properties of the applet or widget.  This code could be
wrapped up in a macro, but (2) would still seem the better option if
there is a way to provide an eg. shell() method which provided access
to the Applet shell for the widget to manipulate.

> the solutions presented here would result in a huge amount of work on existing
> applets

My gut feeling is that the changes could be done pretty quickly, I
could have a go in a separate branch perhaps?


On 31/08/2007, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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
>