[Panel-devel] applet and data engine "management"

[Aaron J. Seigo]

On Friday 25 May 2007, Matt Williams wrote:
> On Friday 25 May 2007 02:20:37 Aaron J. Seigo wrote:
> > On Thursday 24 May 2007, Matt Williams wrote:
> > > On Friday 25 May 2007 00:07:35 Aaron J. Seigo wrote:
> > > >...
> > > >  - Applets, on the other hand, are managed by the container that
> > > > displays them. there is no additional management that goes on, so all
> > > > we need are a couple of static factories. additionally, some of the
> > > > data must be global to work properly; specifically, the appletID
> > > > which should be globally unique.
> > >
> > > That 'container' being the QGraphicsScene and therefore the Desktop
> > > class? So the Desktop is in a way the AppletManager?
> >
> > right, for geometry and grouping. and of course panels will also be made
> > of a Desktop widget. which is .. counterintuitive =) i need a new name
> > for that class.
>
> So we'll have one RootWidget loaded at any time (ignoring multi-head for
> now) and that will be controlling any number of "Desktop"s. Each of
> these "Desktop"s will be displaying something different, say one will be
> acting as the panel, another as the traditional desktop layer and so on.

not quite. there is one RootWidget and it contains a Desktop, er.. View (going 
with your name idea below). and within that View there are 1 or more groups 
of QGraphicsItems (e.g. plasmoids, layouts and groups); at any given time 
there are (at least?) two different possible states the view is in:

0) showing one of these groups full screen (someone suggest the word "Form" 
the other day, but i'm not sure i like that either.. "Sheet"?) 

1) zoomed out showing all of the groups/forms/sheets  for the user to select 
from, bringing us back to 0. in state (1) the groups would not paint all the 
items, but rather simply pain a nice shape with a text label (colour and even 
perhaps shape could be configurable by the user for even quicker 
identification)

we may end up with more states in the future, but the above two are what i'm 
going for right now.

> Would it then make sense to rename "Desktop" to something
> like "PlasmaViewBase" (since it is, in fact, just a QGraphicsView), give it

if this moves to libplasma (hopefully not =) then it would become Plasma::View 
i think; if it stays inside of plasma itself (hopefully) then just View 
should be fine if we don't subclass, or AbstractView if we do. (Abstract* is 
the new *Base in kde4 apparently)

> virtual functions for loading applets and then derive special cases from
> this for e.g. the Desktop or the Panel. All these base classes will do is
> handle their geometry differently (the panel will be mostly linear for
> example) and different rules for applet placement and Form handling.

i'm not even sure we will need to derive subclasses here. it may be enough to 
have one competent canvas with different layouts instantiated within and 
advertising the form factor to the applets (horizontal, vertical, planar). 
but yes, worst case is we have a couple of subclasses. hopefully not though 
=)

> class PlasmaViewBase : public QGraphicsView
> {
>     Q_OBJECT
>     public:
>         PlasmaViewBase(QWidget* parent);
>         ~PlasmaViewBase();
>
>     public Q_SLOTS:
>         virtual void addPlasmoid(const QString& name);
>         <et cetera>
> };
>
> class Desktop : public PlasmaViewBase
> {
>     Q_OBJECT
>     public:
>         Desktop(QWidget* parent);
>         ~Desktop();
>
>     public Q_SLOTS:
>         void addPlasmoid(const QString& name); //reimplemented here to
> allow placement rules etc. <et cetera>
> };
>
> class Panel : public PlasmaViewBase
> {
>     <Same again...>
> };
>
> Or do we not want to be creating special cases for Panels or Desktops?

that would be the ultimate achievement, yes. if need be we can go the subclass 
route, but i'm really wary of large inheritence trees. things tend to get 
confusing and brittle when that happens.

> Rather to treat them identically? If so, Simply renaming "Desktop" to
> "PlasmaView" would clear things up a bit?

yes, i think so. 

-- 
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/20070525/89aba9a8/attachment.pgp