GNOME Bugzilla – Bug 122433
Alt+N shortcut does not select correct tab
Last modified: 2005-02-07 16:57:44 UTC
Do this: - open two documents, drag the first one from gedit to open another window. - drag the document from the new window back to the original gedit window. - do the Alt+N thing. Now you should see that, say, Alt+1 goes to the first document, and not to the first tab.
*** Bug 131750 has been marked as a duplicate of this bug. ***
(cc'ing usability since Gman cc'ed them in the duplicate) As noted in the duplicate bug, this bug/behaviour shows up also in differnt situations other than when dragging a tab to a separate window. - It happens when opening some docs in a window and some in another - It happens when you close a tab, e.g. if you open two docs and then close the first tab (which had the ALT+1 shortcut) you end up with a first tab with the ALT+2 shortcut. This happens because in bonobo_mdi.c the accel is assigned for each BonoboMDIChild. An half idea on how to fix this would be to associate the accel to the GeditView instead of the child, this way you can get the right accel number from the page number of the notebook. Note however that this way you would not be able to switch between docs in different windows. Fix may be not trivial since in theory each child may have many views, even if this never used in gedit afaik.
Do you want to be able to switch between windows using the Alt-number shortcuts? I don't know about how other people use gedit, but I wanted to have one window per active project, with tabs within each project window representing actively edited files in that project. I don't context switch between projects regularly, but I do context switch between files in a project. Having another window pop into view when I pressed Alt-<number> was a big distraction. Also, it's not expected behaviour to switch windows on any shortcut other than the familiar alt-tab.
Fixing this bug in the sane way may require rethinking the way gedit manages multiple windows. This will require some big work that I don't think we can do in the 2.6 time frame. First of all we should get all the bug related to this problem (there are a few of them in bugzilla) and try to get an organized list to understand where is the core problem. Then we should write a plan for fixing them and implement it for 2.8. IMO, we should try to give the user the feeling that each window is independent by each other. So for example, "Close All" should close only the documents in the current window. The list of documents should include only the documents in the current window, etc. The only problem I see in this solution (from an implementation point of view) is to decide how to manage the "global" dialogs like the Open/Save one, the Preferences one, the Page Setup one, etc. Should the user be able to open a preferences app per window or only a single global one (see for example bug #121512). Anyone willing to open a tracker bug for this problem?
Actually, looking at the code I think this bug can be fixed also with the current architecture. In child_list_menu_create (bonobo-mdi.c) we should check if at least a "view" of the "child" is in "win".
Created attachment 37100 [details] [review] prototype patch Here is a prototype patch which reworks the code quite a bit so that the N in alt+N is associated with the View not with the child... this way it always matches the order in the window etc. The patch is incomplete and buggy when you detach a tab etc... I'm attaching it so that Paolo can take a look
Created attachment 37109 [details] [review] Patch against CVS HEAD (v. 1) This is a modified version of the pbor's patch. It works for me. pbor: may you please give a look at it and test it? Do you see mem leaks?
Fixed in CVS HEAD.