Re: adding desktop files to misc packages
On Mon, Jul 16, 2007 at 12:40:28PM +0200, Raphael Hertzog wrote: Bill, you haven't participated in this discussion, what's your opinion? Would you like to do that work? I stated my opinion an hundred time already, here a quick summary: 1) There is a place for two menu structure in Debian: an omnibus one (Debian menu) and a Desktop-oriented one (XDG menu) where only desktop relevant apps would be mentioned. 2) The XDG menu entries suffers from lack of clear policy about what software should go in the menu and in which categories. For example should asciijump provide a .desktop file ? xdvi ? gv ? lilo ? etc. 3) The XDG menu entries suffers from general lack on maintainance. A lot of upstream-provided .desktop files outside native KDE/GNOME packages are wrong, and never fixed. At the very least compliance with the standard should be checked. 4) Bugs with Debian menu under GNOME were actually bugs in the XDG menu implementation in GNOME. The KDE implementation was much better. Blaming Debian menu for them is unfair. 5) There are dozen of ways to not display the Debian menu under GNOME. What is lacking is an easy interface beside do not install menu. Maybe the d-i team could propose an interface and I will see how it can be implemented. Would it be helpful to have the technical committee decide on this topic? It would not. Instead please write a policy about what softwares are worthy to appear in the XDG menu and get it accepted by the debian-desktop participants, and start to report bugs. I am not interested in maintaining the XDG menu myself. I do not use desktop environment. I am interested to maintain Debian menu, however. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Mon, Jul 16, 2007 at 08:07:05PM +0200, Javier Fernández-Sanguino Peña wrote: On Mon, Jul 16, 2007 at 04:12:02AM -0700, Don Armstrong wrote: So it seems like we should do the following: (...) 4. Add i18n support to menu so that it can generate localised menu names, entries and tooltips both when converting desktop - menu (for WM != KDE/GNOME/Xfce) and when converting menu - desktop (for WM == KDE/GNOME/Xfce). As WM might not have i18n support for their menu, this should be based on the system's /etc/default/locale setting when converting from desktop - menu to select a single text string there. As hinted in my d-d-a post, lenny menu will provide full translations of the menu under the condition that the translatable strings (title and longtitle) reach an acceptable quality level. We are working on it. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Thu, 26 Jul 2007 12:49:34 +0100, Ross Burton [EMAIL PROTECTED] said: On Thu, 2007-07-26 at 13:33 +0200, Andreas Tille wrote: I was even not able to get rid of this nautilus thingy at all because killing it opens a new one. I just renamed it and killed it to get rid of. If you don't use nautilus, why not remove the package? If you want to keep the package installed but never use it, why not remove it from the session? Because other users of the machine might want to? Or is Gnome only useful on the subset of single user machines? manoj -- A pencil with no point needs no eraser. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Fri, 27 Jul 2007 14:07:16 +0200, Josselin Mouette [EMAIL PROTECTED] said: Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit : In the end, the people who know whether an application should be given tags that will exclude it from certain menus are the application's maintainers, not the menu systems maintainers. So far they have been reasonable about what is included in the menu, and I have no reason to think this wouldn't remain like that. In that case, I guess I'm confused, because I had the impression that you were still opposed to migrating the existing Debian menu to use the freedesktop standard. Sorry, that wasn't clear: people are currently reasonable with what they include in the *freedesktop* menu. I'm not fond of the idea of converting the Debian menu entries because it will lead to including all that's currently in the *Debian* menu, which is not reasonable. If desktop entries are not generated automatically, and if there are clear rules on how they should be tagged, I think only a small number of maintainers wouldn't follow them. Hmm. I am not sure that the results shall be what you think they will be. Take for example, someone who packages something that has menu entries (me, for example). Well, such people, like, evidently think the package enahnces the menu; and thus, if we swithc to using desktop format by default, I would still want to see my package on the menu. So, if you want to keep you menu small and non-comprehensive, you should not be pushing for f.d.o formatting. :) manoj -- Weekend, where are you? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Wed, 25 Jul 2007 19:22:11 +0200, Frank Küster [EMAIL PROTECTED] said: Josselin Mouette [EMAIL PROTECTED] wrote: As long as it is not shown, it doesn't matter, so I guess we can agree on this matter. No, not at all. I have not yet seen a convincing argument for hiding menu entries. The only ones were less is more, which is to vague to get one much further, and we need to hide stuff like python, which is plain wrong IMHO because I think python shouldn't have a menu entry at all. Actually, microsoft (which seems to be what GNOME folk are trying ever so hard to emulate) came up with a decent solution -- they added shaded areas to menus to indicate that something is hidden from the user, and the user can just hover over the are to open up the hidden entries. So, for people with a phobia of information, the bad extra information is hidden; but it is easy enough to unhide, without having to remember which menu one needed to go to to do so. manoj -- Goals... Plans... they're fantasies, they're part of a dream world... Wally Shawn Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Sat, 2007-07-28 at 04:39 -0500, Manoj Srivastava wrote: If you don't use nautilus, why not remove the package? If you want to keep the package installed but never use it, why not remove it from the session? Because other users of the machine might want to? Or is Gnome only useful on the subset of single user machines? Session-removal is per-user. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: adding desktop files to misc packages
#include hallo.h * Florent Rougon [Thu, Jul 26 2007, 02:55:16PM]: Mike Hommey [EMAIL PROTECTED] wrote: Witness: - usable completion in the File Open dialog - gone [...] Note that AFAIK, completion never disappeared from the file open dialogs. You just have to enable it with a keystroke. I know that; the shortcut is Ctrl-L. But I wrote usable completion because even after hitting Ctrl-L, the kind of completion you get is *much* less efficient than that you got for free in the good old days of GTK+ 1.2. IOW, there is no usable completion in GNOME's current File Open/Save dialogs (neither in Qt, for that matter :-/). Even if not, it is a problem with gimp if it refuses to set menu shortcuts if you change gtk-can-change-accels in your config. OK, it's not GNOME. But I had the impression that the original feature, which was accessible out-of-the-box, was removed/made inaccessible *because* of GNOME's concerns about usability. That is why I brought this point here. This my impression as well, the idioticy of the current file-open dialog behaviour perfectly matches the GNOME development. And the performance is still flawed, the dialog (here: Iceweasel) keeps reading data of each and every file when doing completion. For what? It has never to display the type and icon, I wanna enter this filename manually. I wonder what the people are smoking anyway. Few years ago, performance of kfm in KDE 1.x sucked because it tried to read every file. Looks like GNOME people urge to repeat their mistakes. Eduard. -- Getty Ich find die Domain auch scheisse, aber nem geschenkten Gaul schaut man nicht ins Maul oder wie war das? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Sat, 2007-07-28 at 04:47 -0500, Manoj Srivastava wrote: On Wed, 25 Jul 2007 19:22:11 +0200, Frank Küster [EMAIL PROTECTED] said: Josselin Mouette [EMAIL PROTECTED] wrote: As long as it is not shown, it doesn't matter, so I guess we can agree on this matter. No, not at all. I have not yet seen a convincing argument for hiding menu entries. The only ones were less is more, which is to vague to get one much further, and we need to hide stuff like python, which is plain wrong IMHO because I think python shouldn't have a menu entry at all. Actually, microsoft (which seems to be what GNOME folk are trying ever so hard to emulate) came up with a decent solution -- they added shaded areas to menus to indicate that something is hidden from the user, and the user can just hover over the are to open up the hidden entries. snip That's actually terrible for usability. First, any UI feature that involves hovering is hostile both to novices, because it's effectively hidden, and to experienced users, because they know where they're going and don't want to wait. Second, users cannot learn where menu entries are if they keep moving around. Windows XP and later versions don't hide anything in the Programs sub-menu but they try to duplicate the most commonly used programs directly on the Start menu, with the option of explicitly pinning them in place. This works pretty well, though there are some difficulties in working out which are most commonly used (see the series of articles beginning with http://blogs.msdn.com/oldnewthing/archive/2007/06/11/3215739.aspx). Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] wrote: Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit : In the end, the people who know whether an application should be given tags that will exclude it from certain menus are the application's maintainers, not the menu systems maintainers. So far they have been reasonable about what is included in the menu, and I have no reason to think this wouldn't remain like that. In that case, I guess I'm confused, because I had the impression that you were still opposed to migrating the existing Debian menu to use the freedesktop standard. Sorry, that wasn't clear: people are currently reasonable with what they include in the *freedesktop* menu. Do you mean the menu as shown by desktop environments like gnome, or the menu as specified by the set of .desktop files? I'm not fond of the idea of converting the Debian menu entries because it will lead to including all that's currently in the *Debian* menu, which is not reasonable. I still don't understand what you want: Is it particular categories that you want to hide, or is it the sheer number of applications, and the fact that there are going to be multiple applications for (approximately) the same task, that bothers you? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] wrote: Le vendredi 27 juillet 2007 03:52 -0700, Steve Langasek a écrit : In the end, the people who know whether an application should be given tags that will exclude it from certain menus are the application's maintainers, not the menu systems maintainers. So far they have been reasonable about what is included in the menu, and I have no reason to think this wouldn't remain like that. In that case, I guess I'm confused, because I had the impression that you were still opposed to migrating the existing Debian menu to use the freedesktop standard. Sorry, that wasn't clear: people are currently reasonable with what they include in the *freedesktop* menu. Do you mean the menu as shown by desktop environments like gnome, or the menu as specified by the set of .desktop files? I'm not fond of the idea of converting the Debian menu entries because it will lead to including all that's currently in the *Debian* menu, which is not reasonable. I still don't understand what you want: Is it particular categories that you want to hide, or is it the sheer number of applications, and the fact that there are going to be multiple applications for (approximately) the same task, that bothers you? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] wrote: Le jeudi 26 juillet 2007 08:25 +0200, Frank Küster a écrit : Could you give guidelines how a maintainer of an application should classify their app, Using categories described in [0] is a good start. The maintainers would also have to agree on new categories if the ones listed are not sufficient. To me, these categories look very poor, I really wouldn't want the well-structured debian menu (note that I'm talking about the new Debian menu, not the default menu for etch) to be replaced by anything like this. To me, it rather looks like it doesn't make sense to add additional ones, given that we already have something much better. Moreover, this doesn't answer my question at all, but I was probably unclear. What I meant was How (do you think) should a maintainer decide whether a particular application is marked as not for Gnome, or not for desktop environments, or such. I wanted something more general than Python should be hidden, switching windowmanagers should be hidden, because it's hard to discuss whether this hiding thing makes sense when I have no idea what you think should be hidden, except some special examples. On the contrary, NotShowIn should be used if similar functionality is available in one or several environments and displaying an icon would only be a source of confusion. Okay, that makes sense - a frontend to setxkbmap shouldn't have a menu entry when there's a specific tool for customizing the keyboard for the desktop environement. That's the type of general guideline I'd like to see, but this particular one won't catch many applications. For applications that aren't useful in the general case, NoDisplay=3Dtrue should be set. Let me show an example: gstreamer-properties used to have an icon in the menu. In current releases, the appropriate sinks to use (esd, alsa, etc.) are autodetected which means there is no *need* for users to launch it, and this allowed us to set NoDisplay=3Dtrue. The same should hold for configuration dialogs that are specific to an application and already available from it. That also makes sense, but here I would argue that those shouldn't have a menu entry at all. and how Gnome would decide which classes to hide? ConsoleOnly, Shell, Screensaver, X-WindowManager are good candidates. We could also exclude things like FileManager as nautilus is always launched, for example.=20 ACK Sound judgement should do the rest. I'm sceptical about that. Up to this discussion I didn't even have an idea that people might want to hide things from the menu, and I still don't feel I understand exactly what and why you want to hide. But it's going to be the package maintainers like me who assign these classes, so we'd better give them some guidelines. One guideline could be if there's an application for doing $foo that's provided by the desktop environment, only show this one. Maybe that is what you applied when you suggested to not display other file managers besides Nautilus. However, I don't think this is a good rule in general: If both $gnome_wordprocessor and openoffice.org-writer are installed, I'm sure it would confuse users if there was no menu entry for openoffice.org-writer. Or, nearer to my own packaging work, if someone starts to learn LaTeX, and all they find in the menu to look at DVI files is evince or kdvi or similar, while everyone in the LaTeX community only talks about xdvi (and for a reason). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Andreas Tille [EMAIL PROTECTED] wrote: I really wonder whether this concept of user roles are really that strange or stupid that all posters seem to ignore this idea. (Feel free to teach me in private to keep silent with those stupid ideas.) Personally, I think it's probably a very good idea. Maybe I'd even like to switch between different types of users (oh, ideally even different users in different workspaces at the same time). I imagine that the reason why no one responds to this suggestion is that the discussion is very focused: The friends of the complete Debian menu on the one hand, and the advocates of a newbie friendly desktop environment - and those newbies (I think) are generally believed to use their computer for home office work, from writing a letter and web browsing to listening to music and managing their photos. But in fact, I think a user can both be a newbie to Linux (and even to serious computer usage) and still have a quite focused interest, be it administration of a non-profit organization, a particular field of science, game development, ... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Le samedi 28 juillet 2007 à 04:36 -0500, Manoj Srivastava a écrit : So, if you want to keep you menu small and non-comprehensive, you should not be pushing for f.d.o formatting. :) But I am not pushing it. I am trying to prevent the mess that will be if that actually happens. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: adding desktop files to misc packages
Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit : In the end, the people who know whether an application should be given tags that will exclude it from certain menus are the application's maintainers, not the menu systems maintainers. So far they have been reasonable about what is included in the menu, and I have no reason to think this wouldn't remain like that. In that case, I guess I'm confused, because I had the impression that you were still opposed to migrating the existing Debian menu to use the freedesktop standard. Sorry, that wasn't clear: people are currently reasonable with what they include in the *freedesktop* menu. I'm not fond of the idea of converting the Debian menu entries because it will lead to including all that's currently in the *Debian* menu, which is not reasonable. If desktop entries are not generated automatically, and if there are clear rules on how they should be tagged, I think only a small number of maintainers wouldn't follow them. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Thu, Jul 26, 2007 at 11:37:33AM +0200, Josselin Mouette wrote: Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit : One thing I do not like about the GNOME usability philosophy is precisely this: catering for the novice user is great, but the GNOME usability philosophy caters for novice users *at the expense of experienced users*. This widespread belief is entirely untrue. It is true, and your posts in this thread are the evidence of it. So far, the only proposal I've seen for allowing users to get access to the non-default menu entries, after they've been hidden in GNOME, is by letting them hunt down a config option in a settings menu /which is nowhere near the menu itself/. That's a bad UI; it might be ok for novices, but it's not ok for non-novices *or for novices who aren't looking to be novices for all eternity*. Making advanced configuration options available only to those who already know where to look ensures that there will always be a large gap between the knowledgeable elite, and the uninformed consumers. I have no business into changing other environments' menus. If you're going to be making unilateral decisions about classes of graphical applications that shouldn't be shown in the menu because they don't fit with your ideal of what a desktop menu should look like, I don't think you have any business changing GNOME's menu either. Identifying, as a project, classes of applications that aren't appropriate for inclusion in the menu of a desktop environment at all, and excluding those, is perfectly reasonable; but you appear to insist on referring to the classes identified so far, such as console apps and language interpreters, as *examples* of things you would trim from the GNOME menu, reserving for yourself the right to make the final decisions about what else you'll decide to cut. As a user of GNOME in Debian, I'm not at all ok with that. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le vendredi 27 juillet 2007 à 02:44 -0700, Steve Langasek a écrit : So far, the only proposal I've seen for allowing users to get access to the non-default menu entries, after they've been hidden in GNOME, is by letting them hunt down a config option in a settings menu /which is nowhere near the menu itself/. Right-clicking on the menu isn't near the menu itself? If you have better suggestions to make it accessible, please don't hesitate. That's a bad UI; it might be ok for novices, but it's not ok for non-novices *or for novices who aren't looking to be novices for all eternity*. Making advanced configuration options available only to those who already know where to look ensures that there will always be a large gap between the knowledgeable elite, and the uninformed consumers. Despite not being, I think, a novice user, I almost never crave in the advanced configuration options. They are advanced because there is no need for them in the general case, novice user or not. I have no business into changing other environments' menus. If you're going to be making unilateral decisions about classes of graphical applications that shouldn't be shown in the menu because they don't fit with your ideal of what a desktop menu should look like, I don't think you have any business changing GNOME's menu either. Identifying, as a project, classes of applications that aren't appropriate for inclusion in the menu of a desktop environment at all, and excluding those, is perfectly reasonable; but you appear to insist on referring to the classes identified so far, such as console apps and language interpreters, as *examples* of things you would trim from the GNOME menu, reserving for yourself the right to make the final decisions about what else you'll decide to cut. As a user of GNOME in Debian, I'm not at all ok with that. You make it sound like somehow I would dictate what would be in the menu by removing any application I don't like or use. This has never been my intent. I have quoted window managers and console applications as examples because they are the only identified classes so far; it is hard to tell what will need to be excluded until the desktop files are actually created and we can start seeing what the menu looks like. In the end, the people who know whether an application should be given tags that will exclude it from certain menus are the application's maintainers, not the menu systems maintainers. So far they have been reasonable about what is included in the menu, and I have no reason to think this wouldn't remain like that. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Fri, Jul 27, 2007 at 12:29:35PM +0200, Josselin Mouette wrote: Le vendredi 27 juillet 2007 à 02:44 -0700, Steve Langasek a écrit : So far, the only proposal I've seen for allowing users to get access to the non-default menu entries, after they've been hidden in GNOME, is by letting them hunt down a config option in a settings menu /which is nowhere near the menu itself/. Right-clicking on the menu isn't near the menu itself? If you have better suggestions to make it accessible, please don't hesitate. It wasn't clear to me that this would be togglable from right-clicking on the menu. Although my above criticism wouldn't apply, I'm still not altogether happy with this prospect because you're not just hiding the applications, you're effectively /hiding the fact that they're hidden/, by giving no UI hint that brings this information to your attention. (If your response to this is but all you have to do is right click, well - I think that supports *my* position rather well, since that's an instance where you're giving a /verbal/ hint because there's no visual indicator in the interface itself.) Context menus are great for operations that you know you want to perform on the current data/window/interface element. Unhiding menu entries isn't an operation that you know you want to perform, if you don't know that menu entries are being hidden in the first place! So it's imperative that hiding menu entries in this way is only used for *very* esoteric tools that are just plain incompatible with the environment; not just for applications that don't meet some aesthetic standard, or that you (or someone else) think are unlikely to be used. (I guess it's reasonable to consider console applications incompatible with the environment, but then, hasn't GNOME itself supported, since long before .desktop files existed, marking apps as runs in xterm in launchers?) You make it sound like somehow I would dictate what would be in the menu by removing any application I don't like or use. This has never been my intent. I have quoted window managers and console applications as examples because they are the only identified classes so far; it is hard to tell what will need to be excluded until the desktop files are actually created and we can start seeing what the menu looks like. Why is this hard to tell? Are the kinds of things that would need to be suppressed not evident from the menu policy? In the end, the people who know whether an application should be given tags that will exclude it from certain menus are the application's maintainers, not the menu systems maintainers. So far they have been reasonable about what is included in the menu, and I have no reason to think this wouldn't remain like that. In that case, I guess I'm confused, because I had the impression that you were still opposed to migrating the existing Debian menu to use the freedesktop standard. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Gabor Gombas [EMAIL PROTECTED] wrote: IMHO the best would be a uniof of the two viewpoints: show everything by default, and gradually hide entries that were not used for some time. Or did Microsoft patent that? The result being that if I use the application again for work of type B after only using it for type A for three weeks, everything that is only used for B will be hidden. No, thanks. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
On Thu July 26 2007 01:02:57 am Frank Küster wrote: Josselin Mouette [EMAIL PROTECTED] wrote: If an application is used so infrequently, it shouldn't have its place in a menu. It seems we have a very different notion of what a menu is. To me, the reply Exactly because it is used infrequently it should have its place is obvious and follows strictly from my understanding of a menu, I don't even need an argument for that. To you, it seems to be the contrary. I'm with Frank; what Josselin said only makes sense to me if s/menu/panel or quicklauncher/ This is also my usage scheme: everyday apps in the session, less frequently used apps in the menu, rarely used apps in a terminal or a launching tool. I don't make this distinction between less used and rarely used, and I'm not even sure what a launching tool is. I nearly never start a graphical application from the terminal, and I don't need to be able to start terminal applications from the menu: For me that is the only reason for deciding whether something should have a (possibly hidden) menu entry. I don't think there is any clear dividing line between graphical and terminal based apps as far as menus go. I routinely use text based apps in a windowed environment and if they didn't have a menu entry I would make one because having to open up a term and type in a command or start pdmenu is kinda silly when there is a menu system a click away. The only thing I'm getting outta this round of the discussion is that anything less than complete flexibility with respect to which items get placed in whatever menus would be a mistake. I.e., code the thing up so that it is easy to tell it how to build menus instead of writing it to conform to any particular idea of how menus are used. - Bruce
Re: adding desktop files to misc packages
On Thu, Jul 26, 2007 at 11:38:59AM +0200, Florent Rougon [EMAIL PROTECTED] wrote: SCNR... Frank Küster [EMAIL PROTECTED] wrote: Frank That turns out not to be the case. If I use an app frequently, then it Frank goes on the toolbar. The menu is for finding infrequently used apps. For Frank a lot of users, browsing the menu is how they find out what's available. Mike IIRC, gnome is going to switch to gnome-main-menu. There is a reason for Mike this. [...] Frank I haven't watched the whole video (it being boring to me), but from the Frank reading I still don't understand which of my statements you want to Frank contradict, let alone why. Seems very clear to me: it has been almost a decade now since the GNOME project tries hard to get rid of every feature that makes their software more usable (I'm speaking here about real usability, not about eye-candy). Witness: - usable completion in the File Open dialog - gone - customizable keyboard shortcuts in apps[1] - gone Both are due to gtk, not gnome. And now, a usable menu listing available applications is going to be replaced by a thing where you have to find your casually-used app in a 300-entries unstructered list after clicking on More applications... (exactly as the Open With... in MS Windows works, no wonder where they got the idea). So, yes, there *is* a reason GNOME is going to switch to gnome-main-menu: the previous menu still had a little remainder of (real) usability. [1] No, don't tell me that it is a simple matter of adding gtk-can-change-accels=1 to ~/.gtkrc-2.0. This simply *does* *not* *work*. For instance, even with this, you have to go hunt for the specific option in Gimp's Preferences menu before you can at last add your own keyboard shortcuts. Ugh. Gimp is not a gnome application. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
SCNR... Frank Küster [EMAIL PROTECTED] wrote: Frank That turns out not to be the case. If I use an app frequently, then it Frank goes on the toolbar. The menu is for finding infrequently used apps. For Frank a lot of users, browsing the menu is how they find out what's available. Mike IIRC, gnome is going to switch to gnome-main-menu. There is a reason for Mike this. [...] Frank I haven't watched the whole video (it being boring to me), but from the Frank reading I still don't understand which of my statements you want to Frank contradict, let alone why. Seems very clear to me: it has been almost a decade now since the GNOME project tries hard to get rid of every feature that makes their software more usable (I'm speaking here about real usability, not about eye-candy). Witness: - usable completion in the File Open dialog - gone - customizable keyboard shortcuts in apps[1] - gone And now, a usable menu listing available applications is going to be replaced by a thing where you have to find your casually-used app in a 300-entries unstructered list after clicking on More applications... (exactly as the Open With... in MS Windows works, no wonder where they got the idea). So, yes, there *is* a reason GNOME is going to switch to gnome-main-menu: the previous menu still had a little remainder of (real) usability. [1] No, don't tell me that it is a simple matter of adding gtk-can-change-accels=1 to ~/.gtkrc-2.0. This simply *does* *not* *work*. For instance, even with this, you have to go hunt for the specific option in Gimp's Preferences menu before you can at last add your own keyboard shortcuts. Ugh. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Thu, Jul 26, 2007 at 11:37:33AM +0200, Josselin Mouette wrote: Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit : One thing I do not like about the GNOME usability philosophy is precisely this: catering for the novice user is great, but the GNOME usability philosophy caters for novice users *at the expense of experienced users*. This widespread belief is entirely untrue. If it is widespread, then there must be at least some truth to that statement. It is all about making things understandable for the novice user without reducing functionality for experienced users; Personally, I feel that you succeed in the first but not in the last. You may disagree, but it's still why I don't like the GNOME philosophy about usability: in my opinion, many of the decisions that are made under the pretext of being good for the novice user have a number of seriously negative and problematic repercussions to the experienced user. Of course, it's okay for GNOME people to do that, as long as they don't expect me to use their system :-) that doesn't mean removing functionality, but rather removing the *need* for some functionality or configurability. You do not remove the need for some functionality by simply removing the functionality itself altogether, which is what I see GNOME developers do more often than other developers. Anyway, this thread is not about GNOME, but about the menu system, so let's keep it at that. I'll be happy to bash about GNOME on IRC, if you want me to :-) [...] If you want to do that in GNOME, go ahead, be my guest; I couldn't care less anyway. And in fact, I installed GNOME on my parent's machine, since I don't want to have to repeatedly explain them too much, so your philosophy has some uses. But please don't expand that philosophy to the rest of the Debian system, where it is totally useless. I have no business into changing other environments' menus. If you are going to modify the menu system, then that is exactly what you're doing, even if you want to modify it so that the changes remain mostly limited to GNOME: by removing the Debian menu from GNOME or modifying it so that it doesn't show what's available in all other graphical environments that are available in Debian, you're confusing users. Users who have used Debian (but not GNOME) before, users who use Debian with GNOME on one machine and a lightweight window manager on another (because, say, that other machine has less resources), and so on. I think one of the great selling points of Debian is precisely this unified menu system: no matter what window manager or graphical environment you use, there is still this single menu system that will be there, and that will contain all these applications; it is one of the few things that distinguishes Debian from other distributions. Throwing it out because you don't like the way it is structured just as it's about to be restructured seems like throwing out the kid along with the bath water to me. The right way would be to improve the menu system, so that you can be happy with it. After all, I'll be the first to agree that the way the menu system is structured currently is suboptimal. Having it everywhere, with all applications visible, *except* in GNOME, would be a big, big shame. However, I can agree that the menu system can use some improvements, and that some things (the Python example came up, but surely more can be found) simply don't belong in the menu. If you can come up with some examples, I'm sure we can discuss them, do a mass bug filing, and/or update the menu policy to reflect the stuff we agree on. [...] I'll agree that some things could be finetuned, and that some things simply don't belong in the menu system. But these things are exceptions, and I think most of the applications that are in the menu system currently do belong there. Speaking of modifying the interface, one reason why I think the GNOME people have the idea that nobody ever modifies their interface is that it is simply too hard to modify the interface in GNOME. I don't think anyone claimed that nobody does modify their interface. The problem is that the very idea of modifying it is not intuitive. Then you need to work on that. Adding an icon to the panel or the desktop should be a drag-and-drop operation. It is. Not in my experience. I'll be happy to provide details if you want me to. Changing the desktop background should not require me to add the image to a list of background images first before I can pick it from that list. Whoa? The background properties capplet features a button that spawns a file chooser in which you can choose a picture and get done with it. I've had to explain that point to my dad far too often. And that's for the complicated way; otherwise it's just a matter of right-clicking on the picture in epiphany and selecting use as background. This should also be possible in nautilus, IMO.
Re: adding desktop files to misc packages
Mike Hommey [EMAIL PROTECTED] wrote: Witness: - usable completion in the File Open dialog - gone [...] Note that AFAIK, completion never disappeared from the file open dialogs. You just have to enable it with a keystroke. I know that; the shortcut is Ctrl-L. But I wrote usable completion because even after hitting Ctrl-L, the kind of completion you get is *much* less efficient than that you got for free in the good old days of GTK+ 1.2. IOW, there is no usable completion in GNOME's current File Open/Save dialogs (neither in Qt, for that matter :-/). Even if not, it is a problem with gimp if it refuses to set menu shortcuts if you change gtk-can-change-accels in your config. OK, it's not GNOME. But I had the impression that the original feature, which was accessible out-of-the-box, was removed/made inaccessible *because* of GNOME's concerns about usability. That is why I brought this point here. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] wrote: For your information, this was ironic. There is no compositing manager in metacity as no one seemed interested enough in developing it. Ah, I see. Not everyone follows the development of every window manager on earth, so you couldn't really expect me to get your irony. Anyway... Another unfounded assumption: that you need to configure your shortcuts to be more productive. Err, did you ever wonder why Emacs is so popular among people who actually use their computer? A good application should come up with good shortcuts already configured. Plus, they should be similar across applications. This is so that you don't get lost in front of another account or a new application. I disagree. Applications are different; they provide different features, and therefore cannot have the same shortcuts except for a handful of things, such as copy, paste and quit. If you only accept standard shortcuts, then all other features are not accessible from the keyboard, with the result that in most cases, the app won't be very usable, unless there are means to customize one's own shortcuts. The GTK+ development used to be close to that of GIMP, but now it is sticking to the GNOME releases and is mostly done by GNOME developers. GIMP has still its own team, working with its insane development process with one release each time hell freezes. Okay, so at least this confirms my impression that the GTK+ development is heavily influenced by the GNOME project. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Steve Greenland wrote: 1. The format that will be used by Debian packages to specify their menu entry. I think the consensus in this thread is that the FDo format is better and more flexible than the current Debian menu system format. I wouldn't argue that it's better or more flexible. It is, however, a broadly accepted standard, and quite likely good enough. Transitioning to the FDo format is doable by coding a menu-method for each WM/panel/whatever that does not currently support the FDo format directly, and adjusting the menu package to prefer FDo format entries over the current format. Once menu is able to read .desktop files, and extract the same information from them that it extracts from menu file, there should be no need of any new menu-methods. -- see shy jo signature.asc Description: Digital signature
Re: adding desktop files to misc packages
Frank Küster wrote: Window managers? Yes, in an appropriate category. *That* one could be a candidate for hiding. If I'm not mistaken KDE, Gnome and friends only work with certain window managers, so switching doesn't make sense. Window managers are already not displayed on the gnome or kde menus. Hiding all text-mode programs from those menus could be accomplished trivially: [EMAIL PROTECTED]:~diff -u /etc/menu-methods/xdg-desktop-entry-spec-apps xdg-desktop-entry-spec-apps --- /etc/menu-methods/xdg-desktop-entry-spec-apps 2006-03-20 08:44:23.0 -0500 +++ xdg-desktop-entry-spec-apps 2007-07-26 18:35:53.0 -0400 @@ -25,7 +25,6 @@ supported; x11 = AppEntry(false); - text = AppEntry(true); endsupported; startmenu = ; -- see shy jo signature.asc Description: Digital signature
Re: adding desktop files to misc packages
On 26-Jul-07, 13:41 (CDT), Russ Allbery [EMAIL PROTECTED] wrote: Steve Greenland [EMAIL PROTECTED] writes: 3. The actual contents and structure of the default menu in each WM etc. This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2. In particular, just saying we're going to use the FDo format now does nothing to prevent the kind of mess you see in the Debian menu. OTOH, setting an acceptable policy would clean up not only the GNOME menu but all the other menu systems. Except that the freedesktop.org specification comes with its own set of categories, registration system, and classification system, which does not match the Debian system. I suppose we could use the format without using its categorization system, but that seems a bit strange and Debian's current menu structure doesn't have the concept of primary and additional categories the way that the freedesktop.org specification does. That's okay. It's just a simple matter of policy making :-) Or, the Debian GNOME maintainers (and KDE maintainers, etc.) can just ignore the Debian menu entries and make a package of FDo menu entries for all the packages they want in their menu. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Thu, Jul 26, 2007 at 04:33:17PM +0200, Josselin Mouette wrote: Le jeudi 26 juillet 2007 à 12:59 +0200, Wouter Verhelst a écrit : You do not remove the need for some functionality by simply removing the functionality itself altogether, which is what I see GNOME developers do more often than other developers. This seems to be based solely on hearsay. No, this is based on me using GNOME for about nine months in 2005 until I got fed up with the behaviour I described. [...] The Debian menu in GNOME has been secondary for quite some time, and the source of confusion is rather having two menus than having a menu which isn't the same as WindowMaker's. I'm not saying there isn't confusion in having two menu systems. I'm saying there's *also* confusion in having a menu which isn't the same as WindowMaker's, but for a different class of users than the ones that will get confused by having two menu systems. I think one of the great selling points of Debian is precisely this unified menu system: no matter what window manager or graphical environment you use, there is still this single menu system that will be there, and that will contain all these applications; it is one of the few things that distinguishes Debian from other distributions. This used to be true five years ago. Now, other distributions have moved and worked on their menu systems, and Debian has not. Hmm. I must admit I haven't tried another distribution in years. [...] -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le jeudi 26 juillet 2007 à 12:59 +0200, Wouter Verhelst a écrit : You do not remove the need for some functionality by simply removing the functionality itself altogether, which is what I see GNOME developers do more often than other developers. This seems to be based solely on hearsay. Anyway, this thread is not about GNOME, but about the menu system, so let's keep it at that. Well, I'm interested in a menu system which is usable for GNOME; which means if it has to be shared with other environments with different paradigms, the system has to be flexible enough. I have no business into changing other environments' menus. If you are going to modify the menu system, then that is exactly what you're doing, even if you want to modify it so that the changes remain mostly limited to GNOME: by removing the Debian menu from GNOME or modifying it so that it doesn't show what's available in all other graphical environments that are available in Debian, you're confusing users. Users who have used Debian (but not GNOME) before, users who use Debian with GNOME on one machine and a lightweight window manager on another (because, say, that other machine has less resources), and so on. The Debian menu in GNOME has been secondary for quite some time, and the source of confusion is rather having two menus than having a menu which isn't the same as WindowMaker's. I think one of the great selling points of Debian is precisely this unified menu system: no matter what window manager or graphical environment you use, there is still this single menu system that will be there, and that will contain all these applications; it is one of the few things that distinguishes Debian from other distributions. This used to be true five years ago. Now, other distributions have moved and worked on their menu systems, and Debian has not. Throwing it out because you don't like the way it is structured just as it's about to be restructured seems like throwing out the kid along with the bath water to me. The right way would be to improve the menu system, so that you can be happy with it. After all, I'll be the first to agree that the way the menu system is structured currently is suboptimal. Having it everywhere, with all applications visible, *except* in GNOME, would be a big, big shame. Show me the code. If this wonderful menu system existed somewhere outside your imagination, I guess we could happily used it. Meanwhile, real world people have moved to the freedesktop menu, which despite its flaws is more flexible, more beautiful and allows a better structure designed for each environment. I don't think anyone claimed that nobody does modify their interface. The problem is that the very idea of modifying it is not intuitive. Then you need to work on that. Work on brainwashing users so that they want to modify their interface? What if they don't care and just want something working out of the box? Adding an icon to the panel or the desktop should be a drag-and-drop operation. It is. Not in my experience. I'll be happy to provide details if you want me to. Please file a bug with details, yes. And that's for the complicated way; otherwise it's just a matter of right-clicking on the picture in epiphany and selecting use as background. This should also be possible in nautilus, IMO. This is already the case in eog (which is the default image viewer). -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Thu, Jul 26, 2007 at 02:07:17PM +0200, Josselin Mouette [EMAIL PROTECTED] wrote: Le jeudi 26 juillet 2007 à 13:35 +0200, Florent Rougon a écrit : Eye candy... oh right, this must be why there are so many people interested in bringing a compositing manager to metacity, rather than improving performance or rendering quality. For your information, this was ironic. There is no compositing manager in metacity as no one seemed interested enough in developing it. Actually, there is one. YMMV, but IMHO, I don't think compositing will much improve my efficiency at using a computer (and that's precisely where I measure usability). Exactly my point, thanks. Actually, it can help improve usability, but that is OT. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le jeudi 26 juillet 2007 à 08:25 +0200, Frank Küster a écrit : A window manager choice has nothing to do in an application menu, as it is not an application. This is a matter for a configuration tool, whatever form it takes. The Debian menu has more Categories than just applications. In particular, it has a category for window managers. If you desktop environment guys want to go a different way and hide this category (and instead allow for window manager switching somewhere else, like some control center) that's fine. But that doesn't say that window managers shouldn't have a menu file, or .desktop if that is going to be its successor. As long as they are consistently tagged, I have nothing against .desktop files for window managers. This category doesn't exist in the freedesktop specification, but you can add new categories, like X-WindowManager. Could you give guidelines how a maintainer of an application should classify their app, Using categories described in [0] is a good start. The maintainers would also have to agree on new categories if the ones listed are not sufficient. Also, the OnlyShowIn field is a good one for applications that are really too KDE- or GNOME-specific to be shown in other menus. On the contrary, NotShowIn should be used if similar functionality is available in one or several environments and displaying an icon would only be a source of confusion. For applications that aren't useful in the general case, NoDisplay=true should be set. Let me show an example: gstreamer-properties used to have an icon in the menu. In current releases, the appropriate sinks to use (esd, alsa, etc.) are autodetected which means there is no *need* for users to launch it, and this allowed us to set NoDisplay=true. The same should hold for configuration dialogs that are specific to an application and already available from it. and how Gnome would decide which classes to hide? ConsoleOnly, Shell, Screensaver, X-WindowManager are good candidates. We could also exclude things like FileManager as nautilus is always launched, for example. Sound judgement should do the rest. [0] http://standards.freedesktop.org/menu-spec/latest/apa.html -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit : One thing I do not like about the GNOME usability philosophy is precisely this: catering for the novice user is great, but the GNOME usability philosophy caters for novice users *at the expense of experienced users*. This widespread belief is entirely untrue. It is all about making things understandable for the novice user without reducing functionality for experienced users; that doesn't mean removing functionality, but rather removing the *need* for some functionality or configurability. Many Unix users are used to a high level of configurability, and it is definitely frustrating not to encounter it when you are used to. But in the end I find myself gaining a lot of time, because the only things that are shown in the interface are the things I actually need. If you want to do that in GNOME, go ahead, be my guest; I couldn't care less anyway. And in fact, I installed GNOME on my parent's machine, since I don't want to have to repeatedly explain them too much, so your philosophy has some uses. But please don't expand that philosophy to the rest of the Debian system, where it is totally useless. I have no business into changing other environments' menus. This is why I suggested that we keep the Debian menu as it is for those who prefer it. As people seem to want to switch to the freedesktop menu given its superiority, I only want to ensure the GNOME menu is improved by the process rather than being turned into garbage. I'll agree that some things could be finetuned, and that some things simply don't belong in the menu system. But these things are exceptions, and I think most of the applications that are in the menu system currently do belong there. Speaking of modifying the interface, one reason why I think the GNOME people have the idea that nobody ever modifies their interface is that it is simply too hard to modify the interface in GNOME. I don't think anyone claimed that nobody does modify their interface. The problem is that the very idea of modifying it is not intuitive. Adding an icon to the panel or the desktop should be a drag-and-drop operation. It is. Changing the desktop background should not require me to add the image to a list of background images first before I can pick it from that list. Whoa? The background properties capplet features a button that spawns a file chooser in which you can choose a picture and get done with it. And that's for the complicated way; otherwise it's just a matter of right-clicking on the picture in epiphany and selecting use as background. These are useless hoops to jump through; and even Windows has been doing this correctly for about 10 years. Talking about Windows in a thread about menus sounds... well, no comment. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Thu, 26 Jul 2007, Josselin Mouette wrote: Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit : One thing I do not like about the GNOME usability philosophy is precisely this: catering for the novice user is great, but the GNOME usability philosophy caters for novice users *at the expense of experienced users*. This widespread belief is entirely untrue. This is the proposition. It is all about making things understandable for the novice user without reducing functionality for experienced users; that doesn't mean removing functionality, but rather removing the *need* for some functionality or configurability. Many Unix users are used to a high level of configurability, and it is definitely frustrating not to encounter it when you are used to. But in the end I find myself gaining a lot of time, because the only things that are shown in the interface are the things I actually need. I found (at least one) counter example: I never managed to get rid of the stupid nautilus behavour to open new windows. I was even not able to get rid of this nautilus thingy at all because killing it opens a new one. I just renamed it and killed it to get rid of. So the proposition was disproved by a counter example and thus is not true. q.e.d. Andreas. -- http://fam-tille.de
Re: adding desktop files to misc packages
On Thu, Jul 26, 2007 at 01:13:13PM +0200, Florent Rougon [EMAIL PROTECTED] wrote: Hi, Mike Hommey [EMAIL PROTECTED] wrote: Witness: - usable completion in the File Open dialog - gone - customizable keyboard shortcuts in apps[1] - gone Both are due to gtk, not gnome. From my limited end-user POV (a user who used to like GTK+ and GNOME in the old days), I had the impression that it is the GNOME project that influenced the GTK+ team in this way. Do you think this is wrong? There might be influence, but not every change in gtk is due to gnome. Note that AFAIK, completion never disappeared from the file open dialogs. You just have to enable it with a keystroke. [1] No, don't tell me that it is a simple matter of adding gtk-can-change-accels=1 to ~/.gtkrc-2.0. This simply *does* *not* *work*. For instance, even with this, you have to go hunt for the specific option in Gimp's Preferences menu before you can at last add your own keyboard shortcuts. Ugh. Gimp is not a gnome application. Hmmm. If GTK+ decisions are not influenced by the GNOME project, fair enough. But I doubt this is the case... Even if not, it is a problem with gimp if it refuses to set menu shortcuts if you change gtk-can-change-accels in your config. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 09:56:11PM +0200, Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland [EMAIL PROTECTED] wrote: On 25-Jul-07, 13:28 (CDT), Josselin Mouette [EMAIL PROTECTED] wrote: If an application is used so infrequently, it shouldn't have its place in a menu. That turns out not to be the case. If I use an app frequently, then it goes on the toolbar. The menu is for finding infrequently used apps. For a lot of users, browsing the menu is how they find out what's available. IIRC, gnome is going to switch to gnome-main-menu. There is a reason for this. What does that mean? What is gnome-main-menu? apt-get install gnome-main-menu. That won't help unless I start Gnome, which I won't. http://reverendted.wordpress.com/2007/02/14/show-me-that-updated-gnome-main-menu/ I haven't watched the whole video (it being boring to me), but from the reading I still don't understand which of my statements you want to contradict, let alone why. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
On 26-Jul-07, 04:37 (CDT), Josselin Mouette [EMAIL PROTECTED] wrote: I have no business into changing other environments' menus. This is why I suggested that we keep the Debian menu as it is for those who prefer it. As people seem to want to switch to the freedesktop menu given its superiority, I only want to ensure the GNOME menu is improved by the process rather than being turned into garbage. Sigh. You're still conflating 3 issues: 1. The format that will be used by Debian packages to specify their menu entry. I think the consensus in this thread is that the FDo format is better and more flexible than the current Debian menu system format. Transitioning to the FDo format is doable by coding a menu-method for each WM/panel/whatever that does not currently support the FDo format directly, and adjusting the menu package to prefer FDo format entries over the current format. 2. Whether or not we can just dump the Debian menu system in favor of the FDo system. IMPORTANT: by Debian menu system I mean the ability to support the same menu entry (as specified by the package, in whatever format we choose) in a variety of WMs, menu systems, etc. I don't think this is acceptable to most of the participants in this thread. (Which doesn't keep the GNOME desktop maintainers from ignoring the Debian menu entries.) 3. The actual contents and structure of the default menu in each WM etc. This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2. In particular, just saying we're going to use the FDo format now does nothing to prevent the kind of mess you see in the Debian menu. OTOH, setting an acceptable policy would clean up not only the GNOME menu but all the other menu systems. Regards, Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] wrote: Meanwhile, real world people have moved to the freedesktop menu, which despite its flaws is more flexible, more beautiful and allows a better structure designed for each environment. Tell me, in which world do I live if its not the real world? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Le jeudi 26 juillet 2007 à 13:35 +0200, Florent Rougon a écrit : Eye candy... oh right, this must be why there are so many people interested in bringing a compositing manager to metacity, rather than improving performance or rendering quality. For your information, this was ironic. There is no compositing manager in metacity as no one seemed interested enough in developing it. YMMV, but IMHO, I don't think compositing will much improve my efficiency at using a computer (and that's precisely where I measure usability). Exactly my point, thanks. This feature, despite its coolness, was more a source of annoyance by setting shortcuts by mistake than anything else. I don't remember having been bitten by it (it might be, but at least if it did happen, it didn't leave any bad sequels ;-). And anyway, if you're bitten once, you learn; it takes you, what, one minute? And then you'll be more productive. Not during one minute, *always* (well, until they remove said feature...). Another unfounded assumption: that you need to configure your shortcuts to be more productive. A good application should come up with good shortcuts already configured. Plus, they should be similar across applications. This is so that you don't get lost in front of another account or a new application. The software you are talking about was rejected for inclusion in GNOME 2.18, and is not part of the GNOME 2.19 desktop. Err, but didn't Mike write: IIRC, gnome is going to switch to gnome-main-menu. So? It is not (currently) part of the GNOME 2.19 desktop, you say, but it is just a matter of time? i.e., are you playing on words, or actually contradicting Mike? I'm not aware of such a move. Currently gnome-main-menu is not part of the proposed modules for 2.20. This could still change, of course, but last time it was proposed there was a strong opposition among developers. This is a problem in GIMP, not in GNOME. Hmmm. GOTO my-answer-to-mike. Nothing to add here. The GTK+ development used to be close to that of GIMP, but now it is sticking to the GNOME releases and is mostly done by GNOME developers. GIMP has still its own team, working with its insane development process with one release each time hell freezes. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Wed, Jul 25, 2007 at 06:57:54PM +0200, Josselin Mouette wrote: Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit : Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. Do you expect to see console applications in the menu as well? Some of them. The ``mc'' file manager is an example of a console application that I expect to find in the menu. So are the games from the ``bsdgames'' package. The ``fortune'' program is an example of something I do not expect to find there. All interpreters and shells? No, certainly not. Window managers? Yes. Some window managers support starting another window manager without terminating the X session, which is an interesting feature. The window managers menu entry is only shown in those window managers that have this feature, anyway, so I don't see why it should be hidden in others. Perhaps a menu method implementation should be allowed to place the Window Managers menu someplace else than right along with the other menu entries (the logout menu in IceWM, or the System menu in GNOME spring to mind), but that's about it. If a novice user installs an app and then goes to the menu and doesn't find it, how is this user supposed to know what to do? This bit is correct: someone installing an app can reasonably expect to see it in the menu. However you are drawing wrong conclusions: This is completely *un*usable. The more novice the user, the more important it is for the *default* to be for all graphical apps to be shown. Then let the individual user decide which ones are important to him/her. If the users installs the distribution with default settings or starts a session on a multi-user setup, he should find a usable menu, not a menu with all possible applications he never wanted to install. I think you are mixing two distinct matters in this argument. If a user installs the distribution with default settings and finds that too much software is available in the menu, then this is an indication of there being too much software being installed by default. Rather than aiming to reduce the usefulness of the menu system, you should be aiming to reduce the number of useless applications installed by default. If the user starts a session on a multi-user setup that has way too many entries in the menu, then this is an indication of a sysadmin not doing their job properly. Not much we can do about that, except properly documenting (with examples) how a sysadmin can modify the menu system so that they can hide certain classes of applications to certain classes of users. Menus, by their nature, are inherently unusable for the most frequently used apps, and we should not be trying to make them more usable at the expense of making less frequently used apps harder to access. Why shouldn't we attempt to make menus usable? Because by making them more usable for the frequent user in the way you are suggesting, you make them *less* usable for the casual user. This is a tradeoff; and since I believe the menu system is mainly meant for the casual user (frequent users have scripts or panel shortcuts or desktop icons anyway, or they know the menu system by heart and don't care how much applications there are), I don't think we should be reducing the usefulness of the menu system for the casual user. Menus make less frequently used apps easy to get at, while toolbars make frequently used apps even easier; use the right tool for the right job. Guess what, toolbars are not used by a good share of users. Guess what, toolbars are used by most users I know of. Toolbars sound obvious for experienced users, but a novice will never have the idea to modify the interface that is shown to him; One thing I do not like about the GNOME usability philosophy is precisely this: catering for the novice user is great, but the GNOME usability philosophy caters for novice users *at the expense of experienced users*. If you want to do that in GNOME, go ahead, be my guest; I couldn't care less anyway. And in fact, I installed GNOME on my parent's machine, since I don't want to have to repeatedly explain them too much, so your philosophy has some uses. But please don't expand that philosophy to the rest of the Debian system, where it is totally useless. I'll agree that some things could be finetuned, and that some things simply don't belong in the menu system. But these things are exceptions, and I think most of the applications that are in the menu system currently do belong there. Speaking of modifying the interface, one reason why I think the GNOME people have the idea that nobody ever modifies their interface is that it is simply too hard to modify the interface in GNOME. Adding an icon to the panel or the desktop should be
Re: adding desktop files to misc packages
Hi, Josselin Mouette [EMAIL PROTECTED] wrote: Eye candy... oh right, this must be why there are so many people interested in bringing a compositing manager to metacity, rather than improving performance or rendering quality. YMMV, but IMHO, I don't think compositing will much improve my efficiency at using a computer (and that's precisely where I measure usability). To be efficient, I don't need *one* desktop with little miniatures of windows I don't currently work with, because these windows, even if small, take up useful screen space. My efficient way of working is to have each major app (which requires almost the full screen, programs running in xterms are different) in its own workspace, and to be able to reach each of them *directly* with one keystroke (where directly means: not having to hit Alt-right-arrow or whatever and needing to check each time, until the desired workspace appears). To switch to the workspace where Galeon usually runs, I hit Alt-1. To switch to the workspace where Emacs usually runs, I hit Alt-2. To switch to the workspace where I put my first xterms, I hit Alt-3. ... If I want to do work as root, this is Alt-6. Every task has a *direct* shortcut that brings me right there in a fraction of a second. /That/ is efficient. And I don't see how compositing will improve that. Sure, it's nice, but for me, this mostly counts as eye-candy. (for those who're wondering: I'm using WindowMaker; which does have its flaws, but has a simple and quite efficient workspace handling) Witness: - usable completion in the File Open dialog - gone And back in GTK 2.10. Oh, dear, how many years have we been waiting for this? I'm longing to see it. :) This feature, despite its coolness, was more a source of annoyance by setting shortcuts by mistake than anything else. I don't remember having been bitten by it (it might be, but at least if it did happen, it didn't leave any bad sequels ;-). And anyway, if you're bitten once, you learn; it takes you, what, one minute? And then you'll be more productive. Not during one minute, *always* (well, until they remove said feature...). Plus, as you wrote later, it is hidden, not removed. It was quite convenient to use. Now, it is relatively difficult to use, if not impossible (do all GNOME apps support it nowadays?). And it's even more difficult to discover if nobody tells you about it, since you can't find it by mistake anymore. The software you are talking about was rejected for inclusion in GNOME 2.18, and is not part of the GNOME 2.19 desktop. Err, but didn't Mike write: IIRC, gnome is going to switch to gnome-main-menu. So? It is not (currently) part of the GNOME 2.19 desktop, you say, but it is just a matter of time? i.e., are you playing on words, or actually contradicting Mike? This is a problem in GIMP, not in GNOME. Hmmm. GOTO my-answer-to-mike. Nothing to add here. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le jeudi 26 juillet 2007 à 13:33 +0200, Andreas Tille a écrit : I found (at least one) counter example: I never managed to get rid of the stupid nautilus behavour to open new windows. Edit - Preferences - Behaviour - Always open in navigation windows If the option name isn't clear enough, feel free to propose an alternate wording; there's definitely room for improvement here. I was even not able to get rid of this nautilus thingy at all because killing it opens a new one. This is intentional, nautilus is a fundamental piece of the desktop. You can remove it by editing the session, still. So the proposition was disproved by a counter example and thus is not true. This is because of wrong assertions on your side: that you need nautilus not to run, for example. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Thu, 2007-07-26 at 13:33 +0200, Andreas Tille wrote: I found (at least one) counter example: I never managed to get rid of the stupid nautilus behavour to open new windows. In Nautilus enable Edit - Preferences - Behaviour - Always open in browser windows. I was even not able to get rid of this nautilus thingy at all because killing it opens a new one. I just renamed it and killed it to get rid of. If you don't use nautilus, why not remove the package? If you want to keep the package installed but never use it, why not remove it from the session? Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] wrote: Le mercredi 25 juillet 2007 à 19:35 +0200, Frank Küster a écrit : Menus, by their nature, are inherently unusable for the most frequently used apps, and we should not be trying to make them more usable at the expense of making less frequently used apps harder to access. Why shouldn't we attempt to make menus usable? Because, as Marvin wrote in the text you cite, the drawback is that it makes less frequently used applications harder to access. If an application is used so infrequently, it shouldn't have its place in a menu. It seems we have a very different notion of what a menu is. To me, the reply Exactly because it is used infrequently it should have its place is obvious and follows strictly from my understanding of a menu, I don't even need an argument for that. To you, it seems to be the contrary. Furthermore, in the case a user needs it more often, he can add it to the menu. This becomes even easier if the menu entry is only hidden, not absent. But it seems to be harder than adding it to the toolbar/dock/whatever. But I agree with Marvin (and that's also my usage scheme) that menus should provide access to the less frequently used applications, not the ones started very often. I don't have toolbars in my WM, but it starts the frequently used apps without asking me, so I use the menu for the rare ones. This is also my usage scheme: everyday apps in the session, less frequently used apps in the menu, rarely used apps in a terminal or a launching tool. I don't make this distinction between less used and rarely used, and I'm not even sure what a launching tool is. I nearly never start a graphical application from the terminal, and I don't need to be able to start terminal applications from the menu: For me that is the only reason for deciding whether something should have a (possibly hidden) menu entry. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] wrote: Le mercredi 25 juillet 2007 à 16:17 -0400, Marvin Renich a écrit : My original message was specifically concerned with graphical apps. I'm not sure which console apps should be displayed; for the most part, I think the Debian maintainer should decide whether it deserves to be displayed by default. I still disagree. The policy should enforce detailed tagging that allows window managers and menu systems maintainers to filter out entries they don't want to display. ACK Window managers *definitely* should be displayed. If I went to the trouble of installing sawfish in addition to metacity, I would like to be able to use both. Yes, from the menu. Sorry, but the menu is not a holdall where we put all functionality that we don't know where to put without thinking a few minutes. A window manager choice has nothing to do in an application menu, as it is not an application. This is a matter for a configuration tool, whatever form it takes. The Debian menu has more Categories than just applications. In particular, it has a category for window managers. If you desktop environment guys want to go a different way and hide this category (and instead allow for window manager switching somewhere else, like some control center) that's fine. But that doesn't say that window managers shouldn't have a menu file, or .desktop if that is going to be its successor. Why shouldn't we attempt to make menus usable? I didn't say we should not make them usable, I said we should not try to make them more usable *by reducing access to less frequently used apps*. As things are, even with the best possible menu system one can imagine, you won't manage to make a menu with 500 entries as usable as one with 100. Could you give guidelines how a maintainer of an application should classify their app, and how Gnome would decide which classes to hide? Guess what, toolbars are not used by a good share of users. Also, my experience is that a good share of less-technically-oriented- but-comfortable-using-a-computer users actually do use toolbars. These affirmations are not contradictory. I don't deny that many users make use of their toolbar, but I think we should keep the menu usable for users who don't. I don't use a toolbar, but for me usable means that everything is there... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Steve Greenland [EMAIL PROTECTED] writes: 3. The actual contents and structure of the default menu in each WM etc. This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2. In particular, just saying we're going to use the FDo format now does nothing to prevent the kind of mess you see in the Debian menu. OTOH, setting an acceptable policy would clean up not only the GNOME menu but all the other menu systems. Except that the freedesktop.org specification comes with its own set of categories, registration system, and classification system, which does not match the Debian system. I suppose we could use the format without using its categorization system, but that seems a bit strange and Debian's current menu structure doesn't have the concept of primary and additional categories the way that the freedesktop.org specification does. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/07 00:14, Manoj Srivastava wrote: On Tue, 24 Jul 2007 19:56:37 -0500, Ron Johnson [EMAIL PROTECTED] said: On 07/24/07 17:31, Manoj Srivastava wrote: On Tue, 24 Jul 2007 21:25:47 +0100, Matthew Johnson [EMAIL PROTECTED] said: [snip] Surely the correct approach is to say that people who don't want to see it won't have it installed and people who have it installed want to be able to use it from the menu. Programs which you have to have installed and yet don't want to see in the menu probably shouldn't have (visible by default) menu entries and should be dealt with by fixing that program, not by removing all the other entries. Haven't heard of multi-user systems, have we? What if some of the users want to see it in the menu, and other do not? Surely we do not want to make Debian unsuited for multi user installations? I have been using a central server with essentially Etch thin clients at one of our testbeds at work; and it does solve a number of sysadmin headaches for us. Sounds like he's either (a) got a Windows mentality, or (b) doesn't want unprivileged users to see non-essential apps. The latter might be fine as a local policy; but surely is not correct as a Debian default. We should make it _possible_ to implement a local policy of hiding information from users; but we must not let information hiding be the default; nor the only possible local policy. 100% ACK. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGpvMwS9HxQb37XmcRAoiDAJwJuw70f0DtiQ6faIRoBSixmbZ0/wCeJaop M50vfajDvv0zOmcAidgDUeQ= =VTej -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le vendredi 20 juillet 2007 à 16:26 +0200, Michelle Konzack a écrit : But the bigger problem is, that some applications have titles for applications which go over 1/3 of a 1024x768 screen mostly Openoffice Apps like Openoffice.org Printer Administration where the menu has a width of 372 pixels which is realy annoying. This sounds exactly like the kind of entries which have nothing to do in the menu. Printers should be configured centrally and made available to OOo - in fact, they are. If there are any OOo specific parameters for printers, they should be made available from inside OOo only, not from the menu. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit : The latter might be fine as a local policy; but surely is not correct as a Debian default. We should make it _possible_ to implement a local policy of hiding information from users; but we must not let information hiding be the default; nor the only possible local policy. No. We should hide part of the information by default, but make it both possible: * for users to access the extra information without anything too complicated; * for administrators to really lock information if that's really useful. Relevant information easily gets lost when there is too much of it, which is why a *default* setup should never show all available information. And this isn't only relevant for menus. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
Le mardi 24 juillet 2007 à 20:13 +0200, Eduard Bloch a écrit : This is a very bad idea. It is going to clutter the freedesktop menu with tons of useless entries with ugly icons and make it as useless as Make it short, what is your point? Not allowing others to play in your GNOME sandbox? My point is that currently the GNOME menu is usable, and it's one of the key parts of this desktop's usability. I'm open to any propositions to make it better, and closed to propositions that make it worse (e.g. by making it look like the Debian menu). -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
* Josselin Mouette ([EMAIL PROTECTED]) [070725 12:06]: Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit : The latter might be fine as a local policy; but surely is not correct as a Debian default. We should make it _possible_ to implement a local policy of hiding information from users; but we must not let information hiding be the default; nor the only possible local policy. No. We should hide part of the information by default, but make it both possible: * for users to access the extra information without anything too complicated; * for administrators to really lock information if that's really useful. Actually, it might also be useful to allow different window managers to have different default levels of what information is shown. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le mercredi 25 juillet 2007 à 12:12 +0200, Andreas Barth a écrit : Actually, it might also be useful to allow different window managers to have different default levels of what information is shown. Definitely. The freedesktop specification could allow to do that, provided that menu files are correctly tagged with OnlyShowIn and Categories fields. It also requires some tweaking from the menu systems maintainers. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Wed, 25 Jul 2007, Josselin Mouette wrote: I'm open to any propositions to make it better, Well, I made the suggestion of user roles which was more or less ignored in this thread. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
* Josselin Mouette [EMAIL PROTECTED] [070725 06:10]: Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit : The latter might be fine as a local policy; but surely is not correct as a Debian default. We should make it _possible_ to implement a local policy of hiding information from users; but we must not let information hiding be the default; nor the only possible local policy. Exactly. No. We should hide part of the information by default, but make it both possible: * for users to access the extra information without anything too complicated; * for administrators to really lock information if that's really useful. Relevant information easily gets lost when there is too much of it, which is why a *default* setup should never show all available information. And this isn't only relevant for menus. Absolutely *wrong*. Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. If a novice user installs an app and then goes to the menu and doesn't find it, how is this user supposed to know what to do? This is completely *un*usable. The more novice the user, the more important it is for the *default* to be for all graphical apps to be shown. Then let the individual user decide which ones are important to him/her. Menus, by their nature, are inherently unusable for the most frequently used apps, and we should not be trying to make them more usable at the expense of making less frequently used apps harder to access. Menus make less frequently used apps easy to get at, while toolbars make frequently used apps even easier; use the right tool for the right job. If Gnome were to have a menu policy configuration, with the Debian default being show all apps, but which made it easy for the less is more useable camp to accept someone else's idea of most important apps with a single setting rather than having to wade through the menu editor, I would find that an excellent compromise. As for multiuser systems and servers, the same logic applies. The Debian default should be to show all apps, then let the sysadmin tailor that for the installation, then let the users fine tune it. ...Marvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL PROTECTED] wrote: Absolutely *wrong*. Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. If you install the python interpreter on your machine, do you also expect it to appear in the main menu ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL PROTECTED] wrote: Absolutely *wrong*. Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. If you install the python interpreter on your machine, do you also expect it to appear in the main menu ? No, why do you ask? The python interpreter isn't a graphical application. It also doesn't have a menu entry, so there's nothing to hide. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL PROTECTED] wrote: Absolutely *wrong*. Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. If you install the python interpreter on your machine, do you also expect it to appear in the main menu ? No, why do you ask? The python interpreter isn't a graphical application. It also doesn't have a menu entry, so there's nothing to hide. You obviously never looked at the Debian menu. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL PROTECTED] wrote: Absolutely *wrong*. Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. If you install the python interpreter on your machine, do you also expect it to appear in the main menu ? No, why do you ask? The python interpreter isn't a graphical application. It also doesn't have a menu entry, so there's nothing to hide. You obviously never looked at the Debian menu. How do you come to that conclusion? On the contrary, I use it frequently (there's other menu in my WM). But from Marvin's sentence (which I think is right) , | If, as a desktop user, I install a graphical app on my machine, I | *expect* to see that app in the main menu ` you cannot conclude on his (or my) expectations regarding python, because python is not a graphical application. In case you are in fact interested in the unrelated question Should non-graphical applications have a menu entry?, here's my opinion: In most cases I think they shouldn't. All those interpreters in Applications/Programming are a good example for executables which IMHO don't need a menu entry. There may be cases, though, were a menu entry makes sense. In particular for programs which usually need their own terminal, anyway, and are likely to stay open for a while (e.g. mutt). Selecting appropriate settings for the terminal used is a different issue... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL PROTECTED] wrote: Absolutely *wrong*. Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. If you install the python interpreter on your machine, do you also expect it to appear in the main menu ? No, why do you ask? The python interpreter isn't a graphical application. It also doesn't have a menu entry, so there's nothing to hide. You obviously never looked at the Debian menu. How do you come to that conclusion? Well, that's clear, since it actually has a menu entry. I looked in /usr/share/menu but overlooked it. But that's still completely irrelevant for the question at hand. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Frank Küster schrieb: Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL PROTECTED] wrote: Absolutely *wrong*. Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. If you install the python interpreter on your machine, do you also expect it to appear in the main menu ? No, why do you ask? The python interpreter isn't a graphical application. It also doesn't have a menu entry, so there's nothing to hide. You obviously never looked at the Debian menu. How do you come to that conclusion? Well, that's clear, since it actually has a menu entry. I looked in /usr/share/menu but overlooked it. But that's still completely irrelevant for the question at hand. Actually, it's not. That's Joss' whole point. We should hide entries, such as the python interpreter for novice users (at least in environments like KDE/GNOME/XFCE, which target the novice users). If the Debian menu is too overloaded, it becomes less useful. Sometimes, less is more imho. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: adding desktop files to misc packages
Michael Biebl [EMAIL PROTECTED] wrote: Actually, it's not. That's Joss' whole point. We should hide entries, such as the python interpreter for novice users (at least in environments like KDE/GNOME/XFCE, which target the novice users). If the Debian menu is too overloaded, it becomes less useful. Sometimes, less is more imho. I tend to disagree, simply because I think that python shouldn't have a menu entry at all. Who wants to convince me (or give me an URL to an archived discussion) that it should have one? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit : Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. Do you expect to see console applications in the menu as well? All interpreters and shells? Window managers? If a novice user installs an app and then goes to the menu and doesn't find it, how is this user supposed to know what to do? This bit is correct: someone installing an app can reasonably expect to see it in the menu. However you are drawing wrong conclusions: This is completely *un*usable. The more novice the user, the more important it is for the *default* to be for all graphical apps to be shown. Then let the individual user decide which ones are important to him/her. If the users installs the distribution with default settings or starts a session on a multi-user setup, he should find a usable menu, not a menu with all possible applications he never wanted to install. Menus, by their nature, are inherently unusable for the most frequently used apps, and we should not be trying to make them more usable at the expense of making less frequently used apps harder to access. Why shouldn't we attempt to make menus usable? Menus make less frequently used apps easy to get at, while toolbars make frequently used apps even easier; use the right tool for the right job. Guess what, toolbars are not used by a good share of users. Toolbars sound obvious for experienced users, but a novice will never have the idea to modify the interface that is shown to him; which is why this interface must be as straightforward as possible - and that also includes good default shortcuts in the toolbar. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] wrote: Le mercredi 25 juillet 2007 à 16:40 +0200, Frank Küster a écrit : Michael Biebl [EMAIL PROTECTED] wrote: Actually, it's not. That's Joss' whole point. We should hide entries, such as the python interpreter for novice users (at least in environments like KDE/GNOME/XFCE, which target the novice users). If the Debian menu is too overloaded, it becomes less useful. Sometimes, less is more imho. I tend to disagree, simply because I think that python shouldn't have a menu entry at all. Who wants to convince me (or give me an URL to an archived discussion) that it should have one? As long as it is not shown, it doesn't matter, so I guess we can agree on this matter. No, not at all. I have not yet seen a convincing argument for hiding menu entries. The only ones were less is more, which is to vague to get one much further, and we need to hide stuff like python, which is plain wrong IMHO because I think python shouldn't have a menu entry at all. In particular, nobody has yet answered Marvin's argument about not mixing up the purpose of the menu and the toolbar, , | Gnome and KDE are targeted primarily at desktop users, not servers. If, | as a desktop user, I install a graphical app on my machine, I *expect* | to see that app in the main menu. The place where I put important | and/or frequently used apps is on a panel/toolbar. ` Mike overlooked the word graphical, and since then we are discussing python, not menu/.desktop. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Le mercredi 25 juillet 2007 à 16:40 +0200, Frank Küster a écrit : Michael Biebl [EMAIL PROTECTED] wrote: Actually, it's not. That's Joss' whole point. We should hide entries, such as the python interpreter for novice users (at least in environments like KDE/GNOME/XFCE, which target the novice users). If the Debian menu is too overloaded, it becomes less useful. Sometimes, less is more imho. I tend to disagree, simply because I think that python shouldn't have a menu entry at all. Who wants to convince me (or give me an URL to an archived discussion) that it should have one? As long as it is not shown, it doesn't matter, so I guess we can agree on this matter. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland [EMAIL PROTECTED] wrote: On 25-Jul-07, 13:28 (CDT), Josselin Mouette [EMAIL PROTECTED] wrote: If an application is used so infrequently, it shouldn't have its place in a menu. That turns out not to be the case. If I use an app frequently, then it goes on the toolbar. The menu is for finding infrequently used apps. For a lot of users, browsing the menu is how they find out what's available. IIRC, gnome is going to switch to gnome-main-menu. There is a reason for this. What does that mean? What is gnome-main-menu? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
* Josselin Mouette [EMAIL PROTECTED] [070725 12:57]: Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit : Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. Do you expect to see console applications in the menu as well? All interpreters and shells? Window managers? My original message was specifically concerned with graphical apps. I'm not sure which console apps should be displayed; for the most part, I think the Debian maintainer should decide whether it deserves to be displayed by default. Window managers *definitely* should be displayed. If I went to the trouble of installing sawfish in addition to metacity, I would like to be able to use both. Yes, from the menu. If a novice user installs an app and then goes to the menu and doesn't find it, how is this user supposed to know what to do? This bit is correct: someone installing an app can reasonably expect to see it in the menu. However you are drawing wrong conclusions: This is completely *un*usable. The more novice the user, the more important it is for the *default* to be for all graphical apps to be shown. Then let the individual user decide which ones are important to him/her. If the users installs the distribution with default settings or starts a session on a multi-user setup, he should find a usable menu, not a menu with all possible applications he never wanted to install. Usable, yes; minimal, no. See the next paragraph: Menus, by their nature, are inherently unusable for the most frequently used apps, and we should not be trying to make them more usable at the expense of making less frequently used apps harder to access. Why shouldn't we attempt to make menus usable? I didn't say we should not make them usable, I said we should not try to make them more usable *by reducing access to less frequently used apps*. Menus make less frequently used apps easy to get at, while toolbars make frequently used apps even easier; use the right tool for the right job. Guess what, toolbars are not used by a good share of users. Toolbars sound obvious for experienced users, but a novice will never have the idea to modify the interface that is shown to him; which is why this interface must be as straightforward as possible - and that also includes good default shortcuts in the toolbar. That a novice will not know that he can change the interface is even more reason to make sure the (graphical) app that he installed is in the menu. A good system of hints that includes one about putting applications on the toolbar would be very helpful. Also, my experience is that a good share of less-technically-oriented- but-comfortable-using-a-computer users actually do use toolbars. Josselin, we have not met face-to-face, and email does not convey emotion very well, so I want to make sure you know that this is not a personal attack. Your contribution to Debian is significant, and I appreciate it (along with that of the many other DD's). I respect the technical opinions that you have expressed on the debian mailing lists, and agree with many of them. But I strongly disagree with you on this issue. ...Marvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Wed, Jul 25, 2007 at 06:57:54PM +0200, Josselin Mouette wrote: If the users installs the distribution with default settings or starts a session on a multi-user setup, he should find a usable menu, not a menu with all possible applications he never wanted to install. So the menu system should know if an application was explicitely selected by the user during installation or it was pulled in due to some strange dependency? And in the latter case, the menu system should know that the user _wanted_ the application to be installed regardless (and therefore he/she expects to see a menu entry by default)? Why shouldn't we attempt to make menus usable? IMHO the best would be a uniof of the two viewpoints: show everything by default, and gradually hide entries that were not used for some time. Or did Microsoft patent that? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: adding desktop files to misc packages
That's a good reason to improve the menu system, but not really a good reason to just go ahead and ship two versions of basically the same information, IMO. Recent version(s) of lynx have an icon in my KDE menu. I'd really rather not have it there, and was curious if anyone had filed a bugreport about it. I can remove it manually of course, but by default I feel rather strongly it should not be there. It is a console app, and people who are interested in using it can presumably launch it from there. People like me, when I am on a console. Reading some of the mails in this thread, there are people who feel everything should be in the menu. These people aren't typical KDE/Gnome users. I think it's a fine idea to have two menu systems, one including the kitchen sink and one catering to more standard desktop use and excluding lynx, window managers etc.
Re: adding desktop files to misc packages
Le mercredi 25 juillet 2007 à 16:17 -0400, Marvin Renich a écrit : My original message was specifically concerned with graphical apps. I'm not sure which console apps should be displayed; for the most part, I think the Debian maintainer should decide whether it deserves to be displayed by default. I still disagree. The policy should enforce detailed tagging that allows window managers and menu systems maintainers to filter out entries they don't want to display. Window managers *definitely* should be displayed. If I went to the trouble of installing sawfish in addition to metacity, I would like to be able to use both. Yes, from the menu. Sorry, but the menu is not a holdall where we put all functionality that we don't know where to put without thinking a few minutes. A window manager choice has nothing to do in an application menu, as it is not an application. This is a matter for a configuration tool, whatever form it takes. Why shouldn't we attempt to make menus usable? I didn't say we should not make them usable, I said we should not try to make them more usable *by reducing access to less frequently used apps*. As things are, even with the best possible menu system one can imagine, you won't manage to make a menu with 500 entries as usable as one with 100. Guess what, toolbars are not used by a good share of users. Also, my experience is that a good share of less-technically-oriented- but-comfortable-using-a-computer users actually do use toolbars. These affirmations are not contradictory. I don't deny that many users make use of their toolbar, but I think we should keep the menu usable for users who don't. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: adding desktop files to misc packages
On Wed, 25 Jul 2007, Andreas Tille wrote: I'm open to any propositions to make it better, Well, I made the suggestion of user roles which was more or less ignored in this thread. While beeing uncomfortable to reply to my own mail it seems that the proposal is quite to abstract to get any comment, perhaps a screenshot I'm using in my talks makes clear what I mean. Here you can see a menu of a user that is in the role med (for medicine) and has for testing purpose also added to the role junior (there are no offcial packages that feature the Dabian-Jr. menu. http://people.debian.org/~tille/talks/img/menu-en.png Those users that are not in role med do not see the Med menu entry (resp. for Junior or whatever menu structure is used). Currently the implementation of roles is done as UNIX groups which is suboptimal and thus the implementation is realised as a plugin system. Perhaps some LDAP plugin could be written. I really wonder whether this concept of user roles are really that strange or stupid that all posters seem to ignore this idea. (Feel free to teach me in private to keep silent with those stupid ideas.) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland [EMAIL PROTECTED] wrote: On 25-Jul-07, 13:28 (CDT), Josselin Mouette [EMAIL PROTECTED] wrote: If an application is used so infrequently, it shouldn't have its place in a menu. That turns out not to be the case. If I use an app frequently, then it goes on the toolbar. The menu is for finding infrequently used apps. For a lot of users, browsing the menu is how they find out what's available. IIRC, gnome is going to switch to gnome-main-menu. There is a reason for this. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Wed, Jul 25, 2007 at 09:56:11PM +0200, Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland [EMAIL PROTECTED] wrote: On 25-Jul-07, 13:28 (CDT), Josselin Mouette [EMAIL PROTECTED] wrote: If an application is used so infrequently, it shouldn't have its place in a menu. That turns out not to be the case. If I use an app frequently, then it goes on the toolbar. The menu is for finding infrequently used apps. For a lot of users, browsing the menu is how they find out what's available. IIRC, gnome is going to switch to gnome-main-menu. There is a reason for this. What does that mean? What is gnome-main-menu? apt-get install gnome-main-menu. http://reverendted.wordpress.com/2007/02/14/show-me-that-updated-gnome-main-menu/ Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le mercredi 25 juillet 2007 à 19:35 +0200, Frank Küster a écrit : Menus, by their nature, are inherently unusable for the most frequently used apps, and we should not be trying to make them more usable at the expense of making less frequently used apps harder to access. Why shouldn't we attempt to make menus usable? Because, as Marvin wrote in the text you cite, the drawback is that it makes less frequently used applications harder to access. If an application is used so infrequently, it shouldn't have its place in a menu. Furthermore, in the case a user needs it more often, he can add it to the menu. This becomes even easier if the menu entry is only hidden, not absent. There are other ways to make menus usable even for frequently used applications, without these drawbacks: For example, if a user can influence the order of entries, that would help much more. Or that could be even more confusing. But I agree with Marvin (and that's also my usage scheme) that menus should provide access to the less frequently used applications, not the ones started very often. I don't have toolbars in my WM, but it starts the frequently used apps without asking me, so I use the menu for the rare ones. This is also my usage scheme: everyday apps in the session, less frequently used apps in the menu, rarely used apps in a terminal or a launching tool. I have little experience with such users; the ones I know and would call computer illiterate use the windows desktop or the Mac dock for starting their pet applications. If there's actually a considerable number of people who don't even get that far, I'm not sure how to help them. Maybe you are right, and hiding stuff is a possibility. Automatically moving the often-used entries to a well-visible toolbar is an alternative; I generally don't like if computers change their appearance based on what they perceive my usage patterns, but maybe it's the better choice here than hiding. Things like slab are an attempt in this direction, by making frequently used applications automatically directly accessible, but last time I looked at it I was not convinced at all by the result. I also agree that changing the appearance depending on usage is not a good idea. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: adding desktop files to misc packages
* Frank Küster [EMAIL PROTECTED] [070725 10:08]: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL PROTECTED] wrote: Absolutely *wrong*. Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main menu. The place where I put important and/or frequently used apps is on a panel/toolbar. If you install the python interpreter on your machine, do you also expect it to appear in the main menu ? No, why do you ask? The python interpreter isn't a graphical application. It also doesn't have a menu entry, so there's nothing to hide. You obviously never looked at the Debian menu. How do you come to that conclusion? On the contrary, I use it frequently (there's other menu in my WM). But from Marvin's sentence (which I think is right) , | If, as a desktop user, I install a graphical app on my machine, I | *expect* to see that app in the main menu ` you cannot conclude on his (or my) expectations regarding python, because python is not a graphical application. Thanks Frank; that is exactly what I meant. ...Marvin PS Please do not CC me when replying to the list, I am subscribed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
#include hallo.h * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]: The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. This is a very bad idea. It is going to clutter the freedesktop menu with tons of useless entries with ugly icons and make it as useless as Make it short, what is your point? Not allowing others to play in your GNOME sandbox? Eduard. -- HE Arghl. HE Ich wunderte mich gerade über *sehr* ekliges Perl... bis ich das fand: HE # Copyright (C) 2004 Marc Brockschmidt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Eduard Bloch wrote: * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]: The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. This is a very bad idea. It is going to clutter the freedesktop menu with tons of useless entries with ugly icons and make it as useless as Make it short, what is your point? Not allowing others to play in your GNOME sandbox? Surely the correct approach is to say that people who don't want to see it won't have it installed and people who have it installed want to be able to use it from the menu. Programs which you have to have installed and yet don't want to see in the menu probably shouldn't have (visible by default) menu entries and should be dealt with by fixing that program, not by removing all the other entries. Having said that, I do agree with moving to .desktop by default, but that does not address the issue of what should be in the menus, just how. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: adding desktop files to misc packages
On Tue, 24 Jul 2007 21:25:47 +0100, Matthew Johnson [EMAIL PROTECTED] said: Eduard Bloch wrote: * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]: The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. This is a very bad idea. It is going to clutter the freedesktop menu with tons of useless entries with ugly icons and make it as useless as Make it short, what is your point? Not allowing others to play in your GNOME sandbox? Surely the correct approach is to say that people who don't want to see it won't have it installed and people who have it installed want to be able to use it from the menu. Programs which you have to have installed and yet don't want to see in the menu probably shouldn't have (visible by default) menu entries and should be dealt with by fixing that program, not by removing all the other entries. Haven't heard of multi-user systems, have we? What if some of the users want to see it in the menu, and other do not? Surely we do not want to make Debian unsuited for multi user installations? I have been using a central server with essentially Etch thin clients at one of our testbeds at work; and it does solve a number of sysadmin headaches for us. manoj -- He's just like Capistrano, always ready for a few swallows. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/24/07 17:31, Manoj Srivastava wrote: On Tue, 24 Jul 2007 21:25:47 +0100, Matthew Johnson [EMAIL PROTECTED] said: Eduard Bloch wrote: * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]: The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. This is a very bad idea. It is going to clutter the freedesktop menu with tons of useless entries with ugly icons and make it as useless as Make it short, what is your point? Not allowing others to play in your GNOME sandbox? Surely the correct approach is to say that people who don't want to see it won't have it installed and people who have it installed want to be able to use it from the menu. Programs which you have to have installed and yet don't want to see in the menu probably shouldn't have (visible by default) menu entries and should be dealt with by fixing that program, not by removing all the other entries. Haven't heard of multi-user systems, have we? What if some of the users want to see it in the menu, and other do not? Surely we do not want to make Debian unsuited for multi user installations? I have been using a central server with essentially Etch thin clients at one of our testbeds at work; and it does solve a number of sysadmin headaches for us. Sounds like he's either (a) got a Windows mentality, or (b) doesn't want unprivileged users to see non-essential apps. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGpp/FS9HxQb37XmcRAvKVAJ9QWgEg7G17XmIEI/F2uXlwjWmxdQCggwOz hKI50dPqHRDyb6RI6T0S02I= =MY1/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Tue, 24 Jul 2007 19:56:37 -0500, Ron Johnson [EMAIL PROTECTED] said: On 07/24/07 17:31, Manoj Srivastava wrote: On Tue, 24 Jul 2007 21:25:47 +0100, Matthew Johnson [EMAIL PROTECTED] said: Eduard Bloch wrote: * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]: The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. This is a very bad idea. It is going to clutter the freedesktop menu with tons of useless entries with ugly icons and make it as useless as Make it short, what is your point? Not allowing others to play in your GNOME sandbox? Surely the correct approach is to say that people who don't want to see it won't have it installed and people who have it installed want to be able to use it from the menu. Programs which you have to have installed and yet don't want to see in the menu probably shouldn't have (visible by default) menu entries and should be dealt with by fixing that program, not by removing all the other entries. Haven't heard of multi-user systems, have we? What if some of the users want to see it in the menu, and other do not? Surely we do not want to make Debian unsuited for multi user installations? I have been using a central server with essentially Etch thin clients at one of our testbeds at work; and it does solve a number of sysadmin headaches for us. Sounds like he's either (a) got a Windows mentality, or (b) doesn't want unprivileged users to see non-essential apps. The latter might be fine as a local policy; but surely is not correct as a Debian default. We should make it _possible_ to implement a local policy of hiding information from users; but we must not let information hiding be the default; nor the only possible local policy. manoj -- A verbal contract isn't worth the paper it's printed on. Samuel Goldwyn Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Am Freitag, den 20.07.2007, 18:03 +0200 schrieb Michelle Konzack: Am 2007-07-15 22:57:10, schrieb Daniel Leidert: Am Samstag, den 14.07.2007, 12:44 -0400 schrieb Joey Hess: Until there is one, I don't see any reason why I should accept patches adding menu files to my packages. The .desktop format is not only about the menu item itself. It also contains the application - MIME/file type association information. The update-desktop-database then parses all .desktop files and creates this database (/usr/share/applications/mimeinfo.cache). AFAIK KDE 3 uses this system, his own system and the old system via /usr/lib/mime (metamail, right?). But GNOME AFAIK only uses the current shared MIME info database. Which mean, over the half of the .desktop files would be useless for peoples NOT USING KDE or Gnome. This is wrong. There are many other systems that make use of these _cross-desktop_ specifications, written to unify the ways, the different environments handled these things in the past (e.g. current browser use this information to know, which applications to use for a MIME type; but there are many other systems and implementation to use these information - not only written for GNOME/KDE/XFCE). Further my point was, that .menu only contains a subset of information a .desktop file contains and that the conversion into .desktop files will be very limited. However, I support ONE fileformat since maintaining a .menu AND A .desktop file costs some nerv specialy, if you can not use/test the .desktop files. There are test applications for .desktop files. And PS: That something is getting on your nerves is not a compelling argument. So if menu use the .desktop files as input, it would be good. Yes, that would be possible. However I think, that this only makes more work that simply switching the Debian .menu file format into the .desktop format too. Generating both menu and .desktop files from a third format would be pointless. Either format can be generated from the other format. No. The Debian menu entries do not contain the information about which MIME/file types can be handled nor in which menus the entry should This is right, but WM's which do not use .desktop files do they support those mime stuff? -- AFAIK no. A pretty silly argument. I was talking about the conversion of Debian's .menu files into fd.o .desktop files. Can you please tell me, which WMs support or use Debian's .menu files or it's features? Right: We are talking about a Debian internal system. occur. The Debian menu items also do not contain the information, how to ??? -- What do you mean, with in which entry they should occur? OnlyShowIn, NotShowIn, Categories - Debian .menu files do not follow the Desktop Entry Specification and do not contain the Categories information from the specification, beginning with the fact, that there is no 'Application' category, because it's very useless - the Type key tells, if the .desktop file is for an application. The Menu System have the section= which is, WHERE the item occur. The Debian menu sections are differently organised and use different categories. E.g. Application(s) is not registered category in the Desktop Menu Specification. handle the arguments when calling the program from e.g. nautilus to open Does this work under fvwm too? AFAIK no. We speak about a cross-desktop specification, that was written to unify the systems on the desktops. Also current KDE 3 doesn't fully support all specs, but KDE 4 will. So I cannot tell you, if or when fvwm (parts) will follow the specs, but I can tell you, that using fvwm as argument here, is pretty useless. I was talking about the limitation of converting the different formats. And applications using the extended features of the .desktop format will more suffer from the limited conversion than applications/systems _not_ using _any_ parts of the specifications. But these systems also will not loose anything by dropping the Debian .menu file format in favour of the .desktop file format. I wasn't talking about removing the Debian menu in favour of the GNOME/KDE/XFCE menus. a special file. And I don't want to start to tell about the action section possibilities ;) However, the formats only share some basic information, but the .desktop format contains much more information, than the Debian menu item files. You may be able to create a Debian menu file from the .desktop file. But the other way would be very useless. It depends, whether the apps SHOULD be run from GNOME/KDE or not. This is wrong and I already explained why. And even a limited .desktop file would only work on the systems, where the .desktop format is supported (including Debian's internal menu). So what is your argument? For many (most of my) apps, I do not need any mime stuff and such. And this is the compelling argument against my statement, that .menu only contains a subset of .desktop and you will never be
Re: adding desktop files to misc packages
#include hallo.h * Bernhard R. Link [Sat, Jul 14 2007, 04:26:50PM]: * Eduard Bloch [EMAIL PROTECTED] [070714 14:44]: #include hallo.h I also suggest moving away from the Debian menu files to .desktop files because of more flexible format. Therefore, if the menu using packages support the new style, they would read the menu data from those .desktop files. What do you mean with format and what with more flexible? file:///usr/share/doc/menu/html/ch3.html http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html There can hardly be anything more flexible than free-style key-string Oh yeah, any more extremes? I talk about better roads with more optimal ways and you say there is no difference since it's as good as driving through forests and deserts which also takes you to the destination (figurative speaking). Eduard. -- LGS Halloechen, ihr Spinner, so frueh auf? nusse nein, wir schlafen alle im kollektiv knorke mein alkoven ist kaputt teq alkohol kaputt? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Am 2007-07-13 23:49:29, schrieb Josselin Mouette: Le vendredi 13 juillet 2007 à 17:30 -0400, Joey Hess a écrit : There are probably enhancements that would let it create _better_ .desktop files. For example, ones with translations.. Ah, right. I forgot translations. Another good reason to drop the Debian menu system. And if someone does not use KDE/GNOME for ANY reason? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Hello Joey, Am 2007-07-13 18:02:18, schrieb Joey Hess: Bastian Venthur wrote: You should be able to do this on your own system by editing /etc/menu-methods/translate_menus. But.. The Appications menu can already have up to 23 submenus, and already grows beyond 10 on many typical systems. Rather and moving it up and so having an enormous root menu with 15-30 items, it would be good to reduce the number of items already in it closer to 10 via deeper tree structure or more reorganisation. Bearing in mind that menu can flatten unnecessarily deeper tree structures if the tree is lightly populated. I have nearly the same problem with 16 submenus in Apps. But the bigger problem is, that some applications have titles for applications which go over 1/3 of a 1024x768 screen mostly Openoffice Apps like Openoffice.org Printer Administration where the menu has a width of 372 pixels which is realy annoying. Besides that, from my naive-user's point of view I wonder why my menu has so many redundant entries? Maybe we could get rid of the Debian menu I have never seen a redunant menu entry since I use fvwm and have over 1400 entries in the Debian Menu System. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Am 2007-07-13 23:43:56, schrieb Josselin Mouette: Le vendredi 13 juillet 2007 à 16:54 -0400, Joey Hess a écrit : I've gotten some bug reports lately asking for desktop files to be added to packages like xgalaga and kobodeluxe, and saw some others in the BTS. All of these packages, of course, already include Debian menu files. But I don't understand what the rationalle is behind adding a desktop file to a package that includes a Debian menu file and is not a Gnome/KDE component. The Freedesktop.org menu is not meant to be limited to GNOME and KDE components. IMO the Debian menu should be entirely deprecated unless something serious is done about it. Currently: * It is utterly and absolutely ugly. 32x32 XPM icons are not matching the graphic quality we have on the rest of the desktop. Example? * Its structure is impractical. Most important things are in Applications/, which adds a menu level with no use, and several submenus are useless. Oh right, there are some Entries which can not be started form the Menu System since they need at least a Parameter/Filename/XTerm and such... For such Apps I have several times contacted the appropiated Maintainer in the last 3 years, but nothing has changed... This has something to do with busy or lazzy Maintainers and not the Menu System itself. * Most importantly, it is absolutely full of useless stuff. Example? Why do we need a menu entry for each shell ? A user who wants another shell is most probably capable of running it himself. How to start it form FVWM? if I want a eTerm, and have only an entry vor XTerm schould I start an XTerm and from the XTerm my eTerm? -- Sounds a little bit Weird. A menu entry for each window manager? WTF? We can select them from the display manager now. And if you do now want to logout and ONLY replace the actual WM? (fvwm support it) Oh yes, some of the fvwm Module entries are currently definitiv useless, but they can be improved, since zou can load modules as you need it. (You can create a config for it and then if you need it start it from the Menu System which does not work for most Modules in the current form) A menu entry for yelp? It is already accessible from all applications needing it and from the GNOME panel. I have no GNOME and starting a terminal with info or the xman is in the Section Help right placed. An entry for each python/TCL/guile interpreter on the system? Can't developers use terminals? I found it usefull to runn a Python 2.3 and 2.4 shell or the Tclsh 8.4. An entry for each of the bsdgames? For nano? For so many terminal applications that you want to run, well, in a terminal? Yes, since for most are no GUI applications if you NOT use KDE/GNOME. OK, BSD games schould not be realy there (never used and I do not know...) Apart from a few games (see the initial request you were faced with), I can't find anything in the Debian menu which is neither already in the GNOME menu at a better place, or simply completely unsuitable for a graphical menu. But what about peoples which do not RUN GNOME/KDE? Most of the peoples I know, do not use such DE's AND WE use High-End Machines where we can run 10 Gnome/KDE Installations in parallel without seeing a perforance problem... Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Hello Neil, Am 2007-07-15 14:11:55, schrieb Neil Williams: If all Gnome packages silently drop debian/menu in the next upload, is that actually going to be a problem for anyone? Since WE (me, colegous and friends) do not use any GNOME/KDE Apps, where will be no lost for us. But maybe the KDE/GNOME menu files can be put into a seperated package for those which do not RUN KDE/GNOME but some dedicated Apps? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Hi Don, Am 2007-07-16 04:12:02, schrieb Don Armstrong: So it seems like we should do the following: 1. Make changes to the menu system to use .desktop files in preference to .menu files when they exist 2. Generate .desktop files from .menu files using the menu system when .desktop files don't exist. This two would be realy good. 3. Continue using the menu system for window managers which don't natively understand .desktop files; drop the Debian menu for those that do. The last sentence makes no sense, because WM's do not depend on the Menu System. They only Recommends or Suggests menu. So you can not drop anything. If you have a WM which support .desktop files, this WM should not Recommends/Suggests menu. All others which support menus should. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Am 2007-07-14 10:55:00, schrieb Bernhard R. Link: * Josselin Mouette [EMAIL PROTECTED] [070713 23:44]: IMO the Debian menu should be entirely deprecated unless something serious is done about it. Currently: * It is utterly and absolutely ugly. 32x32 XPM icons are not matching the graphic quality we have on the rest of the desktop. Then just add larger or any other icons (in appropiate additional fields). One of my packages already has a 64x64 icon. Currently no window manager user it, but if I would use any window manager showing icons and not scaling them down to 16x16 it would be almost no efford to make them use them. Mabe the Debian Menu or .desktop files should not only support icon16 and icon32 but icon48 and icon64 too? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Am 2007-07-15 22:57:10, schrieb Daniel Leidert: Am Samstag, den 14.07.2007, 12:44 -0400 schrieb Joey Hess: Until there is one, I don't see any reason why I should accept patches adding menu files to my packages. The .desktop format is not only about the menu item itself. It also contains the application - MIME/file type association information. The update-desktop-database then parses all .desktop files and creates this database (/usr/share/applications/mimeinfo.cache). AFAIK KDE 3 uses this system, his own system and the old system via /usr/lib/mime (metamail, right?). But GNOME AFAIK only uses the current shared MIME info database. Which mean, over the half of the .desktop files would be useless for peoples NOT USING KDE or Gnome. However, I support ONE fileformat since maintaining a .menu AND A .desktop file costs some nerv specialy, if you can not use/test the .desktop files. So if menu use the .desktop files as input, it would be good. Generating both menu and .desktop files from a third format would be pointless. Either format can be generated from the other format. No. The Debian menu entries do not contain the information about which MIME/file types can be handled nor in which menus the entry should This is right, but WM's which do not use .desktop files do they support those mime stuff? -- AFAIK no. occur. The Debian menu items also do not contain the information, how to ??? -- What do you mean, with in which entry they should occur? The Menu System have the section= which is, WHERE the item occur. handle the arguments when calling the program from e.g. nautilus to open Does this work under fvwm too? AFAIK no. a special file. And I don't want to start to tell about the action section possibilities ;) However, the formats only share some basic information, but the .desktop format contains much more information, than the Debian menu item files. You may be able to create a Debian menu file from the .desktop file. But the other way would be very useless. It depends, whether the apps SHOULD be run from GNOME/KDE or not. For many (most of my) apps, I do not need any mime stuff and such. menu already generates .desktop files from menu files, and I don't believe it would be too hard to make menu _read_ .desktop files directly and use it as a source for the other files it generates. This may be possible. Maybe the Debian menu file format should follow the freedesktop.org specification too and contain something like: NoDisplay=true X-Debian_only=true to show, that the item should only appear in the Debian menu. Then put these files into e.g. /usr/share/applications/debian and drop the old menu format in /usr/share/menu. This is just one possible solutions to the situation (not an recommendation). This could be a solution :-) Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Fri, 20 Jul 2007, Michelle Konzack wrote: The last sentence makes no sense, because WM's do not depend on the Menu System. They only Recommends or Suggests menu. So you can not drop anything. I'm talking about droping the 'Debian menu' here, not droping dependencices on 'the menu system'. Don Armstrong -- I leave the show floor, but not before a pack of caffeinated Jolt gum is thrust at me by a hyperactive girl screaming, Chew more! Do more! The American will to consume more and produce more personified in a stick of gum. I grab it. -- Chad Dickerson http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le jeudi 19 juillet 2007 à 10:28 +0900, Charles Plessy a écrit : PS : what is wrong with XPM ? If it is inferior to PNG, I can convert the icons in the packages I maintain. But XPM is a text file, which is convenient since we (unfortunately) use this .diff.gz which requires to uuencode any binary addition to a package. XPM has only a 1bit alpha channel. This makes a very important visual difference, especially when it gets downsized to 22x22. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: adding desktop files to misc packages
Joe Smith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Don Armstrong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So it seems like we should do the following: 1. Make changes to the menu system to use .desktop files in preference to .menu files when they exist 2. Generate .desktop files from .menu files using the menu system when .desktop files don't exist. 3. Continue using the menu system for window managers which don't natively understand .desktop files; drop the Debian menu for those that do. The other issue that was brought up was improving the hierarchical organization of the menus, but how to do that hasn't been made clear in this thread. That is exactly the correct thing to do. It has the advantage of basically converting Debian to the stardard FDO .desktop format. It also effectively adds limited support for the FDO format to the other window managers (the menu system would be converting the .desktop files of any installed package automatically). Of course one of the keys to this transition would be to eventually depreciate the .menu files. If the menu system can read the .desktop files then there would be no reason to keep the .menu format around long term, but it would need to stay temporally as part of the transition. To formalize this as a proposal: -BEGIN PROPOSAL- Given that .desktop is a standardized file format, and is roughly a superset of the current .menu format, the Debian menu system will add support reading .desktop files as source in addition to the .menu files. When both a .desktop file and a .menu file exists the .desktop file takes precedence. The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. The .menu format is depreciated. Lintian should add a check warning about packages that include a .menu file but no .desktop file. Maintainers are encouraged to replace the .menu file with a full .desktop file, conformant with the Desktop Menu Specification and the Desktop Entry Specification. However, once a revised Debian menu policy has been adopted, the files should conform with policy in any case where policy contradicts those specifications. Windows managers that support the Desktop Menu Specification should stop including the Debian menu, as all its entries would be available as .desktop files. A revised menu policy should be drafted. It should indicate when a package requires a .desktop file, and when it would not require a desktop file. It should also specify which types of menu entries should default to NoDisplay=True. If extensions to the .desktop format are desired, such as to implement a roles based system for determining which entries appear in the menu, this would be to document which should specify the extension. Finally the document may amend the Desktop Menu Specification hierarchy, if it is determined that a change to that hierarchy would be benifical to the users. -END PROPOSAL- Comments? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le mercredi 18 juillet 2007 à 12:57 -0400, Joe Smith a écrit : Given that .desktop is a standardized file format, and is roughly a superset of the current .menu format, the Debian menu system will add support reading .desktop files as source in addition to the .menu files. This is feasible, but not as easy as you seem to imply. For example you have to generate 32x32 XPM files (har har har) from the icons, which can be different depending on the icon theme and located at different places. When both a .desktop file and a .menu file exists the .desktop file takes precedence. Fine, but you'll have a hard time isolating duplicates. The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. This is a very bad idea. It is going to clutter the freedesktop menu with tons of useless entries with ugly icons and make it as useless as the Debian menu. Please don't do that, and take the opportunity to enforce stricter rules about what should be in the menu. If this is done, the policy changes you are suggesting will just be ignored. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: adding desktop files to misc packages
Joe Smith [EMAIL PROTECTED] writes: To formalize this as a proposal: [...] Surely any proposal for replacing the menu system with desktop files has to involve generating menu files from desktop files for the benefit of programs that use the menu system and don't understand desktop files? The way I expect a transition would go, assuming we decide it's a good idea, would be: * We write a clear specification for what goes into a .desktop file from a Debian perspective, which can mostly be a reference to the freedesktop.org documentation of the format if that's adequate but probably involves at least some discussion of the menu hierarchy from a Debian integration perspective. We also need a policy on what packages should create desktop files and if some packages should create desktop files that aren't shown by default or some other similar magic. This is the *first* step. * The menu code is modified to generate menu files from desktop files if a desktop file exists and no menu file exists. * Only *then* are packages encouraged to start switching from menu files to desktop files, to avoid unnecessary duplication of information in the packages. * We then track progress on adding desktop files with the *long term* goal (+2 releases, realistically) of dropping the generation of desktop files from the old menu format. The first step is vital and hasn't happened yet, and would be useful even in the absence of a decision to do an overall transition. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Josselin Mouette [EMAIL PROTECTED] writes: Le mercredi 18 juillet 2007 à 12:57 -0400, Joe Smith a écrit : The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. This is a very bad idea. Uh, this is already done, no? This is merely documentation, as I see it, of the current state and a note that we shouldn't drop that support until after we've finished the transition. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: adding desktop files to misc packages
On Wednesday 18 July 2007 19:44, Russ Allbery wrote: Surely any proposal for replacing the menu system with desktop files has to involve generating menu files from desktop files for the benefit of programs that use the menu system and don't understand desktop files? Eh, correct me if I'm wrong, but surely the way it works is that install-menu and the various menu-method provided by window/desktop manager packages to convert the set of menu files into the native menu configuration formats of those window/desktop managers? install-menu would now be improved to read .desktop files directly; there is no need to convert them into .menu files first (and really no reason to convert .menu to .desktop either). -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgpxyCJQ8X0T7.pgp Description: PGP signature
Re: adding desktop files to misc packages
Magnus Holmgren [EMAIL PROTECTED] writes: On Wednesday 18 July 2007 19:44, Russ Allbery wrote: Surely any proposal for replacing the menu system with desktop files has to involve generating menu files from desktop files for the benefit of programs that use the menu system and don't understand desktop files? Eh, correct me if I'm wrong, but surely the way it works is that install-menu and the various menu-method provided by window/desktop manager packages to convert the set of menu files into the native menu configuration formats of those window/desktop managers? install-menu would now be improved to read .desktop files directly; there is no need to convert them into .menu files first (and really no reason to convert .menu to .desktop either). Yes, good point, although I'm worried that it's going to take a while to rewrite that code to convert .desktop files instead, and converting .desktop to .menu would give us interim backward compatibility. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le Wed, Jul 18, 2007 at 07:32:28PM +0200, Josselin Mouette a écrit : The Debian menu system will generate .desktop files from .menu files if the .desktop file does not exist. This is intended solely as a temporary compatibility measure. This is a very bad idea. It is going to clutter the freedesktop menu with tons of useless entries with ugly icons and make it as useless as the Debian menu. Please don't do that, and take the opportunity to enforce stricter rules about what should be in the menu. If this is done, the policy changes you are suggesting will just be ignored. In the end, there will not be a big difference if the generation of the .desktop files will be made by human or computer, provided that there is no information on what the GNOME, KDE, and XFCE teams want or do not want in their menu. The tool for hiding entries exists. All we need is information. In the absence of information, yes, ugly icons and menu entries opening terminals to run interactive command-line programs will appear. PS : what is wrong with XPM ? If it is inferior to PNG, I can convert the icons in the packages I maintain. But XPM is a text file, which is convenient since we (unfortunately) use this .diff.gz which requires to uuencode any binary addition to a package. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Michael Biebl [EMAIL PROTECTED] wrote: Frank Küster wrote: Neil Williams [EMAIL PROTECTED] wrote: I like Don's idea - remove the Debian menu from those window managers etc. that understand .desktop files and make the Debian menu aware of .desktop files for those other systems. Oh, please not. [...] I actually do like Don's idea. The first thing I usually do, after installing KDE or Gnome is to disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu, Okay, as long as it can easily be configured, I see no problem in disabling it by default. But there should be either a prominent menu entry which is easy to find, or a README.Debian in an obvious package. for all the reason already given: - It duplicates entries (so it's potentially confusing for novice users) That's a point. - Has no i18n That isn't an argument to remove it, but for adding i18n support to it. - ugly (although I agree that's subjective). No png icons for applications, no icons for subdirectories, which imho makes it harder to recognize the categories quickly. Having no icons is probably a feature - someone else said in this thread that the icons are the reason for slow menus. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Le lundi 16 juillet 2007 à 19:08 -0500, Steve Greenland a écrit : Some of the users we target don't even know what a window manager is, and they don't want to know it. Some of the users we target don't use any desktop environment, running headless servers. So let's remove KDE and GNOME. If you have nothing to say apart proving that you don't want to understand what people write, what's the point of contributing to a mailing list? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Tuesday 17 July 2007 02:08, Steve Greenland wrote: Some of the users we target don't use any desktop environment, running headless servers. So let's remove KDE and GNOME. This problem is about defaults, not about removing things entirely. Appearently every user gets menu items for all installed window managers. Fine with me if it's easy to add an installed window manager to the menu, but I do agree with the general point here that it's quite useless to build a menu with those options for every user by default. Thijs pgpfuL704q7lj.pgp Description: PGP signature
Re: adding desktop files to misc packages
Frank Küster wrote: Michael Biebl [EMAIL PROTECTED] wrote: for all the reason already given: - It duplicates entries (so it's potentially confusing for novice users) That's a point. That's *the* point in my opinion. Duplicated entries are confusing and therefore not user-friendly. - Has no i18n That isn't an argument to remove it, but for adding i18n support to it. But why re-invent the wheel when .desktop files already provide this and other features? - ugly (although I agree that's subjective). No png icons for applications, no icons for subdirectories, which imho makes it harder to recognize the categories quickly. Having no icons is probably a feature - someone else said in this thread that the icons are the reason for slow menus. It is not a feature of the menu, it is a bug of the DE beeing unable to hide icons if the user wants it. This isn't usually a problem for users of the mainstream DEs. And honestly, I think the vast majority of users (including those with exotic DEs) actually likes icons in the menu since that's what menus usually have. I don't want to waste my time and energy to please *every* user out there (that's virtually impossible), so I'd draw the line right here: If you don't want icons, fine but please don't elevate this bug to a feature. Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
