On a dual-monitor system (TwinView) where the right monitor is the primary one, KTorrent always opens on the left monitor (which is otherwise unused, in my case it's a TV that's turned off). This is the only KDE app where I've noticed this happening - all others seem to open on the primary display. Reproducible: Always Steps to Reproduce: 1. open ktorrent on a dual-monitor setup where the right monitor is the primary one (and the only one being actively used) Actual Results: ktorrent opens on the left monitor Expected Results: The first time ktorrent runs, it should open on the primary display. Future invocations can either do the same, or better yet, remember the last position (and take into account the monitor configuration which can change e.g. with a laptop connected/disconnected from external monitor - for each configuration it can save the position, or just go back to the default if something changes). Running on Kubuntu 12.10, KDE 4.9.3, KTorrent 4.2.1, NVidia TwinView.
The window manager decides where to show windows, ktorrent has no influence on this. I believe you can configure this behavior in KDE's system settings somewhere.
Just to verify it, I've just tried opening some more KDE apps that I've never used (or heard of) before - some games/utilities etc. that come pre-installed with Kubuntu - they all open correctly on the primary monitor. And yet every time I start KTorrent it opens on the wrong monitor and I have to move it over to the primary one. Perhaps KTorrent does something that interferes with or confuses the window manager and causes it to change its behavior from what it does with all other windows? Or maybe there's some KTorrent-specific configuration laying around somewhere on my system that's causing it to behave differently? Any other ideas? Is there anyone else with TwinView that can try to recreate this on a similar setup (with the right monitor being the primary)?
Reassigning to kwin, not a ktorrent problem
Windows open on either the panel where the currently active window or the mouse cursor is. ("kcmshell4 kwinoptions" to configure whether the active screen follows the mouse) In case they don't that means the client requested a specific position to appear at (generally granted) - you can override that by creating a rule in "kcmshell4 kwinrules" and set "ignore requested geometry" to "force" and "yes" (the client can still reposition itself later, though). Esp. if this workaround works (but not restricted to that case) the bug is indeed at ktorrent - the WM cannot prevent windows from being on a "powered off" screen, because it does not know about that (and only for few screens even could) - every screen set active in "kcmshell4 randr" is taken as "usable workspace area". Ktorrent will (maybe implicitly through the systray implementation?) call for a specific position and in calculating that, pot. ignore the geometry offset of the right screen (thus accidentally place it on the left)
The suggested workaround (ignore requested geometry - force - yes) indeed works - with that in place, ktorrent opens on the primary (right) display, on its top left corner. However it no longer remembers its position while it is already running in the system tray - e.g. moving the window to the center of the display and clicking the systray icon twice causes the window to be hidden and then re-appear again on the top left corner (where it was originally opened). Removing that configuration setting and reopening ktorrent once again opens it on the wrong (left) monitor, but it remembers the location as long as ktorrent is running, i.e. when clicking on the tray icon twice (I just did it again for confirmation).
Conclusion: it is a ktorrent issue. See former post. @Joris Whether this is due to some Q/KSystray feature, i don't know. In case please move it to kdelibs and/or Qt. @Amichai Rothman "Minimizing" to systray actually closes the window and creates a new one when you restore it, so the position is not "forgotten" (but just never set, resp. the attempt to set it is denied by the WM because of the rule) Alter the rule to "remember" position (and eventually size) on the second tab (this will re-apply the last known geometry whenever such window appears, you don't have to enter values there - you will most likely still have to "ignore requested geometry")
Just to clarify, without any workaround/rules set, when the window is opened/closeded from systray it *does* remember its last position and reopens there, but after quitting KTorrent entirely and then relaunching it, it *doesn't* remember its last position, and always opens on the aforemntioned left (non-primary) monitor. I have no idea what the root cause is, but the behavior is definitely different on first launch vs. when opened/closed from systray (the bug occurring on the former). I also discovered that amarok, which is also a systray-based application, exhibits the exact same behavior (first launch is on wrong display, whereas subsequent open/close from systray does remember position). Those are the only two applications I've found so far that do this - everything else opens properly on the primary display. I've also tried e.g. Konversation (also systray-based), but it behaves differently - first launch is on the top-left corner of the primary display (so no bug, but no memory), and subsequent open/close from systray does remember position. I hope this helps...
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!