Re: Thumbnail buttons and actions
On Thursday 03 February 2011, Aaron J. Seigo wrote: > On Thursday, February 3, 2011, Marco Martin wrote: > > * this would look sexy > > * would show explicitly a "way out of the browser" > > * would mark a "prototype" on how a full desktop application could look > > without painting limitations qwidgets now have > > * enough? ;) > > this would be truly awesome; merging QML plasmoids and seklie is brilliant. > > should we add this to our 2011 roadmap? sure thing, just did. > if so, target 4.7 or 4.8? depends on the work force that can be found, and if selkie wants to have a release for 4.7 i would go for a proof of concept in time for 4.7 ( basic support in the application *seems* quite easy?) full usable thing, at least for a single site for 4.8 Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, Marco Martin wrote: > * this would look sexy > * would show explicitly a "way out of the browser" > * would mark a "prototype" on how a full desktop application could look > without painting limitations qwidgets now have > * enough? ;) this would be truly awesome; merging QML plasmoids and seklie is brilliant. should we add this to our 2011 roadmap? if so, target 4.7 or 4.8? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011, Martin Gräßlin wrote: > On Thursday 03 February 2011 18:47:01 Aaron J. Seigo wrote: > > On Thursday, February 3, 2011, Martin Gräßlin wrote: > > > On Thursday 03 February 2011 16:51:34 todd rme wrote: > > > > or tab lists on web browsers. > > > > > > Just as a note: I'm working on that together with rekonq developers > > > (see complete thread [1]). I expect to start the kwin side of the > > > implementation after shadow rework. > > > > apps being able to expose tabs in windows would be great. +1 to that. > > > > (as for apps, i still wish we had a completed silky; sebas: we should do > > some project dev and promo around it and see if we can't get some new > > developers plonking away on it!) > > +100 to that. I would rather like to see an awesome selkie and a proper > solution to the web problem, than sticking to the broken one app as > container for many app concept. > > So exposing the tabs is for me just a short term solution on the road to > silk. if marketed well, it could attract quite some people. i envision a selkie done quite like: * the web widget using just the main site web page as now * web apps distributed in packages, with configs, icons for the services, javascript/css snippets to unscrew the site itsef, hiding parts, whatever... * extra toolbars ..and this more or less is present in selkie in it current for, i think? there is where the neat comes. as Nuno briefly mentioned, the other day we were having a nice chat about how the look and stilyng of our current destop applications is not enough(tm) anymore, but to be technically possible to move to a better thing a quite long roadmap is needed. in the selkie package, distribute also qml plasmoids (with eventual services/dataengines, all in js) and will a) nice a set of desktop plasmoids related to that service, but... b) those plamoids can provide ui for selkie itself, as we are doing our "device specific" profiles for qml plasmoids, there could be a profile for selkie too, so for instance the application could give also tabs with a qml based ui for the service but in a bigger window, so would become alsmost a full application (maybe styled in a semi natie widget style) using the native html ui, will become just the last resort (in another tab?) when a better ui isn't available. * this would look sexy * would show explicitly a "way out of the browser" * would mark a "prototype" on how a full desktop application could look without painting limitations qwidgets now have * enough? ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, todd rme wrote: > But how does the visualization know how to arrange things? metadata. if there isn't enough metadata or the right sort, we add it. > Also, there is the issue with passing pixmaps. this is already available in the spec :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thu, Feb 3, 2011 at 1:25 PM, Aaron J. Seigo wrote: > On Thursday, February 3, 2011, todd rme wrote: >> On Thu, Feb 3, 2011 at 1:04 PM, Marco Martin wrote: >> > On Thursday 03 February 2011, Aaron J. Seigo wrote: >> >> On Thursday, February 3, 2011, todd rme wrote: >> >> > 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 this be done with the status notifier spec? >> > >> > sounds to me like a set of action associated to an item... so yes ;) >> > >> > Cheers, >> > Marco Martin >> >> Does the spec have hints for locations, the ability to pass sets of >> significant-sized pixmaps with the ability to click on them, >> categories the tool displaying them can use as cues, and the other >> parts necessary to display, organize, and format the buttons around >> the edge of a 2D block? > > answer: you don't want application developers doing that. > > it assumes a 2D block. what happens when we change that? > it assumes app devs know where to position things: they don't. > > :) > > on the app side always set metadata, enough so the rendering app can decide > how to sort it out. > > on the visualization side, do the arranging. But how does the visualization know how to arrange things? Also, there is the issue with passing pixmaps. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, todd rme wrote: > On Thu, Feb 3, 2011 at 1:04 PM, Marco Martin wrote: > > On Thursday 03 February 2011, Aaron J. Seigo wrote: > >> On Thursday, February 3, 2011, todd rme wrote: > >> > 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 this be done with the status notifier spec? > > > > sounds to me like a set of action associated to an item... so yes ;) > > > > Cheers, > > Marco Martin > > Does the spec have hints for locations, the ability to pass sets of > significant-sized pixmaps with the ability to click on them, > categories the tool displaying them can use as cues, and the other > parts necessary to display, organize, and format the buttons around > the edge of a 2D block? answer: you don't want application developers doing that. it assumes a 2D block. what happens when we change that? it assumes app devs know where to position things: they don't. :) on the app side always set metadata, enough so the rendering app can decide how to sort it out. on the visualization side, do the arranging. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thu, Feb 3, 2011 at 1:04 PM, Marco Martin wrote: > On Thursday 03 February 2011, Aaron J. Seigo wrote: >> On Thursday, February 3, 2011, todd rme wrote: >> > 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 this be done with the status notifier spec? > > sounds to me like a set of action associated to an item... so yes ;) > > Cheers, > Marco Martin Does the spec have hints for locations, the ability to pass sets of significant-sized pixmaps with the ability to click on them, categories the tool displaying them can use as cues, and the other parts necessary to display, organize, and format the buttons around the edge of a 2D block? -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011, Aaron J. Seigo wrote: > On Thursday, February 3, 2011, todd rme wrote: > > 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 this be done with the status notifier spec? sounds to me like a set of action associated to an item... so yes ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011 18:47:01 Aaron J. Seigo wrote: > On Thursday, February 3, 2011, Martin Gräßlin wrote: > > On Thursday 03 February 2011 16:51:34 todd rme wrote: > > > or tab lists on web browsers. > > > > Just as a note: I'm working on that together with rekonq developers (see > > complete thread [1]). I expect to start the kwin side of the > > implementation after shadow rework. > > apps being able to expose tabs in windows would be great. +1 to that. > > (as for apps, i still wish we had a completed silky; sebas: we should do > some project dev and promo around it and see if we can't get some new > developers plonking away on it!) +100 to that. I would rather like to see an awesome selkie and a proper solution to the web problem, than sticking to the broken one app as container for many app concept. So exposing the tabs is for me just a short term solution on the road to silk. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thu, Feb 3, 2011 at 12:47 PM, Aaron J. Seigo wrote: > On Thursday, February 3, 2011, todd rme wrote: >> 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 this be done with the status notifier spec? I don't know. As I said, I don't have any technical knowledge of that spec. That is why I said this could use this spec, or be an extension to it, or be an entirely new spec. I don't know enough to know the relative merits of any of these approaches to recommend one over the others. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, todd rme wrote: > 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 this be done with the status notifier spec? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, Martin Gräßlin wrote: > On Thursday 03 February 2011 16:51:34 todd rme wrote: > > or tab lists on web browsers. > > Just as a note: I'm working on that together with rekonq developers (see > complete thread [1]). I expect to start the kwin side of the implementation > after shadow rework. apps being able to expose tabs in windows would be great. +1 to that. (as for apps, i still wish we had a completed silky; sebas: we should do some project dev and promo around it and see if we can't get some new developers plonking away on it!) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011 16:51:34 todd rme wrote: > or tab lists on web browsers. Just as a note: I'm working on that together with rekonq developers (see complete thread [1]). I expect to start the kwin side of the implementation after shadow rework. Cheers Martin [1]: http://mail.kde.org/pipermail/rekonq/2011-January/002316.html signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Thumbnail buttons and actions
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
