Menu Editor

Christoph Wickert christoph.wickert at
Sun Jun 3 00:29:37 CEST 2012

Am Samstag, den 02.06.2012, 23:05 +0200 schrieb Raphael Groner:
> Jannis Pohlmann jannis at
> Mon May 7 14:50:01 CEST 2012
> >> On Mon, 07 May 2012 12:59:45 +0200
> >> Nick Schermer <nick at> wrote:
> >> There is also not much to discuss, because Xfce is written in C +
> >> Gtk.
> > Exactly. Anything that is ever supposed to be crucial for Xfce or be
> > included in the core of it will have to be written in C. I'd say Vala
> > is acceptable as well as it is only required at build time and is
> > compiled down to C code anyway.
> > 
> Seriously meant question: Why is Alacarte then supported as an
> application that is written in Python and mostly orientated to Gnome? It
> does not use Garcon, instead gnome-menus.

You are confusing two different questions:
     1. Should Xfce have it's own menu editor? Probably, but so far
        nobody has written it.
     2. Should Xfce be able to use alacarte if it is installed?
        Probably, it's better than nothing.

Even though the questions are loosely related, they are still two
different questions that need to be addressed individually.

> Compiling down to C code is no argument at my point of view. Python or
> Java can also be transferred to C code (for instance, there's java2cpp
> [0], don't take that hint too seriously :D ). At the end, there's
> always platform-dependend binary code... Last but not least, a
> discussion about programming languages will not lead to the goal.

Right, only coding will lead to the goal, so please don't hesitate to go

> > What is more, the availability of complete Python bindings for Xfce
> > (or the lack of such; don't recall the status right now) represents an
> > unnecessary hurdle for developers. So, yeah, just stick to C/Vala - be
> > a serious programmer!
> Okay. So far I can summarize the technical requirements for a serious
> Xfce menu editor as the following points:
> - C++ extremely preferred (sorry, OOD/OOP is state of the art)
> - Garcon as the backend for implementation of menu specification [1]
> - Gtk for GUI, nearly Gtkmm then due to object orientation

I agree on garcon but I don't think that it makes any sense to use
another language than all the other components and add another gtkmm as
another requirement.

> Recently, there was some patching going on upstream for the good old
> Alacarte. And doubtfully, there was the Fedora 17 release with a new
> Gnome3 and a broken Alacarte.

This has nothing to do with Xfce. Xfce as an upstream project has no
control over the GNOME code or version. We can only support alacarte
when installed, but we cannot know what version is installed (because of
the different distributions) and if it works or not.

If something is broken in GNOME or Fedora, it's definitely not Xfce's
problem and it's not a reason to stop supporting alacarte.

> But honestly, I don't see any serious future for Alacarte+Xfce. 

Then stop talking and start coding please!

> It seems
> that the people do like lxmed [2], the so called menu editor for
> LXDE. To me, it seems to be a schizophrenic project cause LXDE [3]
> claims to be "lightweight" (just as Xfce, hehe) but why the heck then
> lxmed is written in Java, so then the JVM, that will bring another ton
> of unrequired dependencies with it to garbage the system of the user?

Because lxmed has nothing to do with LXDE. It is not part of the project
but was written by somebody who uses LXDE, who needed a menu editor and
decided to call it lxmed.

> Maybe cause the developer likes AWT for the GUI stuff. 

Probably. And for that very reason lxmed will never become part of LXDE.
Same goes for lxadmin, which is written in python. LXDE is coded in C
and Python or Java code will not go into the project. Period.

> So why not port the lxmed code to CPP and Garcon/Gtkmm?

Just like LXDE does not include other languages but C, Xfce will not do
this either.

You are free to do what you want, you can write a menu editor in
brainfuck or whitespace, but you need to be aware of the fact that it
probably wont be accepted as part if Xfce.

Kind regards,


More information about the Xfce4-dev mailing list