This forum has been archived. All content is frozen. Please use KDE Discuss instead.

[Design Feedback Wanted] - Plasma Addons

Tags: None
(comma "," separated)
User avatar
david_edmundson
KDE Developer
Posts
359
Karma
1
OS
We've made a start porting some of the widgets from the plasma-addons repository: https://todo.kde.org/?controller=board& ... ec365b8f1c

(full blog post here: http://blog.davidedmundson.co.uk/node/75)

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.

We also could do with some help reviewing applets as they get ported.
davidwright
Registered Member
Posts
153
Karma
0
OS
A bit o/t but is python still supported for developing widgets (via PyQt)? Or is it QML & C++ only?
User avatar
david_edmundson
KDE Developer
Posts
359
Karma
1
OS
davidwright wrote:A bit o/t but is python still supported for developing widgets (via PyQt)? Or is it QML & C++ only?

QML only for UIs. C++ for any extra backends.
User avatar
Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
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)?

PS: Here is a list of all addons: https://projects.kde.org/projects/kde/k ... repository
User avatar
david_edmundson
KDE Developer
Posts
359
Karma
1
OS
What I want is to let you guys know we are starting to port them.

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.
User avatar
colomar
Registered Member
Posts
947
Karma
2
OS
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.

The rest is up to our creativity ;)
User avatar
alake
Registered Member
Posts
591
Karma
3
OS
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. :-)
User avatar
colomar
Registered Member
Posts
947
Karma
2
OS
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 up
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).
User avatar
alake
Registered Member
Posts
591
Karma
3
OS
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?
enoop
Registered Member
Posts
101
Karma
0
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.
joaob
Registered Member
Posts
17
Karma
0
OS
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 running
2 - Running minimized
3 - 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.
kdeuserk
Registered Member
Posts
207
Karma
0
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."
User avatar
david_edmundson
KDE Developer
Posts
359
Karma
1
OS
That was quite an essay.

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
Registered Member
Posts
101
Karma
0
joaob wrote:
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 running
2 - Running minimized
3 - 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 color
Running minimised: gray line, black and white icon
Running, not focused: full color icon, gray line
Running, focused: full color icon, blue line

That's how the task manger in plasma 5 does it.
User avatar
Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
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.)


Bookmarks



Who is online

Registered users: Bing [Bot], claydoh, Google [Bot], markhm, rblackwell, sethaaaa, Sogou [Bot], Yahoo [Bot]