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 look.
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 freedesktop.org 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 flexible). 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 manager. 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 buttons. 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 manager. 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. -Todd _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
