[gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

Hi,

Svyatogor and me are working on a menu system (like debian ones) for gentoo.
Now we have come to the part where we have to decide whether to use python or 
bash scripts for the rule files of the window managers.

The Python scripts are 2 times as fast as a bash script and in my opinion 
would make live easier, are easier to handle. But svyatogor votes for bash 
scripts, as more people know how to write bash scripts than python scripts, 
here an example of both:

Python:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/fluxbox.py?rev=1.3&cvsroot=gentoo-src&content-type=text/plain  
 
Bash:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/fluxbox.wm?rev=1.3&cvsroot=gentoo-src&content-type=text/plain

What would you prefer?

mfg, heinrich

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Svyatogor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!
I just want to clarify what is the purpose of the rules file. It contains a 
set of functions for generating the various menu elements for a spicific 
window manager. E.g. it would contain a start_submenu function, which is 
called to begin a new sub menu.

I would like to explain my position of using bash scripts. Even though the 
rules files will be installed by the WM ebuild, it is likely that the users 
will want to change some things, which are not directly customisable through 
the menu files (though we'll do our best to cut down on such things). It is 
reasonable to expect the vast majority of users to be familiar with bash (at 
least basic stuff), while not really many users now Python. With this in mind 
I have proposed to use shell.

P.S. Heh, I also was gonna write it. Youwere quicker ;)

On Wednesday 13 August 2003 19:44, Heinrich Wendel wrote:
> Hi,
>
> Svyatogor and me are working on a menu system (like debian ones) for
> gentoo. Now we have come to the part where we have to decide whether to use
> python or bash scripts for the rule files of the window managers.
>
> The Python scripts are 2 times as fast as a bash script and in my opinion
> would make live easier, are easier to handle. But svyatogor votes for bash
> scripts, as more people know how to write bash scripts than python scripts,
> here an example of both:
>
> Python:
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/f
>luxbox.py?rev=1.3&cvsroot=gentoo-src&content-type=text/plain
>
> Bash:
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/f
>luxbox.wm?rev=1.3&cvsroot=gentoo-src&content-type=text/plain
>
> What would you prefer?
>
> mfg, heinrich
>
> --
> gentoo-dev@gentoo.org mailing list

- -- 
Let the Force be with us!
Sergey Kuleshov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/OnMnbYNN+aDJgscRAqW6AKDCZdMgxCGGqrEJgEfJA3z75yL4KgCfRIOi
4+NyYXve3gBOubo8RCWqrHU=
=SeTj
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Wed, Aug 13, 2003 at 06:44:24PM +0200, Heinrich Wendel wrote:
[... Bash or Python for a menu ...]
> What would you prefer?

A C-program, backed by ncurses.

No seriously, I would vote for Python. I agree totally with svyatogor's
opinion, but I think Python gives us more flexibility if we ever want to
extend the program.

If bash-scripts are chosen though, please make them sh-scripts. Perhaps in
the future we want to make bash non-mandatory (csh, ksh, bsh, zsh, ...) and
having as little bash-only scripts as possible is a Good Thing.

Wkr,
	Sven Vermeulen

-- 
    Save some animals, eat a vegetarian.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Spider]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

begin  quote
On Wed, 13 Aug 2003 18:44:24 +0200
Heinrich Wendel <lanius@gentoo.org> wrote:

> Hi,
> 
> Svyatogor and me are working on a menu system (like debian ones) for
> gentoo. Now we have come to the part where we have to decide whether
> to use python or bash scripts for the rule files of the window
> managers.
> 
> The Python scripts are 2 times as fast as a bash script and in my
> opinion would make live easier, are easier to handle. But svyatogor
> votes for bash scripts, as more people know how to write bash scripts
> than python scripts, here an example of both:


I wish to put my vote in for python.


//Spider


-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Adam Porich]

On Wed, 13 Aug 2003 19:56:10 +0200
Spider <spider@gentoo.org> wrote:

> begin  quote
> On Wed, 13 Aug 2003 18:44:24 +0200
> Heinrich Wendel <lanius@gentoo.org> wrote:
> 
> > Hi,
> > 
> > Svyatogor and me are working on a menu system (like debian ones) for
> > gentoo. Now we have come to the part where we have to decide whether
> > to use python or bash scripts for the rule files of the window
> > managers.
> > 
> > The Python scripts are 2 times as fast as a bash script and in my
> > opinion would make live easier, are easier to handle. But svyatogor
> > votes for bash scripts, as more people know how to write bash scripts
> > than python scripts, here an example of both:
> 
> 
> I wish to put my vote in for python.
> 
> 
> //Spider
>

I like the idea of a scripting language higher than 'sh' being included in gentoo by default. And, considering we already require python for portage, it makes sense. A language that is richer than 'sh' can make our low level scripts read a lot nicer. Even if someone is not familiar with python, a complicated script can be much easier to read in python than in 'sh'.

Our default scripts (e.g. menus, init scripts, modules and others) should be as simple as possible. If that is possible in bash ('sh?') then that makes sense but if the readability of these can be increased by a higher level language (particularly python as we already require it ... I think? ) then by all means go for it (in my opinion).

Cheers,
Adam Porich


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Gentoo Menu - Bash vs. Python Rule files

[thomas weidner]

On Wed, 13 Aug 2003 18:44:24 +0200, Heinrich Wendel wrote:

> Hi,
> 
> Svyatogor and me are working on a menu system (like debian ones) for gentoo.
> Now we have come to the part where we have to decide whether to use python or 
> bash scripts for the rule files of the window managers.
> 
> The Python scripts are 2 times as fast as a bash script and in my opinion 
> would make live easier, are easier to handle. But svyatogor votes for bash 
> scripts, as more people know how to write bash scripts than python scripts, 
> here an example of both:
> 
> Python:
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/fluxbox.py?rev=1.3&cvsroot=gentoo-src&content-type=text/plain  
>  
> Bash:
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/fluxbox.wm?rev=1.3&cvsroot=gentoo-src&content-type=text/plain
> 
> What would you prefer?

Why not implement it natively in language A (Python for instance or even
C/C++) and write bindings for language B (Bash,Perl,Scheme,...) ?



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Philippe Lafoucrière]

Definitively, I vote for python !


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Wednesday 13 August 2003 22:38, Chris Gianelloni wrote:
> On Wed, 2003-08-13 at 12:44, Heinrich Wendel wrote:
> > What would you prefer?
>
> Bash, hands down...
>
> I think it would be a bit of a pain to have to learn python just to be
> able to implement an ebuild for an application which you want to have a
> menu item.

no, you only have to learn it if you write an ebuild for a window manager, 
which want to have all items from a common gentoo menu.

>
> Where is all the work for this "Gentoo menu" being done?  I would
> definitely like to be a part of it since I am very interested in it and
> would definitely like to see this come to fruition.

http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-menu/?cvsroot=gentoo-src

and in irc between me and svyatogor ;)

mfg, Heinrich :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Wed, 2003-08-13 at 12:44, Heinrich Wendel wrote:
> What would you prefer?

Bash, hands down...

I think it would be a bit of a pain to have to learn python just to be
able to implement an ebuild for an application which you want to have a
menu item.

Where is all the work for this "Gentoo menu" being done?  I would
definitely like to be a part of it since I am very interested in it and
would definitely like to see this come to fruition.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On Wed, 2003-08-13 at 16:38, Heinrich Wendel wrote:
> > Where is all the work for this "Gentoo menu" being done?  I would
> > definitely like to be a part of it since I am very interested in it and
> > would definitely like to see this come to fruition.
> 
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-menu/?cvsroot=gentoo-src
> 
> and in irc between me and svyatogor ;)

So how exactly are you going to work with ebuilds that already create
menu entries in their various forms?  What about ebuilds where we create
them?  For example, there is make_desktop_entry in eutils.eclass that
was done by vapier and used by the games team.  I don't know if anyone
else uses it, but they probably should.  Which version of the
freedesktop spec are you using?  Are you planning on changing all of the
ebuilds which provide any form of .desktop entries?  What would an
ebuild submitter need to do to make sure their ebuild's .desktop files
meet the requirements?  Would there have to be anything added to the
ebuild to have the menus created properly, or is it done on-the-fly and
transparently?

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Wednesday 13 August 2003 23:08, Chris Gianelloni wrote:
> On Wed, 2003-08-13 at 16:38, Heinrich Wendel wrote:
> > > Where is all the work for this "Gentoo menu" being done?  I would
> > > definitely like to be a part of it since I am very interested in it and
> > > would definitely like to see this come to fruition.
> >
> > http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-menu/?cvsroot=gentoo-src
> >
> > and in irc between me and svyatogor ;)
>
> So how exactly are you going to work with ebuilds that already create
> menu entries in their various forms?  What about ebuilds where we create
> them?  For example, there is make_desktop_entry in eutils.eclass that
> was done by vapier and used by the games team.  I don't know if anyone
> else uses it, but they probably should.

They have to change to use the new menu system.

>  Which version of the freedesktop spec are you using? 

Desktop Entry Spec 0.9.4:
http://www.freedesktop.org/standards/desktop-entry-spec/0.9.4-onehtml/

Menu Spec 0.5:
http://www.freedesktop.org/standards/menu-spec/0.5-onehtml/

> Are you planning on changing all of the
> ebuilds which provide any form of .desktop entries? 
At the moment i see no other way.

> What would an
> ebuild submitter need to do to make sure their ebuild's .desktop files
> meet the requirements? 

I will create a validater.

> Would there have to be anything added to the
> ebuild to have the menus created properly, or is it done on-the-fly and
> transparently?

take a look at portage/domenu in cvs, so a ebuild would have to add one 
command: domenu foo.directory

mfg, Heinrich :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]

On Wed, 2003-08-13 at 17:16, Heinrich Wendel wrote:
> They have to change to use the new menu system.

Even though ours conforms better to the current way both KDE and Gnome
do it?

> > Are you planning on changing all of the
> > ebuilds which provide any form of .desktop entries? 
> At the moment i see no other way.

That sounds like a complete fuster-cluck and a total waste of developer
time.  This means we would have to make modifications to hundreds of
ebuilds and either create source patches for packages or manually move
and modify .desktop files from ebuilds/packages which currently provide
them.  As I see it, that is a worst-case scenario and probably the most
labor-intensive way to go about it.

> > What would an
> > ebuild submitter need to do to make sure their ebuild's .desktop files
> > meet the requirements? 
> 
> I will create a validater.

I hope you plan on having it added to repoman, because I know that many
developers are not going to care and won't bother running a stand-alone
application to validate the menu entries in an ebuild.  Many people
would consider that "non-essential" behavior of a package.

> > Would there have to be anything added to the
> > ebuild to have the menus created properly, or is it done on-the-fly and
> > transparently?
> 
> take a look at portage/domenu in cvs, so a ebuild would have to add one 
> command: domenu foo.directory

Like I said, it looks like a kludge.  Would a better way of going about
it not be to generate the menus from the already existing structures in
place?  Then no modification would need to be done to an ebuild to
ensure proper menu usage.  If, say, a new Gnome app was added and it
adds its own .desktop entry to /usr/share/applications as it should,
then update-menus should detect that application and modify the menus
accordingly, rather than the developers having to modify the intended
behavior of the package to suit our needs.  If we were providing a
near-stable tree of binary packages, I could see this happening easily,
but Gentoo is too much of a moving target and quite frankly, I don't
know many developers that want to be spending a large amount of time
patching up ebuilds to make sure that they install their .desktop files
into /usr/share/menu/applications or wherever we decide they should be. 
Maybe I am just not understanding exactly hwo this is going to work
out.  Perhaps you could shed some light?

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Peter Ruskin]

Can you reassure me that this stuff is going to be optional?

I run KDE and I have no use for another menu system.  This seems to me 
to be a bad waste of developer resources.

Peter
-- 
======================================================================
Gentoo:	Portage 2.0.48-r5 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1)
kernel-2.4.22_pre2-gss i686 AMD Athlon(tm) XP 1600+
======================================================================


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Fred Van Andel]

Heinrich Wendel <lanius@gentoo.org> wrote:
(08/13/2003 09:44)

>Hi,
>
>Svyatogor and me are working on a menu system (like debian ones) for gentoo.

<snip>

>Python:
>http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/fluxbox.py?rev=1.3&cvsroot=gentoo-src&content-type=text/plain  
> 
>Bash:
>http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/fluxbox.wm?rev=1.3&cvsroot=gentoo-src&content-type=text/plain

So how do I use this in an ebuild.

Do I have to write customized versions of start_menu() etc for each ebuild or do I call the start_menu() etc functions from within src_install() or will they be called automatically using on some defined variables as parameters?

Fred Van Andel
fava@gentoo.org
GPG KeyID: 76526AD599455482  
GPG fingerprint: 64E4 4BAB 9C99 D565 3E3C F5D0 7652 6AD5 9945 5482


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Wednesday 13 August 2003 23:55, Peter Ruskin wrote:
> Can you reassure me that this stuff is going to be optional?
>
> I run KDE and I have no use for another menu system.  This seems to me
> to be a bad waste of developer resources.

If it is a waste of developer resources, tell me why there is at least one 
thread every month about such a system in forums, and why every distro 
(meaning debian, suse, mandrake, redhat ...) has such a system?

>
> Peter
mfg, Heinrich :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Fred Van Andel]

Peter Ruskin <aoyu93@dsl.pipex.com> wrote:
(08/13/2003 14:55)

>Can you reassure me that this stuff is going to be optional?
>
>I run KDE and I have no use for another menu system.  This seems to me 
>to be a bad waste of developer resources.
>
I think you misunderstand.

This is not a new menu, its a way to automatically add entries to your existing menu, regardless of what desktop you use.  So it doesnt matter if you use KDE or Gnome or fluxbox the menu entries will appear as soon as you install a new package.

Unless of course I compleatly misunderstood.

Fred Van Andel
fava@gentoo.org
GPG KeyID: 76526AD599455482  
GPG fingerprint: 64E4 4BAB 9C99 D565 3E3C F5D0 7652 6AD5 9945 5482


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Thursday 14 August 2003 00:14, Fred Van Andel wrote:
> Heinrich Wendel <lanius@gentoo.org> wrote:
> (08/13/2003 09:44)
>
> >Hi,
> >
> >Svyatogor and me are working on a menu system (like debian ones) for
> > gentoo.
>
> <snip>
>
> >Python:
> >http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/
> >fluxbox.py?rev=1.3&cvsroot=gentoo-src&content-type=text/plain
> >
> >Bash:
> >http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/gentoo-menu/examples/
> >fluxbox.wm?rev=1.3&cvsroot=gentoo-src&content-type=text/plain
>
> So how do I use this in an ebuild.
>
> Do I have to write customized versions of start_menu() etc for each ebuild
> or do I call the start_menu() etc functions from within src_install() or
> will they be called automatically using on some defined variables as
> parameters?

If you simply want to add a new entry you need to have a .desktop file and 
then you do "domenu foo.desktop". If you want to add a new windowmanager, you 
have to write a file like the example and add it to a directory, every file 
in this directory will be parsed and a menu will be created based on the 
rules in them.

>
> Fred Van Andel
> fava@gentoo.org
> GPG KeyID: 76526AD599455482
> GPG fingerprint: 64E4 4BAB 9C99 D565 3E3C F5D0 7652 6AD5 9945 5482
>
>
> --
> gentoo-dev@gentoo.org mailing list
mfg, Heinrich :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

begin  quote
On Wed, 13 Aug 2003 15:14:04 -0700
Fred Van Andel <fava@gentoo.org> wrote:


> So how do I use this in an ebuild.
> 
> Do I have to write customized versions of start_menu() etc for each
> ebuild or do I call the start_menu() etc functions from within
> src_install() or will they be called automatically using on some
> defined variables as parameters?
> 

-as I understood it-,

 each  package that wishes to do so should provide an .desktop file
(which is freedesktop standard, and KDE and Gnome have each implemented
them) and then a rule system (written with one rule-parser for each
system. ie, one for black/open/flux - box, one for WindowMaker, one for
Waimea and so on. KDE and Gnome both have their own builtin and"just do
it" . theese rulemakers will then parse the desktop files(via a common
frontend to read the desktopfiles) and add entries to the menu at
rebuildtime.


A desktop file is basically a list (With translations) of the following
entries:

[Desktop Entry]
Name=Megalomaniac example
Exec=megalomaniac-exp --run
Icon=megalomaniac.png
Type=Application
Categories=Gentoo;Application;Development
---

With as many extra fields included as you wish. Theese all install into
a centralized place and is a standard commodity which can be parsed by
rulesets into the menu for, ex. Fluxbox ..


lanius, Svyatogor, correct me if I'm wrong or oversimplifying things
here?

//Spider

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Fred Van Andel]

Heinrich Wendel <lanius@gentoo.org> wrote:
(08/13/2003 15:48)
>If you simply want to add a new entry you need to have a .desktop file and 
>then you do "domenu foo.desktop". If you want to add a new windowmanager, you 
>have to write a file like the example and add it to a directory, every file 
>in this directory will be parsed and a menu will be created based on the 
>rules in them.

So for the average dev it doesnt matter in the slightest whether the supporting code is written in bash or python because we will never see it. 

Fred Van Andel
fava@gentoo.org
GPG KeyID: 76526AD599455482  
GPG fingerprint: 64E4 4BAB 9C99 D565 3E3C F5D0 7652 6AD5 9945 5482


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Thursday 14 August 2003 00:54, Spider wrote:
> begin  quote
> On Wed, 13 Aug 2003 15:14:04 -0700
>
> Fred Van Andel <fava@gentoo.org> wrote:
> > So how do I use this in an ebuild.
> >
> > Do I have to write customized versions of start_menu() etc for each
> > ebuild or do I call the start_menu() etc functions from within
> > src_install() or will they be called automatically using on some
> > defined variables as parameters?
>
> -as I understood it-,
>
>  each  package that wishes to do so should provide an .desktop file
> (which is freedesktop standard, and KDE and Gnome have each implemented
> them) and then a rule system (written with one rule-parser for each
> system. ie, one for black/open/flux - box, one for WindowMaker, one for
> Waimea and so on. KDE and Gnome both have their own builtin and"just do
> it" . theese rulemakers will then parse the desktop files(via a common
> frontend to read the desktopfiles) and add entries to the menu at
> rebuildtime.
>
>
> A desktop file is basically a list (With translations) of the following
> entries:
>
> [Desktop Entry]
> Name=Megalomaniac example
> Exec=megalomaniac-exp --run
> Icon=megalomaniac.png
> Type=Application
> Categories=Gentoo;Application;Development
> ---
>
> With as many extra fields included as you wish. Theese all install into
> a centralized place and is a standard commodity which can be parsed by
> rulesets into the menu for, ex. Fluxbox ..
>
>
> lanius, Svyatogor, correct me if I'm wrong or oversimplifying things
> here?
>

That how it works.

Additionally there is a .menu file (which the user can customize) describing 
how to arrange the submenus (take a look at gentoo.menu in cvs).

The only complex thing is that every ebuild that want to support it needs to 
be changed.

> //Spider
mfg, Heinrich :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Mike Frysinger]

On Wednesday 13 August 2003 17:55, Peter Ruskin wrote:
> Can you reassure me that this stuff is going to be optional?
>
> I run KDE and I have no use for another menu system.  This seems to me
> to be a bad waste of developer resources.
>
> Peter

i wouldnt call it a waste of resources ... theres a large user base that want 
these kind of features ...
although i wish it were otherwise, not everyone lives off a terminal ... some 
ppl dont even use a terminal after they install :)
i would like to put emphasis on the 'optional' part though ... personally i 
like to nuke the menu folders ;)
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Thursday 14 August 2003 01:09, Mike Frysinger wrote:
> On Wednesday 13 August 2003 17:55, Peter Ruskin wrote:
> > Can you reassure me that this stuff is going to be optional?
> >
> > I run KDE and I have no use for another menu system.  This seems to me
> > to be a bad waste of developer resources.
> >
> > Peter
>
> i wouldnt call it a waste of resources ... theres a large user base that
> want these kind of features ...
> although i wish it were otherwise, not everyone lives off a terminal ...
> some ppl dont even use a terminal after they install :)
> i would like to put emphasis on the 'optional' part though ... personally i
> like to nuke the menu folders ;)
> -mike

It's very easy to make it optional via FEATURES="-menu" (already in cvs: 
portage/domenu)

mfg, Heinrich :)

>

> --
> gentoo-dev@gentoo.org mailing list


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Wed, 2003-08-13 at 18:17, Heinrich Wendel wrote:
> If it is a waste of developer resources, tell me why there is at least one 
> thread every month about such a system in forums, and why every distro 
> (meaning debian, suse, mandrake, redhat ...) has such a system?

They are all also binary distributions and have complete control over
the content they decide to include in their systems.  They also only
have to spend developer mindshare on exactly one version of each
application per release.  This is quite a bit easier than the multitudes
of versions we have of some applications in the portage tree.  I tend to
agree that this is a waste of time that could be better spent elsewhere,
at least in its current implementation.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Thursday 14 August 2003 01:47, Chris Gianelloni wrote:
> On Wed, 2003-08-13 at 18:00, Heinrich Wendel wrote:
> > You are right, it takes a lot of work. But the problem is that we want to
> > have flexible menus, via the menu-spec. 	How should this transparent
> > parser know in which category it should put the entry? The gnome/kde
> > categories are not compatible with the categories listened in the
> > menu-spec. And how can you know that the entries in /usr/share/applnk are
> > generated by our parser or by an ebuild?
>
> First off, using a spec that is not in use but will be in use is rather
> pointless, as you are doing WAY more work than need be done.  The better
> way to go about it would be to create optional support for the new
> specifications and build to the current implementations.  I, quite
> personally, couldn't care if this is the way things are "going to be" in
> KDE/Gnome/*box/etc.  I only care how they are now.  Create some
> conditionals which check for versions and match themselves to that
> specification.  The menu structure should fairly well match what is
> being put out by the upstream maintainers as well as possible.  As for
> the "generated by parser or ebuild" that is simple enough.  The parser
> should *never* create files in the "legacy" locations, but only in the
> location where we designate the Gentoo menu system would go.  Any files
> in the legacy locations would be placed by the package/ebuild and should
> not be considered authorative for our menu system, but rather should be
> parsed to *create* our menu system.  For example, if I create an ebuild
> that copies a .desktop file to /usr/share/gnome/apps/Internet and call a
> make_gentoo_menu function at the end of my ebuild, then it should parse
> the file and add it appropriately to the Gentoo menu location.  In this
> same token, I should be able to manually create a file in
> /usr/share/applications or /usr/share/gnome/apps/Office or
> /usr/share/applnk and then run a script, say update-menu, and it should
> parse all of the legacy locations and add any new files to the Gentoo
> menu system.  Essentially, we should create a new menu system that is
> independent of the others, rather than trying to fix the others.  It
> would be fairly trivial to patch the window managers to get their
> information from the Gentoo-created menus as opposed to the intensive
> problem of "fixing" every application that even thinks of installing a
> menu item.  This is of course my opinion, but I am trying to keep this
> all on -dev so we can get some good feedback from the users, as they're
> the ones really requesting it.

How can we make a menu for KDE without writing to /usr/kde/3.1/share/applnk or 
/usr/share/applnk ???

mfg, Heinrich :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

On Wed, 2003-08-13 at 18:00, Heinrich Wendel wrote:
> You are right, it takes a lot of work. But the problem is that we want to have 
> flexible menus, via the menu-spec. 	How should this transparent parser know 
> in which category it should put the entry? The gnome/kde categories are not 
> compatible with the categories listened in the menu-spec. And how can you 
> know that the entries in /usr/share/applnk are generated by our parser or by 
> an ebuild?

First off, using a spec that is not in use but will be in use is rather
pointless, as you are doing WAY more work than need be done.  The better
way to go about it would be to create optional support for the new
specifications and build to the current implementations.  I, quite
personally, couldn't care if this is the way things are "going to be" in
KDE/Gnome/*box/etc.  I only care how they are now.  Create some
conditionals which check for versions and match themselves to that
specification.  The menu structure should fairly well match what is
being put out by the upstream maintainers as well as possible.  As for
the "generated by parser or ebuild" that is simple enough.  The parser
should *never* create files in the "legacy" locations, but only in the
location where we designate the Gentoo menu system would go.  Any files
in the legacy locations would be placed by the package/ebuild and should
not be considered authorative for our menu system, but rather should be
parsed to *create* our menu system.  For example, if I create an ebuild
that copies a .desktop file to /usr/share/gnome/apps/Internet and call a
make_gentoo_menu function at the end of my ebuild, then it should parse
the file and add it appropriately to the Gentoo menu location.  In this
same token, I should be able to manually create a file in
/usr/share/applications or /usr/share/gnome/apps/Office or
/usr/share/applnk and then run a script, say update-menu, and it should
parse all of the legacy locations and add any new files to the Gentoo
menu system.  Essentially, we should create a new menu system that is
independent of the others, rather than trying to fix the others.  It
would be fairly trivial to patch the window managers to get their
information from the Gentoo-created menus as opposed to the intensive
problem of "fixing" every application that even thinks of installing a
menu item.  This is of course my opinion, but I am trying to keep this
all on -dev so we can get some good feedback from the users, as they're
the ones really requesting it.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Peter Ruskin]

On Wednesday 13 Aug 2003 23:17, Heinrich Wendel wrote:
> On Wednesday 13 August 2003 23:55, Peter Ruskin wrote:
> > Can you reassure me that this stuff is going to be optional?
> >
> > I run KDE and I have no use for another menu system.  This seems to
> > me to be a bad waste of developer resources.
>
> If it is a waste of developer resources, tell me why there is at
> least one thread every month about such a system in forums, and why
> every distro (meaning debian, suse, mandrake, redhat ...) has such a
> system?
>
There's no good reason for following those distros.  I came here from 
Mandrake and its awful menu implementation was always the first thing I 
disabled.

Hell, it sounds like I'm flaming here - as long as I can opt out of it I 
don't really mind what you do - but from my viewpoint it ought not to 
to be too much of a drain on resources.

Peter
-- 
======================================================================
Gentoo:	Portage 2.0.48-r5 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1)
kernel-2.4.22_pre2-gss i686 AMD Athlon(tm) XP 1600+
======================================================================


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Thursday 14 August 2003 01:45, Heinrich Wendel wrote:
> On Thursday 14 August 2003 01:47, Chris Gianelloni wrote:
> > On Wed, 2003-08-13 at 18:00, Heinrich Wendel wrote:
> > > You are right, it takes a lot of work. But the problem is that we want
> > > to have flexible menus, via the menu-spec. 	How should this transparent
> > > parser know in which category it should put the entry? The gnome/kde
> > > categories are not compatible with the categories listened in the
> > > menu-spec. And how can you know that the entries in /usr/share/applnk
> > > are generated by our parser or by an ebuild?
> >
> > First off, using a spec that is not in use but will be in use is rather
> > pointless, as you are doing WAY more work than need be done.  The better
> > way to go about it would be to create optional support for the new
> > specifications and build to the current implementations.  I, quite
> > personally, couldn't care if this is the way things are "going to be" in
> > KDE/Gnome/*box/etc.  I only care how they are now.  Create some
> > conditionals which check for versions and match themselves to that
> > specification.  The menu structure should fairly well match what is
> > being put out by the upstream maintainers as well as possible.  As for
> > the "generated by parser or ebuild" that is simple enough.  The parser
> > should *never* create files in the "legacy" locations, but only in the
> > location where we designate the Gentoo menu system would go.  Any files
> > in the legacy locations would be placed by the package/ebuild and should
> > not be considered authorative for our menu system, but rather should be
> > parsed to *create* our menu system.  For example, if I create an ebuild
> > that copies a .desktop file to /usr/share/gnome/apps/Internet and call a
> > make_gentoo_menu function at the end of my ebuild, then it should parse
> > the file and add it appropriately to the Gentoo menu location.  In this
> > same token, I should be able to manually create a file in
> > /usr/share/applications or /usr/share/gnome/apps/Office or
> > /usr/share/applnk and then run a script, say update-menu, and it should
> > parse all of the legacy locations and add any new files to the Gentoo
> > menu system.  Essentially, we should create a new menu system that is
> > independent of the others, rather than trying to fix the others.  It
> > would be fairly trivial to patch the window managers to get their
> > information from the Gentoo-created menus as opposed to the intensive
> > problem of "fixing" every application that even thinks of installing a
> > menu item.  This is of course my opinion, but I am trying to keep this
> > all on -dev so we can get some good feedback from the users, as they're
> > the ones really requesting it.
>
> How can we make a menu for KDE without writing to /usr/kde/3.1/share/applnk
> or /usr/share/applnk ???

Sorry, now i see it, you want to patch KDE. Interesting idea, but I don't 
think this is the way to go, take a look at *box and others, they don't 
support .desktop at all, it would be more work than the other way I think.

>
> mfg, Heinrich :)
>
> --
> gentoo-dev@gentoo.org mailing list


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

begin  quote
On Thu, 14 Aug 2003 00:57:55 +0200
Heinrich Wendel <lanius@gentoo.org> wrote:


> >
> > lanius, Svyatogor, correct me if I'm wrong or oversimplifying things
> > here?
> 
> That how it works.
> 
> Additionally there is a .menu file (which the user can customize)
> describing how to arrange the submenus (take a look at gentoo.menu in
> cvs).
> 
> The only complex thing is that every ebuild that want to support it
> needs to be changed.
> 


Actually to those here who think this is "too complex" I would like to
point that this does 
 a: follow a specified standard
 b: provide the necessary flexibility and modularity 
 c: integrate with small changes to our ebuildtree.


consider that we don't have to provide massive fileupdates, global lists
coherent with our tree, but each capable and installed package requires
a small change that goes back and forwards with versions without
overhead for versionbumps.

//Spider


-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Heinrich Wendel]

On Thursday 14 August 2003 01:35, Chris Gianelloni wrote:
> On Wed, 2003-08-13 at 18:17, Heinrich Wendel wrote:
> > If it is a waste of developer resources, tell me why there is at least
> > one thread every month about such a system in forums, and why every
> > distro (meaning debian, suse, mandrake, redhat ...) has such a system?
>
> They are all also binary distributions and have complete control over
> the content they decide to include in their systems.  They also only
> have to spend developer mindshare on exactly one version of each
> application per release.  This is quite a bit easier than the multitudes
> of versions we have of some applications in the portage tree.  I tend to
> agree that this is a waste of time that could be better spent elsewhere,
> at least in its current implementation.

This has nothing to do with being a binary distri. You are right at the second 
point for suse,redhat,mandrake, but not for debian. I would say better do the 
work now, it will be a lot of mork work to do it later.

mfg, Heinrich :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Mike Frysinger]

On Wednesday 13 August 2003 19:48, Peter Ruskin wrote:
> Hell, it sounds like I'm flaming here - as long as I can opt out of it I
> don't really mind what you do - but from my viewpoint it ought not to
> to be too much of a drain on resources.

it's not really a drain on resources if it's created by developers who want 
the thing ... and if their reason for being here is the menu system ...
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Svyatogor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Guys!
After reading the discussion which followed after Heinrich's initial mail, I 
realised that a lot of you missunderstood the primary goal of our project. 

Goal 1: This is something everyone understood - create a common menu layout, 
which would be independent of the window manager. This point sound quite 
important for those people who use more than one WM. However, I pereceive it 
as a secondary goal.

Goal 2: This is the major one. I have to refer to the experiesnse of using the 
offtopic OS (the on made by M$). When you install some application, you 
immediately see a menu entry in your start menu, and (in most cases) you 
don't have to search on your hard for the exe and add it manually. 
Unfortunately it hasn't been the case for most of the Linux systems. If I'm 
running KDE and install kde-app - it's fine. But if I install a non 
DE-specific tool I have to find (or guess) what is the name of the executable 
and add it to the menu myself. This is called user-*unfriendly*. Especially 
for new users who are just starting to use Gentoo. 

Finally let me stress it out once again. The system is *completely* optional - 
you don't like it - don't run it.

- -- 
Let the Force be with us!
Sergey Kuleshov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O0Q4bYNN+aDJgscRAsJeAKDBlF8K8eY9eBHfb+BTe1QngPrZAQCgyLej
w2N1up59TI2GRQz2TZjV5M0=
=xerQ
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Peter Ruskin]

On Thursday 14 Aug 2003 09:11, Svyatogor wrote:
> Hello Guys!
> After reading the discussion which followed after Heinrich's initial
> mail, I realised that a lot of you missunderstood the primary goal of
> our project.
>
> Goal 1: This is something everyone understood - create a common menu
> layout, which would be independent of the window manager. This point
> sound quite important for those people who use more than one WM.
> However, I pereceive it as a secondary goal.
>
> Goal 2: This is the major one. I have to refer to the experiesnse of
> using the offtopic OS (the on made by M$). When you install some
> application, you immediately see a menu entry in your start menu, and
> (in most cases) you don't have to search on your hard for the exe and
> add it manually. Unfortunately it hasn't been the case for most of
> the Linux systems. If I'm running KDE and install kde-app - it's
> fine. But if I install a non DE-specific tool I have to find (or
> guess) what is the name of the executable and add it to the menu
> myself. This is called user-*unfriendly*. Especially for new users
> who are just starting to use Gentoo.

But easy nonetheless.  I recently emerged bcast200.  No .desktop files 
were installed, so no menu entry.  I decided it belonged in 
/usr/share/applnk/Multimedia so opened an existing .desktop file there 
in kwrite, modified and saved it as bcast.desktop.

We can't make Gentoo like Windows.  Gentoo users, however new, have to 
be able to edit configuration files or they'd never be able to install 
it in the first place.

My bad experience of Mandrake's menu implementation (copied from Debian) 
influences my reaction to your proposals.  There they decided to 
disable kmenuedit and reroute all KDE menus into their own tree.  I 
will have nothing to do with any such interference to a good, working 
menu system.
 
>
> Finally let me stress it out once again. The system is *completely*
> optional - you don't like it - don't run it.
>
Good.

Peter
-- 
======================================================================
Gentoo:	Portage 2.0.48-r5 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1)
kernel-2.4.22_pre2-gss i686 AMD Athlon(tm) XP 1600+
======================================================================


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1239 bytes --]

On Thursday 14 August 2003 00:14, Fred Van Andel wrote:
>
> So how do I use this in an ebuild.
>
> Do I have to write customized versions of start_menu() etc for each ebuild
> or do I call the start_menu() etc functions from within src_install() or
> will they be called automatically using on some defined variables as
> parameters?
>

I would like to make a suggestion. Could you people also provide a do_desktop 
command that has three parameters, the first parameter is the name of the 
application (yes in English), the second is the commandline of the 
application (that what goes into the exec field (so it can contain spaces)), 
and the third is the the icon file.

This would imply that icon files get installed in a gentoo-menu specific 
folder, so they can be overridden by windowmanager specific folders if they 
exist.

This command would not aim to be complete, but to simplify things for adding 
entries for applications that don't have full translated desktop entries yet.

In this line, maybe a do_icon function is also useful for the same reason. 
Desktop entries without icons suck ;-)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Wed, 2003-08-13 at 18:48, Heinrich Wendel wrote:
> If you simply want to add a new entry you need to have a .desktop file and 
> then you do "domenu foo.desktop". If you want to add a new windowmanager, you 
> have to write a file like the example and add it to a directory, every file 
> in this directory will be parsed and a menu will be created based on the 
> rules in them.

Great, but why should I have to change every ebuild when it should
honestly be the PARSER's job to parse the current menu structures and
make its own, rather than modifying the existing ones.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Wed, 2003-08-13 at 18:57, Heinrich Wendel wrote:
> The only complex thing is that every ebuild that want to support it needs to 
> be changed.

This is my main concern.  Editing every ebuild seems like a complete
waste of time when we're building our menu system "from scratch" and
have complete control over how it is implemented.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]

On Wed, 2003-08-13 at 19:45, Heinrich Wendel wrote:
> > the "generated by parser or ebuild" that is simple enough.  The parser
> > should *never* create files in the "legacy" locations, but only in the
> > location where we designate the Gentoo menu system would go.  Any files
> > in the legacy locations would be placed by the package/ebuild and should
> > not be considered authorative for our menu system, but rather should be
> > parsed to *create* our menu system.  For example, if I create an ebuild
> > that copies a .desktop file to /usr/share/gnome/apps/Internet and call a
> > make_gentoo_menu function at the end of my ebuild, then it should parse
> > the file and add it appropriately to the Gentoo menu location.  In this
> > same token, I should be able to manually create a file in
> > /usr/share/applications or /usr/share/gnome/apps/Office or
> > /usr/share/applnk and then run a script, say update-menu, and it should
> > parse all of the legacy locations and add any new files to the Gentoo
> > menu system.  Essentially, we should create a new menu system that is
> > independent of the others, rather than trying to fix the others.  It
> > would be fairly trivial to patch the window managers to get their
> > information from the Gentoo-created menus as opposed to the intensive
> > problem of "fixing" every application that even thinks of installing a
> > menu item.  This is of course my opinion, but I am trying to keep this
> > all on -dev so we can get some good feedback from the users, as they're
> > the ones really requesting it.
> 
> How can we make a menu for KDE without writing to /usr/kde/3.1/share/applnk or 
> /usr/share/applnk ???

You don't.  Read the part of my comment that I left in this message. 
Rather than add OUR menu system to /usr/kde/3.1/share/applnk, we should
patch KDE/Gnome/*box/etc (actually quite simple) to use
/usr/share/gentoo-menu or wherever we decide the Gentoo menu should go. 
This saves the problem of having to edit every ebuild right now to
implement this, allows for a "Gentoo Menu" support which can easily be
turned on or off via FEATURES, and gives us a single location for our
entire menu structure, rather than duplicating our parsed menus all over
the filesystem.  After all, if I have Gnome, KDE, WindowMaker,
AfterStep, and Fluxbox installed, the current proposal would have to
create 5 separate menus and maintain them to keep everything accurate. 
Under my proposal, it would only have to maintain ONE and all 5 window
managers would use it.  At this point you can use ANY version of ANY
spec we wish to support, and we don't have to wait on anyone else to
support it.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Wed, 2003-08-13 at 20:10, Heinrich Wendel wrote:
> Sorry, now i see it, you want to patch KDE. Interesting idea, but I don't 
> think this is the way to go, take a look at *box and others, they don't 
> support .desktop at all, it would be more work than the other way I think.

Not if in our /usr/share/gentoo-menu (or wherever) we also have a
fluxmenu (dont' knwo what flux actually uses here... so this is an
example) file that is generated at the same time.  KDE/Gnome uses the
.directory/.desktop/.menu stuff we supply in our directory and *box use
their native supplied in the same location.  All you're really doing
here is patching the change the default location for the system menus.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Thu, 2003-08-14 at 06:02, Peter Ruskin wrote:
> My bad experience of Mandrake's menu implementation (copied from Debian) 
> influences my reaction to your proposals.  There they decided to 
> disable kmenuedit and reroute all KDE menus into their own tree.  I 
> will have nothing to do with any such interference to a good, working 
> menu system.

I actually like the idea of rerouting the DEFAULT menus to our own
tree.  However, we definitely should not block the user from modifying
the menu in any way.  The user-specific menu structure would remain the
same.  At least that's how I see it.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Toby Dickenson]

On Thursday 14 August 2003 11:56, Chris Gianelloni wrote:

> After all, if I have Gnome, KDE, WindowMaker,
> AfterStep, and Fluxbox installed, the current proposal would have to
> create 5 separate menus and maintain them to keep everything accurate.

Not quite, as I understand it..... KDE and Gnome can share one *.desktop file 
(its just a matter of environment variables to get them looking in the same 
directory) and I believe some *box are going that way too.

> Under my proposal, it would only have to maintain ONE and all 5 window
> managers would use it. 

Thats a good principal, but it doesnt explain why you want to create a _new_ 
standard rather than http://www.freedesktop.org/standards/desktop-entry-spec/ 
as used by KDE and Gnome already.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Thu, 2003-08-14 at 06:24, Paul de Vrieze wrote:
> I would like to make a suggestion. Could you people also provide a do_desktop 
> command that has three parameters, the first parameter is the name of the 
> application (yes in English), the second is the commandline of the 
> application (that what goes into the exec field (so it can contain spaces)), 
> and the third is the the icon file.

inherit eutils

make_desktop_entry pauldv.sh "Paul de Vrieze's custom shell script"
pauldv.png

> This would imply that icon files get installed in a gentoo-menu specific 
> folder, so they can be overridden by windowmanager specific folders if they 
> exist.

Or use /usr/share/applications for the icon files, since that is the
location in the freedesktop specification.  Check out some of the games
ebuilds I have made (americas-army, enemy-territory) to see these in
action.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

On Thu, 2003-08-14 at 07:10, Toby Dickenson wrote:
> Thats a good principal, but it doesnt explain why you want to create a _new_ 
> standard rather than http://www.freedesktop.org/standards/desktop-entry-spec/
> as used by KDE and Gnome already.

I never said we would not be using the freedesktop standard, nor did I
mean to imply it.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1600 bytes --]

On Thursday 14 August 2003 13:17, Chris Gianelloni wrote:
> On Thu, 2003-08-14 at 06:24, Paul de Vrieze wrote:
> > I would like to make a suggestion. Could you people also provide a
> > do_desktop command that has three parameters, the first parameter is the
> > name of the application (yes in English), the second is the commandline
> > of the application (that what goes into the exec field (so it can contain
> > spaces)), and the third is the the icon file.
>
> inherit eutils
>
> make_desktop_entry pauldv.sh "Paul de Vrieze's custom shell script"
> pauldv.png
>

That would be ok to me.

> > This would imply that icon files get installed in a gentoo-menu specific
> > folder, so they can be overridden by windowmanager specific folders if
> > they exist.
>
> Or use /usr/share/applications for the icon files, since that is the
> location in the freedesktop specification.  Check out some of the games
> ebuilds I have made (americas-army, enemy-territory) to see these in
> action.

I believe there is some specification for iconsets as used by kde and gnome. 
Kde for example provides icons for many applications, and there are also 
iconsets like the one from ximian that provide icons for most common 
applications. We probably want the ability to use those. That means that we 
don't want to overwrite those icons with whatever is specified in the ebuild. 
I don't care that much where they are put in the tree, that is an 
implementation issue.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Svyatogor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is what Debian did and many people complain about this, cause they want 
to be able to use KDE native menu system. 
Answering your question  'Why should I modify every ebuild'. Not every, but 
only the ones which provide some apps with UI. Secondly you don't *have to*. 
If you want users of your app's to edit files themselves - fair enough.

On Thursday 14 August 2003 13:56, Chris Gianelloni wrote:
> You don't.  Read the part of my comment that I left in this message.
> Rather than add OUR menu system to /usr/kde/3.1/share/applnk, we should
> patch KDE/Gnome/*box/etc (actually quite simple) to use
> /usr/share/gentoo-menu or wherever we decide the Gentoo menu should go.
> This saves the problem of having to edit every ebuild right now to
> implement this, allows for a "Gentoo Menu" support which can easily be
> turned on or off via FEATURES, and gives us a single location for our
> entire menu structure, rather than duplicating our parsed menus all over
> the filesystem.  After all, if I have Gnome, KDE, WindowMaker,
> AfterStep, and Fluxbox installed, the current proposal would have to
> create 5 separate menus and maintain them to keep everything accurate.
> Under my proposal, it would only have to maintain ONE and all 5 window
> managers would use it.  At this point you can use ANY version of ANY
> spec we wish to support, and we don't have to wait on anyone else to
> support it.

- -- 
Let the Force be with us!
Sergey Kuleshov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O3JabYNN+aDJgscRAuMpAKDDKi1s+sSiby1IOnVpk4VX6tOKsACgssPV
YgJgLHkDGxbIrgTQSijzPZ0=
=6H43
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1502 bytes --]

On Thursday 14 August 2003 11:02 am, Peter Ruskin wrote:
> We can't make Gentoo like Windows.  

I'd hope that we'd make it better, to be honest :)

I for one hate emerging an app, only to have to go hunting later to find the 
binaries that need adding to the desktop menus.  This is 2003, not 1993, and 
by now I'd have hoped that we could do better.

> My bad experience of Mandrake's menu implementation (copied from Debian)
> influences my reaction to your proposals.  There they decided to
> disable kmenuedit and reroute all KDE menus into their own tree.  I
> will have nothing to do with any such interference to a good, working
> menu system.

A creditable (sp?) menu system would install native menu entries for each 
supported WM, I'd hope.

I'd hope that any technical solution would provide a new wm-menu eclass, which 
exports a (for arguments sake) 'wm-install-menuitem' function that 
transparently installs menu entries for each of the wm's currently active.  
Yes, it would mean going back and changing lots of existing ebuilds, but it 
would be a worthy change.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Svyatogor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is common missunderstanding of Linux which I believe is the main reason, 
why Linux is mooving so slowly in Desktop World. The main power of Linux is 
the fact that it provides choice. If you're an experienced user - go on open 
vi and edit all configs manually to get most out of your system. But *don't* 
expect this from novice users. If we want Linux to become a real alternative 
on desktop systems we have to make it as easy to use as possible, and not 
tell people: "Our system is very good and advanced, but you need to have at 
least Master Degree to use it".

P.S. Please don't tell me that Gentoo is for Intermidiate to Advanced users - 
I don't believe in this.

On Thursday 14 August 2003 13:02, Peter Ruskin wrote:
> We can't make Gentoo like Windows.  Gentoo users, however new, have to
> be able to edit configuration files or they'd never be able to install
> it in the first place.

- -- 
Let the Force be with us!
Sergey Kuleshov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O3PGbYNN+aDJgscRAgefAKCoxmhf4z9eZr9UW6VM9JioCGs6gwCfXlNS
TRpm0zcUhEVtgq9+lbEx4G0=
=wfa/
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Thu, 2003-08-14 at 07:28, Svyatogor wrote:
> This is what Debian did and many people complain about this, cause they want 
> to be able to use KDE native menu system. 
> Answering your question  'Why should I modify every ebuild'. Not every, but 
> only the ones which provide some apps with UI. Secondly you don't *have to*. 
> If you want users of your app's to edit files themselves - fair enough.

FEATURES=-menu emerge kde

Better yet, the menu FEATURE should NOT be the default, but rather need
to be set by the user to enable the Gentoo menus.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Thu, 2003-08-14 at 07:22, Paul de Vrieze wrote:
> > inherit eutils
> >
> > make_desktop_entry pauldv.sh "Paul de Vrieze's custom shell script"
> > pauldv.png
> >
> 
> That would be ok to me.

Good, because it's already there... ;p

> > Or use /usr/share/applications for the icon files, since that is the
> > location in the freedesktop specification.  Check out some of the games
> > ebuilds I have made (americas-army, enemy-territory) to see these in
> > action.
> 
> I believe there is some specification for iconsets as used by kde and gnome. 
> Kde for example provides icons for many applications, and there are also 
> iconsets like the one from ximian that provide icons for most common 
> applications. We probably want the ability to use those. That means that we 
> don't want to overwrite those icons with whatever is specified in the ebuild. 
> I don't care that much where they are put in the tree, that is an 
> implementation issue.

The locations of the icon themes are independent of the location of the
default icon supplied by the package/ebuild itself.  The default
location is /usr/share/pixmaps and subdirectories.  I know in Gnome, the
icon themes are stored in /usr/share/icons and they override the default
icons in /usr/share/applications.  The way to have an icon override is
to have ti in the proper directory in the icon theme directory structure
and for it to have the same basename.

For example, there can be a /usr/share/pixmaps/pauldv.xpm which is
provided by your own ebuild.  I can create an icon theme in
/usr/share/icons called wolf31o2.  If I create a file called
pauldv.{xpm,png,svg,jpg,etc} in the applications folder of my icon theme
and select my icon theme as my local icon theme, it will ignore the
default icon in /usr/share/pixmaps and use mine instead.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Some Comments

[John]

On Thu, 14 Aug 2003, Stuart Herbert wrote:

> A creditable (sp?) menu system would install native menu entries for each 
> supported WM, I'd hope.

This would be extremely annoying as I would then have to go back and 
delete/rearrange my menu after every emerge.

I'll take care of adding my own menu entries, thankyou!

John

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Thu, 2003-08-14 at 07:34, Svyatogor wrote:
> P.S. Please don't tell me that Gentoo is for Intermidiate to Advanced users - 
> I don't believe in this.

Until we start shipping pre-installed Gentoo machines at Best Buy and
CompUSA or we have a very nice, smart installer, this will be the truth
for a time to come.  A novice user does not even know what a partition
is, let alone what size they should make it or how to create one without
destroying their system.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1224 bytes --]

On Thursday 14 August 2003 13:34, Svyatogor wrote:
> This is common missunderstanding of Linux which I believe is the main
> reason, why Linux is mooving so slowly in Desktop World. The main power of
> Linux is the fact that it provides choice. If you're an experienced user -
> go on open vi and edit all configs manually to get most out of your system.
> But *don't* expect this from novice users. If we want Linux to become a
> real alternative on desktop systems we have to make it as easy to use as
> possible, and not tell people: "Our system is very good and advanced, but
> you need to have at least Master Degree to use it".
>
> P.S. Please don't tell me that Gentoo is for Intermidiate to Advanced users
> - I don't believe in this.

Well, I have a master degree, and consider myself to be an advanced user, but 
I do like a good automated menu system. I mean, it is easy to have X 
applications available in the menu whichever windowmanager you use. Menu 
editors are for customizations, IMHO not for adding all personal applications 
when that could well have been done automatically.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1345 bytes --]

On Thursday 14 August 2003 13:37, Chris Gianelloni wrote:
> On Thu, 2003-08-14 at 07:28, Svyatogor wrote:
> > This is what Debian did and many people complain about this, cause they
> > want to be able to use KDE native menu system.
> > Answering your question  'Why should I modify every ebuild'. Not every,
> > but only the ones which provide some apps with UI. Secondly you don't
> > *have to*. If you want users of your app's to edit files themselves -
> > fair enough.
>
> FEATURES=-menu emerge kde
>
> Better yet, the menu FEATURE should NOT be the default, but rather need
> to be set by the user to enable the Gentoo menus.

I think it should also be doable to have the gentoo menu maintenance 
application also able to just do everything in the default location. But in 
any case the gentoo menu system as I understand it provides a global menu. 
Most windowmanagers also have user menu's and certainly do not provide means 
for normal users to change the global menu. As the gentoo-menu application 
provides a native menustructure for a windowmanager (only at a different 
location?) the user menu editor should continue to function as expected, only 
having the global items being managed differently.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Thu, 2003-08-14 at 07:45, John wrote:
> On Thu, 14 Aug 2003, Stuart Herbert wrote:
> 
> > A creditable (sp?) menu system would install native menu entries for each 
> > supported WM, I'd hope.
> 
> This would be extremely annoying as I would then have to go back and 
> delete/rearrange my menu after every emerge.
> 
> I'll take care of adding my own menu entries, thankyou!

Simply do not have menu in your FEATURES and you would never see this
menu system.  At least that's the idea behind it.  After all, nobody
wants to force anything on our users, but it has been a requested
feature and something I would love to see implemented.  After all, I run
a large number of machines and consistency is something I strive to
have.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Svyatogor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 14 August 2003 14:31, Stuart Herbert wrote:
> A creditable (sp?) menu system would install native menu entries for each
> supported WM, I'd hope.
>
> I'd hope that any technical solution would provide a new wm-menu eclass,
> which exports a (for arguments sake) 'wm-install-menuitem' function that
> transparently installs menu entries for each of the wm's currently active.
> Yes, it would mean going back and changing lots of existing ebuilds, but it
> would be a worthy change.

Not exactly for each wm, but a single 'universal' desktop entry, based on 
which we generate native wm menus.

- -- 
Let the Force be with us!
Sergey Kuleshov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O3ohbYNN+aDJgscRAgwTAKCUzgUFcqgiB0T2Fq1fB4mz1E7oMACeINZl
0yvKuvRNe7/RwvNOOL4UCDE=
=ki4O
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

Wow, this thread is just getting silly.  For the nay-sayers who just
want to "add my own menu entries, thank you" have you actually READ what
the proposal was?  Did you not see that the thing is optional?  Further,
did you not see that it will NOT overwrite the application's native menu
stuff?

For the developers who won't go and change their ebuilds -- are you sure
you've got the end-user's best interests at heart?  Having been part of
the distro for damned near 20 months now, "why doesn't gentoo have an
automated menu system?" is among the top 10 most frequently asked
questions.  If you won't switch them, we'll find a developer who will.

Please, stop this flame rubbish already.

-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://dev.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Menu - Some Comments

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1561 bytes --]

On Thursday 14 August 2003 1:01 pm, Svyatogor wrote:
> On Thursday 14 August 2003 14:31, Stuart Herbert wrote:
> > A creditable (sp?) menu system would install native menu entries for each
> > supported WM, I'd hope.
> >
> > I'd hope that any technical solution would provide a new wm-menu eclass,
> > which exports a (for arguments sake) 'wm-install-menuitem' function that
> > transparently installs menu entries for each of the wm's currently
> > active. Yes, it would mean going back and changing lots of existing
> > ebuilds, but it would be a worthy change.
>
> Not exactly for each wm, but a single 'universal' desktop entry, based on
> which we generate native wm menus.

The main advantage is central administration of the menu items added by 
ebuilds.  That's a powerful advantage, and one that has its place for sure.

But generating native wm menus seems to me to imply some form of overwriting 
of what's already there - which is at the heart of the objections that some 
of the previous posters in this thread have raised.  That is, if your tool 
re-generates all the menus any time *any* ebuild tries to add a new menu 
item.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]