[Panel-devel] Kpanel replacement -- Container much like the Dock. More.

[James Smith]

Aaron;

I read the reply, I realise this might be the wrong list, but the first one 
was sent here. I CC the -devel list to make sure this gets out prior to panel 
implementation stage. I realise you may have more plans for this, but this 
followup is directly due to aKademy being so near. It's important to get this 
out so that KDE4 ships with a lean, efficient, extendable panel by default. I 
can see possibly pushing back release in order to allow the .desktop files to 
contain .python / .ruby code for right-click and scrollwheel extensions. The 
advantages in this case much outweight the disadvantages as this is the big 
release and a little wait would seriously, seriously be better over the long 
term. A completely configureable panel out-of-box by default makes a big 
impression on the userbase, and the little tricks that one would need code 
for, for example kmix volume control via mousewheel are better off done via 
ruby or python (Kross I believe the rollup is) and not c++ for the first 
release.

Expansion:

I can envision a knotify daemon plasmoid that sits in the container and can be 
used to scroll through the notification history. This would in concept 
replace the tasktray for notifications. One icon with a middle-wheel 
scroll-through ala amarok and a single click to open up a history list. I'd 
program the osd in plasma to allow custom actions for the future, for example 
in the form of system daemon notifications. For postfix for example, a daemon 
failure could be parsed with a knotify plugin module via dbus to allow a 
daemon restart on failure or to open a terminal window displaying log 
entries. For a new instant message, the default behavior on-click would be to 
open a chat window, while for k3b a) on a disk burn failure focus k3b or b) 
on a perfect burn default would be to close the notification.

A hook could probably fairly easily link the legacy plasmoid systray holder 
through the knotify daemon to allow parsing and piping of legacy tray app 
notifications through knotify. I don't know the code or spec well enough to 
make an evaluation on that; I'm a visionary and not a programmer but that may 
change.

--
Default behaviour for the launchers would be a single-click to open an app, a 
right-click to add expanded menu entries to, for example Kontact could have 
as a right-click menu the ability to add a new contact, begin a new email 
message, add a new appointment, etc. while krdc could have a listing of past 
servers to connect to. Konsole might have a list of bookmarks on the 
right-click menu, while Konq might have a bookmark or favorite listing on 
right-click. 

Mouse-wheel scrolling by default on all launchers would be to scroll through / 
minimize the windows in question. Mouse wheel up would scroll through the 
selected windows one by one similar to a focused alt-tab. Mouse wheel down 
would minimize each window in turn to the container. KTaskbar as far as I can 
tell from use uses pids to keep track of tasks so I don't see this being an 
issue to code for at all.

When mousewheel scroll is redefined for some launchers, for example kmix, 
amarok the default behavior is to disable multiple instance launching. If a 
launcher redefines the scrollwheel behavior the default behaviour is to 
disable launching of another instance of the app. This is probably the best 
behavior for any app that's coming in from sitting in the systray as in this 
case it's always a single instance regardless. When one wants to scroll 
through these multiple instances where the wheel has been redefined one finds 
it impossible without alt-tabbing through all windows. I suppose a 
middle-click for an instance / (or window listing in the case of GIMP) 
listing per app could be implemented by default as well which would function 
similarly to the current task bar when it's loaded down with Konqueror 
windows.

On launch from Kickoff / Kmenu Plasmoid, the app slots into place in the 
container. I can't see the number of apps in KDE being an issue as we are 
talking about the entire length of the bottom of the screen. If you have many 
apps there it's not hard to see an auto-resize of the launchers when an app 
from kickoff plasmoid is inserted. I count at my icon size being able to 
insert 42(hah!) launchers and still have room for a clock.

Desktop plasmoids could additionally have two modes, the second activated by 
dropping one from the desktop into the container. For example, the desktop 
clock app could automatically resize itself when dropped into the panel 
container. An Amarok song control applet / unified media control could shrink 
to the size of the current media control applet when dropped from the desktop 
to the container.

That probably takes care of the most commonly used panel applets and again the 
reason for the wait for Kross becomes apparent. If there is a missing panel 
applet it's easy to send a user away to code their own in Kross with no 
guilt. The advantages for the code-drop are apparent. From a look through the 
code it seems to me that the project would be replacing about 5000 lines of C 
that a non-programmer can see directly to about 500 (plus kickoff port to 
plasma knotify glue) plus a handful of Kross scripting in .desktop entries.) 
The Knotify additions can probably wait as the legacy tasktray app will more 
than suffice for the meantime as apps convert.

Thanks again;

(Agent) James Smith


===============

Proposal for Kpanel replacement in Plasma...container class. 

"Taskmoids" - Plasma Elements meant specifically to be used in the panel 
replacement "container", utilizing expanded .desktop entries.

The idea is to replace the kpanel not with taskmoids alone in entirety but 
with a sort of container plasmoid or app that holds applets and can be 
maximized against without being covered. Instead of separate code for 
ksystray, ktasktray, kpanelapps and the panel itself using launch icons, we 
combine what we want of available taskmoid apps in the form of a launcher 
parsing custom per-app .desktop entries. A middle click [or single and 1 
second hold though I would honestly use a middle click and point users 
towards alt-tab with the expose-features in Compiz]brings up a menu if there 
are multiple copies of an application open, a single click either launches an 
app or brings up the window it currently resides in, and a right click menu 
can be customized based on .desktop entries. The parsing of entries should 
also dramatically lower memory use close to that of just having a launch icon 
on the panel.

I look at my tasktray and I see one of three uses. First, as a container for 
running applications, of which I have 4. Those are easily replaced with the 
above solution. The other is as a interactive widget, ie kmix / klipper type. 
Klipper I don't see as being required on the tray to begin with but that's a 
different story. The third is as a container for apps that I don't even want 
on the tray, but want use of all three as services. All three can be 
converted to daemons (as they should have been written in the first place and 
dumped from the tray entirely. )

For notifications that are currently iconic I see using Knotify + xcomposite 
with an OSD ala amarok. Fade-in, click on the knotify popup to bring up the 
app or a chat window using a socket or dbus to pass along the desired 
behavior for example, and fade out with a set length. I see the tasktray 
specification at freedesktop.org being surpassed by perhaps dbus and a 
combination of interactive elements in the near future, kde should probably 
be ahead of the ball game when that happens. The tasktray is a good standard 
but the concept is limiting in what it can achieve and on-screen popups with 
xcomposite and alternative launchers as explained here are much more fitting 
for a modern desktop. To keep up with freedesktop.org spec and older 
software, a legacy tasktray applet can be supplied.

For an app such as kmix that has interactivity I see .desktop files holding 
taskmoid code in the form of ruby/python. This would allow, say a 
volume-slider to be embedded in the .desktop file while allowing backwards 
and cross-desktop compatibility. A middle-click would launch the actual kmix 
app, and mousewheel adjusts the mixer volume.

Plasmoid apps such as a clock can be resized and replace the panel applets 
entirely. For applets that haven't been ported or never will, a plasmoid 
legacy container applet can be used.  The beauty of using 
expanded .desktop files is apparent here as you can include any right-click 
menu as plasmoid code in an existing .desktop and gnome is not even aware.

Kmenu remains as a tasmoid or even just a taskmoid wrapper via .desktop 
plasmoids. A container class can be used in a taskmoid as well, of the 
non-maximized against variety. For example, one could have a "tasktray app" 
that is basically a container for more taskmoids at the click of a single 
button. This class might be used to recreate kmenu / kickoff in the form of a 
plasmoid app, by just parsing the standard .desktop portion and leaving out 
the interactive bits.

The advantages are this:

1) Substantial code reduction. Kpanelapps, ktasktray, ksystray, kpanel, kicker 
(to a certain extent, though rewritten as a taskmoid) can all 
be dumped. Code reuse in the form of reuseable applets and the container 
concept for other panels means less to maintain and easier maintenance for 
non-programmers. Replacement applets/launchers/taskbar uses in the form of 
easily customised plasmoids parsing expanded .desktop files take 
their place. 

2) Memory use. 4 of the icons currently in my systray could easily be replaced 
with a container and expanded .desktop entries. Kmix takes 83k alone. I can't 
see it using much more than 1k as a .kdesktop plasmoid including pop-up 
volume control. Think about other apps that sit in-tray and do nothing but 
hook to other higher-level apps on mouseover or click.

I can make a mock-up but my graphical skills are not up-to-spec. If anyone 
wants one please say so.

Feedback?

J.D. Smith