Bug 157400 - New containment(/More flexibel panel): Add some kind of "quick menu" that could contain widgets which are used often
Summary: New containment(/More flexibel panel): Add some kind of "quick menu" that cou...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-08 07:22 UTC by Bernd Steinhauser
Modified: 2018-06-08 20:16 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Steinhauser 2008-02-08 07:22:48 UTC
Version:            (using Devel)
Installed from:    Compiled sources

It's really hard to describe this in one sentence, so I'm not very proud of the summary, if you can come up with a better one feel free to modify it (if possible).
I'm also not sure if this is just a way more flexible panel or if that would define a new containment, at least I guess it would share code with the panel.
This is also the reason, why I didn't select the panel component, if you think, that it belongs there, change it. ;-)

Ok, here is the idea:
There could be a containment, that has a few widgets in it, the containment is normally hidden, it pops up if the user hits a shortcut (like the "Super" key or a special button on the mouse). It could either just pop up in the middle of the screen or where the pointer currently it (which means, that it should follow the pointer). It stays there for the time the user holds the key.

Now why would that be helpful?
Lets take "klipper" as an example. klipper has a history functionality, but I almost never used it. The reason is not, that I don't have a use for it, the reason is, that it is in the systray and that is (for reason, that don't really matter here, but there are reasons) on another screen than the screen I'm normally working on. If I would access klipper (by klicking on it and selecting a special clipboard entry) I would have to go over half the current screen and then another one (remember that the pointer most of the time is somewhere in the middle of the screen) and I end up just doing Alt+Tab a few times to reget the paste I wanted.
With the containment described above this would change. You could add a "klipper widget" (which does not exist yet, but I clearly think that that one will be there at some time in the future) which shows a small list (lets say 3-6 history entries dependent on the size of the thing) of the history entries of klipper.
There are other kinds of widgets, that could be very helpful in such a containment (some of them don't exist yet): Floating contacts (I've never seen a point to floatings before I thought about this ;-)), maybe a color chooser, some quick launcher, the pager or even the systray

I don't know if such a thing existed in KDE3, if there is something like that, then I've never seen it, at least. ;)
I also don't know if there is another desktop environment, that has something like that, so I can't just point at another one, saying "That's what I want". ;-)
What I do know is, that some games (mainly ego shooters) have similar elements in their GUIs (I remembered that when I searched for examples.).

I don't know if it's clear what I'm wishing here for, so comments, suggestions, questions are welcome. ;-)
But I do think, that it would help users to work in a more efficient and quicker way.
Comment 1 Aldoo 2008-02-11 15:50:55 UTC
Having such a container that pops up under the current position of the cursor would be a great feature, imho.

Currently, in most desktop environment, all those things you want to keep under the hand are on a panel, which has one of those two behaviors:
- either it is always visible, which takes a lot of pixels on the screen
- either it autohides (or can be covered by over windows), in which case it is difficult to access its elements. How are you supposed to aim for some UI element when you don't see it yet ?
In both case, how can you efficiently aim, when you have to do first a big mouse move to the border of the screen ? In this system, you need both big mouse moves, and precision in the end.

With your idea, suppose your container has a shape of a wheel (wheel menu), we minimize the necessary movement of the cursor, and the needed precision (since all the directions around the cursor maybe used for an useful UI element) without using pixels when not needed.

Use case: I need to use klipper widget.
1 - I press button 6 (or another extra-button of the mouse, or an easily reachable key of the keyboard, though if I had to use the keyboard, I would certainly prefer another mechanism, à la krunner)
2 - after a really quick glance I see where is the klipper (if my eyes are already on the cursor, finding the widget will be much quicker than on a panel)
3 - small move of the cursor on the right direction
4 - I release button 6, and the klipper menu appears.
Comment 2 Bernd Steinhauser 2008-02-21 00:31:29 UTC
I've been told, that Kommando does something similar for KDE3. See it here:
http://www.linux.com/feature/124329
http://www.kde-apps.org/content/show.php/Kommando?content=29514

Although it is not exactly what I thought of it goes in the same direction.
Comment 3 George 2008-12-01 16:29:21 UTC
*** This bug has been confirmed by popular vote. ***
Comment 4 George 2008-12-01 16:39:08 UTC
you mean some containment that have size, where you can put widgets and it will appear when some shortcut is pressed?

something like grid applet http://blip.tv/file/1104616/

that will appear
when some keybord keys or mouse keys will be clicked and then will hide
Comment 5 Aaron J. Seigo 2008-12-01 17:33:29 UTC
or just use the dashboard with ctrl+12 or whatever keyboard shortcut you decide to change it to.
Comment 6 Bernd Steinhauser 2008-12-01 19:56:42 UTC
(In reply to comment #4)
> you mean some containment that have size, where you can put widgets and it will
> appear when some shortcut is pressed?
> 
> something like grid applet http://blip.tv/file/1104616/
> 
> that will appear
> when some keybord keys or mouse keys will be clicked and then will hide
> 

No, then what Aaron just said would be true.

What I was suggesting is a bit different.
It's much more flexible. Look at the "Kommando" links above, it's very close to what I had in mind when writing this feature request (although I didn't know it yet).
It's also a very common GUI thing in Games.

The thing is, that it isn't sort of "static" like the current plasma widgets (of course you can move them but they won't move on your desktop automatically, and even if, that wouldn't be what I want).
It's a panel/containment that appears when pressing a shortcut (for example my mouse has a button that would be perfect for it), right where the mouse is atm, so you can quickly access several functions, like programs or widgets you often use.

BTW, that doesn't have to be round like the Kommando example above, although that would be one possibility.
Comment 7 FiNeX 2010-07-11 12:19:24 UTC
This idea has been implemented in the "new panel" action on KDE 4.5: you can add an empty panel or a panel with the default widgets.
Comment 8 Nate Graham 2018-06-08 20:16:53 UTC
Hello!

This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable.

Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham