GNOME Bugzilla – Bug 527177
Prefs dialog covers up notes
Last modified: 2017-07-31 12:42:14 UTC
I suggest that the preferences window not be set to forcibly cover any Tomboy notes, as it is possible that one would want to look at or edit notes while the preferences window is open. At the VERY least, however, it should not obstruct the New Note Template. Other information:
Just writing to confirm that this bug is still present in the 0.12.0 release.
Yeah, you're right, this makes editing the New Note Template kind of a drag. Targeting for this cycle. I can't think of any problems with letting you edit notes while this dialog is up.
Created attachment 150948 [details] [review] Patch makes note template window modal This is a little weird, honestly. As far as I can tell, Gtk.Dialog is meant to be on top at all times--which is why setting KeepAbove and Modal to false didn't do much. I think it has to do with Gtk.Window.TransientFor, but I'm not sure what prefs_dlg is using as its parent. Anyhow... setting the note template window as Modal allows it to take focus when the button is clicked. It also allows you to give focus back to the prefernces dialog. This was a little unexpected, but I guess it has to do with using Present instead of Run? Anyhow... Now the Preferences Dialog and the Note Template Window are both in front. Opening a note in the background will cause it to go behind both of these windows. Any more flexibility, and we'll have to go to using Gtk.Window instead of Gtk.Dialog for PreferencesDialog.
This patch makes sense, but it didn't work for me. What platform did you test on? I'm on GNOME with Metacity. Another thing missing from this patch is setting Window.Modal back to false after the Preferences window closes.
(In reply to comment #4) > This patch makes sense, but it didn't work for me. What platform did you test on? I'm on GNOME with Metacity. > > Another thing missing from this patch is setting Window.Modal back to false after the Preferences window closes. Well, at the time, I probably tested on the same. So, I'll get my little virtual machine setup, reapply the patch, and figure out what's going on and maybe try to fix it again.
how would you fix this if the new note template is obstructed
(In reply to comment #6) > how would you fix this if the new note template is obstructed If you mean, how do you get around this right now, the answer is to just move the preferences window so that the New Note Template is revealed. Or you can close the Preferences windows and the New Note Template will stay open.
Yeah, failwhale. I applied the patch that I submitted, and apparently it doesn't. I'll take a look at this one as well. It seems like it shouldn't be as difficult as it is.
Created attachment 186325 [details] [review] Place note template on top of prefs dialog
I know the original report was that the preferences dialog covers up all notes, but that was intentional. It's a preferences window. They are traditionally modal and thus on top until closed--as they are only meant to be opened periodically and for a short time during configuration. It definitely shouldn't cover up the note template, though, as the note template window is a child of the preferences dialog. That should be taken care of with this patch.
Comment on attachment 186325 [details] [review] Place note template on top of prefs dialog Doesn't work when another note is open. 1. Open "Start Here" note 2. Open Preferences 3. Click "Open New Note Template" Expected: template note shows up on top of preferences Actual: template note shows up behind preferences Its funny, because if you then close "Start Here", the temlplate note pops on top of the Preferences window.
I knew I was forgetting to test something. I was afraid it wouldn't be so simple. This means refactoring PreferencesDialog to be a Gtk.Window instead of a Gtk.Dialog, I'm afraid. That is going to take me some time, I think. What I'm hoping is this: If PreferencesDialog is a modal Window, and the note template Window is set as TransientFor PreferencesDialog, then it will force the stack to be: all other windows -> PreferencesDialog -> note template Window
As discussed with Aaron in IRC, going to refactor PreferencesDialog and make it a Gtk.Window (non-modal, but presented on top).
Created attachment 193368 [details] [review] PreferencesDialog is now a GTK Window and NoteTemplate is Foremost Here's my stab at making the Preferences Window not foremost, but the Template editor is above all other windows *template_note.Window.KeepAbove = true;* Comments welcome.
Review of attachment 193368 [details] [review]: Great job, needs some work though. In general, you should keep the formatting changes (removing extra line breaks) separate from functional changes. Incase there is a formatting change and a functional change on the same line, it is hard to see. ::: Tomboy/PreferencesDialog.cs @@ +102,3 @@ Gtk.Button button = new Gtk.Button (Gtk.Stock.Close); button.CanDefault = true; + button.Label = "Close"; This shouldn't be needed if youre using the stock button. If you need to override the label, you'll need to translate it with the Catalog.GetString() function. @@ +107,1 @@ button.Show (); The button currently fills the entire width, try to keep the UI similar to how the Gtk.Dialog would look. It might mean sticking an HBox in the VBox. @@ +113,3 @@ + + this.Add (VBox); + if ((this.Child != null)) { Please remove extra () @@ +116,3 @@ + this.Child.ShowAll (); + } + this.Show (); Calling this.ShowAll() should recursively call Show() on the children, so the if statement above shouldn't be necessary @@ +1290,3 @@ Note template_note = manager.GetOrCreateTemplateNote (); + // Template Window should be top-most. bgo #527177 + template_note.Window.KeepAbove = true; This actually makes the window *always* on top. Instead I think you want gtk_window_present, which will focus the window instead, even if it is already open. ::: Tomboy/Tomboy.cs @@ +283,3 @@ static void OnShowPreferencesAction (object sender, EventArgs args) { + prefs_dlg = new PreferencesDialog (manager); Let's keep the lazy initialize and only initialize once. that's the way most things work in tomboy. you'll have to remove the Destroy() from the close button handler.
The Tomboy team has moved from GNOME Bugzilla to GitHub for bug reports and feature requests: https://github.com/tomboy-notes/tomboy/issues/ Closing this report as NOTGNOME as part of Bugzilla Housekeeping (bug 781054) to keep tasks in one place. Please feel free to transfer this task to GitHub if this task is still valid in a recent Tomboy version. We are sorry for the inconvenience.