[Panel-devel] Unofficial Meeting notes : Panel Meeting

Siraj Razick sirajr at gmail.com
Sat Oct 27 05:26:07 CEST 2007 

Following includes the Gobby Notes.

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Plasma Meeting of the 24th October 2007
Scope of this meeting: "get panels done in the right way"


---- Attendees ----

* sebas (Sebastian Kügler)
* ruphy (Riccardo Iaconelli)
* aseigo (Aaron J. Seigo)
* ereslibre (Rafael Fernández López)
* robertknight (Robert Knight)
* dani_l (Daniel Laidig)
* siraj (Siraj Razick)
* beineri (Stephan Binner)
* fred84 (Andrea)
* frerich (Frerich Raabe)
* koos (Koos Vriezen)
* annma (Anne-Marie Mahfouf)
* spstarr (Shawn P. Starr)
* nefertum (Jon de Andres)
* dirk (Dirk Müller)
* Pinheiro (Nuno Pinheiro)
* darktears (Menard Alexis)
* teprrr (Teemu Rytilahti)



---- Agenda ----

1. General technical discussion about layouts and the problems we have in that.
 1.1 Put here all the problems that do not need an advanced understanding of the
     concepts for the panel

2. Ideas for the panel, what should it be (visually) and how should it behave
 Options:
	1.) Nunos mockups [1] (Ruled out for KDE)
	2.) KDE3 like Kicker look [2] (missing plasmoid: showdesktop)
	3.) Slicker like Kicker [3]
	4.) Dock like Kicker (e.g. KSmoothDock [4]/KoolDock [5]/kxDocker [6])
	5.) Proceed with the current panel and make it look like [7]


 2.1 Default arrangements of the items on the panel
 	1.) Kmenu button
 	2.) System tray
 	3.) Taskbar
 	4.) Desktop switcher
 	5.) Default buttons (show or expose desktop, Quick Launcher buttons)
 	6.) Clock
 	7.) Possibly trashcan? Ubuntu/Kubuntu/OSX like.
 	8.) Possibly lock/lockout plasmoid? openSUSE like :-)
 2.3 Default sizes of panel elements
 	1.) Icon size
 	2.) System tray size
 	3.) Taskbar size
 	4.) Desktop switcher size
 	5.) Panel size
 2.4 Extra features
 	1.) Panel Transparency: we will only support True Transparency?
 	2.) Panel Show/Hide Effects
 2.5. Discussion on those ideas

3. Alternative plans on providing desktop & panel for KDE 4.0 in case of
   technical difficulties while implementing discussed features ('Plan B').
   * An option would be to do a "classic" option by porting the KDE 3.5
     kicker/kdesktop
     - Disadvantage: cannot live in kdebase due to dependency issues
     It'd probably technically feasible to embed Plasma applets into Kicker
     applets (by having a KPanelApplet which embeds a QGraphicsView)

     Who writes the code? who wants to maintain it for 4.0.x and beyond?
     I (Frerich) would look into it. I suppose it would only need to live until
     whatever technical issues exist are solved.


4. Technical decisions to implement the panel
 4.1 Adapt to resolution changes
   * The panel should react sanely to resolution changes, i.e. stay at
the bottom,
     keep full-width, stay centered/right, for example
 4.2 Hiding
 	4.2.1 Sliding
 			- improve it with more frames and a slown effect at the end of sliding
 	4.2.2 Fading
 	4.2.3 Zooming
 4.3 Resizing
 4.4 Positioning (left/right/center; screen edge; multiple panels on same edge)
 4.4 Adding new panels and removing existing panels
 4.5 Panel Theming: belongs in the PanelContainment (plasma/containments/panel)
 4.6 Kiosk Mode: handled in the containments and applets (and already
implemented)

5. Implementation tricks and niceties
 5.1 How to handle Mac OS X style menu bar Option And the Desktop Menu
which we had on KDE3
 	aseigo: A special top level view (in plasma) for it that embeds the
menu widget and then shows 2 small panel containments, one to each
side
 5.2 Multiple panel types ala kicker
 	aseigo: PanelContainment + Applets suffice; anything more can use
specialized containments

6. Outstanding topics unrelated to panel implementation
 6.1 Zooming in/out in ZUI
 6.2 Merge panels?
 6.3 Should the panel look the same on all Desktops?
     - Different Panel Backgrounds : Gives a good visual clue to which
Desktop you are in
      - How about keeping the same panel outfit, but just changing the
background image?
          - Or how about having different season desktops with foliage
or snow on,
            early flower before and sune shine on the icons (just joking :-)
            - If it's already possible to create different (pluggable,
something Zack
              demonstrated with OGL at Akademy this year) background
painters, go for it ;-)

 6.4 Hover interface for applets giving access to close, configure, move
 6.5 Notification Interface
 	-actually one applet inform user about the new device added to the system.
 	 By clicking on it you can launch solid ui server (old media notifier).
 	 Where we can put this applet/area of notification?
 6.6 Applets to Panel: What space is given for each applet on panel
         minimal/maximum size, expanding or not


---- Notes ----

We agreed that the following features are showstoppers for panels to
have in 4.0:
- Support multiple sizes
- "drag and reposition"
- Display resolution independence
- D&D for applets on the panel and from the desktop or vice versa
- Be able to remove plasmoids (manyoso was working on that until he disappeared)

Aaron suggested that the "show desktop" action, which will be a plasmoid,
should cause an on-top, full screen, translucent window to show with a QGV
displaying that screen's DesktopContainment. That's for a dashboard-like effect.
- something like that? [8]
 - that shows widgets floating over desktop icons/launchers though where Plasma
   has no such differention, or?

--- Aaron's conclude-this-meeting-in-a-dictatorial-this-is-what-i'm-going-to-friggin'-do
rant ---
[13:57] <aseigo> a) we need a coorindator algo in Corona to manage the
PanelContaiments
[13:57] <aseigo> (a) will accomplish the following things:
[13:58] <aseigo> - it will solve the larger part of the
react-to-resolution-changes issue
[13:58] <aseigo> - it will allow us to have multiple panels
[13:58] <aseigo> (i love how we were all talking about panels this and
panels that and nobody stopped to note that we don't even support more
than one panel right now ;)
[13:58] <richmoore4> or floating panels
[13:58] <aseigo> - panels must conform to one screen in xinerama, no
screen-spanning panels
[13:58] <aseigo> richmoore4: indeed
[13:59] <aseigo> ok, that's simple enough
[13:59] <aseigo> b) resolution reaction, finishing the problem out
[13:59] <aseigo> - we need to store positions of Containments that are
aligned to screen extents as such.. e.g. if a panel spans an entire
side of a screen or is positioned "at the bottom" of a screen it
should not use pixel coordinates for that
[14:00] <aseigo> - we need some code to react to randr notifications
that triggers the coordinator code in Corona from (a) to re-jigthings
[14:00] <aseigo> c) we need a way to manage the top level windows
[14:00] <aseigo> - frederikh is going to provide a
ARGB-with-input-masks demo app which we can evaluate for use in the
situation we have a composition manager
[14:01] <aseigo> - someone needs to work on the fallback position,
which will end up defaulting to me unless someone beats me to it
[14:01] <aseigo> d) we need a PanelLayout that does cooperate
freespace negotiation between applets as i outlined on the mailing
list
[14:01] <aseigo> those things, a-d will get us:
[14:01] <aseigo> panels.
[14:01] <aseigo> THEN we can talk about things like themeing and
defaults and hiding and other shit
[14:01] <aseigo> why?
[14:02] <aseigo> because HOW we implement, for instance, hiding
depends on the anser from (c)
[14:02] <aseigo> so ... *i* will start working on (a) immediately
[14:02] <aseigo> i will then start working on (d)
[14:02] <ruphy> ok, apart from that, there's a pinheiro idea which
will may affect the way panels are done... the idea that applets are
made by applets that glow toghether
[14:02] <aseigo> i would then like to go back to the toolbox
[14:03] <aseigo> ruphy: which is fundamentally not going to happen in
a non-composited environment and/or not without window manager
cooperation
[14:03] <aseigo> ruphy: so no, there is nothing to talk about there.
not until we have the basic mechanics in place.
[14:03] <ruphy> aseigo: ok, fine by me
[14:03] <aseigo> those basic mechanics are not affected by how we
present these things
[14:03] <aseigo> other than when we don't have a coposited
environment, we *can't* do things like applets-clicking-together


---- References ----

[1] http://www.nuno-icons.com/images/estilo/image2476.png
[2] http://www.kde.org/screenshots/images/3.4/snapshot05.png
[3] http://www.slicker.org/setup/modules/gallery/fop/images/slicklarge.jpg
[4] http://kde-apps.org/content/show.php/KSmoothDock?content=6585
[5] http://kde-apps.org/content/show.php/kooldock?content=50910
[6] http://kde-apps.org/content/show.php?content=10958
[7] http://ktown.kde.org/~fredrik/tasks4.png
[8] http://rzserv2.fhnon.de/~lg017420/images/dashboard.jpg

More information about the Panel-devel mailing list