jannis at xfce.org
Fri Sep 11 02:27:47 CEST 2009
On Thu, 10 Sep 2009 16:35:35 -0700
Drew Leske <dleske at uvic.ca> wrote:
> Hello Jannis, thanks for the response.
> > > (1) Is being a lightweight desktop environment still a goal?
> > Yes, I'd say so. Perhaps not ultra-lightweight but in the
> > foreseeable future the thing we call Xfce will remain a small
> > number of components with a realistic set of dependencies and I
> > don't think there's any reason to be concerned about bloat in Xfce.
> That's a relief. Seriously, that's all I wanted to hear. :)
> > Actually, I'd go as far as to say that 4.6 didn't introduce any
> > additional bloat compared to 4.4 except maybe for GStreamer.
> If I hadn't tossed off the original e-mail in a bit of a rush I would
> have made note of this. I haven't actually felt any bloat in the
> upgrade. I was more concerned about some of the commentary I had seen
> which almost seemed to indicate people were more interested in a
> feature-rich environment.
Don't listen to all those... people. ;)
Developing a desktop environment is a bit of a tightrope walk. Some
people are very happy with just a panel and a desktop menu (like those
Fluxboxers). Others prefer to have a lot of hardware and
online services features directly integrated into the desktop
environment. And then there are people who still think that the UNIX
way of using different tools for different things is a good idea.
I think it's something inbetween that we are aiming for. We provide an
environment for basic (and sometimes also sophisticated) access to
applications, windows and files via relatively well-done user
interfaces and a tad bit more configuration options than others.
If you need more, then you have to rely on extra tools which are, if at
all, probably not as tighly integrated into Xfce as they are in GNOME
or KDE. Personally, I'm fine with that. But I can see where the world
is heading and apparently tight frontend integration with the
flexibility being hidden under the hood (like with D-Bus) is very
So, I think of Xfce as a more traditional environment because we
clearly don't have the manpower to follow most of todays trends. For
instance, I kinda doubt that we'll in the near future jump on that
"revolutionize the desktop" train GNOME is riding on with things like
gnome-shell, zeitgeist, wizbit and others.
We're more likely to improve our set of applications and libraries for
a better user experience, leaving the applications for *real* tasks
(everything beyond launching/managing applications, windows and files)
up to others.
But still... everything is possible, and if someone has a good idea
things might change. I guess this is where I see us right now.
> > > (2) For those using custom menus, have you found a reasonable
> > > solution?
> > For 4.6 we have adopted the freedesktop.org menu specification which
> > ensures compatibility with most desktop applications available
> > today.
> > I agree that custom menus are now more complicated to maintain.
> > Pleasing all participants on freedesktop.org involves a certain
> > level of complexity and compromises.
> > There are menu editors out there (like Alacarte) which do a decent
> > job at making it easier to edit menus. The bad news is that 4.6
> > doesn't support the bits in the specification dealing with menu
> > editing. For that you'll need to wait for 4.8 (scheduled for next
> > April) or possible development releases between 4.6 and 4.8.
> For me I occasionally would update menu.xml directly, but taskmenu.xml
> and hostmenu.xml were generated by scriptage and data from other
> sources. It was super-simple.
You can still auto-generate custom menus from a simpler representation.
It's just not as easy as it was before. The things that need to be
1) a .menu XML file
2) one .directory file per root and sub menu
3) one .desktop file for each menu item
Neither of these are really complicated. The .menu file just defines
the hierarchy of menus, where to look for .directory and .desktop
files and which categories or items to include in which menu.
The .directory files basically provide a display title fore each menu.
The .desktop files define name, tooltip, categories and a shell command
for each menu item.
I know you just wrote you hardly have to the time to read up on the
specs, but in case you still want to, here are the menu and desktop
The first defines how .menu files are written. The second explains the
format of .directory and .desktop files in a bit more detail.
> > (I don't feel comfortable myself to tell you this because I am the
> > one responsible for the menu library and all that... I certainly
> > made life more complicated for a lot of people.)
> Given the interoperability with established tools that will be
> available in 4.8, you may have made things less complicated for more
> people, if indeed much of the XFCE user base customises their menus.
> I could easily be in the minority here and I can respect that, and
> I'll just have to adjust one way or another.
Yes, I think the situation in 4.8 will be a notable improvement over
what we had in 4.4. But with a little more time and effort we could've
had the same in 4.6 already.
> However, in the recent archives for this list I read one question
> where somebody asked, "would it be possible to have the option to use
> the old-style XML menus" and that was dismissed summarily. Do you
> think it's doable? If the ramp-up wasn't huge, I might look into
> contributing a patch for this. If it allowed both menuing systems,
> that would, at least to me, seem ideal.
No, that's unlikely to happen. But if someone thinks it's worth it, he
can always write a separate menu plugin for supporting the old format.
That of course doesn't bring the old format back in the desktop menu
but it's something at least.
We simply don't have the manpower to maintain the same thing twice. And
it doesn't make much sense either.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: not available
More information about the Xfce