GNOME Bugzilla – Bug 606110
note window position is out-of-range of the current screen size
Last modified: 2012-12-18 04:44:06 UTC
as a laptop user i often work with an external screen. when I move a tomboy note, say the the external windows that goes beyond the laptop screen size, after disconnecting the external screen, i can't access my tomboy note anymore, since the note position is saved in the note it-self. therefore while showing a note, tomboy should check if the note is within the range of screen size. my current work-around is to exit tomboy, go into notes directory, grep for the note, and edit its <x> and <y> preferences.
Will try to look into it tomorrow on my work laptop. Quick note on the workaround for now: If that happens again: Press Alt + Space (opens the system menu on windows from the upper left corner) Press M (hotkey/accelerator for "_M_ove") Press any single cursor key (Up, Down, Left, Right) to move the window 1px in any direction Move the mouse. The window will now follow your mouse pointer (which is visible) and you can easily put it whereever you want (just click to "drop" it) Worked for similar and related problems for me.
Confirming. One possible long-term solution is to stop storing this information (and other system-dependent metadata) in the note file. But we definitely need to at least check when opening the note that it's going to be visible.
This bug is highly related to #608164. I think a good solution would be to trust the stored information because it's nice when a certain note always appears in a particular location, but after the construction of the Window, there should be a check that the rectangle is within the viewable screen area. If not, reposition it. By the way, why wouldn't this also occur on Linux in a dual-screen setup? Does Gnome fix window positions automatically if they're off the screen?
Probably bug #604059 is really the same issue.
*** Bug 646520 has been marked as a duplicate of this bug. ***
I can no longer reproduce this issue with Tomboy 1.5.2 on Ubuntu 10.10. It hasn't been addressed in Tomboy, but I suspect it was fixed Gtk or Gtk#. It looks like if the X or Y arguments to Window.Move() are beyond the extent of the Window's Screen, it resets the invalid argument with a valid one. Can anyone else confirm? If someone can reproduce the issue and let me know what Tomboy version, operating system and version, window manager they're using, I'd appreciate it. I'm certainly not against having Note check that it's going to be displayable before opening. I've actually already got a patch, but I wanted to see if this is even still an issue and to determine where and how it was fixed outside of Tomboy.
Greg, this is a Windows-specific bug.
Aha. Thanks. I can test that too. Maybe we need an OS field for Bugzilla. :-/
(In reply to comment #8) > Aha. Thanks. > > I can test that too. Maybe we need an OS field for Bugzilla. :-/ There is one. See below the comment area. :-)
Hahahaha. Why would I ever look past the comments section?! *facepalm*
Anyway, I'm tempted to just add a check in the Note class so that if the X,Y position of the NW corner of the note is outside window.Screen.Width or window.Screen.Height, we move it to something like 100,100. This should take care of the "it's under my taskbar" bug as well.
Created attachment 185166 [details] [review] Move notes off screen into viewable rectangle If someone would please take a look at this patch and test it out against git head, I'd really appreciate it.
Review of attachment 185166 [details] [review]: ::: Tomboy/Note.cs @@ +1126,3 @@ + x = 100; + else if (ne_x > window.Screen.Width) + x = window.Screen.Width - data.Data.Width; If the width > Screen.Width, we'll end up pushing the the NW corner off the screen. I think in this scenario we actually want to end up in the second clause: x=100 and let the rest hang off the right of the screen. @@ +1132,3 @@ + y = 100; + else if (sw_y > window.Screen.Height) + y = window.Screen.Height - data.Data.Height; Same as above.
Created attachment 185174 [details] [review] Check extent and position of saved notes Checks the extent and position of saved notes to make sure that they are sane. If not, it corrects them.
Review of attachment 185174 [details] [review]: ::: Tomboy/Note.cs @@ +1122,3 @@ + y = data.Data.Y, + ne_x = data.Data.X + data.Data.Width, + sw_y = data.Data.Y = data.Data.Height; typo = instead of + sw_y = data.Data.Y + data.Data.Height; Missed this before.
Created attachment 185189 [details] [review] One more time Thanks for the good eye, Aaron.
Review of attachment 185189 [details] [review]: Greg, I looked at this again but I'm not convinced that it protects against that condition I mentioned in my first comment. Let me know if I'm missing something. ::: Tomboy/Note.cs @@ +1128,3 @@ + x = 100; + else if (ne_x > window.Screen.Width) + x = window.Screen.Width - data.Data.Width; My first comment still stands here. When data.Width is larger than screen.Width, you'll end up moving the note off the left side of the screen. The stuff on line 1115 will only prevent the window's initial width/height from being set, but doesn't affect data.Width/Height which you are using to position the window. I would try to either add another condition here or you can clamp data.width and data.height.
Okay, I didn't quite understand what you were pointing out before. Thanks for the catch. I'll address that in the next version.
I thought this has been addressed by another patch and is now working properly.
As posted on the mail list - I think that's just a different case, that fix was for Search All being off the screen. Unless Greg is willing to continue, I'd take this one, going to tackle it in the nearest couple of days.
BTW, that was bug 619888 where we fixed the Search window
Created attachment 229308 [details] [review] Proposed patch v1 Here's my take at it, taking into account Aaron's notes and also the fact that on Windows we may have negative coordinates in some multi-monitor configs. Tested to work with different problems with the note coords/dimensions on Win7. I haven't added anything to "HasExtent" clause, mainly because I assume we can't have a note with width/height but without coordinates, please correct me if I'm wrong. Other than that - the logic in the "HasPosition" clause handles both wrong dimensions and coordinates. Your feedback is highly welcome.
If someone wants to have a debug build instead of the patch - just let me know.
Review of attachment 229308 [details] [review]: Looks good. Instead of choosing a hard-coded clearance, it would be better to query the taskbar/panel height/width and use that. I believe there is some API that will get the "available" screen height/width which accounts for taskbars/panels but I'm not sure if they work cross platform. I'm fine to commit as is.
Thanks for the review Aaron. Let me do some research on the API you mentioned and get rid of the hardcoded clearance if that's available cross-platform (or report here if it's not).
Created attachment 230123 [details] [review] Proposed patch v2 Looks like there's indeed something we could use to get the actual working area of the monitor (less the taskbars, etc). Surprisingly it comes from .NET (and is implemented in Mono) - System.Windows.Forms.Screen.GetWorkingArea [1]. It indeed works nicer with it both on Windows and Linux. Recognizes toolbars, whereever they are and allows us to position the note window more precisely. We still need some hardcoded clearance - to account for window decorations, because that information is not available to us during the window creation (where the code in question is). But it is more of a "to make it nice" kind of thing than in the previous case, because we now sure we won't overlap with taskbars. There's one potential caveat and I'd like to get your opinion on that - I had to add two assemblies into Tomboy's Makefile.am - System.Windows.Forms and System.Drawing. Does anyone see any problems with that? According to Mono-WinForms list [2], this was implemented quite long ago, at least in Mono 1.1.4 and we require 1.9 for Tomboy - so I personally don't think that should be a problem, but let me get your view on that. This patch tested to work as intended (and avoid hitting the taskbars :) ) on Win7 and OpenSUSE 12.2 (Gnome-Shell). [1] http://msdn.microsoft.com/en-us/library/1a92hss5.aspx [2] http://lists.ximian.com/pipermail/mono-winforms-list/2005-February/001421.html (and using this function is part of the examples mentioned there)
Aaron, could you please review that second one? I'm fairly sure it's going to work, but nothing can be better than a peer review :)
Looks like Aaron is too busy to look into this one, could someone else please review that? The changes from the previous patch accepted by Aaron are minimal and are only around that System.Windows.Forms which I don't see as any kind of problem, to be honest, but just want to make it explicit to make sure.
Review of attachment 230123 [details] [review]: Alex, After talking with Sandy a bit we've decided that the Winforms dependency is too risky. Mainly because it also will require other libraries that will increase the dependency greatly. Would it be possible to talk with the GTK+ guys or directhex and see if there is another way to fix this? Sorry, but Ubuntu is really picky about install size and we don't want to step on their toes more than required.
Ok, I'll take some further look into other ways of implementing that. Thanks for the review and feedback.
Created attachment 231677 [details] [review] Patch v3 After further exploration I would say there's no cross-platform consistent way to account for taskbars/panels other than that introduced in my patch v2, just like Aaron suspected. There was one possible opportunity in a form of Gdk.Global.ListDesktopWorkareas, but it doesn't work on Windows (uses native calls to X server at the backend). So I propose to get back to the approach introduced in patch v1, reviewed by Aaron. Attaching slightly updated version which changes only two things: 1) replaces Logger.Info with Logger.Debug to hide the messages until really needed; 2) removes a comment regarding the fact that screen coordinates may be negative on Windows - further experimenting shows that GTK remaps that to the (0,0)-originated space, even though the Windows itself works with negatives as documented;
Review of attachment 231677 [details] [review]: commit 3cc89715485e426c842fce12c124a08cf4d749b8