Version: (using KDE Devel)
Installed from: Compiled sources
I simply cannot figure out how to move the applets added to the panel around. Maybe it is not implemented yet?
I consider this a bug and not a feature, as I tried to add the classic menu applet and it ended up in the right side which is pretty bad place for it...
*** Bug 154126 has been marked as a duplicate of this bug. ***
I wonder why this is considered a wish. When applets appear in a random order on the panel, that is a bug IMO.
Plasma and the panel is technically new software. Classing it as a wish just means that it's in the "stuff that hasn't been implemented" group rather than the "implemented stuff that's broken" group.
Sorry, but in that sense if I create a new text editor which cannot save the text, than I can say that this is not a bug, but a not implemented feature.
Bug doesn't mean only that it is implemented, but works wrong (e.g. I can move the applets to left), but that something is not working. If it is not working because there is no code that does it or because the code is broken is simply not important.
All in all, I hope that is fixed or implemented for the 4.0 release, whether it is classified as a wish or a bug.
Yes, so do I. Plasmoids are almost done for desktops, but are working poorly on pannels.
Btw, the pannel looks very good now, but plasmoids have troubles. And maximized windows look weird because of the pannel look.
Very high priority feature addition then. :)
@Peter: lets try and keep the bug reports focused and not deal with multiple issues per report (the maximized window issue is an art issue, btw, nothing to do with the code =)
@Andreas: quibbling over wish vs bug ... who cares. it'll get implemented because it's an obviously needed feature. that it has our (and specifically my) attention is much more important that wish vs bug =) so don't worry.
After all that is the most important, but it is important to not make
bug reporters angry as well. ;)
imho, it's more important not to piss off the people who will fix them.
The best is not to piss anyone. And everyone's happy.
*** Bug 151721 has been marked as a duplicate of this bug. ***
I second (or third or whatever^^) this. It would be great if such a possibility was implemented :)
Adding/removing applets from the panel works well now so a workaround for moving is to remove and add where you want it.
*** Bug 155549 has been marked as a duplicate of this bug. ***
*** Bug 155955 has been marked as a duplicate of this bug. ***
Created attachment 23729 [details]
Allow to (cumbersomly) move applets around
Dumb proof of concept. Yeah, it doesn't know about vertical panels and
drag'n'drop would be nicer. Any volunteer? :-)
A bit more sophisticated patch: http://mattr.info/r/261/
*** Bug 160776 has been marked as a duplicate of this bug. ***
Stephen, could you post your patch?
Your site is not working
*** Bug 158301 has been marked as a duplicate of this bug. ***
From bug 158301:
------- Additional Comment #3 From Kevin Kofler 2008-04-19 16:23 -------
Here's the plasma-4.0-openSUSE commit:
------- Additional Comment #4 From Kevin Kofler 2008-04-19 17:20 -------
Patch against 4.0.3:
(Maybe the one on the Plasma review board applies against 4.0.3 already, but I can't reach mattr.info at the moment, so I can't check.)
I just run the Daily build from kde 4.1 an still can't figure out how to move plasmoids around the panel. My approach would be:
Go in the panelsettingsmode. Have there a button like "move applets" or somthing in order to move afterwards the applets around.
Just my two cents. By the way, Plasma got/get realy nice;)
Moreover, as moving plasmoids from desktop to panel work, the contrary should work as well.
*** Bug 162817 has been marked as a duplicate of this bug. ***
*** Bug 164674 has been marked as a duplicate of this bug. ***
Please, make this a bug. With this number of votes, it would make it into the Most Hated Bugs list - maybe someone will finally notice.
Jiri, 'someone' already noticed and it is said that this is being taken care of for KDE 4.2.
4.2 is too late. way too late, such a basic function should have been in kde 4.0
I fully agree with Peter, it's a fundamental feature.
I think even Windows 3.1 had this, and there IS a patch from SUSE for KDE 4.0 which already works AFAIK.
This can't be ignored.
The KDE team says that 4.0 was to test the API, and 4.1 is for the Users. Everybody will laugh over KDE - "ha, you mean the 'DE' where you even can't move panel items?" - with this publicity already this could get a major disaster, not because it is such a big problem, but because it is seen as a small problem treated with ignorancy.
If I knew C++, first thing to do would be getting this to work, at any cost.
People, please stop using this bug entry to make comments such as "it is a fundamental feature" or something like that. bugs.kde.org is a bug reporting tool, not a means for you to complain about a missing feature (whether that is right or not, it makes no difference here). It won't help making the feature implemented faster.
Let's not make the lives of the developers harder, shall we?
I'm sorry for creating more noise in the ML but I feel that if this isn't clearly communicated, people will still confuse Bugzilla for a discussion tool.
you are right - e.g. better here: http://brainstorm.ubuntu.com/idea/10233/
Fwiw, fedora has assigned a developer to work with the kind plasma folks, with the lofty/optimistic goal for this to land in time for 4.1.
So at this point, either jump in and help code, or be patient.
Thanks for the info, this is a big relief for many, I think...
Very difficult to use if you cannot move the widgets in the taskbar.
Has it been decided yet if this will be in 4.1 or 4.2?
> People, please stop using this bug entry to make comments such as "it is a
> fundamental feature" or something like that. bugs.kde.org is a bug reporting
> tool, not a means for you to complain about a missing feature (whether that
> is right or not, it makes no difference here).
This is a usability regression from KDE 3 (and a severe one at that), and as such it is a bug.
> This is a usability regression from KDE 3 (and a severe one at that), and as
> such it is a bug.
It is not a regression because plasma is a complete new program (it's not kicker). So it is a missing feature. But this whole discussion is completely irrelevant to the developer so let's stick to helping out implementing it. It's not important for implementation to consider this a bug or a missing feature.
I just put myself into CC to get info about when it is fixed. But currently people are creating totally useless noise argueing about whether this is a "feature" or "bugfix". :-(
On Tuesday 24 June 2008 16:49:07 Luca Beltrame wrote:
> People, please stop using this bug entry to make comments such as "it is a
> fundamental feature" or something like that. bugs.kde.org is a bug
> reporting tool, not a means for you to complain about a missing feature
> (whether that is right or not, it makes no difference here). It won't help
> making the feature implemented faster.
I just noticed this comment...well, you're wrong. bugs.kde.org is a tool to
report bugs AND wishes - aka as wanted features. For the last sentence I
agree, that too much complaining won't necessary mean that it will be
implemented faster, but might scratch the itch of some developer. IMO instead
of just adding extra comments how it is needed, vote for the bug.
Here's my attempt to port Stefan Binner's patch from plasma-4.0-openSUSE to 4.0.83 (4.1 beta2):
I know it compiles, I don't know yet whether it works or not.
[More feature v. bug noise]
The dialog over whether this is a feature request or a bug IMO is not "useless noise". Rather it holds attention to the problem and demonstrates the demand for a fix. Developers will ultimately decide if the problem is an actual bug or not, but the importance of the dialog need not be ignored. For what it's worth, I also consider the absence of this feature a bug and hope to see the feature implemented soon.
The patch from comment #41 has been confirmed working by Rex Dieter.
Of course it shares all the issues of Stephan Binner's original patch which it is based on.
About the patch in #41
if (!m_movedApplet || (m_movedApplet && m_movedApplet!=applet))
is the same as
if (!m_movedApplet || m_movedApplet!=applet)
Yes it is.
Btw... I'm working on improving the patch. I already improved it for horizontal panels... tomorrow I'll fix the vertical ones, and will try to put it online for testing.
My version of the patch is here:
It works a bit better for me.
I think this kind of patch (context menu) is not the best one.
We could maybe let users drag applets around when the panel config ui is shown.
Better ideas anyone?
Ideas: two modes should be provided, as in KDE3 really
a) d&d -- because it is very intuitive
b) "move" from context menu -- after choosing this action, the item behaves like it is d&d but user does not have to hold LMB pressed all the time, just move mouse, or use <- -> v ^ keys to move it -- reason: all those people with RSI or worse
As we have now the panel config widget (that transparent ones that appear on
top of the panel), imo the move should be possible only if the configuration is
activated. An idea would be to display the position of the applets on the
ruler there, as now there are no visible applet handles, so with simple d&d
you might move e.g the systray instead of the nearby clock or taskbar.
Simple d&d would no longer simple if in order to d&d object you have to d&d its remote counterpart -- UI design of panel is going to be more weird than it is already.
But it is a good point to display remote controller -- if it is displayed, panel could be in "freeze" mode, i.e. if you click on any item on panel it does not activate, instead you could grab it and move it. It would behave (panel) as it was just a bag of moveable pieces.
Nice part is it does not break current UI because currently you cannot click on panel and have remote controller at the same time.
"if it is displayed, panel could be in "freeze" mode, i.e. if you click on any item on panel it does not activate, instead you could grab it and move it."
that's pretty much the idea, actually. i even have cute hand drawings of this from 2-3 years ago, from during one of zack's visits to the house here. =)
best is that for those who suffer from RSI, something you are especially concerned about, the task goes from:
* hover over and area of an applet
* right click, often after hunting for a small area to do so in
* select "Move" from a menu
* move mouse around
* left click
* left click cashew
* hover above applet
* left click
* move mouse around
* click again
the last two steps are pretty much the same, but but the first three are signficantly different: the first requires using multiple mouse buttons (right, then left, then left) and aiming at much smaller spaces (required increased accuracy in pointing)
it's also much easier to do the latter on a touch screen (due to lack of special mouse clicks, such as the right click). for both RSI issues as well as learnability, i really think such interfaces are "the future" (ick, such a horrible phrase, but you know what i mean ;)
Yes, this is great! Classic d&d is intuitive, but it is a11y killer, so this would be great step to merge those two worlds.
*** Bug 165339 has been marked as a duplicate of this bug. ***
@Aaron J. Seigo 2008-06-29 09:26,
the obvious and easy way to do it for most people would be to:
-1.left click over any area of the applet/icon 2. hold left click and drag to desired location -> just one click and a drag.... the way I have been moving stuff around the desktop for almost the past 20 years. (Maybe you would want to lock some icons against accidental dragging, in case a user drags such an icon/applet just have a message popup saying the item is locked and to right click to unlock or click somewhere in message bubble to unlock)
- alternatively right click applet/icon select move and move applet/icon to desired location
I see that I am just repeating Maciej Pilichowski's suggestion, which is not strange because that is what people have come to expect (and takes the least steps to accomplish too)
I also vote for simple d&d.
The problem in KDE3 now is:
if you "take" an icon on kicker and drag it elsewhere, there are 2 icons visible: the original one on kicker and the icon glued to your mouse pointer. this is a little bit confusing.
I would suggest:
1. you hold down your mouse on an applet and drag.
2. while you are moving and dragging inside the panel, the applet is glued to the mouse, but everywhere you move the icons arrange themselves automatically (like it is the case in GNOME panel, when you right click->move).
This is intuitive and easy, and precicely shows you the situation how ti would look like if you dropped it here.
3. if you leave the panel, the applet disappears from the panel and follows the mouse (for dragging it on the plasma desktop.
Things like havind a vertical line between icons are useless IMO.
But, I agree as well with the "lock panel" option: applets can only be move if panel is in "edit" mode.
The problem here is - it is inconsistent with the "drag applets/icons from anywhere at anytime to the panel"
I would sugest that icons/applets on the panel should have some highlight as the icons on the desktop have. That way, the user will intuitevely know he can move.
Also, for me it would be interesting that beside moving I could copy/duplicate a icon/applet easily. A common use of this is to copy an icon from the desktop to the panel, as the user want to keep them on both.
For that should be holding down the Ctrl key, like elsewhere.
(I support moving files in konqueror/dolphin without Shift key as well, each time this annoying menu is really...but that's another story)
Hi, tried the patch. (From comment 41)
But unfortunately, it didn't work for me.
But let me share some ideas, that I think would make it more easy for users to to move and resize applets on the panel.
First, I would vote against any kind of context menu or key combinations etc.
That just makes it more complicated.
What I would suggest:
If someone opens the panel configuration part, the applets are shown different.
Every applet shows up as a box (nicely shaded), with it's name as the content.
Here you can drag and drop them (even drag them to the desktop or other panels and vice versa).
The borders of the applets, that are connected to each other can be used to adjust the space that it assigns to these applets etc.
(I hope that wasn't too confusing. ;))
That would be more clear then if you just drag stuff around with its actual content in it, which can be confusing sometimes to some people. ;)
Have a look at Bug 154804
#58 From Bráulio Barros de Oliveira 2008-06-29 22:09,
that was going to be my next request; get rid of that highlight with toolbox thing around the icons and plasmoids on the desktop because it took me about several hours and tries at installing, trying and uninstalling kde4 in frustration because I couldnt figure out how to move a simple icon on the desktop and even now when I have figured it out I am only about 50% succesful because it is so difficult to time and target (especially with a touchpad).
I just want a simple click anywhere on the icon to grap, move, release left button and drop.... and a right click to resize, remove etc.
> If someone opens the panel configuration part, the applets are shown
> different. Every applet shows up as a box (nicely shaded), with it's name as
> the content.
I think nice border would be really enough -- note, that when you do a big change you looking at something else and you cannot tell the outcome. Not mentioning reaction "oh, did I break it?".
that was already reported, I still think it is a very good idea, but unfortunately it was shot down. Here:
I had fun implementing Aaron suggestions from #51
the source is here...
The patch is really trivial (plasma has a nice and friendly API).
Maybe we could make it into 4.1.
If you want me to commit... just tell me :-)
If you tried the latest patch before reading this message... please redownload it.
I just fixed a bug.
Same url for the download.
@ comment 64:
Looks good for moving applets and works here.
But, I wouldn't activate the moving mode through the context menu.
Just enable it, when one goes into panel configuration mode (where you can resize the panel).
I also think, that this is what his second suggestion was. ;)
(And I'm still in favour of dropping the content of the applets when moving them, so it is easier to see where which applet is, but that's more of a style question.)
But it is a first step. Thank you. ;)
i've got something working that activates as soon as you go into edit mode here. seems we've even got clearance for 4.1
Not like you've ever heard this before, but... you da man.
My patch enables "applet drag mode" when the config ui is shown or when you select it from the context menu.
If you don't like the option shown into the context menu, I can simply remove it.
Maybe whe should give visual feedback to warn the user that the "drag mode" is on.
Ideas? (I'm not good enaught as a GUI designer :-) )
@Aaron: are you working on new code?
> Maybe whe should give visual feedback to warn the user that the "drag mode"
> is on.
When the remote controller is shown? imho -- no. For us (tracking progress with KDE4) this could be a change, but we should consider it as obvious feature (i.e. that was there for long, since KDE3 for sure).
imho, the widgets move/resize highlight should be enabled on mouse hover when they are not locked, not when the panel configuration is open.
imho, it doens't make sense to open panel configuration to move/resize a applet.
Btw: r826398 in kdebase/workspace/plasma/plasma made my patch not working
when the config UI is shown.
My patch works up to r826380.
r826398: looks like the beginning of Aaron's own approach. He uses a
different approach than mine: so the new code prevents my patch from
obtainig events from the panel and applets :-)
@Aaron: The unrendered moveOverlay widget makes my systray disappear when
the config UI is shown.
@ comment 70:
It does make sense. Because this way it is consistent.
If you allow moving the widgets, unless they are locked, you could also argue, that you should be able to resize the panel without opening the configuration menu.
Doing it this way is intuitive and it prevents to splatter config options all over the place.
Besides, as Aaron explained somewhere else afaik, the Widgets locking has a different purpose. (Kiosk-mode etc.)
imo this wish can be closed because since yesterday there exists a way to easily move around widgets on the panel (it works like a charm here :-) )
AND: it will be in 4.1 !!
Can you set the default place where the icons are displayed when you use "move to taskbar" too?
*** Bug has been marked as fixed ***.
I just like to add that I _did_ have an option "Start move of this widget" before, but it has miraculously disappeared from the context menu...
On another pc with KDE4.1, it is still there.
Both PC's have been upgraded from opensuse 10.3/KDE3.5.
@Edwin: SUSE had their own patch - this is the one that got adopted for KDE4.1 here I think.
@Edwin: yes, it's not in the context menu anymore but accessed via the Panel Settings interface
and just to clear up any possible confusion: what is in 4.1 is not the patch the Suse people made for 4.0 =)
@Christian: downgraded to KDE 4.0.5 from the openSUSE DVD, and the option is back. But as you said, it could be a SUSE patch.
Anyway, will it be available again in 4.1?
SUSE had it's own patch for KDE 4.0.
And in KDE 4.1/upstream is it fixed as well, so it will be included in 4.1.
I see moving applets in the panel is implemented. However applets take too much space. In my case if i remove the taskbar widget from the panel, i can't move the clock widget to the right. That is because the applet is too wide. Actually i can move the clock, but when i release the mouse clock get centered in its widget space.
Created attachment 26170 [details]
this is the end effect when i remove the task bar
This is when i remove the task bar widget. Clock can't be moved to the right of
Georgi, this is separate issue, and this is bug for systray and for clock plasmoid. It has nothing to do with moving (apart from the fact I am able to move this oversized clock plasmoid, today SVN).
Here, I opened appropriate reports:
There is some problem with managing position of widgets (icons) on the Panel still, I'm afraid. I'm not able to move the widgets (icons) after having put them on the Panel.
KDE: 4.1.00 (KDE 4.0.99 (4.1 RC1+)) "release 13.7"
openSUSE 11 64bit (repository KDE4:/Factory:/Desktop/openSUSE_11.0/)
I suppose that this report is not only about the systray as Maciej wrote in the Comment #84 and issue should be reopened
works fine here.
Ladislav, you unlock widgets, for example you d&d konqueror on the panel, you open remote controller for panel, you click on konqueror icon, you move mouse cursor, you click to drop and this does not work?
Ups & nice! I'm so sorry. I omitted the step with the remote controller (right click menu 'Panel Settings'). Great work!
I just noticed that I knew what to do because I keep track of this report. One idea about how this could be solved (it is hard to expect users to read bugzilla):
Creating a new panel on a secondary xinerama display is skitzo, it won't allow me to locate applets on it (I move them, they then snap back to wherever they want to be).
Also, manipulating panel elements is cumbersome, please bring back standard KDE middle-mouse-drag to relocate panel items.
This is with the latest Fedora Rawhide KDE.
The bug report is set as resolved, however - in which version was this resolved? I'm running KDE 4.2.0 (Arch w/KDEMod 64 Bit) and still unable to position widgets where I want them in the panel.
Can a developer confirm which version this has been resolved in?
kde-4.2.0 is the first officially released version to include this feature.
That said, afaik, Alex, it doesn't allow placement down to the pixel, which may or may not be what you're looking for.
Ok, yeah I am on about absolete positioning of widgets on a panel, so I can have something far left, far right or where ever I want.
Should I create a wish report for this?