Re: Is menu orphaned? (Was: Debian Menu transition status)
On Sun, 9 Dec 2007, Bill Allombert wrote: On Wed, Dec 05, 2007 at 11:10:29AM +0100, Andreas Tille wrote: On Wed, 5 Dec 2007, Bill Allombert wrote: Actually this is not true: You can just add !C menu-1 to the start of each files (or each menu-1 files if you prefer) before concatening them. Menu change format each time it see a !C request, even inside a file. OK, this hint (is it documented somewhere?) would probably help Not yet, though you are welcome to provide a patch for the menu manual. Before I think about a patch I wonder whether this is really working for any window manager. I changed cdd-menu accordingly which you can see at http://svn.debian.org/wsvn/cdd/cdd/trunk/cdd/share/menu/cdd-menu?op=diffrev=0sc=0 If you call /usr/share/menu/cdd-menu as user and have med-bio installed, you get an output like this: !C menu-1 ?package(arb):needs=X11 section=Med/Biology \ title=Arb icon=/usr/share/arb/arb.xpm command=/usr/bin/arb !C menu-1 ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/bl2seq needs=X11 \ section=Med/Biology/Blast2 title=bl2seq hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/blast2 needs=X11 \ section=Med/Biology/Blast2 title=blast2 hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/blastall needs=X11 \ section=Med/Biology/Blast2 title=blastall hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/blastcl3 needs=X11 \ section=Med/Biology/Blast2 title=blastcl3 hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/blastclust needs=X11 \ section=Med/Biology/Blast2 title=blastclust hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/blastpgp needs=X11 \ section=Med/Biology/Blast2 title=blastpgp hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/copymat needs=X11 \ section=Med/Biology/Blast2 title=copymat hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/fastacmd needs=X11 \ section=Med/Biology/Blast2 title=fastacmd hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/formatdb needs=X11 \ section=Med/Biology/Blast2 title=formatdb hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/impala needs=X11 \ section=Med/Biology/Blast2 title=impala hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/makemat needs=X11 \ section=Med/Biology/Blast2 title=makemat hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/megablast needs=X11 \ section=Med/Biology/Blast2 title=megablast hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/rpsblast needs=X11 \ section=Med/Biology/Blast2 title=rpsblast hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/seedtop needs=X11 \ section=Med/Biology/Blast2 title=seedtop hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm !C menu-1 ?package(boxshade): needs=text \ section=Med/Biology \ title=Boxshade hints=Pretty-printing of multiple sequence alignments \ command=sensible-pager /usr/share/doc/med-bio/boxshade.txt !C menu-1 ?package(boxshade):\ needs=text\ section=Med/Biology\ title=Boxshade\ command=/usr/bin/boxshade ... This leads to the wanted user menu in Xfce4 (unchanged behaviour as before). Unfortunately fvwm has no menu and if I start sawfish I just get Unbound variable: debian-menu and no Debian menu at all. (I'm doing my tests in Xephyr -ac :2 export DISPLAY=:2 ) Is there any reason why the undocumented trick you suggested works only for one out of three tested environments or did I missed something? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is menu orphaned? (Was: Debian Menu transition status)
On Tue, Dec 11, 2007 at 05:42:27PM +0100, Andreas Tille wrote: On Sun, 9 Dec 2007, Bill Allombert wrote: Before I think about a patch I wonder whether this is really working for any window manager. I changed cdd-menu accordingly which you can see at http://svn.debian.org/wsvn/cdd/cdd/trunk/cdd/share/menu/cdd-menu?op=diffrev=0sc=0 Your check 'grep -q -c ^!C' is wrong and useless since it might catch !C in the middle of the file. It is simpler to always add !C menu-1 inconditionnally. If you call /usr/share/menu/cdd-menu as user and have med-bio installed, you get an output like this: !C menu-1 ?package(arb):needs=X11 section=Med/Biology \ title=Arb icon=/usr/share/arb/arb.xpm command=/usr/bin/arb !C menu-1 ?package(libvibrant6):command=/usr/bin/vibrate /usr/bin/bl2seq needs=X11 \ section=Med/Biology/Blast2 title=bl2seq hints=Biology icon=/usr/share/pixmaps/ncbilogo.xpm Thare are two missing '\', one at the end of the fisrt line, on at the end of the third line (unless you reformatted it). This leads to the wanted user menu in Xfce4 (unchanged behaviour as before). Unfortunately fvwm has no menu and if I start sawfish I just get You probably have fvwm and/or sawfish misconfigured. You can use 'update-menu --stdout' to see what are the menu entries from the point of view of menu, and compare the output before and after. 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: Is menu orphaned? (Was: Debian Menu transition status)
On Tue, 11 Dec 2007, Bill Allombert wrote: Your check 'grep -q -c ^!C' is wrong and useless since it might catch !C in the middle of the file. It is simpler to always add !C menu-1 inconditionnally. Right if !C menu-2 comes next there is no harm if !C menu-1 is inserted before. I'll change this. Thare are two missing '\', one at the end of the fisrt line, on at the end of the third line (unless you reformatted it). No the entries are right - I guess the reformatting is done in any of our MUAs. This leads to the wanted user menu in Xfce4 (unchanged behaviour as before). Unfortunately fvwm has no menu and if I start sawfish I just get You probably have fvwm and/or sawfish misconfigured. I removed $HOME/.fvwm before I was running update-menus. In how far can this be misconfigured in a way that with the change the menu is broken but with the old script it was right? You can use 'update-menu --stdout' to see what are the menu entries from the point of view of menu, and compare the output before and after. I'll try this. Besides these detail problems - what's your opinion about my request for a general strategy how to continus menu development? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is menu orphaned? (Was: Debian Menu transition status)
On Wed, Dec 05, 2007 at 11:10:29AM +0100, Andreas Tille wrote: On Wed, 5 Dec 2007, Bill Allombert wrote: Actually this is not true: You can just add !C menu-1 to the start of each files (or each menu-1 files if you prefer) before concatening them. Menu change format each time it see a !C request, even inside a file. OK, this hint (is it documented somewhere?) would probably help Not yet, though you are welcome to provide a patch for the menu manual. to fix cdd-common easily. But my question regarding the general menu strategy obviousely remains. My strategy is simply to let developers experiment with the menu-2 format. If at one point we decide that menu-1 is too ugly to be kept, we could deprecate it, but we are not there yet. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is menu orphaned? (Was: Debian Menu transition status)
On Tue, Dec 04, 2007 at 07:48:22AM +0100, Andreas Tille wrote: Anyway, if you have some cdd scripts that are broken by menu-2, please send them to me and I am sure we will fix them in a short time. Well, I'm sure that /usr/share/menu/cdd-menu (from cdd-common) can be fixed to cope with /usr/share/menu/amide (from amide) to create a valid menu. The problem is that I'm missing a clear strategy in which way it should be fixed. There are several possibilities. The cdd-menu scripts concatenates single menu entries to build a user menu. The concatenation only works if the input files have the same format. Actually this is not true: You can just add !C menu-1 to the start of each files (or each menu-1 files if you prefer) before concatening them. Menu change format each time it see a !C request, even inside a file. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is menu orphaned? (Was: Debian Menu transition status)
On Wed, 5 Dec 2007, Bill Allombert wrote: Actually this is not true: You can just add !C menu-1 to the start of each files (or each menu-1 files if you prefer) before concatening them. Menu change format each time it see a !C request, even inside a file. OK, this hint (is it documented somewhere?) would probably help to fix cdd-common easily. But my question regarding the general menu strategy obviousely remains. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is menu orphaned? (Was: Debian Menu transition status)
On Tue, 4 Dec 2007 07:48:22 +0100 (CET), Andreas Tille [EMAIL PROTECTED] said: On Tue, 4 Dec 2007, Bill Allombert wrote: The menu entry format is not documented in the menu policy, so this discard #447389. Well, you are right that policy should not _describe_ the menu format, but policy should definitely _mention_ that there are at least two formats and should give an _advise_ which to use. I tend to reopen the bug (depending from the outcome of this discussion). No, policy does not offer advice, or do best practices recommendations. That is generally the role of the developers reference. Since menu-1 is not deprecated, #447390 is a wishlist. If menu-1 is not deprecated then lintian should only issue an info. That seems fair. Because this make functions definitions in menu-methods much more readable. menu-2 is used in menu-methods for 8 years or so. menu entry files are much simpler. However some people do not like the fact that line break are significant. So don't you think that this fact should be written down anywhere? I can not cope with statements have no feeling about using menu-2. If we want a consistent menu system we should give maintainers clear guidelines. While I think this probably should be discussed, resolved, and a guideline created, I do not think policy is the place in which this sort of activity takes place. Policy is happy to let multiple variati9ons compete, and let darwinian selection determine the winner. Then policy will happily ratify the solution the developers have chosen. 1. I want to be menu-2 dead if menu-1 obviousely is not. 2. I want to have one single menu format if there is no strong reason to support more than one (feelings are no reasons). 3. I want dh_make to generate files of the _suggested_ format. (Your announcement sounded kind of a suggestion for menu-2 and thus I felt my bug report would be reasonable.) 4. I want lintian report (just report, not as an error) that something else than the suggested format is used. I do not think it is the role of policy, or the policy checking tool, lintian, to offer opinions; perhaps you meant the developers reference? manoj -- Not intimate with laity or monks, wandering about with no abode, and few needs - that is what I call a brahmin. 404 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]
Is menu orphaned? (Was: Debian Menu transition status)
Hi, well, waiting more than five weeks for an answer to a question that at least I would regard as urgent seems to show enough patience. The only conclulsion I could draw is that menu is not really maintained any more. I'm particularly interested in this question because if this is the case I see no need to continue supporting menu in cdd-dev / cdd-common tools. Instead we would switch to freedesktop.org exclusively which would be a shame because we would lose several window managers that do not support this format - but it makes no sense to support stuff which is not documented and requests for documentation remain unanswered. Bill, I just noticed that I forgot to CC you in my previous mail which might lead to the fact that you missed my question because you are not reading debian-devel. While this is my fault I would suggest you should watch possible responses of your announcements in the archive. Kind regards Andreas. On Sat, 20 Oct 2007, Andreas Tille wrote: On Tue, 9 Oct 2007, Bill Allombert wrote: Others changes: === -- Menu support a new format called menu-2 since 8 years. Uhmmm, this is one of the strangest sentences I read on this list this year. At which time scale you would regard eight years old as new (at least in the world of computers)? I would rather pronounce: The menu format that is currently used by nearly every package was obsolated by the menu-2 format two years ago because the information about was so perfectly hidden that nobody really noticed. I base my assumption that nobody really noticed on the fact that grep menu-2 /usr/share/menu/* revealed no result on my machine. In this format lines break are not significant, but logical lines end by a semi-comma: This is an example: !C menu-2 ?package(pari-gp): section=Applications/Science/Mathematics needs=text title=PARI/GP command=gp ; I do not have strong opinion about this format, but feel free to use it. Well, the strongest prove that you are not alone is that neither debian-policy mentions it (see #447389), nor dh-make creates menu-2 templates (see #447390) nor lintian suggests this format (see #447391). But how should we interpret the sentence below: Since even potato support menu-2, there are no upgrade or backport issue, however this might break the lintian code to parse menu file. menu-2 is also available for menu-methods, through the definition compat=menu-2. I highly recommend its use for menu-methods. So you highly recommend something you have no feelings about? What is the sense of inventing a format and not providing any information about it. Even grepping through /usr/share/doc/menu/html revealed only some notes amout menu-2 but no code example locked like above. The manual claims to describe menu format menu-2 but considering that the code uses backspace '\' which should be necessary according to the information above and given that the line !C menu-2 is mandatory as well as the final semicolon in contrast to the statement of /usr/share/doc/menu/html/ch1.html that this document describes the menu-2.0 format this is just not the case (and I should probably a file against the menu package about this). So how could you expect developers to adopt a new format if there is no information about it? Imagine a large red swirl here. I have to admit that my brain turned in a multi colored huge swirl when I finaly was pointed to this information which was hidden in the very end of a long mail that was posted to debian-devel-announce (but got archived on debian-devel strangely enough). After settling down with this I wonder whether you could easily turn a menu-1 format file into a menu-2 format file by just wrapping it i between !C menu-2 contents of old file ; or is there some other magic? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is menu orphaned? (Was: Debian Menu transition status)
On Mon, Dec 03, 2007 at 10:24:42PM +0100, Andreas Tille wrote: Hi, well, waiting more than five weeks for an answer to a question that at least I would regard as urgent seems to show enough patience. The only conclulsion I could draw is that menu is not really maintained any more. I'm particularly interested in this question because if this is the case I see no need to continue supporting menu in cdd-dev / cdd-common tools. Instead we would switch to freedesktop.org exclusively which would be a shame because we would lose several window managers that do not support this format - but it makes no sense to support stuff which is not documented and requests for documentation remain unanswered. It is not the only conclusion you could draw. Bill, I just noticed that I forgot to CC you in my previous mail which might lead to the fact that you missed my question because you are not reading debian-devel. While this is my fault I would suggest you should watch possible responses of your announcements in the archive. Indeed another conclusion you just drawn was that I never actually received your email. I am not subscribed to debian-devel, and I did not post to that list. Instead I posted to debian-devel-announce. My email ended in debian-devel for reasons I did not anticipate. I will resend it to debian-devel-announce. Generally, if you want to reach me, please email me directly. On the other hand, I am currently lacking a menu developer with a good understanding of C++, which delays the resolution of some bugs, but if you just want to help me with menu QA, you are welcome too. On Tue, 9 Oct 2007, Bill Allombert wrote: Others changes: === -- Menu support a new format called menu-2 since 8 years. Uhmmm, this is one of the strangest sentences I read on this list this year. At which time scale you would regard eight years old as new (at least in the world of computers)? I would rather pronounce: The menu format that is currently used by nearly every package was obsolated by the menu-2 format two years ago because the information about was so perfectly hidden that nobody really noticed. menu-1 format is not obsoleted. I was not the menu maintainer 8 years ago (I was not even a Debian developer). Whatever plans Joost had for the menu-2 format, I don't know. Until recently I thought the menu-2 format only applied to menu-methods, but I discovered I was wrong, so I decided to announce it. I base my assumption that nobody really noticed on the fact that grep menu-2 /usr/share/menu/* revealed no result on my machine. There must be a first time for everything. But try grep menu-2 /etc/menu-methods/* In this format lines break are not significant, but logical lines end by a semi-comma: This is an example: !C menu-2 ?package(pari-gp): section=Applications/Science/Mathematics needs=text title=PARI/GP command=gp ; I do not have strong opinion about this format, but feel free to use it. Well, the strongest prove that you are not alone is that neither debian-policy mentions it (see #447389), nor dh-make creates menu-2 templates (see #447390) nor lintian suggests this format (see #447391). But how should we interpret the sentence below: I don't see how it is relevant to debian-policy or dh-make. Since even potato support menu-2, there are no upgrade or backport issue, however this might break the lintian code to parse menu file. menu-2 is also available for menu-methods, through the definition compat=menu-2. I highly recommend its use for menu-methods. So you highly recommend something you have no feelings about? I have no feeling about using menu-2 for menu file, but I recommend it for menu-methods. What is the sense of inventing a format and not providing any information about it. Even grepping through /usr/share/doc/menu/html revealed only some notes amout menu-2 but no code example locked like above. The manual claims to describe menu format menu-2 but considering that the code uses backspace '\' which should be necessary according to the information above and given that the line !C menu-2 is mandatory as well as the final semicolon in contrast to the statement of /usr/share/doc/menu/html/ch1.html that this document describes the menu-2.0 format this is just not the case (and I should probably a file against the menu package about this). Thanks for explaining to this list all the trouble I had to get through before discovering menu-2. So how could you expect developers to adopt a new format if there is no information about it? By posting to debian-devel-announce. Imagine a large red swirl here. I have to admit that my brain turned in a multi colored huge swirl when I finaly was pointed to this information which was hidden in the very end of a long mail that was posted to debian-devel-announce (but got archived on debian-devel strangely enough). Apparently one is not allowed to
Re: Is menu orphaned? (Was: Debian Menu transition status)
On Mon, 3 Dec 2007, Bill Allombert wrote: Indeed another conclusion you just drawn was that I never actually received your email. I am not subscribed to debian-devel, and I did not post to that list. Instead I posted to debian-devel-announce. My email ended in debian-devel for reasons I did not anticipate. I will resend it to debian-devel-announce. Well, my understanding of debian-devel-announce is that it is for important announcements and debian-devel is for discussing thise announcements. That's why I suggested that somebody should read possible replies to his announcements (even if I admit that a CC in this special case would have been reasonable). Generally, if you want to reach me, please email me directly. Lesson learned. ;-) On the other hand, I am currently lacking a menu developer with a good understanding of C++, which delays the resolution of some bugs, but if you just want to help me with menu QA, you are welcome too. I had a look into menu code but realised that my poor C++ knowledge is probably not enough. The menu format that is currently used by nearly every package was obsolated by the menu-2 format two years ago because the information about was so perfectly hidden that nobody really noticed. menu-1 format is not obsoleted. Well, I admit I'm failing to find the quote - I probably imagined to have read it was obsoleted. There must be a first time for everything. But try Yes, this is right. grep menu-2 /etc/menu-methods/* My problem is that after 8 years the first menu file that is actually using it broke a script in cdd-common and I have no idea how to fix this because there is no description of this format. I don't see how it is relevant to debian-policy or dh-make. You don't want to tell me that #447389 and #447390 make no sense. I have no feeling about using menu-2 for menu file, but I recommend it for menu-methods. But why? Thanks for explaining to this list all the trouble I had to get through before discovering menu-2. ?? I don't understand this statement? So how could you expect developers to adopt a new format if there is no information about it? By posting to debian-devel-announce. After 8 years and without drawing the consequences to file the apropriate bug reports especially #447391? This sounds not very convincing. Apparently one is not allowed to post a followup to a previous debian-devel-announce post, even if it is two month old. I did not anticipated that. Well, my first posting had a delay of eleven days and both are listed at http://lists.debian.org/debian-devel/2007/10/threads.html in the very same thread. (BTW, I'm keen on the explanation why your original posting does not show up in debian-devel-announce archive but in debian-devel exclusively.) Assuming your menu-1 file has a single entry, this is sufficient. (Else you obviously need one ';' for each entry). Well, to come to a productive suggestion: If menu-2 just adds some syntax sugar that makes no real advantage - could we just drop this new and unknown format? Would this have any bad consequences (except of rewriting some menu methods)? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is menu orphaned? (Was: Debian Menu transition status)
On Mon, Dec 03, 2007 at 11:51:25PM +0100, Andreas Tille wrote: My problem is that after 8 years the first menu file that is actually using it broke a script in cdd-common and I have no idea how to fix this because there is no description of this format. I don't see how it is relevant to debian-policy or dh-make. You don't want to tell me that #447389 and #447390 make no sense. The menu entry format is not documented in the menu policy, so this discard #447389. Since menu-1 is not deprecated, #447390 is a wishlist. I have no feeling about using menu-2 for menu file, but I recommend it for menu-methods. But why? Because this make functions definitions in menu-methods much more readable. menu-2 is used in menu-methods for 8 years or so. menu entry files are much simpler. However some people do not like the fact that line break are significant. Thanks for explaining to this list all the trouble I had to get through before discovering menu-2. ?? I don't understand this statement? You explained that the documentation of menu-2 was sub-par. This is exactly the reason I took five years before learning about menu-2. I inherited this feature from the original menu author (Joost). So how could you expect developers to adopt a new format if there is no information about it? By posting to debian-devel-announce. After 8 years and without drawing the consequences to file the apropriate bug reports especially #447391? This sounds not very convincing. Why should lintian flag menu-1 as an error ? menu-1 menu file are absolutly fine as far as I am concerned. Assuming your menu-1 file has a single entry, this is sufficient. (Else you obviously need one ';' for each entry). Well, to come to a productive suggestion: If menu-2 just adds some syntax sugar that makes no real advantage - could we just drop this new and unknown format? Would this have any bad consequences (except of rewriting some menu methods)? If you want menu-2 dead, why asking dh_make to generate menu-2 file ? Why asking lintian to report menu-1 file as error ? Strange... Anyway, if you have some cdd scripts that are broken by menu-2, please send them to me and I am sure we will fix them in a short time. Actually you can even use update-menus to convert from menu-2 to menu-1. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
