Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
clone 348775 -1 reassign -1 xdg-utils 1.0.2+cvs20100307-3 retitle xdg-utils please introduce (sane) xdg-terminal tags -1 + upstream quit Paul Wise wrote: In xdg-utils CVS there is an xdg-terminal script, not sure why that isn't available in Debian yet: When no desktop is in use, it uses $TERM to choose a terminal, so on this machine it would end up trying to run 'linux'. :) Using $TERMINAL would fix that, I think. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101125184355.gb17...@burratino
Processed (with 1 errors): Re: Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Processing commands for cont...@bugs.debian.org: clone 348775 -1 Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users Bug 348775 cloned as bug 604959. reassign -1 xdg-utils 1.0.2+cvs20100307-3 Bug #604959 [general] general: terminal emulators' alternatives settings' priorities annoy users Bug reassigned from package 'general' to 'xdg-utils'. Bug #604959 [xdg-utils] general: terminal emulators' alternatives settings' priorities annoy users Bug Marked as found in versions xdg-utils/1.0.2+cvs20100307-3. retitle xdg-utils please introduce (sane) xdg-terminal Unknown command or malformed arguments to command. tags -1 + upstream Bug #604959 [xdg-utils] general: terminal emulators' alternatives settings' priorities annoy users Added tag(s) upstream. quit Stopping processing here. Please contact me if you need assistance. -- 604959: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604959 -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 348775: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348775 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.12907106544895.transcr...@bugs.debian.org
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Hi, Simon Richter wrote: The problem at hand is the proposed (and implemented) solution for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332223 . [lxterm having higher priority than konsole on KDE systems] I'm unconvinced that bumping the priority on the other terminal emulators is an adequate solution, hence I'm opening this general bug for discussion on how to reflect individual users' choices properly. It has been suggested on #debian-devel that maybe creating a per-user ~/bin with its own alternatives links might be an option, however there needs to be a fallback mechanism in case the currently selected option goes away. To make this concrete: . unlike browsers with $BROWSER and desktop-specific settings, there is no standard, cross-distro way to make a user-specific choice of terminal . apps integrated into Debian can and should be using x-terminal-emulator, without an explicit /usr/bin/, as hinted at by policy §6.1 Introduction to package maintainer scripts . therefore users can put a script implementing whatever policy they choose in ~/bin/x-terminal-emulator, but: 1. that requires more know-how than many users have 2. applications not integrated into Debian would just use xterm anyway, which is not so great. To solve (1): an interested person could make an app that installs an easily configurable ~/bin/x-terminal-emulator script. This seems like a rfp rather than a general bug, if anything. To solve (2): one could introduce a TERMINAL environment variable analogous to MAILER and implement xdg-terminal that reads it. Please clone this bug and assign to xdg-utils if interested. Sensible? Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101124172454.ga1...@burratino
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
On Thu, Nov 25, 2010 at 1:24 AM, Jonathan Nieder jrnie...@gmail.com wrote: . unlike browsers with $BROWSER and desktop-specific settings, there is no standard, cross-distro way to make a user-specific choice of terminal ... To solve (2): one could introduce a TERMINAL environment variable analogous to MAILER and implement xdg-terminal that reads it. Please clone this bug and assign to xdg-utils if interested. In xdg-utils CVS there is an xdg-terminal script, not sure why that isn't available in Debian yet: http://webcvs.freedesktop.org/portland/portland/xdg-utils/scripts/xdg-terminal.in?revision=HEADview=markup http://webcvs.freedesktop.org/portland/portland/xdg-utils/scripts/xdg-terminal?revision=HEADview=markup -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimbbxf455kw7h0xj4uomo+xorsfab-jrtud=...@mail.gmail.com
Re: alternatives and priorities
Wouter Verhelst writes (alternatives and priorities): Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. I have a suggestion: how about we make it a rule that to provide a new alternative with a greater priority than another package (or to adjust your alternative upwards), you need to get the maintainers of the `losing' package(s) to agree (ie, the packages whose priority your alternative now newly exceeds). If the maintainer(s) disagree, the affected maintainers should discuss it on debian-devel and the `losing' maintainer should implement the consensus. (Obviously the TC can rule if really necessary but I think what amounts to informal consensus polling seems like the right approach here.) Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Sunday 21 May 2006 16:31, Wouter Verhelst wrote: You would end up with nvi or nano as editors, since they are installed by default. Probably more as viewer and so on. Which is bad why? What I meant was that you would have a high number of installations for the packages that are installed by default in a normal installation, and that is not an objective way of getting information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Fri, May 19, 2006 at 03:46:28PM +0200, Wouter Verhelst wrote: That's not an issue. First, ed doesn't install an alternatives for editor. Second, there's also 'by_vote', which puts vim on top. Which is an excellent demonstration of why we should not use popcon to decide alternatives priorities. nano is a more sensible default because it is usable by newbies and by people who do not understand the concept of a modal editor. Being popular is overrated... Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Mon, May 22, 2006 at 10:42:26PM -0300, Maximiliano Curia wrote: On Sunday 21 May 2006 16:31, Wouter Verhelst wrote: You would end up with nvi or nano as editors, since they are installed by default. Probably more as viewer and so on. Which is bad why? What I meant was that you would have a high number of installations for the packages that are installed by default in a normal installation, and that is not an objective way of getting information. Again, this is why I didn't suggest to use the by_inst numbers, but rather the by_vote numbers. The former count the number of installations; the latter count the actual _use_ of a binary. If you have nano installed on your system but never actually use it, that won't move it up in the vote. If you have a look at the order of the by_vote numbers for editors, you'll see that vim, not nvi or nano, is at the top. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
Wouter Verhelst [EMAIL PROTECTED] writes: If you have a look at the order of the by_vote numbers for editors, you'll see that vim, not nvi or nano, is at the top. A list like this only seems meaningful if the entries are fairly consistent with each other. For instance, if you have packages like: PACKAGE NAMEUSE COUNT - EDITOR-1123 EDITOR-2-VERSION-3 55 EDITOR-2-VERSION-3.149 EDITOR-2-VERSION-4 73 The package EDITOR-1 is more popular than any other _package_, but one could also fairly say that EDITOR-2 is actually more popular than EDITOR-1 in general. Which should be higher priority? -Miles -- Come now, if we were really planning to harm you, would we be waiting here, beside the path, in the very darkest part of the forest? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Tue, May 23, 2006 at 04:55:52PM +0900, Miles Bader wrote: Wouter Verhelst [EMAIL PROTECTED] writes: If you have a look at the order of the by_vote numbers for editors, you'll see that vim, not nvi or nano, is at the top. A list like this only seems meaningful if the entries are fairly consistent with each other. For instance, if you have packages like: PACKAGE NAMEUSE COUNT - EDITOR-1123 EDITOR-2-VERSION-3 55 EDITOR-2-VERSION-3.149 EDITOR-2-VERSION-4 73 The package EDITOR-1 is more popular than any other _package_, but one could also fairly say that EDITOR-2 is actually more popular than EDITOR-1 in general. Which should be higher priority? Good point. I would say that all three should receive approximately the priority of all three editors combined, but with version 4 slightly more than version 3, and version 3 in turn slightly more than version 3.1 How's that sound? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
[George Danchev] or some hosts have popularity-contest installed from pure upstream sources instead from a popularity-contest debian package, thus don't have it registered with the dpkg db. That would seriously surprise me, as popularity-contest only is distributed as a Debian package, and the Debian maintainers are also upstream. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Fri, May 19, 2006 at 09:51:58PM +0200, Petter Reinholdtsen wrote: [Gregor Herrmann] If you look at by_vote [0] the situation is different: http://popcon.debian.org/main/editors/by_vote [0] which seems more relevant to me: #inst is the number of people who installed this package; #vote is the number of people who use this package regularly; Note, the popcon vote is not always accurate. It only use files in some directories (like */bin/, but not */lib/*), so most library packages will never get a vote, and most user packages will get votes. Which, I'm sure, is important for popcon maintainers; however, I don't think it is very relevant in this discussion (unless you can point me towards an editor that is implemented as a library ;-) -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Fri, May 19, 2006 at 03:23:09PM -0300, Maximiliano Curia wrote: On Friday 19 May 2006 10:25, Wouter Verhelst wrote: So, instead of using static feature lists to define an application's priority with which it would be configured in the alternatives system, why not use popcon data to do that instead? Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. You would end up with nvi or nano as editors, since they are installed by default. Probably more as viewer and so on. Which is bad why? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
[Wouter Verhelst] Which, I'm sure, is important for popcon maintainers; however, I don't think it is very relevant in this discussion (unless you can point me towards an editor that is implemented as a library ;-) The problem do not only affect libraries. There are other packages (with user applications) which show up with no votes, or with a very low number of votes. I have not investigated this in detail, but want everyone looking at the vote numbers to be aware of the problems with it. Heck, even the installation number have problems. Just check out URL:http://qa.debian.org/developer.php?popcon=popularity-contest, showing that 99.72% of the machines reporting to popcon have popcon installed. I believe that when I figure out how the rest are reporting to popcon. (I suspect the last issue is a problem with corrupt dpkg data.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Sunday 21 May 2006 22:48, Petter Reinholdtsen wrote: --cut-- Heck, even the installation number have problems. Just check out URL:http://qa.debian.org/developer.php?popcon=popularity-contest, showing that 99.72% of the machines reporting to popcon have popcon installed. I believe that when I figure out how the rest are reporting to popcon. (I suspect the last issue is a problem with corrupt dpkg data.) or some hosts have popularity-contest installed from pure upstream sources instead from a popularity-contest debian package, thus don't have it registered with the dpkg db. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
Goswin von Brederlow [EMAIL PROTECTED] writes: Similary any vi extension should top vi itself. Also zile, emacs, xemacs build kind of a progression. Kind of progression?? -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
Hello! On Fri, 19 May 2006 08:46:28 -0500, Wouter Verhelst wrote: On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote: At 1148052328 past the epoch, Wouter Verhelst wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Thoughts? Interesting idea, but by my reckoning that would make ed the default editor for most people, which I don't think is a good idea: http://popcon.debian.org/main/editors/by_inst That's not an issue. First, ed doesn't install an alternatives for editor. Second, there's also 'by_vote', which puts vim on top. ed is installed as an alternative editor: = [EMAIL PROTECTED]:~$ su Password: gismo:/home/luca# update-alternatives --list editor /bin/ed /usr/bin/emacs21 /usr/bin/mcedit-debian /usr/bin/emacs-snapshot /usr/bin/vim.tiny gismo:/home/luca# = And the postinst script says so, too: = [EMAIL PROTECTED]:~$ grep alternatives /var/lib/dpkg/info/ed.postinst update-alternatives --quiet --install /usr/bin/editor editor /bin/ed -100 \ [EMAIL PROTECTED]:~$ = Thx, bye, Gismo / Luca pgpfsxFY6kze9.pgp Description: PGP signature
alternatives and priorities
Hi, Today, after upgrading my system, suddenly mcedit became the default editor, rather than vim as I expected it. Investigating showed that some funny guy decided that mcedit could use a priority of 100, whereas vim had fallen back to 60 since the latest upgrade. Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. I mean, if you maintain a package, you probably like the editor very much, probably more so than any of the other editors in Debian; so you're quite biased. This would mean you would be the worst person to make an objective choice as to what the best priority for your editor would be. Granted, for some things the Policy defines the amount of points you can add to your priority based on the features your program has, but it doesn't do so for everything (unless I've missed something), which means that it's not a definite solution. It's also not at all guaranteed that doing it this way is actually useful. So, instead of using static feature lists to define an application's priority with which it would be configured in the alternatives system, why not use popcon data to do that instead? Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Thoughts? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
At 1148052328 past the epoch, Wouter Verhelst wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Thoughts? Interesting idea, but by my reckoning that would make ed the default editor for most people, which I don't think is a good idea: http://popcon.debian.org/main/editors/by_inst -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
At 1148048910 past the epoch, Jon Dowland wrote: Interesting idea, but by my reckoning that would make ed the default editor for most people, which I don't think is a good idea: http://popcon.debian.org/main/editors/by_inst Eek. Of course if you go by vote, then vim or nvi trump ed, and nano: http://popcon.debian.org/main/editors/by_vote I'd think that if nano was installed it should be preferred over a vi-instance, because vi is so unintuitive to someone who has not experienced it before. Perhaps some kind of mashing of the two datas together... -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote: Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. Mm -- I always wondered why xfce-session-manager had a priority over gnome-session-manager by default. (One might argue that GNOME is installed by default, though, so if a user installs XFCE that's a conscious choice...) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote: At 1148052328 past the epoch, Wouter Verhelst wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Thoughts? Interesting idea, but by my reckoning that would make ed the default editor for most people, which I don't think is a good idea: http://popcon.debian.org/main/editors/by_inst That's not an issue. First, ed doesn't install an alternatives for editor. Second, there's also 'by_vote', which puts vim on top. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Interesting idea, but by my reckoning that would make ed the default editor for most people, which I don't think is a good idea: http://popcon.debian.org/main/editors/by_inst If you look at by_vote [0] the situation is different: http://popcon.debian.org/main/editors/by_vote [0] which seems more relevant to me: #inst is the number of people who installed this package; #vote is the number of people who use this package regularly; gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Janis Joplin Big Brother And: Summertime signature.asc Description: Digital signature
Re: alternatives and priorities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Dowland wrote: At 1148052328 past the epoch, Wouter Verhelst wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Thoughts? Interesting idea, but by my reckoning that would make ed the default editor for most people, which I don't think is a good idea: http://popcon.debian.org/main/editors/by_inst That's only if you use the inst column. ISTM that the vote field is what should be used. In which case vim becomes the default editor, followed by nano. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEbc6IS9HxQb37XmcRAm1NAKCgcVFmq9oYcH4uOjph/MRpy03MowCg0Nkn SMEr3JnXSABHjD2dUw5NLs4= =Hh3W -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
Steinar H. Gunderson [EMAIL PROTECTED] writes: On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote: Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. Mm -- I always wondered why xfce-session-manager had a priority over gnome-session-manager by default. (One might argue that GNOME is installed by default, though, so if a user installs XFCE that's a conscious choice...) /* Steinar */ Similary any vi extension should top vi itself. Also zile, emacs, xemacs build kind of a progression. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
At 1148053588 past the epoch, Wouter Verhelst wrote: That's not an issue. First, ed doesn't install an alternatives for editor. Ah. Of course :) Sheepish, -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Fri, May 19, 2006 at 03:41:12PM +0200, Steinar H. Gunderson wrote: On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote: Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. Mm -- I always wondered why xfce-session-manager had a priority over gnome-session-manager by default. (One might argue that GNOME is installed by default, though, so if a user installs XFCE that's a conscious choice...) Hmm. Recent gnome-session and xfce4-session call update-alternatives with a priority of 50. ksmserver appears to use 40. gnome-session in sarge used 20, ksmserver in sarge used 40 and xfce4-session still used 50. It does look like we might have started a bit of priority inflation there. I don't remember why we set the priority to 50 in the first place. I'd be happy (as one of the xfce guys) for everyone to use the same priority to be honest. -- Simon [ [EMAIL PROTECTED] ] *\ Emergency! Emergency! There's an \** ** ]-+-+-+-+-+-+-+-+-[ **\ emergency going on! - Holly \* ** [ Htag.pl 0.0.22 ] ***\\ signature.asc Description: Digital signature
Re: alternatives and priorities
On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote: Today, after upgrading my system, suddenly mcedit became the default editor, rather than vim as I expected it. Investigating showed that some funny guy decided that mcedit could use a priority of 100, whereas vim had fallen back to 60 since the latest upgrade. Not really on topic, but regarding the relative alternative priorities of vim, nvi, and mcedit have a look at #367991 (summary: as vim maintainers we asked the mc maintainer to lower the alternative priorities of that package). Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: alternatives and priorities
On Friday 19 May 2006 10:25, Wouter Verhelst wrote: Today, after upgrading my system, suddenly mcedit became the default editor, rather than vim as I expected it. Investigating showed that some funny guy decided that mcedit could use a priority of 100, whereas vim had fallen back to 60 since the latest upgrade. Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. I mean, if you maintain a package, you probably like the editor very much, probably more so than any of the other editors in Debian; so you're quite biased. This would mean you would be the worst person to make an objective choice as to what the best priority for your editor would be. Granted, for some things the Policy defines the amount of points you can add to your priority based on the features your program has, but it doesn't do so for everything (unless I've missed something), which means that it's not a definite solution. It's also not at all guaranteed that doing it this way is actually useful. So, instead of using static feature lists to define an application's priority with which it would be configured in the alternatives system, why not use popcon data to do that instead? Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. You would end up with nvi or nano as editors, since they are installed by default. Probably more as viewer and so on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
[Gregor Herrmann] If you look at by_vote [0] the situation is different: http://popcon.debian.org/main/editors/by_vote [0] which seems more relevant to me: #inst is the number of people who installed this package; #vote is the number of people who use this package regularly; Note, the popcon vote is not always accurate. It only use files in some directories (like */bin/, but not */lib/*), so most library packages will never get a vote, and most user packages will get votes. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Hi, On Fri, Jan 20, 2006, Simon Richter wrote: And GNOME would by default be configured to launch gnome-www-browser, thus solving the problem for GNOME users who do not set any other browser in gnomecc. The question for me would be whether this affects people who use neither GNOME nor KDE (the browsers optimized for a specific environment could then be demoted to some lower priority than the non-specific ones, perhaps?) GNOME could then be configured to launch either sensible-browser or gnome-www-browser (my preference would go to sensible-browser because it makes sense system-wide, not only under GNOME). I'm not sure about demoting the priorities. I think priorities should decrease with the number of users because the more specific a package is (in terms of number of users) the more likely you want it to be the default, but I suppose there's no general rule, and it's difficult to measure the importance of launching a browser matching the current environment with respect to its popularity. These changes were commited in galeon and epiphany's SVN, the changes to sensible-browser and to firefox remain to be done. You mean, that they now register as an alternative for gnome-www-browser? epiphany-browser and galeon do, yes. Of course, this could be followed for KDE too. It should not be difficult to get that done. I had somehow expected that the bug report and any followups are forwarded to -devel to spark discussion, so I'm explicitly forwarding it there. My response went through debian-devel when I Cc: the bug report, so I'm continuing this way. Not entirely, since it isn't limited to browsers or terminals. Many users have personal preferences about things that are currently handled through the alternatives system, and the sysadmin's choice (or non-choice, as in the bumping priorities scenario) will affect them. Yes. However, I consider that the system command sensible-browser is user-configurable (via $BROWSER) and the GNOME environment is user-configurable (via gconf settings), so for the browser choice front system-wide and in GNOME, I'm satisfied with the way of things. For example, everytime a GNOME or KDE application launches, a lot of dotfiles will be created for me, so I'd like to avoid this as much as possible as I will only have to clean up afterwards. Hmm, this sounds like a whole new class of problems. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED
Re: Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Hello, Loïc Minier wrote: Rationale: you don't want to see konqueror launched as the default browser in GNOME but you want GNOME to be integrated with Debian. Ah, I remember that one as well. It is simple to extend this scheme with: - gnome-www-browser for browsers with GNOME support (epiphany-browser, galeon, firefox-gnome-support, ...) And GNOME would by default be configured to launch gnome-www-browser, thus solving the problem for GNOME users who do not set any other browser in gnomecc. The question for me would be whether this affects people who use neither GNOME nor KDE (the browsers optimized for a specific environment could then be demoted to some lower priority than the non-specific ones, perhaps?) - check for $DISPLAY and eg. $GNOME_DESKTOP_SESSION_ID in sensible-browser to decide to launch gnome-www-browser or default to x-www-browser Sounds good. These changes were commited in galeon and epiphany's SVN, the changes to sensible-browser and to firefox remain to be done. You mean, that they now register as an alternative for gnome-www-browser? Of course, this could be followed for KDE too. It should not be difficult to get that done. I had somehow expected that the bug report and any followups are forwarded to -devel to spark discussion, so I'm explicitly forwarding it there. Simon, would this help with the problem you mentionned? Not entirely, since it isn't limited to browsers or terminals. Many users have personal preferences about things that are currently handled through the alternatives system, and the sysadmin's choice (or non-choice, as in the bumping priorities scenario) will affect them. For example, everytime a GNOME or KDE application launches, a lot of dotfiles will be created for me, so I'd like to avoid this as much as possible as I will only have to clean up afterwards. Simon signature.asc Description: OpenPGP digital signature
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Hi, On Wed, Jan 18, 2006, Simon Richter wrote: I'm unconvinced that bumping the priority on the other terminal emulators is an adequate solution, hence I'm opening this general bug for discussion on how to reflect individual users' choices properly. We had a similar problem for GNOME recently, but not on the terminal emulator front, it was with web browsers. Rationale: you don't want to see konqueror launched as the default browser in GNOME but you want GNOME to be integrated with Debian. The www-browser and x-www-browser alternatives provide an useful mean for classing browsers system-wide with a priority. The sensible-browser script is an useful entry point to launch the most suitable browser from the current environment. sensible-browser will use the environment to guess what browser or alternative to launch (browsers in $BROWSER, x-www-browser, www-browser in xterm, www-browser). It is simple to extend this scheme with: - gnome-www-browser for browsers with GNOME support (epiphany-browser, galeon, firefox-gnome-support, ...) - check for $DISPLAY and eg. $GNOME_DESKTOP_SESSION_ID in sensible-browser to decide to launch gnome-www-browser or default to x-www-browser These changes were commited in galeon and epiphany's SVN, the changes to sensible-browser and to firefox remain to be done. Of course, this could be followed for KDE too. Simon, would this help with the problem you mentionned? Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Package: general Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The problem at hand is the proposed (and implemented) solution for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332223 . I'm unconvinced that bumping the priority on the other terminal emulators is an adequate solution, hence I'm opening this general bug for discussion on how to reflect individual users' choices properly. It has been suggested on #debian-devel that maybe creating a per-user ~/bin with its own alternatives links might be an option, however there needs to be a fallback mechanism in case the currently selected option goes away. Perhaps it might be an idea to have a wrapper binary that will fall back on the highest precedence alternative in this case, or optionally show a menu (gee, there may be multiple wrapper programs, so there needs to be a mechanism to select them...NOT!). This message shall serve as a starting point for discussion. Please CC the bug in replies. Simon - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=de_DE.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQCVAwUBQ87HPVYr4CN7gCINAQJRxwP9ErXin3cuJ3ZRjTPqJTSTXYUWKZk/cOm1 bPdktUtLUcdRpbRDDB37LEzkkhaUjSfN2JTdGzzSOUkGgJJw4kZ7N10aU6oSLrrd JAAolW3jIr8d+kH7kI3SF478X3J2mEiS4t21maY8N0Yz8fo2vj/YMsHeP0dRG0ck k0FVwyE4J3E= =eOr6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
