Please join xdg mailing list if you can.

Discussion on LXDE releases and Development. This forum is not the best way to contact the developers, please use the Development mailing list and Sourceforge to interact with them.
PCMan
Posts: 85
Joined: Mon Oct 06, 2008 9:52 am

Please join xdg mailing list if you can.

Post by PCMan »

If you don't like to be forced to use Gnome standards, please join xdg mailing list to let them hear you.

The current standard/specifications followed by most of the major UNIX desktop enviromnents, such as Gnome, KDE, XFCE, LXDE, and ROX, is called freedesktop.org. See http://www.freedesktop.org/ for detail.

Freedesktop.org is formed by a group of developers. Developers duscusses on the so called ‘xdg’ mailing list to come up with some specs which will be followed by major desktop environments. The specs developed by Freedesktop.org are not formal standards, but they are widely used in Gnome, KDE, and XFCE.

Freedesktop.org standards defines the way window managers work, they way how file types are recognized, how icons are named, the way to define the main application menu, to exchange data between applications and different desktop environments, and more.

The process to form those specs, however, is quite inefficient and problematic. All discussions are held on their xdg mailing list. If someone has a proposal, he/she then writes a draft of the spec for it, and then post it to the mailing list. Then, if you’re lucky enough, or you’re a big guy (famous Gnome or KDE developers), you’ll get attentions and some feedbacks. After lenghthy discussions, if there are no obvious objections, the draft will be added to freedesktop.org repository, and was posted on their wiki. This is roughly how the specs are formed. Nevertheless, if there is no one implement your spec, your spec soon became useless. That means, either Gnome or KDE should support your proposal, otherwise no one will use it. How can something be called ’standard’ when nobody is following it?

Later, if someone has some good ideas regarding to improving the spec, he/she can post his/her proposal in the mailing list with a patch, and if there is no objection, the patch *might* be applied to the spec. However, once the original author/maintainer of that spec doesn’t like your idea, your proposal will never be accepted. Or even worse, your messages got omitted by the original author/maintainer of existing specs, then there is no way to improve anything in existing specs. This is a real problem in freedesktop.org.

Besides, another big issue here is, most of the specs/standards are advocated by Gnome or KDE developers, and they don’t even consider the needs of other desktop environments. The so-called cross-desktop standards are actually well-implemented in Gnome and KDE only. XFCE tried hard to follow all those standards, but never get everything work flawlessly. LXDE tried to follow those specs, too, but found that many of the specs are very complicated and inefficient, which can slow down our desktops and add bloatness. Nowadays they are trying to add more things, and get modern desktops more and more complicated. It’s nearly impossible to keep lightweight if you want to follow ‘all’ the standards developed by Gnome and KDE. So that’s why we only supports the parts we need.

Recent changes in freedesktop.org, like PolicyKit and ConsoleKit, are mainly developed and implemented by Gnome-related developers. Then the KDE guys are forced to follow them. They even drop their well-designed and high performance IPC mechanism, DCOP, and adopt dbus, which is mainly advocated by Gnome developers. Some people even suggested that KDE should replace their own VFS with GIO/GVFS developed by Gnome. Some new technologies are developed by Gnome first, and then they wrote freedesktop.org specs for them. Later, those things are copied to KDE and they soon have their KDE equivalence. Unfortunately, all other desktop environments are forced to follow those standards whether they really need it or not, to keep the compatability with those two major desktop environments.

Why should we always be forced to follow all those things we don’t like or don’t even need? If we don’t follow them, we lost compatibility with many existing Gnome/GTK+ and KDE programs. In addition, they modify the specs frequently, and always break backward compatibility. So our precious time are wasted on re-implement everything in their new specs and try to fix all broken compatibility left by them. It’s enough!

Sometimes things developed by the two major DEs are quite awesome and useful. However sometimes those specs just don’t suitable for other DEs and they didn’t consider the needs of users of DEs other than Gnome and KDE.

So, every enthusiastic developers/users of lightweight desktop environments, please join their xdg mailinst list and join their discussions and let them listen to your voice. If you don’t want to be forced to use things developed by Gnome and KDE, please let them hear your voice in the mailing list. Since they are now moving gnome libs into GTK+, like it or not, all gtk+ applications will be affected. Desktop environments other than Gnome and KDE might have some special needs and goals and those Gnome standards might not suitable for us sometimes. So we need to let them hear our voice and we should be part of the decision making.

So, please, join the xdg mailing list and get involved if you can.

Subscribe to xdg mailing list at http://lists.freedesktop.org/mailman/listinfo/xdg .
bjlockie
Posts: 5
Joined: Fri Nov 13, 2009 7:27 am

Re: Please join xdg mailing list if you can.

Post by bjlockie »

Why not just get rid of freedesktop compatibility?
maces
Posts: 503
Joined: Sat Oct 25, 2008 6:04 pm
Contact:

Re: Please join xdg mailing list if you can.

Post by maces »

LXDE work together with other applications, like openbox.

maces
IgnorantGuru
Posts: 30
Joined: Sat Feb 27, 2010 7:35 pm
Contact:

Re: Please join xdg mailing list if you can.

Post by IgnorantGuru »

That's an excellent analysis PCMan - you've described the politics very well. I recently removed all KDE apps and components from my system because of the direction I see KDE4 going in. From what I've read of Gnome, they're considering similar directions. As Hazelnice said, these DEs are becoming bloated.

I'm not sure I believe in your solution, though. It's always good to make some noise, but I don't think it will have much effect in that circle. Most of those KDE devs are corporate slaves at this point, and that is the driving force. They don't really care what users want, and they're not going to be interested in keeping things light. And because of the politics they'll get their way. They're really losing quality too - not one of my KDE4 bugs has been addressed, let alone fixed. I don't see how DEs like LXDE will be able to share standards with what KDE and Gnome are becoming.

I think the real solution is for lightweight/KISS devs of all flavors to create a fork of the freedesktop standards suitable for their purposes, deliberately keeping KDE and Gnome out of the loop. This standard could be less complex, more stable, etc. As apps are developed for it, KDE and Gnome will have to accept it as an alternative standard, in the same way that KDE now accommodates GTK.

That may sound unfeasible but I think it is inevitable. As you observed, those standards are not suitable for lightweight purposes, and they're just going to get worse. I think eventually forking or redeveloping GTK, and even the linux kernel may also be necessary to avoid being pulled in the direction that KDE and Gnome (and their corporate relatives) are taking Linux. Now is the time to begin moving away from them, even where it means losing features and some compatibility. They are beginning to act like Microsoft - dictating standards and setting their platform up as a requirement.
Check out my blog for useful scripts, mods and tips... http://igurublog.wordpress.com
rtimai
Posts: 3
Joined: Mon Jul 12, 2010 1:58 am

Re: Please join xdg mailing list if you can.

Post by rtimai »

This is my first hour running LXDE! -- in Ubuntu 10.04 Lucid, which is installed as an alternative to Gnome. I am happy to say that installation (by Synaptic Package Manager) completed flawlessly, and I was able to log out and log back in running LXDE. And so far, I have not encountered any GUI bugs with any application, and every task does indeed appear to run noticably faster.

PCMan's plea to participate in the xdg mailing list is heart-felt. I hope lightweight desktops are not forced to adopt bloated configurations to remain compatible with common applications. However, I have reservations about how common users such as myself will be regarded on the mailing list. I don't believe our concern will carry much weight.

IgnorantGuru's suggestion that lightweight DTs should fork off FreeDesktop.org standards sounded like a wise alternative. However, when I checked to make sure that I understood what a fork was, I saw this comment posted by the famous Juergen Haas of About:Linux (credits below):

Definition: fork: In the open-source community, a fork is what occurs when two (or more) versions of a software package's source code are being developed in parallel which once shared a common code base, and these multiple versions of the source code have irreconcilable differences between them. This should not be confused with a development branch, which may later be folded back into the original source code base. Nor should it be confused with what happens when a new distribution of Linux or some other distribution is created, because that largely assembles pieces than can and will be used in other distributions without conflict. Forking is uncommon; in fact, it is so uncommon that individual instances loom large in hacker folklore. Notable in this class were the http://www.xemacs.org/About/XEmacsVsGNUemacs.html, the GCC/EGCS fork (later healed by a merger) and the forks among the FreeBSD, NetBSD, and OpenBSD operating systems.
.................................
Source: Jargon Dictionary / Linux Dictionary V 0.16
http://www.tldp.org/LDP/Linux-Dictionar ... index.html
Author: Binh Nguyen linuxfilesystem(at)yahoo(dot)com(dot)au
-------------------------------------------------------------------------

I wonder why this is true of development forks. Is it possible that starting a fork serves to awaken the community to the the problem, and that such divergences eventually result in a healing? I hope this will be true for the future of lightweight environments.
kevinpeter
Posts: 4
Joined: Sat Feb 05, 2011 11:04 am

Re: Please join xdg mailing list if you can.

Post by kevinpeter »

If I open a translated desktop file with LC_ALL=fr_FR.UTF-8, the
following works as expected (ipython session):

In [1]: import xdg.DesktopEntry

In [3]: e=xdg.DesktopEntry.DesktopEntry()

In [4]: e.parse('plugins/Games/Chess.desktop')

In [5]: e.getName()
Out[5]: u'\xc9checs'

In [6]: print "%s" % e.getName()
------> print("%s" % e.getName())
Échecs

Now, if I use LC_ALL=fr_FR or fr_FR.ISO-8859-1 (which should be
equivalent), the final step instead throws:

UnicodeEncodeError: 'ascii' codec can't encode character u'\xc9' in position 0: ordinal not in range(128)

It clearly fails to guess the correct charset to use.
kevinpeter
Posts: 4
Joined: Sat Feb 05, 2011 11:04 am

Re: Please join xdg mailing list if you can.

Post by kevinpeter »

Mailing Lists

If you're interested in working on specifications, the best way to get started is to join our mailing list; mail xdg-request@lists.freedesktop.org with the word "subscribe" in the subject of your email. xdg-list has archives and on-the-web subscription here.

For other mailing lists and archives, go here.

Again, because this is important: XDG is not a diplomacy project, we want to actually work on specifications rather than discussing what the specifications could contain. Whenever possible, discussion on xdg should focus on a concrete draft specification or existing code. It's best to post a draft of a document, or go ahead and code something up, rather than asking for comments on an abstract topic.
melodie
Posts: 5
Joined: Sun Jan 16, 2011 12:01 pm

Re: Please join xdg mailing list if you can.

Post by melodie »

kevinpeter wrote:Mailing Lists

If you're interested in working on specifications, the best way to get started is to join our mailing list; mail xdg-request@lists.freedesktop.org with the word "subscribe" in the subject of your email. xdg-list has archives and on-the-web subscription here.

For other mailing lists and archives, go here.

Again, because this is important: XDG is not a diplomacy project, we want to actually work on specifications rather than discussing what the specifications could contain. Whenever possible, discussion on xdg should focus on a concrete draft specification or existing code. It's best to post a draft of a document, or go ahead and code something up, rather than asking for comments on an abstract topic.
Hi,

I don't know how to code, so I don't quite fancy myself participating to that sort of mailing list. But, I would like to point to a problem I meet with in this context, it's the change of a menu organisation in a Lxpanel menu, whereas no menu editor exists actually. Here are a few posts about the subject (direct link to the start of discussion about the menu problem):
Re: PCLinuxOS Edu RC3 Testers Wanted

So I would just like to ask one question : has anyone in the XDG project have a thought about the way Openbox handles the main menu ?

What pcman says seems very right to me : specifications that would allow menus to work in any desktop environment would be a very good thing. One example I saw recently is with OOo4Kids : the rpm version contains 4 archives related to menus : each one related to a different distro. (?)
lm8
Posts: 16
Joined: Sat Feb 14, 2009 7:39 pm

Re: Please join xdg mailing list if you can.

Post by lm8 »

rtimai wrote:IgnorantGuru's suggestion that lightweight DTs should fork off FreeDesktop.org standards sounded like a wise alternative. However, when I checked to make sure that I understood what a fork was, I saw this comment posted by the famous Juergen Haas of About:Linux (credits below):

Definition: fork: In the open-source community, a fork is what occurs when two (or more) versions of a software package's source code are being developed in parallel which once shared a common code base, and these multiple versions of the source code have irreconcilable differences between them. This should not be confused with a development branch, which may later be folded back into the original source code base. Nor should it be confused with what happens when a new distribution of Linux or some other distribution is created, because that largely assembles pieces than can and will be used in other distributions without conflict. Forking is uncommon; in fact, it is so uncommon that individual instances loom large in hacker folklore.
Don't know where the person who was referenced got the idea forking is uncommon. I run across it all the time. The CoApps project is going to do all shallow forks when they convert things over to their system. MinGW has been forked and there's now a mingw32 and mingw64 project by another developer. Sylpheed was forked to make Sylpheed Claws. Gqview was forked to make geeqie. Debian forks most of the Mozilla and cdrecord tools into their only tools such as Iceweasel and wodim. The Free Software Foundation also has their own fork of Firefox. Yad is a fork of Zenity according to its web site. Graphicsmagick is a fork of Imagemagick. LibreOffice is a fork with many of the original developers from OpenOffice. Cinepaint was originally a fork of Gimp.

I don't know if I'd like to see GTK+ forked. However, I would like to see exploration of using minimal GTK+ libraries (avoiding addition of Gnome libraries when possible) and using alternative GUI libraries to GTK+. I know some of the lightweight GUIs are lacking in Internationalization support, but maybe using some of them in conjunction with a desktop could help spur further development in those areas. Some of the applications I work with regularly make use of wxwidgets, fltk and fox toolkit as alternative GUI libraries. According to the wxwidgets web site, they're working on versions of their GUI that will use X libraries or directfb and won't require GTK+ at all. I also use quite a few command line, curses based and sdl applications.

I think diverging from the FreeDesktop standard where it doesn't make sense for light resource or high performance (avoiding code bloat) machines is a good idea. I also think it's better to have a plan and know where one's headed than continually have to follow someone else's standards as they constantly change. How many changes and deprecations have been made to udev, hal, devicekit, udev-extras? If FreeDesktop comes up with useful standards, then it would be great to adopt them. However, if groups come up with continually changing standards and don't know where they're going, why not come up with a better plan that won't need constant changing? If it's truly better, maybe other groups will start adopting that plan instead.

Personally, I'd much rather run a lightweight desktop environment or window manager than the standard desktops available on Linux or FreeBSD. I want to be able to compile and build the software from scratch so I can modify it if necessary. I don't want anything that's so complicated, you need a string of packagers or tons of dependencies and settings just to get anything to build properly. If I have to go back to using mainly command line or console based (curses, slang, sdl) just to simplify the programs and get them to do an efficient job, I'd do that.

I recommend LXDE to everyone wanting a fast system as the most lightweight desktop out there for Linux. I hope it continues on that path rather than trying to follow everyone else's standards.
mywan
Posts: 1
Joined: Sun Jul 17, 2011 6:23 am

Re: Please join xdg mailing list if you can.

Post by mywan »

I am now going through live CDs of various distributions to decide which I want to develop on. It was the desktop standards via freedesktop.org, more specifically the arcane crap that made implementing my own changes on my own machine a nighmare, that finally made me give up and go back to windows for my GUI stuff. LXDE did come the closest, and was only a few steps off of what I need and expect, but it fell short to. In fact IMO freedesktop.org is single handedly responsible for trashing *nix as any real market contender for the desktop market, period! If LXDE is willing to fork off from these standards (ignore freedesktop.org) and make certain usability changes LXDE can take a huge chunk of the windows market. The real reason windows users get disgusted with Linux desktops I have never seen written down plainly anywhere, and the windows users posting about it rarely realize that the GUI is by design not even capable of what they are looking to make it do without major text editing every instance. Stuff that is not even mentioned in the ad copy for any desktop nor visible on any screenshot.

You can question my knowledge, but questioning the fact that I would not even touch a Linux desktop for any other reason than to try to fix it is out of the question. No windows user I have ever personally demonstrated nix desktop to, and mentioned what could not be done without editing miles of text, would EVER consider it for themselves. It is not the lack of apps and such, as pcworld.com claimed in "Desktop Linux: The Dream Is Dead". So here is what I see is needed, not that a few of the KDE or Gnome desktop functions is not very cool without using their desktops.

1) A new shortcut standard. (One that does not run entire untrusted scripts!)
Basically they need only execute a single command line, period. A very tiny script is all it would take so users can choose 'New Shortcut' anywhere and point it to any command line or program with switches. Perhaps some limited scripting exceptions to allow the output of resident scripts to act as plugins, like a clock, network status query, etc., so that people can script their own active task bar content or use the defaults, but that is a different issue.

2) A Main Menu with shortcuts that can be added or deleted at will.
Merely have an \.LXDE\usermenu folder (or similar) on the users home directory to hold these shortcuts. When the Main Menu is clicked is merely reads the shortcuts in that folder and cascades the folders in that folder. Now Menu management, desktop shortcuts, etc., is utterly trivial through countless different approaches.

3) A Launch Bar that any shortcut can be added to.
Merely have an \.LXDE\launchmenu folder (or similar) on the users home directory to hold these shortcuts. Now any shortcut in that folder gets displayed on the Launch Bar. It can even be a sub-folder of the Main Menu if so chosen. Adding a new app, command line, etc., to the Launch Bar mere adds a new shortcut to the folder belonging to that Launch Bar.

These 3 things (or their simple functionality) are deal makers/breakers for the majority of windows users, period. Implementation by far lacks the overhead cost of the monstrosity outlined by freedesktop.org. Since each icon slot will be indexed in an array that array index is all that is needed to recover all the data the GUI needs to execute the proper shortcut limiting what is needed to be maintained in memory. With these over 98% of the work I intend to embark upon myself is done and I become 1000% more efficient at developing the parts I want to do. There are, however, a couple more things needed for the desktop itself but which are more annoyances than deal breakers.

4) The option to stack a pair Launch Bars, as if one bar with two separate content levels.
This was mainly an annoyance for me. In order to have an application Task Bar that was separate from the Launch Bar requires me to put one on the top or sides of the screen. Very ugly when all I want is to keep my OS/desktop level interactions at the bottom and active window interactions at the top without Quick Launch icons eating all my Task Bar space.

5) Make sure that the custom Open With in the file manager can handle multiple entries to the same script/program with different CLI switches.
I think this was more an issue with Nautilus. I hate to say it but TreePad is the best Linux desktop GUI I have found, including many file manager functions.

6) Tree view in file manager.
Yes I know what you are dealing with PCManFM, I am not picking on you or your choices that were in fact well informed. Personally I would shell out and parse the return so that only the information requested by the user is loaded and shell script which only runs long enough to return the output does most of the backend work. I have made mouse driven text based (edit box) remote file managers for windows that worked this way, faking in the tree with indented |->. I would certainly not glob in the entire file system on startup and only provide the tree branches as requested.

6) Movable desktop icons.
Yeah I know, but when my desktop looks like my bedroom floor and just as mutable...

With a few hundred kilobites of source code I completely replaced all windows file associations to point to the same program, where either a command line switch or filetype determined the action or set of action options and ran only on demand. On windows I have over 200 apps, settings, etc., two clicks away from a single Quick launch bar and barely using the available space. It also doubled as drawers rather than single shortcuts in the quick launch bar, and replaced the compile string in SciTE to give me predefined compile options system wide whether in SciTE or the file manager. I also wrote a very tiny UserJS version that gave me the same unlimited contextual options in browsers, for a browser independent CloudOS type interface. When I scripted a Linux version it worked great, only there was no way to hook it into the desktop without major editing for every single hook that may need to come and go on a whim. So basically it was limited to aliasing command lines on the command line in Linux. The windows apps run under Wine were somewhat more versatile on the desktop, minus the integration (and filetype issues) except with TreePads exec function.

It's a shame that sitting on top of the best OS ever created is a monstrous resource hogging desktop dumber even than what its developers apparently think their users are. So dumb even TreePad outperforms it as a GUI. Sorry, some windows users might think it so cool seeing rubber windows, but as soon as they notice the desktop only lets them do what its developers decided it would do how they decided it would be done (most simply presuming they can't figure out how to get it to do what it will not do) frightfully few will be around after supper. Many begging some forum for help on how to get rid of it. I've set a task for myself to try again and see how much of this I can fix.
Locked