Version: (using KDE 4.2.0) Compiler: gcc 4.3.3 OS: Linux Installed from: Unspecified Linux First of all my setup: Laptop with external screen at the office, nvidia gfx card (twinview setup). At the office I use the external screen as the primary one, so I move the panel to it. At home, I do not have an external screen, but when I start KDE, the panel is gone... still on the now non-existent second screen. I cannot find a way to get it back except for logging out, deleting plasma configuration and logging in again. Since I use some other applets as well, this is not a great solution: I have to reconfigure plasma every time I forget to return the panel to the first screen when leaving my office. I think plasma should be made aware of the screen size, putting all applets on the available screens.
which breaks in the case of having more than one activity, moving from two screens to one temporarily and more. the proper solution here would be to have the external screen identified as the new primary screen (taking the id of the internal one when plugged in). barring x.org actually doing intelligent things like that, it would be up to some "if there are no panels, look for them from other non-existent screens" heuristic.
I can see your point as a developer myself, however, you cannot blame me for not caring as a user. As a user, I want to see a panel when I login, otherwise I am lacking a lot of functionality and deleting the plasma configuration every time I have forgoten to move the panel back to the laptop screen is not a good solution. The heuristic you describe is not that hard to implement I think and would solve a really annoying issue. Just my 2 cents...
"The heuristic you describe is not that hard to implement I think" it's not just how hard it is, it's how important this is to implement relative to other things that need implementing. that said, it's not as trivial as it first appears. if a panel is moved from screen 0 to screen 1 and then screen 1 disappears at some point, it should move to screen 0 if there is no panel on that same screen edge. but then .. if it screen 1 re-appears it should probably move back there again. which means we need to implement "last screen, current screen, automatically moved from" bookkeeping. now, if a panel is created on screen 1 and then screen 1 disappears at some point, should it move to screen 0 if there are no panels on that screen edge? hopefully nobody will say "no" to that, but again this too needs the same bookkeeping. what happens if there are panels on screen 1 and screen 0 on the same edge when screen 1 disappears, and then later the panel on screen 0 is removed? should the panel from screen 1 now appear there? it will on next start if nothing changes, but should it happen immediately as well? still ... it is kind of funny how people will say "that's not hard" as if we're all just sitting here idly, not doing anything, waiting for something to do. ;)
*** Bug 182959 has been marked as a duplicate of this bug. ***
*** Bug 195738 has been marked as a duplicate of this bug. ***
Other windows already do this. If I have a window on screen 1, remove screen 1, it gets moved onto screen 0 for me. If I reenable screen 1, back it goes automagically to screen 1. Why can't this same mechanism be used? Also, what's so bad about panels being stacked on top of each other? 1) They could be left "dumb" and the user could have access to the one on top, move it to a different edge thus exposing the bottom one. 2) Or, they could be made intelligent and merge their contents into a single panel, ignoring duplicated widgets. Either way, any user that has this use case often enough will figure it out and choose their best option.
nick: please read comment #3. it answers it pretty thoroughly ("we can do this, it just needs quite a bit of work because panels aren't like other windows") "Also, what's so bad about panels being stacked on top of each other?" tell that to the people who file bug reports about it. we already have such bug reports, in fact. while you are trying to get your problem solved and don't really need to think about the problems of others in the process, i have only the problems of others, including yours, to think about and then actually fix. this issue will get addressed at some point as long as we are allowed to do our job, which includes not making trouble for person B just because person A needs something.
Not trying to cause waves for you devs. I appreciate all you've accomplished. What's the simplest way to manually edit/remove the current plasma panel location? Is it something in .kde/share/config/{plasmarc,plasma-appletsrc} ? (I've played around w/o success) Suggestion: rather than adding bookkeeping of where it's been and all that state and logic, perhaps just add a few more behavior parameters to the panel itself--let it be responsible for moving itself according to it's own defined behavior, whenever a desktop change event comes around: 1) desktop priority (1, then 0) 2) priority (if I'm colliding with another panel, who stays and who gets moved?, if priorities are the same, go to last resort) 3) edge priority(top, bottom, left, right) // if there's a collision, move me to the next available edge 4) last resort, if i'm same or lowest priority, on my last desktop, at my last edge, and still collide, with another panel, add a menu to the panel menu to select which panel is displayed. (perhaps some eye-candy notification that there are now two panels there, directing the eye to the selection menu) - or - a second last resort could display it offset of the existing panel(s), so all are visible. By default, if all panels have at least the primary desktop as their last desktop priority, and a single edge priority, then the 'last resort' behavior is what most people will encounter when removing a screen. Implementing just (1) and (4) for starters would solve most use cases I think. Adding (2) and (3) just add additional flexibility to those that really want it.
> Is it something in .kde/share/config/{plasmarc,plasma-appletsrc} appletsrc; look for screen= in groups with plugin=panel > perhaps just add a few more behavior parameters to the panel > itself first, we (plasma) don't add configuration where a proper solution is plausible. that's just punishing the user for poor implementation and crowds out items that really should or need to be configurable. second, the scheme you suggest, even if automated, fails in the case of the person who plugs a screen in and out often. there are several use cases here, and i think that the bookkeeping method actually works to cover as many as possible.
By bookkeeping, how about recording for each panel: map< {set of active screens}, {placement} > for example: {0,1} -> screen 1, bottom {0} -> screen 0, top {1} -> screen 1, bottom Whenever the user moves a panel it simply updates it's entry for the current screen layout. With this, the only time any sort of heuristic would need to be applied is when a user adds or removes a screen and there exists a panel with no entry for the resulting screen layout. Here's a heuristic that would work: (1) panels with an entry for the layout get moved to their stored positions for the layout (2) panels w/o an entry for the layout: (a) not conflicting with (1) that are on an active screen stay put, and get an entry added (b) panels now conflicting with (1) get moved first in step (3) followed by (c) any panels remaining on a screen that was removed get moved in step (3) (3) move panels by: (a) see if any postions are available from other layouts, starting with 'best matched' layout (b) if it's on an active screen already, find any available edge on an active screen (c) if it's not on an active screen, find any available edge on the currently focused screen (starting with the same edge it was already on if possible) (d) find any available edge on other active screens (starting with the same edge it was already on if possible) (4) add the appropriate screen layout entries for all panels from (2) and (3) that are successfully placed, as necessary (last), if there's no room for one or more panels - set their position to 'nowhere' - add a selector menu that is common to all of the panels' panel menu that lets them swap a 'nowhere' panel with the panel at that position (placing that panel 'nowhere' in turn)--this at least makes the remaining panels accessible, and in a uniform manner. (2b) is the only really touchy part of the heuristic, here's one use case: - user adds panel-1 to screen-0,top - user adds screen-1 - user moves panel-1 from screen-0,top to somewhere on screen-1 - user adds new panel-2 to screen-0,top - user removes screen-1 at this point: (1) places panel-1 on screen-0,top from it's entry (2a) has panel-2 in conflict (2b) goes to (3) to place panel-2 (3a) fails, since panel-2 has no entry for the {screen-0} layout yet (3b) moves it to either bottom, left or right (4) adds an entry for it on the {screen-0} layout The question that we can't answer is "did the user really prefer panel-2 going back to the single screen-0 layout?". But, with both available the user can move them, and from then on, the settings would be remembered and honored. Another option that should probably be added is the ability to set a panel to 'nowhere' even if there is room for it. Take the above use case for example. Assume the user had placed panel-1 on screen-1,top. It's possible that both panel-1 and panel-2 are redundant, and only one is desired in the single-screen layout. The first time the panel is moved on him, the user could select 'nowhere' on it, and from then on both layouts would have one panel per screen at the top edge.
that's pretty close; i think it can be simplified in a few ways, though. first, all panels always have an associated screen and edge. if they are edge-based, then they are marked as Floating (though we don't actually support floating panels atm; i really should implement that in PanelView in plasma-desktop for 4.4) and can be completely ignore for the purpose of this exercise. second, i'm not sure if we need to worry too much about trying to change the edge of the screen the panel is on when moving it from a non-existent screen. for example, if i have a panel at the bottom of both of my screens and i remove one of the screens ... do i really want that bottom panel to now appear on the other screen? in some cases i might, but i'm not sure it's really needed or even wanted. at the very least, i doubt i'd want it on the right edge of my screen when it was previously on the bottom (this assumes there's a panel at the top and bottom of my screen). but then again, maybe i would. depends on the panel, probably. *thinks* one option would be to offer a dialog at that point asking the user if they'd like the panel to be moved temporarly, permanently or left off-screen, with an "always for this panel" checkbox in it. then it only needs to decide where to move it to, using a heuristic like the one you outline; e.g. if the panel is on edge X: * check each existing screen's edge X * if no such screen edge is available, check each existing screen's complimentary edge X (so, top <-> bottom, left <-> right) * if still no such screen edge, try the non-complimentary edges "check" would consist of seeing if there would be overlap with any existing panels. e.g. i may have a bottom edge panel on screen 0 that occupies the left 25% of the screen and a bottom edge panel on now-non-existent screen 1 that occupies the right 25% of the screen; they actually both fit on the same screen on the bottom edge. if there are no such available spots, perhaps it could just tell the user that there is nowhere to put the panel (with a passive notification in the tray?) and leave it where it is. besides figuring out the "right" heuristic and user interaction, there are the implementation details. it would probably need to be calculated on every start of plasma-desktop, after all the panelviews are created (otherwise detecting edges may not work due to order-of-creation). PanelView could keep all of this informaton to itself, but then the panel containment doesn't know it's on a different screen. this would cause problems for screen based behaviour variances, such as the task widget's "show only windows on this screen" since "this screen" would actually be "that other screen which doesn't exist anymore" and so would probably remain forever blank. so i think the View should manage the move but set the containment's screen to be actual screen it ends up on for that session, remember what screen the panel actually was on previously and make sure that gets set in the configuration file properly (on exit? sucks for crashing). makin sure that works properly would be the trickiest bit, probably, since it would be all about timing (when and where to ensure the proper value was placed there).
whats the status of this bugreport? can it be closed as won't fix?
I am using KDE 4.3.2 on Debian unstable, and I usually work on the leftmost display, which is the external display if one is attached, and the laptop's display if there is no external display. When I started with KDE 4, which was about three weeks ago, the main panel was always shown on the bottom of the leftmost display, as it was working for years with KDE 3. Suddenly, last week, without no updates to the system being done, my system began showing the behavior which is described in this bug report, leaving me without panel when undocked. This is a serious regression over KDE 3 and a severe annoyance. Please implement a fix. Greetings Marc
*** Bug 218716 has been marked as a duplicate of this bug. ***
as for comments #13, and #14: I do not agree that #218716 is a duplicate for the following reasons: (1) It used to work on my KDE 4.3.2 and suddenly broke (2) on my system, it doesn't help to manually move the panel to the other screen. This is a severely annoying issue which severely reduces KDE's useability. Especially since there are widgets such as the tray which can only be in one panel at a time. Greetings Marc
*** This bug has been confirmed by popular vote. ***
Will it be possible to move the panels by some kind of script? Maybe with a dbus call. Then the user could simple add a script after the login, where he checks the available displays and call xrandr with the specific setting, and move the panels at his will. Greetings Fran
that might even be possible with the new plasma scripting api...
yes, the scripting makes this possible, though the user would have to start the script themselves.
in 4.5, panels are now migrated to to still existing screens as long as no other panels are in the way.
Ugh... I thought that jumping panel from external to internal laptop screen when logging in without external screen connected was a bug, but then I found this ticket... It's really annoying, I made panel for second screen and I want it only on that second screen - on my primary screen I already have my panels as I want. Well, looks like I'll have to do some script. Fortunately I know how to tackle that, but well, not everybody does. I think it should be somehow configurable.
Actually, #238817 :/
Hi. Whats the code that fixes this bug, or, which commit? I would like to revert it myself as I enjoyed having two panels on each screen and this bug prevents me from doing that correctly. Thanks.
I have quite opposite issue. Panel moved back to my laptop.. but then I connect external monitor it remains on the laptop. But desirable move will be as bug creator says.. make panel only on this monitor.. some kind of binding.. Is it possible?
I second Maksim's idea. In addition in my case, I have two screens for either external displays (when laptop is in dock) and when I disconnect both of them the both panels are moved to my laptop screen, one covering the other.