Auto-close current task window when opening parent task (as Task Editor utility windows focus but don't raise when "presented" on X11/Xorg GNOME session)

[nekohayo]

When we changed the Task Editor's window "type hint" to "utility" in issue #89 and #266, we created the following symptom: when running in a X11/Xorg GNOME session, if you click the "Open Parent" (or "Add Parent") button in a task, the newly opened task window shows up, gets focused, but shows up behind the existing task editor window, and the user has to click that newly created window's titlebar to actually see the contents and interact with it. But it turns out, this issue does not occur when running a Wayland GNOME session.

So I went into a bit of a rabbit hole trying to "fix" that... and it seems to be impossible. I thought it was because we were using window.present() instead of window.present_with_time(time.time()), but not only does this approach not work either, it seems we would be at the mercy of a window managers in the future. Here's a chat I had on IRC:

• Me: hi there, I'm wondering about something... I have a utility window trying to spawn another window on button click, but the new window doesn't get focus (it is spawned in the background)... the code was using gtk_window_present(), now I made it use gtk_window_present_with_time(the_time_at_which_the_button_was_clicked) but no luck; what am I missing?
• E.: present_with_time() is mostly used focus-stealing prevention; if you want to focus, you can use present()
• Me: E., weird because reading the docs made me think the reverse, it's a bit confusing
• Me: but in any case... with just present(), it doesn't work either
• Me: in both cases it refuses to programmatically focus the window
• E.: "focus stealing prevention" means "don't give focus to this window I'm raising"
• E.: Is this utility window managed by the window manager (i.e. is it a TOPLEVEL or a POPUP)?
• Me: it's a "GtkWindow" set in glade to property name="type_hint":utility/property: but nothing else noteworthy that I can see
• Me: E., as soon as I take out that "utility" type_hint, present works as expected and the window gets put in the foreground when requested
• Me: but I would've wanted to be able to have them be utility windows :/
• E.: Is this wayland or x11?
• Me: X11. It behaves OK on Wayland
• E.: Well, it's kind of up to the window manager to decide depending on window hint
• C.: isn't a utility window meant to be a utility window?
• C.: ie just an add-on that is part of its toplevel?
• Me: the reason why I thought of utility type is that those are GTG's individual task editor windows (so you can have a gazillion of them), and utility lets me not have to clutter the window management (i.e. not a bunch of subwindows in gnome shell, and when clicking GTG in a task bar or dock or whatever, all the windows are shown at once) and it also solves the "Ubuntu puts extra minimize/maximize buttons on all of them" thing
• C.: i would totally not try to build a UI like that, because it will not work in the future
• C.: in the future there's toplevels and popovers and that's it
• mclasen: we still have transients
• Me: so what do you mean by "not build a UI like that", you mean the window type, or not do a multi-window UI at all?
• mclasen: make your users happy. don't build a multi-window ui
• C.: not do a multi-window ui
• Me: what if they're transient_for and "skip-taskbar-hint = True" ?
• C.: the main issue here is that window managers are getting more and more stupid, and applications are more and more pushed towards a state where they should assume they're fullscreen
• C.: because especially on mobile, but also when tiling on desktops, that's essentially the freedom those apps have

...and then, it occurred to me that I'm trying to put a band-aid on the problem, while there is a more elegant and "useful" solution: closing the current window when opening the new window. Whether I want to open (or create) a parent task, or open a child task (by clicking one of the subtasks hyperlinks), it's pointless to keep the old window open at the same time, and it creates potential out-of-sync issues like #38. By closing the window, this would reduce clutter for the user, and if entering a child task this way, they can always go back to the parent task easily thanks to the existence of the new "Open Parent" button.

I have hacked around the code to prove to myself that it would work, and it does. It solves my window management issues and it doesn't feel unnatural from a UI perspective. So I'll clean up my code hacks and provide a clean patch/commit for this to be reviewed & tested. This might also reduce a bit the need for #275.

[nekohayo]

I've pushed a commit to a branch of mine at https://github.com/nekohayo/GTG/commits/task_editor_window_management that addresses the "open/create parent" part of this issue, however to be consistent I think it should also close the parent when you click the hyperlink of a subtask; however I was not able to find what code method handles the clicks onto subtask hyperlinks, maybe @diegogangl would know?

[nekohayo]

For the 2nd part, in taskview.py I found the methods for entering subtask links, "_tag_event" (pretty badly named, no mention of clicking or anything, so it took me a good while to find this!) and "_keypress"... which have something like this (print additions mine):

                    anchor = tag.link
                    typ = tag.type
                    if(anchor):
                        if typ == "subtask":
                            print("open the subtask:", anchor)
                            self.open_task(anchor)
                            print("opened the subtask")

So theoretically that's where the magic happens, but I can't figure out how to access the TaskEditor instance/object/window from within TaskView, to be able to tell the existing TaskEditor to close after opening the subtask...

[diegogangl]

You can't access the app from the taskview, self.open_task is a callback set in editor.py which has access to the application class.
self.textview.open_task_callback(self.app.open_task)

The problem is that you don't have a way to distinguish between opening subtasks and opening tasks in general at the level of app.open_task. So it's better if you make a new method in the editor to do your thing and call open_task.

Also, remember everything in taskview.py is getting the axe :)
The new code will be easier to mess with

[nekohayo]

OK, in that case, what do you think about the proposed approach here (closing task editor windows automatically as much as possible), if you like it then I could merge that commit as it currently stands, and then we keep/retarget this ticket for "after the taskview refactoring" for the subtasks part?

[diegogangl]

Nah, it's only going to be a few lines of conflict. Go ahead!
In general, I think the best approach is what the devs said in IRC. A single window with optional task editor windows is going to be sooooo much better

[nekohayo]

Commit 600d6ce pushed to master, closing this issue for 0.4, with #345 being the follow-up for when the taskview will have been reshaped by Diego's woodcutting skills.