Version: unknown (using KDE 3.4.1, Gentoo) Compiler: gcc version 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1) OS: Linux (i686) release 2.4.27 Hi, I have xinerama setup where my kicker with system tray is on the right screen, everything works fine but the KPassivePopup that are shown are located at the x and y location gotten from the right screen not taking notice that it should ad some x and possibly even a y value for the left screen. example the resolutions i'm running are 1600x1200 and 1680x1050 now a popup should apair on the second screen on location 1660x1050 taking notice of the left screen this would become 3260x1050 for the location but with kpassivepopup this is somehow not done and the popup is place at 1660x1050. I don't know if it has been fixed in upcoming versions but in my setup it exists. hopefully I have given you enough information kenny
I had a fix for this but nobody cared. Not sure if I still have a patch on my hdd.
It still happens with kde 3.5.0 and 3.5.1 on gentoo, x86.
How should one reproduce the problem? Works just fine here.
Worksforme, no response.
Unfortunately I forgot to put myself on the CC list and so did not notice the reply (thought CC would be automatic for commenters). This happens on KDE 3.5.5 built from Gentoo packages. Note that I am not sure about the passivepopups, because I cannot really find an app where I am 100% sure that I trigger a passive problem. Here is a way to illustrate the problem, even though it may not be a passive popup: My monitors are set up like so: +-----+-----+ | | | | 2 | 1 | | | | +-----+-----+ The Main Panel is on 1 (top) start konversation/ktorrent/kmix Hide it to the system tray use the context menu to select quit The box with "are you sure you want to quit" will appear on Monitor 2. Note that this does not happen with kbluetoothd so either it is depending on the app. For the quit box this is not a huge deal, unless you have a setup like such: +-----+-----+ | | | | 1 | 2 | |xxxxx| | +-----+-----+ Where x marks an area that is not shown and either completely missing or only accessible via panning screen 1 (this is the case for NVIDIA twinview and most laptop users that have a larger external screen than their internal resolution). If the main panel is on screen 2 on the bottom, then the quit box will be displayer in the area marked with x it is not immediately obvious that it appears there.
Created attachment 18553 [details] Screenshot with panel left With the panel on the left side, the box is placed at the correct position.
Created attachment 18554 [details] Screenshot with panel right With the panel on the right, the message box gets placed on the left screen. Notice that it is placed flush on the right boundary, even though the left screen is larger (1400x1050) than the right one (1280x1024). According to the above comment, the message box should be placed further to the left (if the distance from left border on the right monitor is taken on the left monitor). It could be a difference in implementation of kPassivePopup and that message box.
This doesn't seem to be related to kpassivepopup at all. Reassigning to konversation
First of all, I stated in my comment that I did not test it for kpassivepopup but that this is the way that it can be reproduced. Possibly there are two issues here. I will try to see if I can reproduce it with kpassivepopup proper. About the reassignment to konversation, I think it is unlikely that konversation, kmix and ktorrent all implement the quit message box separately and all exhibit the same strange behavior. But assuming that you are correct in moving it from kdelibs, should I file separate bug reports against kmix and ktorrent as well?
(a) The quit-from-systray dialog box is spawned in KSystemTray, not Konversation. We do nothing to influence its placement. (b) The quit-from-systray dialog box spawned by KSystemTray is a KMessageBox, not a KPassivePopup. (c) You might want to check out Lubos' Xinerama patchset mentioning, among other things, improved dialog placement behavior: http://www.kde-apps.org/content/show.php?content=40586
Reassigning back.
Re (b) Then I am talking about a different issue here and the bug is possibly misassigned. Anyway, the illustration about what is happening could apply to passive popups as well, as I said I do not know for sure which application uses kpassivepopup. Re (c) I will try the patches and report back.
Created attachment 18569 [details] Screenshot Panel right with paches from comment 10 Panel on the right side with patches from comment 10 does place the box on the right screen. However the box does not appear as close to the selected tray icon as one would expect from the original one screen behavior
Created attachment 18570 [details] Screenshot Panel left with paches from comment 10 The behavior on the left screen with the panel on the left is made worse by the patchset, the box does not appear close to the tray icon any longer, instead it appears centered.
I see a similar problem when I use xinerama/xrandr to place a monitor (Xinerama #1) to the right of my laptop's screen (Xinerama #2). Clicking the KDE K (K) in the lower-left of my laptop pops up a menu (kkk) on the left edge of the monitor, while right-clicking on firefox/iceweasel (III) links (L) on the monitor pops up menus at the corresponding location (p) on the laptop's screen. 2048x768 ---------------------------- | #2 |k #1 | | p |k IIIILII | | p |k IIIILII | K===========================| The browser popup link problem seems OK if I position Screen #1 above #2, but still the panel menu appears far from the pointer when I click on the K.
Does this still occur in KDE4?
no response to question in two years. I assume the bug has been resolved by now.
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 set the bug status 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!
Dear Bug Submitter, 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!