|Summary:||Moving/resizing applets on the panel|
|Product:||[Plasma] plasma4||Reporter:||András Manţia <amantia>|
|Component:||panel||Assignee:||Plasma Bugs List <plasma-bugs>|
|Severity:||wishlist||CC:||alex, billcrawford1970, bluedzins, DavidLBarbour, emanuele, fredcwells, godutchnow, jdluhos, jonas.vejlin, kde, kdebugs, linux, lure, me, mefoster, pij, rdieter, sadysta, saulotoledo, snoopy, tuju|
|Latest Commit:||Version Fixed In:|
Allow to (cumbersomly) move applets around
this is the end effect when i remove the task bar
Description András Manţia 2007-12-15 18:19:56 UTC
Version: (using KDE Devel) Installed from: Compiled sources OS: Linux 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...
Comment 1 Jason Stubbs 2007-12-16 08:12:18 UTC
*** Bug 154126 has been marked as a duplicate of this bug. ***
Comment 2 András Manţia 2007-12-16 08:35:04 UTC
I wonder why this is considered a wish. When applets appear in a random order on the panel, that is a bug IMO.
Comment 3 Jason Stubbs 2007-12-16 09:40:59 UTC
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.
Comment 4 András Manţia 2007-12-16 10:21:44 UTC
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.
Comment 5 David 2007-12-16 10:50:59 UTC
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.
Comment 6 Jason Stubbs 2007-12-16 10:59:54 UTC
Very high priority feature addition then. :)
Comment 7 Aaron J. Seigo 2007-12-16 19:51:52 UTC
@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.
Comment 8 András Manţia 2007-12-16 20:47:38 UTC
After all that is the most important, but it is important to not make bug reporters angry as well. ;)
Comment 9 Aaron J. Seigo 2007-12-16 21:04:29 UTC
imho, it's more important not to piss off the people who will fix them.
Comment 10 David 2007-12-16 21:07:33 UTC
The best is not to piss anyone. And everyone's happy.
Comment 11 Jason Stubbs 2007-12-21 13:16:01 UTC
*** Bug 151721 has been marked as a duplicate of this bug. ***
Comment 12 Unknown 2007-12-29 19:39:52 UTC
I second (or third or whatever^^) this. It would be great if such a possibility was implemented :)
Comment 13 Jason Stubbs 2007-12-30 04:06:23 UTC
Adding/removing applets from the panel works well now so a workaround for moving is to remove and add where you want it.
Comment 14 Jason Stubbs 2008-01-12 19:00:43 UTC
*** Bug 155549 has been marked as a duplicate of this bug. ***
Comment 15 George Goldberg 2008-01-17 02:55:44 UTC
*** Bug 155955 has been marked as a duplicate of this bug. ***
Comment 16 Stephan Binner 2008-02-27 18:24:07 UTC
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? :-)
Comment 17 Stephan Binner 2008-03-07 06:31:47 UTC
A bit more sophisticated patch: http://mattr.info/r/261/
Comment 18 Pino Toscano 2008-04-13 09:26:22 UTC
*** Bug 160776 has been marked as a duplicate of this bug. ***
Comment 19 David Broome 2008-04-17 06:28:51 UTC
Stephen, could you post your patch? Your site is not working
Comment 20 Kevin Kofler 2008-04-24 22:48:47 UTC
*** Bug 158301 has been marked as a duplicate of this bug. ***
Comment 21 Kevin Kofler 2008-04-24 22:49:49 UTC
From bug 158301: ------- Additional Comment #3 From Kevin Kofler 2008-04-19 16:23 ------- Here's the plasma-4.0-openSUSE commit: http://websvn.kde.org/?view=rev&revision=791852 ------- Additional Comment #4 From Kevin Kofler 2008-04-19 17:20 ------- Patch against 4.0.3: http://cvs.fedoraproject.org/viewcvs/rpms/kdebase-workspace/devel/kdebase-workspace-4.0.3-kde%23158301.patch?rev=1.2&view=markup (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.)
Comment 22 Etienne 2008-05-28 19:20:49 UTC
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;)
Comment 23 Marco Stronati 2008-05-28 21:35:13 UTC
Moreover, as moving plasmoids from desktop to panel work, the contrary should work as well.
Comment 24 Dennis Nienhüser 2008-06-11 20:45:05 UTC
*** Bug 162817 has been marked as a duplicate of this bug. ***
Comment 25 FiNeX 2008-06-22 19:29:18 UTC
*** Bug 164674 has been marked as a duplicate of this bug. ***
Comment 26 Jiri Dluhos 2008-06-24 12:47:15 UTC
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.
Comment 27 Bram Schoenmakers 2008-06-24 14:52:04 UTC
Jiri, 'someone' already noticed and it is said that this is being taken care of for KDE 4.2.
Comment 28 David 2008-06-24 14:57:16 UTC
4.2 is too late. way too late, such a basic function should have been in kde 4.0
Comment 29 Gustavo Narea 2008-06-24 15:00:30 UTC
I fully agree with Peter, it's a fundamental feature.
Comment 30 Christian González 2008-06-24 15:36:33 UTC
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.
Comment 31 Luca Beltrame 2008-06-24 15:49:06 UTC
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.
Comment 32 Christian González 2008-06-24 15:51:03 UTC
you are right - e.g. better here: http://brainstorm.ubuntu.com/idea/10233/
Comment 33 Rex Dieter 2008-06-24 16:21:55 UTC
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.
Comment 34 Christian González 2008-06-24 18:27:52 UTC
Thanks for the info, this is a big relief for many, I think...
Comment 35 william hart 2008-06-24 20:09:27 UTC
Very difficult to use if you cannot move the widgets in the taskbar.
Comment 36 Jay LaCroix 2008-06-26 22:57:43 UTC
Has it been decided yet if this will be in 4.1 or 4.2?
Comment 37 Rex Dieter 2008-06-26 22:59:06 UTC
Comment 38 Kevin Kofler 2008-06-27 08:36:37 UTC
> 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.
Comment 39 Kai Krakow 2008-06-27 08:59:48 UTC
> 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". :-(
Comment 40 András Manţia 2008-06-27 09:04:18 UTC
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.
Comment 41 Kevin Kofler 2008-06-27 10:24:15 UTC
Here's my attempt to port Stefan Binner's patch from plasma-4.0-openSUSE to 4.0.83 (4.1 beta2): http://cvs.fedoraproject.org/viewcvs/rpms/kdebase-workspace/devel/kdebase-workspace-4.0.83-kde%23154119.patch?rev=1.1&view=markup I know it compiles, I don't know yet whether it works or not.
Comment 42 Fred Wells 2008-06-27 23:45:07 UTC
[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.
Comment 43 Kevin Kofler 2008-06-28 02:26:16 UTC
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.
Comment 44 Vincenzo Di Massa 2008-06-28 14:10:27 UTC
About the patch in #41 if (!m_movedApplet || (m_movedApplet && m_movedApplet!=applet)) is the same as if (!m_movedApplet || m_movedApplet!=applet) Isn't it?
Comment 45 Maciej Pilichowski 2008-06-28 14:12:59 UTC
Yes it is.
Comment 46 Vincenzo Di Massa 2008-06-29 02:24:01 UTC
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.
Comment 47 Vincenzo Di Massa 2008-06-29 02:29:11 UTC
My version of the patch is here: http://clem.dii.unisi.it/~dimassa/move_applets.diff 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?
Comment 48 Maciej Pilichowski 2008-06-29 08:23:57 UTC
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
Comment 49 András Manţia 2008-06-29 08:55:21 UTC
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.
Comment 50 Maciej Pilichowski 2008-06-29 09:06:26 UTC
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.
Comment 51 Aaron J. Seigo 2008-06-29 09:26:38 UTC
"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 to: * 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 ;)
Comment 52 Maciej Pilichowski 2008-06-29 09:39:51 UTC
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.
Comment 53 Christophe Marin 2008-06-29 17:17:45 UTC
*** Bug 165339 has been marked as a duplicate of this bug. ***
Comment 54 aapgorilla 2008-06-29 17:41:19 UTC
@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) and/or - alternatively right click applet/icon select move and move applet/icon to desired location
Comment 55 aapgorilla 2008-06-29 17:50:34 UTC
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)
Comment 56 Christian González 2008-06-29 18:07:50 UTC
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"
Comment 57 Maciej Pilichowski 2008-06-29 18:58:05 UTC
Comment 58 Bráulio Barros de Oliveira 2008-06-29 22:09:38 UTC
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.
Comment 59 Christian González 2008-06-30 00:11:05 UTC
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)
Comment 60 Bernd Steinhauser 2008-06-30 01:47:38 UTC
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. ;) @comment 59: Have a look at Bug 154804
Comment 61 aapgorilla 2008-06-30 08:29:26 UTC
@ #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.
Comment 62 Maciej Pilichowski 2008-06-30 17:25:18 UTC
Bernd, > 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?". Ffi, that was already reported, I still think it is a very good idea, but unfortunately it was shot down. Here: http://bugs.kde.org/show_bug.cgi?id=164062
Comment 63 Vincenzo Di Massa 2008-07-01 01:49:58 UTC
I had fun implementing Aaron suggestions from #51 the source is here... http://clem.dii.unisi.it/~dimassa/move_applets2.diff 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 :-) Vincenzo
Comment 64 Vincenzo Di Massa 2008-07-01 02:33:11 UTC
If you tried the latest patch before reading this message... please redownload it. I just fixed a bug. Same url for the download. http://clem.dii.unisi.it/~dimassa/move_applets2.diff
Comment 65 Bernd Steinhauser 2008-07-01 03:29:22 UTC
@ 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. ;)
Comment 66 Aaron J. Seigo 2008-07-01 03:54:40 UTC
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
Comment 67 Rex Dieter 2008-07-01 05:15:16 UTC
Not like you've ever heard this before, but... you da man.
Comment 68 Vincenzo Di Massa 2008-07-01 16:44:15 UTC
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?
Comment 69 Maciej Pilichowski 2008-07-01 16:51:52 UTC
> 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).
Comment 70 Bráulio Barros de Oliveira 2008-07-01 16:56:12 UTC
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.
Comment 71 Vincenzo Di Massa 2008-07-01 17:38:43 UTC
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. 2008/7/1 Br
Comment 72 Bernd Steinhauser 2008-07-01 18:06:58 UTC
@ 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.)
Comment 73 Bernhard Friedreich 2008-07-06 13:28:02 UTC
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 :-) ) http://blog.lydiapintscher.de/2008/07/05/move-your-applets-freely/ AND: it will be in 4.1 !!
Comment 74 Lionel Lecoq 2008-07-06 15:59:18 UTC
Cool :D Can you set the default place where the icons are displayed when you use "move to taskbar" too?
Comment 75 Aaron J. Seigo 2008-07-06 21:00:59 UTC
*** Bug has been marked as fixed ***.
Comment 76 Edwin Boersma 2008-07-09 12:17:40 UTC
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.
Comment 77 Christian González 2008-07-10 16:25:17 UTC
@Edwin: SUSE had their own patch - this is the one that got adopted for KDE4.1 here I think.
Comment 78 Aaron J. Seigo 2008-07-10 19:26:56 UTC
@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 =)
Comment 79 Christian González 2008-07-10 20:39:30 UTC
Comment 80 Edwin Boersma 2008-07-11 10:18:16 UTC
@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?
Comment 81 Christian González 2008-07-11 12:00:07 UTC
Both Yes. 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.
Comment 82 Georgi Ivanov 2008-07-16 12:34:28 UTC
Hi, 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.
Comment 83 Georgi Ivanov 2008-07-16 12:37:19 UTC
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 the panel.
Comment 84 Maciej Pilichowski 2008-07-16 16:09:25 UTC
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: https://bugs.kde.org/show_bug.cgi?id=166737 https://bugs.kde.org/show_bug.cgi?id=166738
Comment 85 Ladislav Nesnera 2008-07-28 19:17:55 UTC
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. Environment: Qt: 4.4.0 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
Comment 86 Rex Dieter 2008-07-28 19:45:24 UTC
works fine here.
Comment 87 Maciej Pilichowski 2008-07-28 19:55:04 UTC
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? Which part?
Comment 88 Ladislav Nesnera 2008-07-28 20:29:04 UTC
Ups & nice! I'm so sorry. I omitted the step with the remote controller (right click menu 'Panel Settings'). Great work!
Comment 89 Maciej Pilichowski 2008-07-28 21:41:40 UTC
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): http://bugs.kde.org/show_bug.cgi?id=167617
Comment 90 Mathew Hennessy 2009-01-27 02:33:44 UTC
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.
Comment 91 alex 2009-02-11 22:02:31 UTC
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?
Comment 92 Rex Dieter 2009-02-11 23:06:29 UTC
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.
Comment 93 alex 2009-02-12 08:30:14 UTC
Rex, 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?