[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Panel-devel] [PATCH] Beginnings of a panel implementation for
From:       "Matt Broadstone" <mbroadst () gmail ! com>
Date:       2007-08-17 18:35:42
Message-ID: 621909c70708171135n2784e84bmd3d4d2ff808e07d1 () mail ! gmail ! com
[Download RAW message or body]

On 8/17/07, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Friday 17 August 2007, Robert Knight wrote:
> > This is mainly here to discuss the API for the Panel class and so that
> > we can put something together for the applet developers to test with.
>
> there are many issues with this code as it stands, but i'm fine with using it
> as a start. issues, in no particular order, none of which imho block you
> putting this into svn as a draft right now:
>
> - the dptr in Panel needs to be const'd
>
> - can you put it under the "LGPLv2 or later" please? thanks....
>
> - 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%
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).

> - style guide is not followed consistently (some day soon someone is going to
> poison my food or something for being such a grump about that ;)
OK ok, guilty again - but it *was* a spike

> - why another layout instead of just using HBoxLayout for horizontal panels
> and VBoxLayout for verticals? i suppose this is a property of using its own
> Corona at the moment.

> - 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?

> - 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.

> - size, position setting/loading also needs to be set up, but i have ideas
> there as well and this can wait for a week or two..
>
> thanks for getting this ball rolling.
>
> --
> 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
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel@kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>
>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]