On Sun, 2011-04-03 at 14:21 -0400, Shaun McCance wrote: > On Sun, 2011-04-03 at 13:30 -0400, John J. McDonough wrote: > > On Sun, 2011-04-03 at 12:40 -0400, Eric H. Christensen wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > On Sun, Apr 03, 2011 at 11:09:29AM -0400, John J. McDonough wrote: > > > > In GNOME 3 the whole concept of menus is gone. This means, among other > > > > things, that there is no Documentation menu. There are a number of > > > > categories: > > > > > > > > Accessories > > > > Games > > > > Graphics > > > > Internet > > > > Office > > > > Others > > > > Sound & Video > > > > System Tools > > > > > > Are these coming from the standards from the opendesktop group? > > > > It is my understanding that these come from a new standard, but I > > haven't studied it. These are the same categories we used to have on > > the Applications menu. > > To my knowledge, there is no new standard, nor any deviation > from the existing standard. Desktop files have never specified > where they are in a hierarchy. They specify categories, and > desktops are free to organize things as they see fit based on > those categories. > > The GNOME Shell developers have decided to do something a bit > different, showing all applications at once, and then having > a select few buttons to filter them. It's not a menu. And it's > perfectly in line with the flexibility built into the desktop > key file format. The idea of showing "all" applications and then filtering might make sense, but only if "all" was something similar to "all". One obvious choice would be all applications that have .desktop files. But what is shown is all applications that have .desktop files that fit into one of the categories already there. "Search" seems to be able to find .desktop files that aren't somehow blessed, but that seems like a terrible way to start an application. Sort of defeats the benefit of the GUI. If I need to type in the app name anyway, why not just use the command line? OK, after some more playing, it seems like new categories show up depending on what apps are installed, however, that doesn't happen all the time and there seems to be little logic in what works and what doesn't. > > > > > There is also an 'All' category, but this only includes applications > > > > that are in one of the other categories. An application must be > > > > specifically placed in the 'Other' category to appear there. > > > > > > That doesn't seem to be extremely helpful... > > > > > > > > > > > I could see putting the Release Notes in "System Tools", but it doesn't > > > > seem to me that documentation in general belongs there. Yelp is in > > > > "Accessories", but that category is already cluttered, and I can see > > > > "System Tools" getting pretty cluttered, too. > > > > > > I'd create a Documentation category before putting the RNs (and other docs) in with programs. > > > > I don't know what is involved in creating a Documentation category. I > > got the impression from Shaun that it wasn't going to happen upstream, > > but that the Fedora maintainer might be able to do that for us. > > I only meant that it's not going to happen in 3.0.0 upstream. > It's just too late for that. That would violate the hard code > freeze, string freeze, and user interface freeze. You might > yet get it into a later version of the shell. Although that > of course doesn't help you right now. > > Also, I'd encourage you to think of different ways this could > be presented. Like, instead of burying it in some category in > the (semantically wrong) Applications overview, what about an > overview just for documentation? Instead of shoehorning old > approaches into new interfaces, think of new ways we can fit > help and documentation into the user experience. I'm not sure what you are getting at here. I'm not madly in love with anything I've thought of, so new ideas are welcome. I just don't quite understand. > > > > > To further complicate the matter, previously GNOME, XFCE and LXDE could > > > > all share a .desktop file. It looks as if now a unique file will be > > > > required for GNOME. > > > > > > This seems less than useful. Why the break in the standard .desktop file? > > > > The old .desktop files still work for XFCE and LXDE. It is only on > > GNOME where it is a problem. > > If there's no combination of categories that creates good > results in all desktops, you could ship multiple desktop > files, each with OnlyShowIn keys set. Yes, previously we had a KDE and everyone else .desktop. Looks like we now need a KDE, GNOME and everyone else. > > -- > Shaun > > --McD -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
