GNOME Bugzilla – Bug 619888
search_window_x_pos and y_pos set to -32000
Last modified: 2012-05-12 16:05:28 UTC
Running Windows 76 x64, GTK# 2.12.9-win32, Tomboy 1.2.0 from MSI install. I had Tomboy running fine, but suddenly the 'Search all notes' window did not appear. I can't recall any notable system changes around the time the 'Search all notes' window stopped appearing. Fixed by deleting and re-creating the prefs.xml file, this was the offending entry: <search_window_x_pos>-32000</search_window_x_pos> <search_window_y_pos>-32000</search_window_y_pos> Could this possibly be caused by detaching and re-attaching a second screen? That's the only thing I can think of that occurred around that time.
This value is read directly from Gtk, using GtkWindow.GetPosition. Were you able to reproduce this behavior? Do you remember some more details about the second monitor? Did you make it the primary desktop or not? Did you add it to the left or right? Trying to find a recipe to reproduce it on my machine (and hopefully to fix it).
Hi there, I've had the behaviour a second time, after adding a third monitor temporarily using a Toshiba Dynadock (this is a universal dock that connects by USB and uses Displaylink to connect an additional screen). The third screen was a Samsung Syncmaster 740N. The third screen is now disconnected, but the x_pos and y_pos in prefs.xml read -32000. This hasn't been an issue when connecting / disconnecting my second screen (not since the original bug filing) and / or connecting via RDP, it was only the third monitor that did it. Let me know if you need any further clarification. Cheers, Ben
Regardless of what's causing it, we probably should not accept negative values for those prefs (unless those are somehow valid in a multiple monitor situation).
I experienced the same error when using version 1.2.x as well as version 1.4.1. I used two screens with extended desktop switched on. The second screen was left of the primary desktop. Operating system used: Windows 7 64 bit.
any news for this report?
I too am experiencing the same problem on: Windows 7 32 bit Tomboy 1.4.2 Could someone please tell me where to find the "prefs.xml file" mentioned in the first post? I looked under c:\Program Files\Tomboy and under c:\Program Files\GtkSharp but could not find it anywhere. Thanks.
(In reply to comment #6) > I too am experiencing the same problem on: > Windows 7 32 bit > Tomboy 1.4.2 > > Could someone please tell me where to find the "prefs.xml file" mentioned in > the first post? I looked under c:\Program Files\Tomboy and under c:\Program > Files\GtkSharp but could not find it anywhere. > > Thanks. for this comment confirm the bug, change the status,
*** Bug 641980 has been marked as a duplicate of this bug. ***
Per http://live.gnome.org/Tomboy/Directories : Windows Notes: %APPDATA%\Tomboy\notes\ Configuration and add-ins: %APPDATA%\Tomboy\config\ Caches: %LOCALAPPDATA%\Tomboy\cache\ Log: %LOCALAPPDATA%\Tomboy\tomboy.log
I confirm that I also have this bug on Windows XP, Tomboy 1.4.2 and it seems to certainly be related to the extra monitor.
I can also confirm this bug is present in Tomboy 1.8.3 in Windows 7 64. But I don't have an extra monitor. Single monitor desktop computer. A quicker fix is to use the 'maximize shortcut' (Windows key + Up), after switching via Alt+Tab, and then dragging with the mouse and re-sizing. Since the thumbnail in the task-bar showed a black icon at first, I thought that it may simply be a frozen windows, but when I read the description of this bug, and then tried the aforementioned remedy, I was surprised to finally see my 'Search All Notes' window. This may also be a separate bug, but it may or may not be related to a crash when enabling and disabling the Web synchronization service (since I re-installed Tomboy because of this bug, I've been unable to synchronize).
Like spammy_bp, my prefs.xml had large negative numbers, abet not both -32000. <search_window_x_pos>-30400</search_window_x_pos> <search_window_y_pos>-32000</search_window_y_pos> Rolando's suggestion of the maximize shortcut does work, but if you then un-maximize the search window, it vanishes again. This behavior is occurring on Tomboy 1.8.3 on Windows 7 64 bit. It just started happening, although I have been installing a number of new software packages lately including gimp and Python. Tomboy is .Net though, correct? And I have not installed a .Net based package lately.
I forgot to mention. This is a multi-monitor system with an nVidia eVGA 7950GT. It is an i7 2600K with 16GB RAM.
Frederick: I think you didn't follow Rolando's full advice: When it is maximized, drag it away from the edge (restoring it, but still dragging) and fix the size afterwards. Another possible workaround: Alt-Tab to that window and press Alt+Space (Opens the system window, from the top left corner of that window) M (Selects 'Move') Any arrow key (moves the window one tick to the direction of that key) The window is now in ~floating~ mode and follows your mouse. Move the mouse pointer to see it on your screen, drop it by clicking. Apologies for still having this bug in the first place.
Created attachment 210823 [details] [review] Proposed fix Negative coordinates are valid for multi-monitor configurations on Windows, when primary screen is not the topmost and leftmost one in the setup. Details here: http://msdn.microsoft.com/en-us/library/dd145136%28v=vs.85%29.aspx At the same time these coordinates are way too big to be valid anyway. We could just reset any negative coordinates to (0, 0) but it doesn't look too nice to me. Attached is the proposed more generic solution I'd like to get your feedback on. Built around on the Gdk.Screen.GetMonitorAtPoint (http://docs.go-mono.com/?link=M%3aGdk.Screen.GetMonitorAtPoint%28System.Int32%2cSystem.Int32%29) which returns either the number of the monitor where an (x, y) point is located, or nearest one. We store the monitor number along with the coordinates and upon restoration check whether it's the same number or not. If yes - we assume the monitor setup didn't change and restore to saved coordinates, if it doesn't match - we restore to the center of the monitor returned by that function (should be the "nearest" to the desired one, whatever they mean by that). It compiles and works for me both on Win and Linux but I unfortunately don't have a multi-monitor setup right now to test. Maybe will have in a couple of days. In the meantime anyone willing to test - feel free to try the patch or let me know if you want the binary debug build.
For the record: I am able to duplicate this on OpenSuSE 12.1 by opening the search Window and placing on the external monitor. Then shutdown Tomboy, disconnect the monitor, startup Tomboy. The Search Window, when opened will open on the external monitor (that isn't connected)
It doesn't work for me. I followed my steps above to duplicate and it still opened to the disconnected Monitor. [INFO 19:07:34.310] Monitor number returned by GetMonitorAtPoint (actual) is: 1 [INFO 19:07:34.311] Saved monitor number is: 1 [INFO 19:07:34.311] Saved Search window position is 2423 x 276 [INFO 19:07:34.311] Saved monitor number does match the actual one - restoring as-is [INFO 19:07:34.311] Restoring Search window to position 2423 x 276 at monitor 1
Hmm, interesting, thanks Jared. I've got my multi-mon setup working today and tested this in and out on Windows 7 (primary OS on the box) and a little less than that - on OpenSUSE 12.1 (runs in VMware Player and has known troubles with video drivers from VMware tools, so it doesn't recognize several monitors when I set it, but I was able to simulate that using Unity mode). What's strange - it works as expected for me :) I.e. when on Windows I (1) just unplug the additional monitor or (2) close the window on the additional monitor (so the position is saved), then reboot the machine and unplug it during the reboot or (3) close the window on additional monitor then change the setting from dual-mon to single-mon - all the time then if I open the window - it detects the monitor config change and restores it to the center of the new main monitor. On Linux as I said it was trickier, but I was able to simulate multi-mon using Unity mode (which is when Player shows the Guest windows like if they are running directly on the host system) and dual-monitor mode on the windows side. I was able to drag the Search window to my second monitor, close it, then exited the Unity mode (which turned Guest back into usual window), then restored the window - it told me the mon number is different and restored it properly. Jared, I wonder how specifically did you disconnect the monitor? Meaning - did the OS realize there's no second monitor now? Windows does detect that even if you simply unplug it, but maybe your window manager doesn't (or it depends on the specific way you did that)? That's how it looked like on OpenSUSE for me: [INFO 21:35:12.808] Monitor number returned by GetMonitorAtPoint (actual) is: 0 [INFO 21:35:12.815] Saved monitor number is: 1 [INFO 21:35:12.815] Saved Search window position is 1996 x 57 [INFO 21:35:12.815] Saved monitor number does NOT match the actual one - restoring to the center [INFO 21:35:12.817] Restoring Search window to position 458 x 184 at monitor 0
...and I've just realized the problem with VMware Player and multi-mon was not due to drivers and was able to properly simulate multi-mon setup for OpenSUSE as well. So when I click the "switch monitors" button in Player (which switches between dual-mon and single-mon modes) my Gnome immediately detects that and reflects that in the System Settings->Displays window and Tomboy with the patch detects that as well. So it must be something different in how we do the monitor switching. Would be interesting to hear from other people to check different configs and ways of switching the monitor setups.
Anyone else having desire to test this patch out? I can provide pre-built package for those who don't want to mess up with patching and compiling.
Do you want me to test on Linux more? I don't have a Windows machine to test with :)
Yeah, would be nice in any case :) It seems like it doesn't really matter whether it's Linux or Windows, rather it depends on the the "window manager" - whether it detects the disconnection properly or not. As I mentioned before - in my case OpenSUSE 12.1 behaved just fine with the patch, so I'm curious whether it's just Gnome (or whatever you use) not detecting the disconnection in your case, or something else.
OK; I will test to night and see if I can capture more information to maybe help. Yup, i'm using GNOME-SHELL.
Thanks Jared. Anything you've got out of testing? Frederick or Rolando (as two last and relatively recent reporters) - don't you want to check it out? Or you no longer see the problem?
Hum. I can't tell any difference between this patch and no patch (on OpenSuSE with GNOME-SHELL) I haven't been able to test on Windows. I'm not getting any entries in the system logs that would help either. If you can tell a difference on Windows, then I would say we should apply it. If I "properly" disconnect the monitor I don't have problems with this. It's when I pull the monitor cable that the problem happens. So maybe most people disconnect properly :)
Looks like the fact that OS detects the disconnection would be a key here. If it doesn't detect that - the function doesn't work, but in such a case nothing (IMHO) will be able to tell that the monitor is actually gone. Even the OS itself will try to work with it. Though again - I wasn't able to reproduce that on either "real" Windows or virtual OpenSUSE. They both were detecting disconnection just fine even if I just pulled the cable (in OpenSUSE that was clicking the "single/dual" button). If it does detect that - the patch does the job and while the Tomboy has wrong [for that moment of time - the monitor is disconnected] coordinates in the settings - it detects that and places the window accordingly.
Review of attachment 210823 [details] [review]: Passed testing. No one else commented on the patch. Commit r5e53a5e1b984
Shouldn't we set the bug to resolved in view of the fact the fix made it into the code?
Closing: Fix has been committed and hasn't caused any known regressions.