[Panel-devel] Plasma panel

Aaron J. Seigo aseigo at kde.org
Sun Sep 30 17:26:11 CEST 2007


On Saturday 29 September 2007, Alex Merry wrote:
> On Saturday 29 Sep 2007, Alex Merry wrote:
> > This is an implementation of panels in Plasma.
> >
> > It uses a Containment subclass, Panel.  PanelView (which was
> > previously called Panel) attaches to a Panel and displays it.

=)

in plasma/applets/panel/panel.h you have put the Panel class in the Plasma 
namespace. it probably shouldn't be, as it isn't in libplasma. (also, you 
indented the code inside the namespace {}s, which shouldn't be, but that's a 
moot point here as the namespace should be removed =)

when creating the default panel there is:

+    const int y = desktop.screenGeometry().height() - height;

i can't remember off the top of my head if passing in -1 to screenGeometry 
gets *all* screen geometries added together or if it returns the 
screenGeometry of the default screen ... hopefully the latter ;)

in PlasmaApp you've put in a #warning. please don't unless it's actually a 
compile time issue, as it otherwise clutters up the compile output; replace 
this with a "//FIXME:" as i actually look for those when looking for things 
to fix.

now, that said, screen() should return the screen the panel is on, so yes, 
this is currently broken as implemented =) so how to identify panels ... 
(formFactor() == Plasma::Vertical || formFactor() == Plasma::Horizontal) 
should do the trick a bit better, but probably still isn't fool proof. i had 
planned on putting all panels in *negative* coorindates on the Corona, 
however, as a way to help sort this all out.

so back in the loadDefaultSetup, the y is almost certainly wrong. think of 
hiding panels: when the panel was hidden, you'd still see the panel in the 
DesktopView ;) so ... y should actually be something like this:

const int y = 0 - height;

and we will need to maintain a "stack" of panels... so in the Corona, we have 
something like this for geometry:

Panel
Panel
Panel
------------- 0 -----------
Screen 1			Screen 2			Screen 3

DesktopViews are created for each ScreenN, which correspond in size to the 
resolution of each screen. the panel objects are used to populate panels.

which means that in loadPanels one could simply check to see if y() < 0 to 
tell if it is a panel ...

the trick will be preventing users from accidently moving objects into the 
negative coordinate space themselves, but i think this is pretty easy to do, 
really (mostly by controling what the views are showing).

> > * the applets get backgrounds when the panel is reloaded from
> > plasma-appletsrc (we have no hook into addApplet from subclasses of
> > Containment in which to do this)
>
> we've solved this by making addApplet virtual in Containment

wrong place imo; this should be handled in Applet::paintWidget. a check there 
for the form factor should be made and a FormFactor appropriate background 
drawn. i've just made a commit to Applet that does this, so this should not 
be necessary anymore.

> So I have a working panel implementation sitting here.  It's almost
> identical to the one I posted, apart from the virtual addApplet.
>
> OK to commit?

yes... however, i see there is a patch there to the tasks applet which seems 
to be not directly related to the new Panel code. please commit this 
separately. (each distinct change should be committed independantly)

-- 
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
-------------- 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/20070930/f63d81a3/attachment.pgp 


More information about the Panel-devel mailing list