Thumbnail buttons and actions

todd rme toddrme2178 at
Thu Feb 3 16:51:34 CET 2011

One feature I think would be useful would be if applications were able
to add buttons to their thumbnails in the task manager.  Use cases
could include play and pause buttons on media players, or tab lists on
web browsers.  I got what I interpreted as positive feedback when I
mentioned this earlier, so I thought it warranted a more detailed

So far I have seen two major proposals about how to implement this:
applications can use plasma widgets as their thumbnails, or a
dbus-based system similar to (or added to) the system tray spec.  I
think the former is not a good idea because it is KDE-exclusive, which
discouraged use by non-KDE applications.  I will use the latter
proposal, then.  Whether it is a new spec or an extension to an
existing spec if beyond my technical knowledge, as is specific
implementation details, so I my discussion will unfortunately be
somewhat superficial.  Nevertheless, I hope it will be helpful for
getting some forward movement on this.

For this idea, the issue is that there are a lot of ways that these
sorts of interfaces could be represented.  That is why you will see a
lot of "hints".  These hints are provided by either the application or
the task manager (or whatever is displaying the buttons), but the one
receiving the hints can choose to ignore them.

I also wanted to keep in mind some earlier proposals for a dbus-based
system for putting buttons in the title bar.  Whether that is a good
idea or not, I think that could also be a potential implementation of
this spec, which is another reason why the use of "hints".  However,
since the current focus is on task managers, I will refer to that
exclusively from now on.  You can replace "task manager" with anything
else that might want to display the buttons.

The most basic element is a button.  Buttons are provided the
application, and displayed by the task manager.  The button has a
number of properties.  The application can send properties to existing
buttons, which replace the existing property, as well as send orders
to add or remove buttons.

1. Icon hint.  The icon hint not a picture, it simply an icon name
from the icon naming spec.  The icon theme used would
be up to the task manager, and the task manager could potentially
override certain buttons and replace them with others (I am not sure
why it would want to, but since it is just a name this would be
possible).  This could also be a list of icon names, which would lead
to a button that cycles through the icons on each click (such as a
play/pause button, but making it an arbitrary-length list is more

2. Button text hint.  How the text is handled is once again up to the
task manager.  It could be a mouse-over text or displayed permanently
somewhere near the button.  This could also be a list with the same
number of text strings as the icon list.  The text can be html
formatted, but task managers can choose to ignore the formatting.

3. Button state hint.  This is either enabled or disabled.  How the
button state is indicated by the task manager, if at all, is once
again up to it.  This would probably be a bool.

4. Button location hint.  This is either N, S, E, W, NW, SW, NE, or
SE, with N being the north (top) edge, E being the east (right) edge,
NE being the north-east (top-right) corner, and so on.  The hint tells
where the button should be located.  Exactly how to interpret the
location hint, or whether to ignore it completely, depends on task
manager.  This would probably be an enum or integer corresponding to
each state.

5. Button order hint.  This is used to determine the order of the
buttons at a given location.  The smaller the value (it would be a
signed int), the further to the left it would be.  So for instance if
you could give the back button a value of -10, the play button a value
of 0, the next button a value of 10, and put them all at the S
location, you would have back, play, then forward (in that order)
along the bottom edge.  The task manager could re-interpret this (for
instance reversing it for right-to-left languages) or ignore it
entirely.  The reason for using signed ints is to make it easier to
add and remove buttons while maintaining a desired ordering.  How to
handle orders at a corner, for instance, would also be up to the task

6. Button type.  I will discuss this below, but I want to point out
that the type is a property of the button, since some implementations
might want to display different button types differently, and some
might not want to display certain button types at all.

Buttons types fall into three categories:

1. Action buttons.  Basic buttons.  They send both click and release
signals back to the application.  Examples include play and pause
2. Menu buttons. These popup a menu.  They send a request to the
application, which provides a list of items for a menu, and then the
resulting item is sent back.  The menu would probably be based on how
it is down for the system tray spec.
3. Pixmap buttons.  This sends a signal that it is clicked to the
application, which then sends a single pixmap.  The pixmap size is a
hint provided by the task manager, but the application can ignore it
and the task manager has to be able to deal with that.  How the pixmap
is displayed is up to the task manager.  This could be use, for
instance, for switching to the next tab and showing the contents of
that tab.  It also sends a release signal to the application.
4. Pixmap set. This sends a signal that it is click to the
application.  The application then sends a list of pixmaps.  The user
can click on one of the pixmaps, and which pixmap is clicked is then
sent to the application as well.  One pixmap can also be marked as
priority status, although this is optional.  There is also a pixmap
size hint here (only one), a pixmap count hint (i.e. the maximum
number of pixmaps the task manager wants), but once again these can be
ignored by the application and the task manager has to be able to deal
with that.  A good example is showing a list of open tabs, with the
current tab being the one with the priority status.  Each pixmap can
also be optionally associated with a label.  It might be good if the
pixmaps were able to have buttons as well (using the same pattern),
but this may be getting too complicated.

I think these would cover most situations I can think of.  Hopefully
it is clear how this could be used by a task manager to put useful
buttons on thumbnails.  However, task managers could also use it to
put buttons right on the task, it could be used by window managers to
put icons on the window title, and so on.  Perhaps dealing with these
situations more explicitly might be good, but hopefully the spec is
general enough that different implementations can make good use of it
without needing any additional information.

Other possible properties I can think of that might be useful but
don't seem critical:

1. A linear location hint: used when there is linear layout, it only
has left, right, and center values (enums or ints).  This would be
used in the title bar or in a task manager that includes buttons in
the tasks
2. A priority indicator: This tells how important the button is.  If
the implementation does not have enough space, it will use this to
figure out which buttons to use.  This would probably be an signed
float, with anything less than zero being considered "low-priority"
buttons that are not used unless there is a lot of space, or could be
displayed in a pop-up interface.
3. A size hint: a float between 0 and 1 (including 1 but not including
0).  This is used to shrink the button relative to the normal button
size as determined by the task manager.  So a button with a value less
than 1 will appear smaller than the other buttons.  How to interpret
this is, or whether to use it at all, is once again up to the task
4. Primary menu: this is a menu you get on right-click either on a
blink area of the task or a blank area of the thumbnail.  The task
manager could add its own entries to this as well, so it would be more
of a supplement for the normal task manager menu.

This is just a strawman, please tear into it viciously.


More information about the Plasma-devel mailing list