[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