[Panel-devel] [PATCH] Beginnings of a panel implementation for discussion

Aaron J. Seigo aseigo at kde.org
Fri Aug 17 23:11:08 CEST 2007


On Friday 17 August 2007, Matt Broadstone wrote:
> On 8/17/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Friday 17 August 2007, Robert Knight wrote:
> > - KWindowSystem::setOnAllDesktops(winId(), true);  is of course correct
> > and not questionable at all =)
>
> Well, I put that comment there because:
> a) oddly enough (not sure if this is a bug or something) but when we
> make a QGV on all desktops memory usage jumps up to like 20%

really? hm.. .that sounds very, very not right. the QGV itself is not aware of 
the setting, only the top level window and the window manager. are you seeing 
this same jump with any window set to all desktops? and when you say "up to 
like 20%" do you mean 20% of all available RAM or 20% more RAM? and how was 
this measured?

> b) We might not necessarily *want* this panel on every desktop, though
> its probably a sensible default. This was just sort of my way of
> moving away from Kickers idea of static global panels, and to our
> ideal of a bunch of different type of panels; e.g. I might want to
> have my desktop 2 be a media player which is only displayed on the tv
> connected to my graphics card (bear with me I can already tell this is
> a cumbersome example :) but an example nonetheless).

for general panels, though, i think we want to keep to OnAllDesktops. we can 
provide (later?) for specialty panels ... one interesting problem to solve is 
having a panel on desktops 0..N except for N-1 where N>2 (as an example). 
with the "this is my media panel on this desktop" concept, we will certainly 
run into the issue where users will want their "main" panel(s) on all the 
other desktops.

> > - the really interesting thing is how to manage multiple panels on
> > screen. i suppose that will probably be left to me to figure out based on
> > my experience with kicker (it's a remarkably non-trivial problem =)
> > though i'm happy to be pleasantly surprised.
>
> Well this we need to discuss. Multiple panels where, in the same
> screen edge, on top of each other, next to each other etc. or just
> having a panel on every screen edge?

same screen edge, but not on top of each other. i think we can (and should) 
get rid of that concept. we can have multiple rows of items in the same panel 
perhaps, and if we have shaped windows we can probably do this nicely, even. 
that would sort of imply that we have multiple views stacked (we can't have, 
afaik, non-rectangular qgraphicsviews?) acting as one panel... we can leave 
that for later even, but we need to support at a minimum panels on all 4 
screen edges as "floating" (that one is easy ;) and multiple non-overlapping 
panels on the same edge. what do you think?

> > - it does need to share the main corona, as matt noted, but that can
> > wait. this is blocked by the background painters, which may sound odd at
> > first but it isn't when one considers they are the natural containers for
> > applets (and where form factors will also be moving =). this is something
> > i'm already working on, so don't worry about it too much right now. when
> > this is in svn, we can also address the hardcoded applets then
> >
> > - we need to integrate some composite manager bling here
>
> What are you referring to besides transparency? I'd have fun playing
> with this today.

cool. transparency as well as shaped windows so we can have, for instance, 
properly rounded edges =)

-- 
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/20070817/52bfa5a0/attachment.pgp 


More information about the Panel-devel mailing list