(*** This bug was imported into bugs.kde.org ***) Package: kcmkwinoptions Version: 2.0 (using KDE 2.1.1 ) Severity: wishlist Installed from: compiled sources Compiler: gcc version 2.96 20000731 (Red Hat Linux 7.0) OS: Linux 2.4.2 i686 OS/Compiler notes: In the window placement options for center under cursor and manual would be good... I dislike having to scroll across two monitors to get the window that pops up in the top left corner (Submitted via bugs.kde.org) (Called from KBugReport dialog)
*** Bug 23711 has been marked as a duplicate of this bug. ***
As of KDE 3.5.5 window placemet "Center" is already implemented. But KDE is still lacking placement "Manual" - to have window placed in a spot pointed by user (with a mouse click). (so hard to accept anything else when you are used to... especially when using large virtual screen) Please at least CONFIRM this feature request... Thanks
I'm not sure if anybody is at all yet interested in solving this request. Yet in early 2007 I did a simple (at flawed) patch to add Manual Placement to kwin in KDE 3.5, but never improved it seemed pointless since KDE 4 was coming... Now, once Fedora upgraded me to KDE 4.2 (4.0 & 4.1 was really painful) I decided to give it another try. So - if you are still reading, and you are still interested - there is one issue to discuss. If multiple windows opens in the same time (i.e. application opens many windows at a time, or one application starts slowly and another is started just after - both may display a window in the same moment) we need to figure out best way to handle it. We cannot 'Manually Place' two windows simultaneously... Propositions (easiest to implement first): 1. First window opened is handled as 'Manual Placement', and until this window is finally positioned (mouse clicked), any window that have opened in the meantime is handled as a 'Smart Placement'. 2. When new window arrives while the previous is not finally positioned (mouse clicked), previous one is left where it has floated at the moment, and the new one is now processed as 'Manual Placement' 3. When new window arrives while the previous is not finally positioned (mouse clicked) it waits in the queue (is not even displayed) until processing of the previous is done. Any better idea?
(In reply to comment #3) > 3. When new window arrives while the previous is not finally positioned (mouse > clicked) it waits in the queue (is not even displayed) until processing of the > previous is done. This one but it would be nicer if there was some notification that there are windows in the queue. Maybe the queued windows are all shaded and placed at the bottom of the screen for instance?
A manual placement strategy would require to change the implementation. The current placement strategies do not require user interaction, but a manual would require user interaction. It is hard to say whether this feature request would improve the user experience for enough users to justify such a change. Due to that I would currently say that this request won't be implemented. I suggest to get feedback on the idea on forum.kde.org. I want to thank you for the feature request and I am sorry that it took such a long time to find a decision on the request.
*** Bug 45488 has been marked as a duplicate of this bug. ***