[Panel-devel] KDE/kdebase/workspace/plasma/lib

[Alexander Wiedenbruch]

Am Freitag, 2. März 2007 schrieb Aaron J. Seigo:
> On March 2, 2007, Alexander Wiedenbruch wrote:
> > Am Freitag, 2. März 2007 schrieb Aaron J. Seigo:
> > > On March 1, 2007, Alexander Wiedenbruch wrote:
> > > > SVN commit 638393 by wirr:
> > > >
> > > > Move the InputBox from SuperKaramba to Plasma.
> > > >
> > > >
> > > >  M  +6 -0      CMakeLists.txt
> > > >  M  +1 -1      datavisualization.h
> > > >  A             widgets (directory)
> > > >  A             widgets/lineedit.cpp   [License: GPL (v2+)]
> > > >  A             widgets/lineedit.h   [License: GPL (v2+)]
> > >
> > > this won't work; libplasma is lgpl. so either this needs to move into
> > > plasma itself, or we could just use QGraphicsTextItem, no?
> >
> > I can put it under LGPL as I am the original author.
>
> can you explain the commend just above LineEdit::paint then? either there
> is significant copying and we can't relicense it to lgpl, or there wasn't
> significant copying and that comment is wrong. i'm guessing the former.

Oh, right, I forgot about that, sorry... :/

>
> > In SK I had some problems with using different colors for the frame,
> > selected text, ... in QGraphicsTextItem so I implemented it myself.
>
> hm.. i think we can just rely on
>
> > > yes, this would mean special casing the construction of this one widget
> > > a bit; if we keep the "set the size in the ctor" feature of Widget then
> > > we could also subclass QGraphicsTextItem and provide a compatible ctor
> > > at least. ditto for the svg and pixmap items.
> >
> > If Widget will still inherit a QGraphicsItem, inheriting from both
> > QGraphicsTextItem and Widget is not good.
>
> of course; so not all the widgets used would subclass from Plasma::Widget.
> we'd use the collection from Qt and our own collection; the latter would
> have a common superclass (Plasma::Widget) that the Qt ones wouldn't. as i
> said, we'd have to special-case the creation of
>
> > > >  A             widgets/widget.cpp   [License: LGPL (v2)]
> > > >  A             widgets/widget.h   [License: LGPL (v2)]
> > >
> > > i see this implements the (pure virtual) boundingRect(). i suppose the
> > > question is whether or not makes any sense to set the size in the
> > > constructor?
> >
> > boundingRect should actually be virtual in Widget, so it can be
> > reimplemted.
>
> it is virtual in QGraphicsItem, so it's virtual in Widget as well.
>
> > My thought was that any widget needs a size, so this is
> > necessary for every widget so I put it in the ctor.
>
> the question is where that size comes from and when; e.g. does the widget
> determine it? does the object creating the widget determine it?

The creating object (API calls from script) will determine the size (e.g. 
image of different size)

>
> > > additionally, this class is missing a dptr and a setter for
> > > m_boundingBox. also, could we call it m_size since that's the parameter
> > > in the ctor?
> >
> > Not sure about a setter for m_boundingBox. Perhaps a setSize(QSizeF) is
> > better than changing the complete boundingBox?
>
> if it doesn't have a setter, does it really belong as a class member then?
>
> > > finally, everything in libplasma should be in the Plasma namespace.
> > > i've fixing Runner right now, actually.
> > >
> > > what else are you planning on implementing in Widget, if anything?
> >
> > Actually it was just an idea to have a fixed interface for all widgets.
> > Perhaps some necessary functions that need to implemented in each widget,
> > like setSize()?
>
> yes, i can see the use for such a class... it would just be good to define
> what those necessary functions are so we understand why we have it.

OK, then I remove the LineEdit, keep Widget for now and add a new LineEdit 
based just on a QGraphicsTextItem.
Are you fine with that?