Next taskbar generation

[edscott wilson garcia]

On Mon, 2002-05-20 at 07:34, Staszyszyn, Marcin wrote:
> As a taskbar author I want to summarize here a few points of discussion,
> which has arisen on the list during last few days. This mail contains a few
> proposition of next-generation taskbar features.
> 1. enabling taskbar at compilation time in not sufficient. There must be a
> possibility of switching it on/off from setup window. My proposition is as
> follows:
> taskbar is enabled by default at compilation time, but can be completely
> removed from xfce by passing '--disable-taskbar' option to configure script.
> Therefore all binary distributions (primary rpm-based) have taskbar enabled
> by default, but all anti-taskbar xfce users are still able to have xfce
> version not polluted by this resource-wasting feature ;-). Of course if
> taskbar is enabled at compilation time, it can always be switched off from
> setup window. In that case even wide, thin button at the bottom of xfce
> panel doesn't appear.

:-)

> 
> 2. new features:
> - custom height of taskbar itself and opening button (maybe proportional to
> xfce size). It sounds good to 1600x1200 monitor users

How about being able to choose the font and having the height = ascent +
descent + margin? This would make it customizable without having to
think in pixels.


> - custom minimum size of task button (i.e. button representing a window on
> taskbar). When button must be shrunk bellow that size taskbar area is
> expanded to hold another line of task buttons. You can also set no. of those
> task button lines (like in Windows when resizing taskbar).

Good idea, as long as the minimum can go very low so that multilines
will not be forced upon users who don't want them.

> - edit pop-up menu which arises when task button is right-clicked (it's not
> present at all in current implementation). All valid xfwm events can be put
> into that menu (e.g. close, minimalise, maximalise, make [un]stick).
> - GeoShellX / KDE2 behaviour of task buttons i.e. compressing windows with
> the same name to single task button. I was not happy with that behaviour in
> KDE2, so it has to be customizable.

Disabled by default, until the user changes his/her settings, of course
;-)

> - 'window trash' -- all rarely used windows can be removed from taskbar and
> be accessible by pressing special 'trash' button, presenting pop-up list of
> all 'trashed' windows to chose from. Great possibility to save space on
> taskbar area.

Sounds like a very good idea. Which makes me think (I might be talking
through my elbow) it might replace the multiline functionality if the
user could define more groups on the fly and have them persist from
session to session. 

> 
> 3. taskbar state must be saved between sessions
> 
> What do you think of that?

There might be one more thing, but it might be too hard or not enough
demand for the feature. I can run several instances of the xfce panel on
one display but on different boxes. By using the xfgnome module, any one
of the panels works to switch desktops. But only the taskbar that runs
on the same box as xfwm has any entries. It would be neat to be able to
use any instance of the taskbar for all tasks on the display. Maybe this
can be done with xfgnome, maybe not...

Edscott