We should set NoDisplay=true on the gnu emacs .desktop file. Its going to be very rare that this is launched from the menus, and by removing the file we get rid of the "Programming" category on default installs.
Ok, I'll add that in the next build, which should be before test3.
Hey Jens, did this make it in? I'm not seeing it in the latest Rawhides.
Should get fixed in 21.3-15.
Looks to be fixed.
FWIW, I think disabling the menu item is a bad idea in the first place, I use it all the time for XEmacs (and one of the first things I do on new installations is to drag&drop that menu icon to the KDE panel for quick launch). Further, IMO it is the wrong solution to the Programming category problem. Instead, it'd be better if all text editors would be located in the "Accessories" category. That's where for example Kate and KWrite are on FC1 KDE (can't verify later FCx versions now). So, could you consider removing the NoDisplay=true, but also remove the Development category from the Emacs and XEmacs desktop files? (And add Utility if necessary, or whatever to get it shown where other text editors are.) Reopening for comments.
Fine by me. Seth?
Why don't we just move Emacs out of the default desktop install and put it in the Software Development component or whatever it's called.
Emacs, for all its charms, uses completely different UI conventions than our desktop (or Windows or MacOS for that matter). Its a beast from another age. I think its great to have Emacs on the system for programmers and for people accustomed to Unix, but we don't really want it exposed to people by default. That said, I would be leary about removing it from the default install given emacs' role in fixing a busted system. Its sort of on the level of bash or gnome-terminal (we could make an argument for moving that out of the default too...). I see two solutions that meet these constraints: 1) Have NoDisplay=true on the .desktop file 2) Don't include the .desktop file with emacs but include an "emacs-desktop-menus" package that just adds the (visible) .desktop file. Put it in the software development component, but don't install it by default. Still install the core emacs package by default. (2) is more of a PITA because it requires an extra package, but would at least mean emacs appears in the menus when you do a more full install, doesn't show up by default, but is still present from the terminal by default.
Accessing Emacs from the menus is probably very rare, so I would suggest we stick with (1). But I have no problems with (2). In either case, removing from the FC3 YellowPad and retitling.
My .02â¬: a separate subpackage for the menu entry is overkill, weird, and inconsistent with the rest of the distro. And vi is the editor that people use to fix busted systems, that's expected to be available everywhere, Emacs not. Seth, why not use the "correct" Category (ie. the same as for other text editors) for the .desktop entry? If you insist, keep the NoDisplay=true (which I still maintain is a, er, suboptimal solution for the original problem), but the categories could be "fixed" anyway?
With "NoDisplay=true" how is one supposed to get Emacs onto the panel if one wants to? It wasn't obvious to me anyway when I tried.
By removing that line from the .desktop file and doing it the usual way... that's what I'll be doing anyway if the shipped package has NoDisplay=true. And whether NoDisplay=true is there or not, as said I would find it logical if Emacs and XEmacs would be placed in Accessories (or wherever other text editors are) -> the Categories could be changed in any case.
So is there no difference between having "NoDisplay=true" and no .desktop file at all? When I added "NoDisplay=true" I naively assumed one would still be able to add Emacs to the panel easy and have its icon appear in "Run Application" dialog etc. Unfortunately it is probably too late to revert this change for fc3 now. :-(
Fwiw, I agree with Ville that adding a separate subpackage just for this seems a bit silly. I suggest putting Emacs and XEmacs in "Accessories -> Other" for now.
AFAIK the only practical difference between a .desktop file with NoDisplay=true and no .desktop file at all is that the former allows the application to show up in eg. various [Right Click]->"Open with..." -style functions, even if it's not shown in the menus. See also the NoDisplay docs at http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html#id2444496
The programming category is the correct place for emacs. As much as it might be a text editor like gedit it is really a development environment. I mean emacs even has a mail and news reader! :-) The separate package solution seems like a viable way of acheiving our goal of not having emacs in the menus by default and allow people who want the emacs launcher to have it. Perhaps it's a little overkill for the .desktop file to own an entire package, but having a 'Programming' category with only one item, which is emacs is overkill in many other ways.
Ville, I kinda agree that Emacs and XEmacs are a little big to be considered Accessories: not that I really understand what "Accessories" are anyway - probably I'm being unfair but it seems to me to be somewhat of a mish-mash of programs that don't fit into the other categories. Though I also agree that the Programming category doesn't feel like an exact fit either even if it is a bit closer than Accessories IMO. Bryan, how do people find out about the emacs-desktop-menu package? On the other hand you can argue that since Emacs is included in a default install currently, then it doesn't belong in the Programming category (Programming is surely for devel related packages).
Jens, Good point. I guess basically I'd like to see the WS and other releases include the emacs-desktop-menu package, but not the Desktop. People shouldn't be using the Desktop product as a development environment, it doesn't even include gcc or other common libraries. Emacs is really only a development tool, I doubt that most desktop users will find emacs to be an easy to use text editor. So I'm assuming that only developers will be looking for the emacs-desktop-menu package and they would probably be able to create a launcher of their own; it's just a hassle. So what are we supposed to do? Confuse the regular Desktop users with the Emacs entry or make the lives or a few developers simpler for a single moment in time when they add the icon to their panel. I'm going with the latter. As far as the Category goes, I think Programming is the best especially compared to the other categories. However something like 'Kitchen Sink' be the best for Emacs.. ;-)
Ok, I see the point, and partially agree. The separate menu item subpackage would still suck :/ But my personal concerns are really related to the XEmacs, not GNU Emacs package. Would it be possible to revert the NoDisplay=true from the XEmacs package, without introducing kludgy subpackages? XEmacs is not installed by default (nor with other groups except Everything IIRC) so the initial Programming menu problem does not really exist with it. Please don't punish XEmacs users because of an unfortunate/undecided situation with the GNU Emacs package...
Ville, I agree I don't think we need a separate menu item package for XEmacs since it is not installed by default. :) I'll revert the XEmacs change in the next build. As for Emacs, I guess I take Bryan's Desktop point of view. So if we're going to decide this in comps, then for my last question: what are we going to do for Fedora Core 4 - install the Emacs .desktop file by default or not? :)
Then again I'm still (relunctantly:) thinking that hp's suggestion actaully makes some sense: I mean what Bryan is saying about Desktop vs Workstation is close to saying that really only WS users need Emacs but not Desktop users (by default). So for RHEL would it not make as much sense to just not install Emacs by default for DT but only for WS, etc? But that probably isn't going to fly since DT and WS actually have identical comps afaict. For FC we would probably still want to install Emacs by default since FC users tends to be developers or power users. But this would still leave the lone Emacs sitting in the Programming submenu for a default Desktop install: so then one could arguably take hp's suggestion literally and only install Emacs for devel installs... Have I gone full circle yet? (-:
In case you're still looking for opinions: I think following hp's suggestion and removing NoDisplay=true would be OK.
Ok, re-assigning to comps.
Of course Emacs should still be listed under Editors in anaconda. What I'm requesting is that Emacs not be installed by default when doing a FC Desktop install. Is that possible?
Fwiw I turned on emacs in the menu again in emacs-21.3-18 in rawhide.
Has it also been moved into development category instead of being in the default selection as HP suggested?
Rahul, nothing has happened yet, but that is the current suggestion yes.
I'm not really seeing a clear consensus here. With regards to comps, is the following acceptable? A) Leave emacs in the editors group, but mark it optional there. B) Add emacs to the development-tools group, marked as default.
(In reply to comment #30) > A) Leave emacs in the editors group, but mark it optional there. ^^ I'm reading this as the Programming category Yes, for the Desktop optional and in Programming category > B) Add emacs to the development-tools group, marked as default. Yes, for the Workstation default and same category
Bryan's answer amounts to Mike's (B) I think, right? Hmmm, Bryan, putting Emacs (and by consequence XEmacs) into the Programming package category feels real strange, but perhaps one just needs to get used to it? So I think I prefer Shouldn't there really be some matchup between package categories and the submenus on the application menu. We have Editor category, so can't we have an Editor app submenu? Anyway, can't Emacs and XEmacs appear both in the Editors and Programming categories: being off by default in the former and Emacs on by default in the latter?
I'm sorry for being unclear. I meant to implement both A and B. In A, I really meant the editors group. This is a group in the comps file (comps controls how packages are organized in the installer). I was not talking about the kind of groups that one specifies in a spec file. (There is no "Programming" group in comps).
Mike, yep, doing both A and B sounds good. :-) If you add Emacs to Programming please add XEmacs there too for consistency.
Ok, sounds good to me too. :-)
A and B implemented. xemacs added to development-tools also, but listed as optional.