[gentoo-dev] Status of GLEP 16

[gentoo-dev] Status of GLEP 16

[Heinrich Wendel]

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

Hi,

This GLEP exists for a long time now, still it is not accepted. I will outline
the current status:

* KDE 3.2 (x86) supports this specification
* GNOME 2.6 (~x86) support this specification
* domenu[12_] has to be included in portage to be used by the ebuilds to  
install a desktop entry
* Somebody needs to write patches for the other WM's:

We should focus on adding support to the following WM's first:

* xfce, blackblox / fluxbox / openbox / waimea / kahakai, icewm
* fvwm, windowmaker, enlightment, afterstep

The following are not so important, but support some kind of applications
menu:

* aewm / aewm++ / evilwm / windowlab / oroborus, amiwm, ctwm, flwm
* golem, larswm, pekwm, plwm, pwm, qvwm, selectwm, treewm, trwm
* vtwm, xpde

mfg, heinrich 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAk38PevY57Fted3ERAv9UAJwJ0XOLjuRG8KPJG/VR7KaiKAVDQACgrfgg
/BA+YgKQEOiFJhwumykRV04=
=nTkE
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Status of GLEP 16

[Joshua Brindle]

Does this need a vote? It seems to me to be a proposal entirely 
contained within -desktop which doesn't need outside approval 
(necessarily) and therefore if the -desktop managers and devs like the 
idea it should be proceeded. That said I think this would be a huge 
benefit to all Gentoo desktop users and fully support it (although I am 
not part of the -desktop project)

Joshua Brindle

Heinrich Wendel wrote:

> Hi,
> 
> This GLEP exists for a long time now, still it is not accepted. I will outline
> the current status:
> 
> * KDE 3.2 (x86) supports this specification
> * GNOME 2.6 (~x86) support this specification
> * domenu[12_] has to be included in portage to be used by the ebuilds to  
> install a desktop entry
> * Somebody needs to write patches for the other WM's:
> 
> We should focus on adding support to the following WM's first:
> 
> * xfce, blackblox / fluxbox / openbox / waimea / kahakai, icewm
> * fvwm, windowmaker, enlightment, afterstep
> 
> The following are not so important, but support some kind of applications
> menu:
> 
> * aewm / aewm++ / evilwm / windowlab / oroborus, amiwm, ctwm, flwm
> * golem, larswm, pekwm, plwm, pwm, qvwm, selectwm, treewm, trwm
> * vtwm, xpde
> 
> mfg, heinrich 

--
gentoo-dev@gentoo.org mailing list




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Status of GLEP 16

[Brandon Hale]

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

On Sat, 2004-05-01 at 12:42 +0200, Heinrich Wendel wrote:

> * KDE 3.2 (x86) supports this specification
> * GNOME 2.6 (~x86) support this specification
> * domenu[12_] has to be included in portage to be used by the ebuilds to  
> install a desktop entry
> * Somebody needs to write patches for the other WM's:

This is the problem for me.. I am not capable or interested in patching
a dozen or more wm's for something I'll never use. Also, from further
discussions with foser on the topic, I get the impression that the idea
is to throw the current ability to edit the menu to my taste out the
window
and go for a menu generated completely by .desktop items. I feel that
other minimalistic wm folks won't like the sound of this either, could
you clarify the plans there? Also of note, if upstream rejects your
patch, you'll end up maintaining it for life, updating as often as
upstream moves a few things in their own menu code.

So the questions are, *who* is the somebody who will patch all these
wm's, and will I have to use it?

Thanks,
Brandon Hale
Gentoo Linux

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

Re: [gentoo-dev] Status of GLEP 16

[Ciaran McCreesh]

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

On Sat, 01 May 2004 10:10:53 -0400 Brandon Hale <tseng@gentoo.org>
wrote:
| So the questions are, *who* is the somebody who will patch all these
| wm's, and will I have to use it?

I'll be happy to do fluxbox, but not until after upstream finish their
changes to the menu code (it's being rewritten as we speak). The way
things are working out, it'll be easy to add in a [Gentoo] (or
[Gnome Desktop] or whatever we're calling it( submenu with our own
handler.

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Status of GLEP 16

[Ciaran McCreesh]

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

On Sat, 1 May 2004 12:42:22 +0200 Heinrich Wendel <lanius@gentoo.org>
wrote:
| * domenu[12_] has to be included in portage to be used by the ebuilds
| to  install a desktop entry

Not all WMs have desktop stuff. FluxBox for example only has a menu.
Could the wording in the GLEP be revised to make this clearer?

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Status of GLEP 16

[Heinrich Wendel]

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

Am Saturday 01 May 2004 16:17 schrieb Ciaran McCreesh:
> On Sat, 1 May 2004 12:42:22 +0200 Heinrich Wendel <lanius@gentoo.org>
>
> wrote:
> | * domenu[12_] has to be included in portage to be used by the ebuilds
> | to  install a desktop entry
>
> Not all WMs have desktop stuff. FluxBox for example only has a menu.
> Could the wording in the GLEP be revised to make this clearer?

What do you mean with that?

mfg, heirnich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAk72SevY57Fted3ERAjkwAKCghC5aMKrWemzxq5ZijC6+UEtWjACeJZfk
H5iKpnRnZSyPnJxgiz70EmQ=
=yF7Z
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Status of GLEP 16

[Patrick Lauer]

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

On Sat, 2004-05-01 at 17:09, Heinrich Wendel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Saturday 01 May 2004 16:17 schrieb Ciaran McCreesh:
> > On Sat, 1 May 2004 12:42:22 +0200 Heinrich Wendel <lanius@gentoo.org>
> >
> > wrote:
> > | * domenu[12_] has to be included in portage to be used by the ebuilds
> > | to  install a desktop entry
> >
> > Not all WMs have desktop stuff. FluxBox for example only has a menu.
> > Could the wording in the GLEP be revised to make this clearer?
> 
> What do you mean with that?
The *box WMs (fluxbox, blackbox, etc) don't support "desktop icons" but 
only a context menu (like the K-menu in KDE, only free-floating)

hth,
Patrick

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

Re: [gentoo-dev] Status of GLEP 16

[Grant Goodyear]

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

Method wrote: [Sat May 01 2004, 06:47:14AM EDT]
> Does this need a vote? It seems to me to be a proposal entirely 
> contained within -desktop which doesn't need outside approval 
> (necessarily) and therefore if the -desktop managers and devs like the 
> idea it should be proceeded. That said I think this would be a huge 
> benefit to all Gentoo desktop users and fully support it (although I am 
> not part of the -desktop project)

When this GLEP was originally proposed we were still in working at
building a desktop team.  Now that we have one it will, indeed, be up to
the desktop leads to decide whether or not this GLEP should be approved.

That said, it should probably go through another iteration before it
gets sent up for approval, since I know there's still a lot of questions
about it.

Best,
g2boojum
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

Re: [gentoo-dev] Status of GLEP 16

[Alexander Gretencord]

On Saturday 01 May 2004 16:10, Brandon Hale wrote:
> > * domenu[12_] has to be included in portage to be used by the ebuilds to
> > install a desktop entry
> Also, from further discussions with foser on the topic, I get the impression
> that the idea is to throw the current ability to edit the menu to my taste
> out the window and go for a menu generated completely by .desktop items.

If this is really the case I'm all against the proposal. Easily generated 
menus desktop icons or whatever is great for Joe Average or else he won't 
find the apps but this MUST NOT (see RFC2119) make it impossible for me to 
edit my menus the way I want.

Also does a Desktop Entry really mean desktop or menu or both? I like my 
desktop to be clean (no icons on it at all, except those the stupid WM always 
puts back and I haven't bothered to really get rid of). There will be some 
use flags to control what the "desktop entry" can do, right?


Alex

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Status of GLEP 16

[Ciaran McCreesh]

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

On Sun, 2 May 2004 14:43:19 +0200 Alexander Gretencord <arutha@gmx.de>
wrote:
| On Saturday 01 May 2004 16:10, Brandon Hale wrote:
| > > * domenu[12_] has to be included in portage to be used by the
| > > ebuilds to install a desktop entry
| > Also, from further discussions with foser on the topic, I get the
| > impression that the idea is to throw the current ability to edit the
| > menu to my taste out the window and go for a menu generated
| > completely by .desktop items.
| 
| If this is really the case I'm all against the proposal. Easily
| generated menus desktop icons or whatever is great for Joe Average or
| else he won't find the apps but this MUST NOT (see RFC2119) make it
| impossible for me to edit my menus the way I want.

Well... The way I'm planning to implement it for fluxbox is to have a
[Gentoo Menu] (or something) submenu off the main right click menu. This
would be implemented by adding a line roughly like the following to the
default fluxbox menu (syntax may be different if fluxgen's new code
works):

[pipe] (Gentoo Menu) {gentoo-commonbox-menu-thingie.py --fluxbox}

and patching fluxbox-generate_menu to include said line by default. No
desktop icons, obviously, because fluxbox doesn't support them.

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Status of GLEP 16

[Chris Gianelloni]

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

On Sun, 2004-05-02 at 08:43, Alexander Gretencord wrote:
> On Saturday 01 May 2004 16:10, Brandon Hale wrote:
> > > * domenu[12_] has to be included in portage to be used by the ebuilds to
> > > install a desktop entry
> > Also, from further discussions with foser on the topic, I get the impression
> > that the idea is to throw the current ability to edit the menu to my taste
> > out the window and go for a menu generated completely by .desktop items.
> 
> If this is really the case I'm all against the proposal. Easily generated 
> menus desktop icons or whatever is great for Joe Average or else he won't 
> find the apps but this MUST NOT (see RFC2119) make it impossible for me to 
> edit my menus the way I want.
> 
> Also does a Desktop Entry really mean desktop or menu or both? I like my 
> desktop to be clean (no icons on it at all, except those the stupid WM always 
> puts back and I haven't bothered to really get rid of). There will be some 
> use flags to control what the "desktop entry" can do, right?

No USE flags needed.  A "desktop" entry is really a .desktop entry. 
Most people simply drop the . due to laziness.  We're talking menus
only, not "desktop" icons.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

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

Re: [gentoo-dev] Status of GLEP 16

[Alexander Gretencord]

On Sunday 02 May 2004 15:52, Chris Gianelloni wrote:
> No USE flags needed.  A "desktop" entry is really a .desktop entry.
> Most people simply drop the . due to laziness.  We're talking menus
> only, not "desktop" icons.

Well then the GLEP should be clear on that too. Without the need to read 
through [9] at freedesktop.org (which is not too terribly clear about that 
matter either, from the introduction: "... how it appears in menus, etc..." 
What bothers is the "etc" which could mean the real 'desktop' too.).

Also, will there be a submenu like Ciaran McCreesh will implement for fluxbox 
in KDE/Gnome or will the applications be added to the normal menu structure?


Alex

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Status of GLEP 16

[foser]

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

On Sun, 2004-05-02 at 17:04 +0200, Alexander Gretencord wrote:

> Also, will there be a submenu like Ciaran McCreesh will implement for fluxbox 
> in KDE/Gnome or will the applications be added to the normal menu structure?

Normal structure, that's the whole idea : to not have several layered
structures to support everything. How this will work out exactly I'm not
sure at this time. We probably don't want to show every possible item in
every situation (eg. get menu's filled with several similar text
editors), so some priority based system would be interesting.

In my opinion flubxbox (and other WM's) should adopt the menu completely
and not dump it in some submenu. The point of adapting Gentoo wide to
the specification is to get rid of such illogical constructs.

- foser

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

Re: [gentoo-dev] Status of GLEP 16

[foser]

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

On Sat, 2004-05-01 at 10:10 -0400, Brandon Hale wrote:
> On Sat, 2004-05-01 at 12:42 +0200, Heinrich Wendel wrote:
> 
> > * KDE 3.2 (x86) supports this specification
> > * GNOME 2.6 (~x86) support this specification
> > * domenu[12_] has to be included in portage to be used by the ebuilds to  
> > install a desktop entry

Note that 'domenu' should hardly ever be used nowadays : most GUI
applications already come with a standard .desktop file.

> > * Somebody needs to write patches for the other WM's:
> 
> This is the problem for me.. I am not capable or interested in patching
> a dozen or more wm's for something I'll never use.

The idea is to adapt everything to use the same menu, that's the whole
point of the GLEP (something that apparently people would like to see).
The fd menu spec gives a good opportunity to do so and is already being
adopted by several leading desktop projects, the others should not stay
behind. So you will be using it, everybody will.
The basic code to use the freedesktop menu spec can probably be injected
in a lot of projects with minimal changes, so I don't think it's such a
big thing to patch a few WMs. We probably can't cover every little
insignificant-userbase WM out there, but we should try to pach the most
important ones.
By making this a GLEP & desktop toplevel project we try to evenly divide
the workload over the different desktop herds. You should appreciate
that as DTL lead here and not be questioning it right away because you
see a lot of work ahead that has no immediate significance for your
personal user experience.

>  Also, from further
> discussions with foser on the topic, I get the impression that the idea
> is to throw the current ability to edit the menu to my taste out the
> window
> and go for a menu generated completely by .desktop items.

That is no less configurable (even more) than most of the current ways
to adapt menus and is way beyond the usual 'i edit my own menu' thing,
interesting from a sys-admin/big desktop deployment perspective as
well : sys-wide/locked/group/user profiles. Read up the spec. I don't
think you got the right picture of this.

> Also of note, if upstream rejects your
> patch, you'll end up maintaining it for life, updating as often as
> upstream moves a few things in their own menu code.

That's why the patch to the WM code should be minimal and it should
re-use as much available code as possible. But I assume most WM's will
actually be positive towards moving to the xdg spec and see it as an
overall improvement as well. I don't think these patches will get
rejected.
But in the end : yes, that's a risk we're taking here. On the other
hand, we do the patches ourselves, it's not like maintaining an outside
patch we have never had our hands on.

> So the questions are, *who* is the somebody who will patch all these
> wm's, and will I have to use it?

The different herds will patch their packages as needed, a herd that has
a significant amount of patching could probably ask the project lead for
extra resources.
Yes, you will have to use it, like everybody else. But the transitions
shouldn't be all that noticable and the situation shouldn't get worse.
What you get is a powerful, uniform & 'portable' (on the WM level) menu
system.

- foser

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

Re: [gentoo-dev] Status of GLEP 16

[Ciaran McCreesh]

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

On Mon, 03 May 2004 23:13:07 +0200 foser <foser@gentoo.org> wrote:
| > Also of note, if upstream rejects your
| > patch, you'll end up maintaining it for life, updating as often as
| > upstream moves a few things in their own menu code.
| 
| That's why the patch to the WM code should be minimal and it should
| re-use as much available code as possible. But I assume most WM's will
| actually be positive towards moving to the xdg spec and see it as an
| overall improvement as well. I don't think these patches will get
| rejected.

The Fluxbox people are basically saying they're only interested if it
doesn't introduce another major dependency. One of the ideas behind the
lightweight WMs is that they don't require everything-plus-kitchen-sink.

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Status of GLEP 16

[Olivier Crête]

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

Hi,

On Mon, 2004-05-03 at 23:27, Ciaran McCreesh wrote:
> On Mon, 03 May 2004 23:13:07 +0200 foser <foser@gentoo.org> wrote:
> | > Also of note, if upstream rejects your
> | > patch, you'll end up maintaining it for life, updating as often as
> | > upstream moves a few things in their own menu code.
> The Fluxbox people are basically saying they're only interested if it
> doesn't introduce another major dependency. One of the ideas behind the
> lightweight WMs is that they don't require everything-plus-kitchen-sink.

The people who want minimal window managers probably are not interested
in large auto-generated easy to use menus that include every apps
installed. If the upstream providers are not interested in having their
WM support the freedesktop standard so be it, they wont have nice menus.
Lets not become debian on that front. 

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

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

Re: [gentoo-dev] Status of GLEP 16

[Nick Rout]

I am a late comer to this discussion and this may have been covered
previously, but does this wheel need re-inventing?

debian have a menu system which has also been picked up by mandrake, and
i have been impressed with it on thse systems. Each package has a
wm-neutral menu file descrbing where the package should fit in to the
system, and there are system wide scripts to add those entries into each
wm's menuing system. 

coupled with  global menu USE flag this could work well as most of the
work has been done by the debian and mandrake package maintainers. IIRC
mime-types are handled too.


On Sat, 1 May 2004 15:14:54 +0100
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> On Sat, 01 May 2004 10:10:53 -0400 Brandon Hale <tseng@gentoo.org>
> wrote:
> | So the questions are, *who* is the somebody who will patch all these
> | wm's, and will I have to use it?
> 
> I'll be happy to do fluxbox, but not until after upstream finish their
> changes to the menu code (it's being rewritten as we speak). The way
> things are working out, it'll be easy to add in a [Gentoo] (or
> [Gnome Desktop] or whatever we're calling it( submenu with our own
> handler.
> 
> -- 
> Ciaran McCreesh, Gentoo XMLcracy Member G03X276
> (Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
> Mail:    ciaranm at gentoo.org
> Web:     http://dev.gentoo.org/~ciaranm
> 

-- 
Nick Rout <nick@rout.co.nz>


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Status of GLEP 16

[Duncan]

Nick Rout posted <20040505120233.2BA2.NICK@rout.co.nz>, excerpted below, 
on Wed, 05 May 2004 12:02:41 +1200:

> debian have a menu system which has also been picked up by mandrake, and
> i have been impressed with it on thse systems. Each package has a
> wm-neutral menu file descrbing where the package should fit in to the
> system, and there are system wide scripts to add those entries into each
> wm's menuing system. 
> 
> coupled with  global menu USE flag this could work well as most of the
> work has been done by the debian and mandrake package maintainers. IIRC
> mime-types are handled too.

Coming from Mandrake myself, I've wondered about this as well, but hadn't
voiced it as I didn't know if it was appropriate, being I'm a Gentoo
newbie still running Mandrake as my main distrib.

The caveat on Mandrake is that there's little newbie documentation on the
menu package, other than what's under /usr/share/doc/, and that's mostly
targeted at developers and seasoned sysadmins, not at someone just wanting
to modify their menu a bit and have it stick.  As a new Mandrake user
coming from MSWormOS, where I was a power user and hobbyist programmer, I
quickly found the KDE KMenu files and immediately grasped how to edit that
structure to my liking, since it was conceptually similar to the MSWormOS
start menu.  I was rather frustrated to find my changes wiped out when I
updated a package, however, until I discovered the menu system.  So far,
the single thing I've been MOST impressed with on Gentoo is the
documentation, and I expect it would be no different in this case, should
the menu system be adopted.   Gentoo could again show the way for other
distribs, as there's certainly an opportunity for Mandrake to improve in
this area.  Don't know about Debian.

BTW, I've seen references to the various GLEPs.  They seem similar to the
internet RFCs in some ways.  However, I've not found them in my wanderings
on the site, yet, and don't know much about them.  Anybody care to point
me to them, and to something explaining them a bit?

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Status of GLEP 16

[Duncan]

Duncan posted <pan.2004.05.06.09.34.33.955444@cox.net>, excerpted below, 
on Thu, 06 May 2004 02:34:34 -0700:

> BTW, I've seen references to the various GLEPs.  They seem similar to the
> internet RFCs in some ways.  However, I've not found them in my wanderings
> on the site, yet, and don't know much about them.  Anybody care to point
> me to them, and to something explaining them a bit?

Found it already, following a link from the GLEP26 thread to it, and then
loading the "parent", which as hoped, was an intro to GLEPs and an
index/contents listing of current GLEPs and their status.

DEFINITELY RFC-like!

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list