[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