Given we are rewriting some of the plasmoids, if you have any design ideas on how the plasmoids which are being ported should look or behave now is the perfect time to share it. Design comments as we are rewriting something will have most influence.

There are a lot of more or less powerful tools in this package. Do you want input on a general basis, for instance the idea to discriminate between taskbar and desktop only plasmoids (just brainstorming), or detailed input on a particular tool like the systemloadviewer (I'm using it, and it could be improved on some aspects)?

Thank you for the heads-up, David! Now is the time for us to define a unified design language for Plasmoids!

We now have a set of layout guidelines for Plasmoids within the general layout guidelines, so the first thing to do would be to make sure all new Plasmoid UIs conform with those guidelines.They should be checked with all other HIGs which apply as well, of course.

Also if there is a collective desire to see more or clearer guidelines than colomar already highlighted in the layout guidelines that might help produce consistent plasmoid designs, speak up and we can work through what might make the most sense.

alake wrote:Also if there is a collective desire to see more or clearer guidelines than colomar already highlighted in the layout guidelines that might help produce consistent plasmoid designs, speak up and we can work through what might make the most sense.

* colomar speaks upI guess that especially Plasmoids can benefit greatly from guidelines and patterns, since their use cases may have more in common than those of different applications (most Plasmoids are mostly for displaying information, maybe with some browsing involved).

colomar wrote:I guess that especially Plasmoids can benefit greatly from guidelines and patterns, since their use cases may have more in common than those of different applications (most Plasmoids are mostly for displaying information, maybe with some browsing involved).

Awesome. So right now the guidelines recommend patterns for a simple command structure and a flat or, at most 2-deep content structure. That's probably still be a lot of patterns to choose from (1 command pattern and 16 navigation patterns depending on content). What if we attempted to whittle the patterns down a bit for plasmoids (with modifications if necessary)?

For the simple command structure, the current guidance is for all commands to be exposed by direct manipulation of content (buttons, toolbuttons, text fields, click, drag..., no menu button, no context menus nor context panels). Might we want a special command pattern for plasmoids? If so, what commands might be common (or sufficiently common) and worth exposing in a common place in the layout? Similarly which commands might be frequently used and worth exposing in a common place in layout? If we decide we don't want a special command pattern for plasmoids, we could continue with the existing guidance. I'm happy to support whatever approach makes sense.

For the flat and 2-deep content structure, are there any patterns that we could maybe rule out as not an option for plasmoids?

One thing that I would like to see is the icon task manger using one of the default task manager's features. If an application is minimised, the icon should change to black and white. It would also be nice if they both used the same tooltip on hover over, hopefully the icon tasks one as it has many useful features over the default.

enoop wrote:One thing that I would like to see is the icon task manger using one of the default task manager's features. If an application is minimised, the icon should change to black and white. It would also be nice if they both used the same tooltip on hover over, hopefully the icon tasks one as it has many useful features over the default.

Icon tasks need 3 states:

1 - Not running2 - Running minimized3 - Running visible

I'm not sure having black and white icons would work that well in the case of icon tasks.

Edit: Another state would be focused, forgot that one.

Last edited by joaob on Thu Aug 07, 2014 10:02 pm, edited 1 time in total.

Reposting my comment from the blog, since I have not seen the thread here before:

"Are there any special changes planned when you are at rewriting things? One wish I have had for a very long time was more sensible scalability and initialization when dragging them from widgets explorer, as well as better context switches depending on if the plasmoid is initialized on a panel or on the "dashboard". For example: There are some widgets that are simply an icon when they are initialized and need to be resized, and others such as "manage print jobs" and "instant messaging presence" are simply an icon that needs to be clicked in order to show the desired overview, regardless if they are placed on the dash board or on a panel. It would be really cool if there would be a focus on presenting the widget as good as possible and dependent on the context from the beginning and in a size oriented way. There are also widgets that are initialized with lots of empty space, like widgets that are supposed to list something.

Flexibility should be given at the same time: For example the dictionary plasmoid could always show the search field in the panel if there is enough space, but it should also be possible to reduce it's size to an icon only.

One very special case to make clear what I mean: For example the Lock/Logout widget which is basically an icon triggering an action. That is of very limited use, it would be cool if it could be implemented to show direct actions, like the ones in the dialog that comes up when you click it. For example: In the panel it would be really cool to place a power button and if you click that button a plasma popup like calender appears that shows you all the possible power actions. That would be a really cool session menu. If you would place the same widget on the dashboard, it would of course be desired to expand instantly at initialization, like calendar does and not only if the user click the icon.

If an One very special case to make clear what I mean: For example the Lock/Logout widget which is basically an icon triggering an action. That is of very limited use, it would be cool if it could be implemented to show direct actions, like the ones in the dialog that comes up when you click it. For example: In the panel it would be really cool to place a power button and if you click that button a plasma popup like calender appears that shows you all the possible power actions. That would be a really cool session menu. If you would place the same widget on the dashboard, it would of course be desired to expand instantly at initialization, like calendar does and not only if the user click the icon.

if a plasmoid only makes sense in one context like the panel, then could we simply differentiate that already in the widget browser?

I know technically the possibilities like the context detection are already there, but they are poorly used in some plasmoids."

One wish I have had for a very long time was more sensible scalability and initialization

So when a plasmoid is dropped on the desktop the default size should be big enough to show a good version of the expanded view. Totally agree, please file a bug report on any plasmoids that don't do this. It's just a question of developer laziness not setting a default size properly.

[The lock screen] would be cool if it could be implemented to show direct actions

Speaking as a super grumpy old man, I'm not very motivated by things being "cool" or because we can. Us devs are a largely lazy species who need a lot of coercing into changing things.

if a plasmoid only makes sense in one context like the panel, then could we simply differentiate that already in the widget browser?

I personally want a completely separation between panel and desktop. It'd be a cleaner UI, and the code would be vastly simpler too... but that's getting outside the scope of porting some older plasmoids I think.

enoop wrote:One thing that I would like to see is the icon task manger using one of the default task manager's features. If an application is minimised, the icon should change to black and white. It would also be nice if they both used the same tooltip on hover over, hopefully the icon tasks one as it has many useful features over the default.

Icon tasks need 3 states:

1 - Not running2 - Running minimized3 - Running visible

I'm not sure having black and white icons would work that well in the case of icon tasks.

Edit: Another state would be focused, forgot that one.

Not running: no line, full colorRunning minimised: gray line, black and white iconRunning, not focused: full color icon, gray lineRunning, focused: full color icon, blue line

david_edmundson wrote:That way if someone here has an amazing mockup on how the RSS Reader plasmoid should look they should share it _now_ not in 3 months. As once it's ported it'll be 100 times harder to find the time.

The thread goes in three different directions after a few hours. I read your answer that you tell us step by step what you plan to do the next time, and don't want to get bothered with future tasks or x-mas ideas. So shouldn't we focus on the guidelines and the RSS reader for the moment? (I have nothing to add about the reader plasmoid, never used it.)