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

[Robert Knight]

> the simpler and less central one to this issue relates to whether layouts
> expand on their own or remain constrained to their container.

I don't understand what you are getting at here.  I am
using/implementing layouts in the same way they work in Qt.  Namely,
top-level layouts are given a geometry (usually by the widget which
owns them) and they divide that space up between their children.
Layouts and layout items do not usually resize themselves, that is
done by the parent layout, containing widget or some other actor.

> the more important one is "what is contentSize supposed to return".

There is a difference between the actual size of an applet's content,
which is whatever the applet's size was set to via setGeometry() minus
the border size versus the 'ideal' size of the content which is useful
input to the layout when deciding on sizes for its children.  When an
applet is placed on the desktop, it can simply be resized to its
sizeHint().  sizeHint() would in turn call a method ( such as
contentSizeHint() in my local build ) to determine a suitable ideal
size for the contents.

What I am after are separate methods to determine the actual size of
the content, versus the ideal size for the content.

Regards,
Robert.


On 31/08/2007, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Friday 31 August 2007, Robert Knight wrote:
> > > 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.
>
> ok, so we have a couple of issues here.
>
> the simpler and less central one to this issue relates to whether layouts
> expand on their own or remain constrained to their container. we went for
> the
> latter as it makes a number of things easier, including actually
> approximating resolution independant layouts.
>
> the more important one is "what is contentSize supposed to return". and
> indeed, it is supposed to return the actual size.
>
> the reason it defaults to the sizeHint() of the layout is that the layout
> actually fits to the size of the applet, so we can't meaningfully ask for
> its
> size.. we simply ask for the optimal size it suggests.
>
> for applets that don't use a single top-level layout, then they need to
> reimplement contentSize to do as you expect.
>
> we could make the base implementation of contentSize (which must remain
> virtual) not return layout()->sizeHint() but some other value. of course,
> what that value would be is a good question, since the layout adapts to the
> container not the other way around. personally, i think it is returning the
> correct thing given the original goal. =)
>
> anyways:
>
> > 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.
>
> this is perhaps just one more reason to s,content,applet, in the method
> names
> to make the reason for the difference clear.
>
> and really the *Content*() methods (or *Applet*() methods, as the case may
> be)
> only get used internally in Applet and reimplemented by applets that need
> to.
> it'll be a pretty hidden inconsistency. not perfection, indeed, but other
> options seems either more convoluted or simply more fragile.
>
> --
> 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
>