GNOME Bugzilla – Bug 707422
Improve GtkRecentAction deprecation notice
Last modified: 2016-09-16 09:33:51 UTC
GtkRecentAction has been deprecated because GtkAction has been deprecated in favor of GAction. However GtkRecentAction's deprecation documentation does not suggest any replacement, and there is no replacement. Deprecation without replacement, or some explanation of why the API should not be wanted, is not good. Note that GtkRecentAction's description does not mention the deprecation, but all of its API is deprecated.
(In reply to Murray Cumming from comment #0) > Deprecation without > replacement, or some explanation of why the API should not be wanted, is not > good. I totally agree. I want to add an "Open Recent" submenu to a GtkMenuBar and it looks like there is no easy way to do it with the current non-deprecated API. Having a GMenuModel implementation of GtkRecentChooser would be one solution I think. With a GtkRecentChooserMenu, gtk_menu_item_set_submenu() needs to be called. But it doesn't seem possible to get a certain GtkMenuItem from a GtkMenuBar. And with modern code, the GtkMenuBar is usually created with gtk_menu_bar_new_from_model() or implicitly with an automatic resource. And if there is an easy solution that I didn't find, it should be documented.
Not everything ever deprecated needs a replacement. That's one of the mechanisms with which we move apps from bad UI design to good one. GtkRecentAction was introduced as a stepping stone to move people away from the recently used lists of files inside menus, as those are actively awful (multiple files with the same name without any indication of the folder where they are from; long names that need to be truncated to avoid runaway menu items) or unhelpful (inline menus with just ~4 recently used files, clamped by a Most Recently Used predicate). The only reason I wrote it was because people were still porting from the EggRecent code and used GtkUIManager. The file selection dialog has a list of recently used files, with a much better UI; other applications have more complex recently used files display, like gedit and its composite 'Open file' popover. On top of that, GAction does not provide enough hooks to create a GtkRecentAction replacement, as it does not create or hold UI items. I'm all in favour of a better deprecation note for GtkRecentAction, and probably for a deprecation of most of the GtkRecentChooser widgetry.
(In reply to Emmanuele Bassi (:ebassi) from comment #2) > Not everything ever deprecated needs a replacement. That's one of the > mechanisms with which we move apps from bad UI design to good one. > Just because you think it's a bad UI design doesn't make it so. Open Recent menus are widely used in many editing applications, on many platforms, from many vendors, and I suspect there are many people (like me) who find them very useful. > GtkRecentAction was introduced as a stepping stone to move people away from > the recently used lists of files inside menus, as those are actively awful > (multiple files with the same name without any indication of the folder > where they are from; long names that need to be truncated to avoid runaway > menu items) or unhelpful (inline menus with just ~4 recently used files, > clamped by a Most Recently Used predicate). The only reason I wrote it was > because people were still porting from the EggRecent code and used > GtkUIManager. > I find 'File->Open Recent' menus are actively helpful. Programs can put the full path since there's plenty of room on just about any screen from the last 20 years, unless you use absurdly long filenames (I often do but they never run off the screen). I agree it's silly for applications to show too few files, but even showing just ~4 files is better than showing 0 files. > The file selection dialog has a list of recently used files, with a much > better UI; other applications have more complex recently used files display, > like gedit and its composite 'Open file' popover. > The file selection dialog has the awful problem you listed above regarding it showing a bunch of files with the same basename (most prominently at least, for some reason it needs a separate column (in the wrong position) for the path rather than listing the full path), not to mention showing impossible files for certain applications, like opening a binary file in one application and in another application it offers you to edit it as a text file, and also for having a whole separate unexpected UI, and making you switch mental modes to figure out how to show your actual filesystem, taking more steps to accomplish the intended goal, and is more often than not, actively annoying.
(In reply to Emmanuele Bassi (:ebassi) from comment #2) > (multiple files with the same name without any indication of the folder > where they are from; long names that need to be truncated to avoid runaway > menu items) The full path could be displayed in the statusbar.
> Just because you think it's a bad UI design doesn't make it so. The people developing the toolkit get to decide which UI designs are considered appropriate. This is how it has always worked. If you want to use menu items for recent files then you have a choice to make: * use GtkRecentAction and the deprecated GtkUIManager API * implement your own specialized menu that shows menu items the way you want them using placeholders GTK+ does not have API for the latter because GTK+ does not need to have API for every conceivable use case somebody may or may not have. We can then discuss whether or not accept a patch to GTK+ so that it can show recently used files inside menus built using the GMenu API; personally, I think the usability considerations against it are larger than the ones for it — which by and large boil down to "this is how Windows 95 used to do it, so it's good for everyone". In any case, this particular bug is not about that request. (In reply to Sébastien Wilmet from comment #4) > (In reply to Emmanuele Bassi (:ebassi) from comment #2) > > (multiple files with the same name without any indication of the folder > > where they are from; long names that need to be truncated to avoid runaway > > menu items) > > The full path could be displayed in the statusbar. Which requires looking in a completely separate place; additionally, the amount of applications with a status bar is pretty much the same as the amount of applications with a list of recently used files in a menu.
GTK+ has a reputation of bad documentation. This is a really good example. GtkRecentAction has been deprecated, without a direct replacement. The class description doesn't contain any warning, you need to look at the functions to know that the class is deprecated. And it is explained nowhere *why* the class doesn't have any replacement (the developer needs to go through the whole GTK+ API to figure out that there is no equivalent in the first place), and what application developers are supposed to use instead.
(In reply to Sébastien Wilmet from comment #6) > GTK+ has a reputation of bad documentation. Then feel free to re-open the bug when you have a patch. > The class > description doesn't contain any warning, you need to look at the functions > to know that the class is deprecated. And it is explained nowhere *why* the > class doesn't have any replacement (the developer needs to go through the > whole GTK+ API to figure out that there is no equivalent in the first > place), and what application developers are supposed to use instead. This is a good outline for a patch for the class description.
(In reply to Emmanuele Bassi (:ebassi) from comment #5) > > Just because you think it's a bad UI design doesn't make it so. > > The people developing the toolkit get to decide which UI designs are > considered appropriate. This is how it has always worked. > I actually tried to participate, as a contributor to a non-GNOME DE (was under the impression input was wanted from them), and as a cross-platform application developer, and got no where; the decision had been firmly made (off-list) by the time it was announced on the development mailing list. IIRC it wasn't deprecated due to bad UI, it was because anything related to GUI actions was being deprecated and re-implemented into the IO library. > > GTK+ does not have API for the latter because GTK+ does not need to have API > for every conceivable use case somebody may or may not have. > I agree it shouldn't have API for every use-case, just common ones like this. > We can then discuss whether or not accept a patch to GTK+ so that it can > show recently used files inside menus built using the GMenu API; personally, > I think the usability considerations against it are larger than the ones for > it — which by and large boil down to "this is how Windows 95 used to do it, > so it's good for everyone". In any case, this particular bug is not about > that request. > It has nothing to do with Windows 95. For example on my Macbook, both Photoshop and SublimeText have "Open Recent" menus in their File menu. I don't think anyone would typically find either of those as Win-95 like or having bad UI design. > (In reply to Sébastien Wilmet from comment #4) > > (In reply to Emmanuele Bassi (:ebassi) from comment #2) > > > (multiple files with the same name without any indication of the folder > > > where they are from; long names that need to be truncated to avoid runaway > > > menu items) > > > > The full path could be displayed in the statusbar. > > Which requires looking in a completely separate place; additionally, the > amount of applications with a status bar is pretty much the same as the > amount of applications with a list of recently used files in a menu. So a lot then? Anyway, I'll shut up now. As you rightly pointed out, this is not really on-topic for this particular bug.