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

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

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

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

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

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- 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/20070302/0b880834/attachment.pgp