Bug#741573: Two menu systems
Didier 'OdyX' Raboud writes (Bug#741573: Two menu systems): The 'trad' menu file or the 'desktop' xdg file are only the starting point of their technical differences; one other technical difference that matters is the support for icon formats. You have missed my key point about differences of goals between the two menu systems. The trad menu explicitly has the goal of providing a menu item for every invokable thing; whereas the desktop menu maintainers want it to provide only entries for a much smaller subset of programs. This means that we need two systems. Now in principle you might argue that the comprehensive menu should also be provided via xdg desktop files because they are supposedly technically superior. However, this technical superiority is disputed by the maintainers of the software for handling the trad menu. Under the circumstances I think it is not appropriate to try to enforce an upgrade. From the 'trad' Debian Menu System: * The icons should be in xpm format. ... This doesn't say what non-xpm icon formats are supported Yes, it clearly does. The icons should be in xpm format. I.e. no non-xpm formats are supported. The set of supported non-xpm formats is empty. and in practice, the icon path also has to be specified completely; one can't provide more than two (fixed) icon resolutions either. This is not, however, a disbenefit of the trad system. It does reduce the capability of the system as a whole, and impose more constraints on the providers of menu entries. But the other side of that is that it is easier to consume menu entries. It's a tradeoff. Enforcing the use of the antique XPM format I don't think there is anything wrong with the xpm format for small fixed-size icons. Antique is here a pejorative word for well supported by a range of mature and reliable software. in a limited resolutions set is one of the pains of the 'trad' menu system IMHO. The limited set of resolutions is another tradeoff that makes it easier for a wm to consume menu entries. In practice, in order to add an xpm icon to one of my packages [0] which already shipped a .desktop file, an SVG icon and built various sizes' pngs at build-time using rsvg-convert [1], I had to add an imagemagick build-dependency and convert it out of the 32^2 png icon as I didn't find a software to convert the svg directly to xpm. The alternative would be to force menu entry consumers to add a similar dependency. It is IMO better to have a build-dependency than an install-time dependency. If you think imagemagick is too heavyweight, perhaps you would prefer pbmplus. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21317.11576.830437.290...@chiark.greenend.org.uk
Bug#741573: Two menu systems
Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit : You have missed my key point about differences of goals between the two menu systems. The trad menu explicitly has the goal of providing a menu item for every invokable thing; whereas the desktop menu maintainers want it to provide only entries for a much smaller subset of programs. This means that we need two systems. I don't think I missed the point; I was bringing a orthogonal one. I understand you think the 'trad' menu is a useful metadata collection on top of $PATH for 'every invokable thing'; I happen to disagree. Enforcing the use of the antique XPM format I don't think there is anything wrong with the xpm format for small fixed-size icons. Antique is here a pejorative word for well supported by a range of mature and reliable software. For the record, I intended antique to litterally mean antique: Old, (...) out of date. [0]. You are putting words in my mouth by assuming I meant it in a pejorative way. That said, while old is factual, out of date is arguably subjective. I think I can agree with there being nothing wrong with the xpm format for small fixed-size icons, but I don't think small fixed-size icons is the experience we should aim to offer in the future: screens and resolutions are still getting bigger and a 32^2 icons will look smaller and smaller (or uglier and uglier) over time. We do have more modern formats to use right now; we're not discussing adopting a brand new image format, but PNG or SVG! Cheers, OdyX [0] https://en.wiktionary.org/wiki/antique signature.asc Description: This is a digitally signed message part.
Bug#741573: Two menu systems
2014-04-09 15:13 GMT+02:00 Didier 'OdyX' Raboud o...@debian.org: Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit : You have missed my key point about differences of goals between the two menu systems. The trad menu explicitly has the goal of providing a menu item for every invokable thing; whereas the desktop menu maintainers want it to provide only entries for a much smaller subset of programs. This means that we need two systems. I don't think I missed the point; I was bringing a orthogonal one. I understand you think the 'trad' menu is a useful metadata collection on top of $PATH for 'every invokable thing'; I happen to disagree. Regarding metadata, this is something other sources (e.g. DEP-11) can provide in a much better and less redundant way. What would be interesting to know is: Why would I want to launch non-GUI applications from a menu? Usually people working with these launch them from a Terminal. Can you provide a usecase for that, other than it has always been this way? Enforcing the use of the antique XPM format I don't think there is anything wrong with the xpm format for small fixed-size icons. Antique is here a pejorative word for well supported by a range of mature and reliable software. For the record, I intended antique to litterally mean antique: Old, (...) out of date. [0]. You are putting words in my mouth by assuming I meant it in a pejorative way. That said, while old is factual, out of date is arguably subjective. I think I can agree with there being nothing wrong with the xpm format for small fixed-size icons, but I don't think small fixed-size icons is the experience we should aim to offer in the future: screens and resolutions are still getting bigger and a 32^2 icons will look smaller and smaller (or uglier and uglier) over time. We do have more modern formats to use right now; we're not discussing adopting a brand new image format, but PNG or SVG! Also think about HIDPI-screens in particular, where these small icons don't make sense at all (in fact, they are so small that you often can't even tell what they display). Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKNHny_xCV2h_MvKjEETaSfZ0=v1jrqv8j7e1zyi0mnq8et...@mail.gmail.com
Bug#741573: Two menu systems
Didier 'OdyX' Raboud writes (Bug#741573: Two menu systems): Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit : This means that we need two systems. I don't think I missed the point; I was bringing a orthogonal one. I understand you think the 'trad' menu is a useful metadata collection on top of $PATH for 'every invokable thing'; I happen to disagree. Right. I understand that some people don't think the comprehensive menu is useful. However, there are a lot of things in Debian that some people think aren't useful. The usual principle is that if someone thinks something useful and wants to do the work to provide it, they should be able to do so. That applies, obviously, to individual packages. But it applies to a lot of other cross-package things too: examples include manpages, cross compiling, hardening build flags, and indeed the desktop-style menus. I'm sure people can think of others. Our general approach is that it is a bug if a package fails to provide one of these - but that there is no reason not to upload or upgrade (or migrate to testing) a package for such a bug. Instead, the workflow is this: the maintainer can choose to work on the bug if they wish; if they don't, then someone who is interested in the feature can do the work and submit the result for inclusion in the package. We do have more modern formats to use right now; we're not discussing adopting a brand new image format, but PNG or SVG! As I have explained, there are tradeoffs here. To support a more sophisticated format, all the menu consumers need to be updated. But the real question is: who should be making this decision ? We need two menu systems because of disagreements about the content of the menus. I think that decisions about the technological future of the trad menu should be made by the people who are working on, and continue to promote, the comprehensive menu. I don't think there is anything wrong with the xpm format for small fixed-size icons. Antique is here a pejorative word for well supported by a range of mature and reliable software. For the record, I intended antique to litterally mean antique: Old, (...) out of date. [0]. You are putting words in my mouth by assuming I meant it in a pejorative way. Are you saying you _didn't_ mean it pejoratively ? I'm sorry, but I find that implausible. Particularly as you now clarify that you mean out of date which is also pejorative. If you didn't mean it pejoratively, I think you need to seriously reconsider your communication style, because your comment that xpm was antique looked critical to me. I can't see why you would use that word if you intended a neutral meaning. And indeed if the meaning was neutral, the word performs no useful function in your sentence, since the sentence is arguing against the use of xpm. Perhaps we are just disagreeing about the meaning of the word pejorative. To my mind a phrase describing software is pejorative if it unjustifiably combines a factual meaning (e.g. has been around a long time) with a critical implication (e.g. ... and this a bad thing). So, entertainingly, the word pejorative is itself pejorative. By describing your statement as pejorative I was implicitly criticising it, just as by describing xpm as antique you were criticising it. Let me put my criticism of your use of antique another way: your imply that having been around for a long time is a bad thing. However, I disagree. There are significant advantages to use of a longstanding file format. These advantages are more important in the widely-consumed trad menu than they would be in the less-widely-consumed but more sophisticated desktop menu. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21317.21132.22823.659...@chiark.greenend.org.uk
Bug#741573: On menu systems. [and 1 more messages]
Matthias Klumpp writes (Bug#741573: Two menu systems): Regarding metadata, this is something other sources (e.g. DEP-11) can provide in a much better and less redundant way. What would be interesting to know is: Why would I want to launch non-GUI applications from a menu? Usually people working with these launch them from a Terminal. Can you provide a usecase for that, other than it has always been this way? Matthew Vernon has already answered this question earlier in this thread: Matthew Vernon writes (Bug#741573: On menu systems.): I'm rather non-plussed by the proposal to devalue the Debian Menu system. I use fvwm, and while for frequently-used apps I don't use the menu (instead launching them from particular keys), the Debian menu is how I both launch apps I use less frequently, and explore what I've got installed. Its comprehensive coverage means that if I'm not quite sure what application I want, I can have a bit of a browse and try things out. Any proposal that reduces the coverage of the Debian Menu seems a bad idea for me... Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21317.21330.684480.879...@chiark.greenend.org.uk
Bug#741573: Two menu systems
Matthias Klumpp writes (Bug#741573: Two menu systems): Also think about HIDPI-screens in particular, where these small icons don't make sense at all (in fact, they are so small that you often can't even tell what they display). In situations like this, presumably the icons would need to be scaled. Whether the menu consumer (window manager) supports doing this is a quality of implementation issue for that menu consumer. If you find that a menu consumer doesn't support that, then I'm sure patches would be welcome. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21317.21364.82687.450...@chiark.greenend.org.uk
Bug#741573: Two menu systems
On Wednesday 09 April 2014 15:04:36 Ian Jackson wrote: Matthias Klumpp writes (Bug#741573: Two menu systems): Also think about HIDPI-screens in particular, where these small icons don't make sense at all (in fact, they are so small that you often can't even tell what they display). In situations like this, presumably the icons would need to be scaled. Whether the menu consumer (window manager) supports doing this is a quality of implementation issue for that menu consumer. And why not the opposite? Require bigger sizes and let the menu consumer downscale it? -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#741573: Two menu systems
Didier 'OdyX' Raboud writes (Bug#741573: Two menu systems): Le mercredi, 9 avril 2014, 15.00:44 Ian Jackson a écrit : Right. I understand that some people don't think the comprehensive menu is useful. However, there are a lot of things in Debian that some people think aren't useful. The usual principle is that if someone thinks something useful and wants to do the work to provide it, they should be able to do so. I think this is allowed by the patch pointed by Charles, which adds the following paragraph to the policy: ... As I read it, the complete patch is essentially the addition of a 'desktop' menu 'should' and a s/should/can/g for the 'trad' menu. That patch got its three seconds within the usual Policy process but got (fully) reverted by Bill. It is the demotion of the traditional menu from should to can which is controversial. For the reasons I have already explained, I do not agree with that. There are significant advantages to use of a longstanding file format. These advantages are more important in the widely-consumed trad menu than they would be in the less-widely-consumed but more sophisticated desktop menu. Your assertions about how widely the two menu systems are consumed seem quite bold to me and are at least not backed by Cyril numbers in 741573#35 [0]. By widely consumed I meant that a wide range of different window managers are capable of displaying the traditional menu. But it seems that you interpreted my comment as referring to the use of the trad menu by end users, and I want to respond to that. Of course we don't know how often end users actually click on the trad menu and use it to find and launch programs. So I won't assert that it's widely used. Equally, assertions that it's not used by end users are unjustified. We don't know how widely it's used. We do have testimonial evidence from individual people saying they find it useful, and we have the evidence from the people working on providing the trad menu that they think it's a good thing to keep on using. For me, that is enough to say that we should continue to allow those people who care about it to work on it. Of course Cyril's message #35 that you refer to doesn't talk about the consumption of the trad menu at all. It talks only about the _supply_ of menu entries. Some maintainers want to declare the trad menu obsolete and abolish it, and have been reluctant to include trad menu entries or have removed them, contrary to policy and indeed thus sabotaging the work of the trad menu maintainers. It is gratifying to see that this doesn't seem to be widespread, looking at Cyril's statistics. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21317.51979.114443.457...@chiark.greenend.org.uk
Bug#741573: Two menu systems
Sam Hartman writes (Bug#741573: Two menu systems): So, I'd like to request the TC to first consider whether a consensus was reached in the process and if so whether there's a compelling reason not to respect that consensus. If no consensus was reached or the TC finds it has a compelling interest not to respect that consensus, then focusing on the technical details of the policy seems reasonable. In my opinion, not respecting the project as a whole enough to make a determination about consensus does significant harm. This is hardly the first time that a matter has come to the TC after a dispute has escalated to acts (on one or both sides) whose legitimacy is disputed. I doubt it will be the last. Our approach has always been to look at the underlying dispute and try to resolve it. So, no. The TC will not make decisions about the content of policy on the basis of an adjudications about the policy process. We will rule on the underlying question(s), on the merits. (In my view, the menu question should have been referred to the TC much sooner.) The legitimacy of the actions of the policy maintainers is a matter for the policy team as a whole, and in extremis for the DPL (given that the policy team are DPL delegates). However I would strongly encourage everyone not to dwell on the alleged wrongs of the disputants. Such discussions are unpleasant and almost always unproductive. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21317.52659.998591.791...@chiark.greenend.org.uk
