LXDE one of the largest open-source teams in the world

I just found this factoid on Ohloh and I am amazed to read this:

LXDE: Very large, active development team
Over the past twelve months, 26 developers contributed new code to LXDE. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 46 developers have contributed. (http://www.ohloh.net/p/lxde/factoids/)

I believe everyone in the LXDE team still considers the project as a rather small project with a small team. There have been many changes and advances, but I would have never guessed that LXDE is one of the big projects. If we see it in regards to Gnome and KDE, the relations become different though. Gnome has 432 developers according to Ohloh and KDE even 482 code contributors. XFCE shows up with 12 coders during the last twelve months.

I wonder how many people actually work in different desktop projects at the same time. We have friendly relationships with many contributors working on different projects already. Chris Wickert for example is a core member of LXDE and at the same time taking care of XFCE packages in Fedora. In the end we all share the same ideas and goals about free and open source and we actually share a lot of the code with many projects, especially with our friends from XFCE.

Everyone, keep up the good work! I hope to see more exchange and friendships among our projects. We welcome everyone to work and cooperate with us even if we have some different views sometimes on specific questions. In the end it is cooperation what makes us – as a software project and a community – advance faster and become better.

LXNM current status and the plan in the future

Next generation of LXNM (Lightweight Network Manager) is still under development right now, You guys can see the prototype which was implemented in SVN already. In the future, LXNM will provide some programs includes lxnm daemon, utility which is a command line program to make control of all kind of networking devices be unified into only one utility, a LXPanel plugin and a standalone applet for running without LXPanel.

So the project will has three parts to be maintained:
1. lxnm (LXNM Daemon and command line utility – lxnetctl)
2. lxpanel-netstat (LXPanel plugin)
3. lxnm-applet (standalone applet)

For the current version in SVN, lxnm can be working now, we can using lxnetctl utility to connect to lxnm daemon to control our networking devices and get informations include ethernet and wireless interface.

BTW, I am now working on lxnm-applet to implement a graphical LXNM client to display and control network devices.

Besides, in the future, LXNM will provide a library to make easy to write a new LXNM client(eg, lxnm-applet) for developer.

LXDE core member Chris Wickert for Fedora Engeneering Steering Committee

Please support LXDE and vote for our core member Chris Wickert in the elections of the Fedora Engeneering Steering Committee.

  • Christoph is the maintainer of Xfce and LXDE in Fedora. A vote for Chris is a vote for lightweight desktops in Fedora.
  • His goals are to make Fedora more lightweight and less ressource hungry as well as keeping depencies low.

chriswickert-fedora-lxde

To vote for Chris you need to have a  (1) Fedora Account and (2) be accepted in a group, for example join Fedora Ambassadors. Voting is possible until June 22, 2009.

Chris is the most active distro package maintainer of LXDE in Fedora. His engagements is a great success for both Fedora and LXDE as the large interest at Chemnitzer Linuxtage and other events have shown recently.

A quote from Chris Wickert:

(I want to) … improve packaging quality and enforce higher standards for better cross desktop interoperability. Try to reduce the dependency bloat to make sure Fedora does not become too fat, so it still can be used on older or smaller hardware like netbooks or the OLPC without too much pain.

Nominations followed a predefined structure, where people could ask questions and get answers. The answers of Chris here. There was also an official IRC meet up for candidates with the logs also available.

Please vote for Chris on this page: https://admin.fedoraproject.org/voting/about/fescof12

Links

* Blog of Chris Wickert http://www.christoph-wickert.de/blog/
* Join Fedora https://admin.fedoraproject.org/accounts
* https://fedoraproject.org/wiki/Elections/Questionnaire
* http://www.leemhuis.info/files/fedora/answers.txt
* http://www.leemhuis.info/files/fedora/answers-table.ods
* https://fedoraproject.org/wiki/Meetings:Town_Hall_FESCo_2009-06-03_1400

Next generation PCManFM is now under development!

Everybody loves screenshots!
This is the little demo program included in libfm demonstrating the functionality of libfm – the core of next generation PCManFM.

libfm-demo

Due to some limitations and various hard-to-fix problems in the original PCManFM, a new project is started to work on a fresh rewrite of PCManFM. Now I’ve created a project named libfm. It’s a gio-based library used to develop file manager-like programs.

http://sourceforge.net/projects/libfm

This will be the core of next generation PCManFM. Currently the work that has been done is in branches.  It contains a simple demo program named libfm-demo. Most of the menu items in this demo program are not working.

Currently it can only listed the files on your disk. No other operations are avaiable since they haven’t been written yet. I’ll work hard to finish it and hope the first really usable release can be made before 2010.  The project is in its very early stage, but you can see the progress here.

http://cia.vc/stats/project/libfm

After finished, the lib will be separated into two parts, libfm and libfm-gtk.  The former is a generic non-gui library, and the later provides useful file manager-related widgets.

The roadmap of PCManFM is updated, too. Those are the tasks to finish.

http://wiki.lxde.org/en/PCManFM_Roadmap

If someone is willing to help, that’ll be appreciated. Help is wanted!!

LXDE start pages in Portuguese

The LXDE.org start pages are now available in Portuguese thanks to Henrique P. Machado (zehrique) from Brazil who has translated the content. The set up of the language was done together with Mwei from Taiwan. We welcome contributors who are interested in having the LXDE start pages in their language. Please contact us through the mailing list of the translation project.

lxde.org-lightweight-x11-desktop-environment-portugues

The Portuguese Introduction of LXDE

O “Lightweight X11 Desktop Environment”, é um ambiente de área de trabalho extremamente rápido, ágil e poupador de energia. Ele é mantido por uma comunidade internacional de desenvolvedores e vem com uma bonita interface com o usuário, suporte a múltiplos idiomas, atalhos de teclado padrões e características adicionais, como um gerenciador de arquivos com navegação em abas. O LXDE exige menos da CPU e consome menos memória RAM. Ele é desenhado especialmente para computadores em nuvem com especificações de hardware limitadas, como netbooks, dispositivos móveis (ex.: MIDs) ou computadores antigos. O LXDE pode ser instalado em distribuições como Ubuntu ou Debian. Ele provê uma rápida interação com o desktop, conectando-se facilmente com aplicativos na nuvem. O LXDE suporta uma gama enorme de programas, que podem ser instalados localmente com os sistemas Linux. O código-fonte do LXDE está licenciado parcialmente sob os termos da Licença Pública Geral (GPL) e parcialmente sob a LGPL.

Join the Translation Project

Please join the translation project, subscribe to the mailing list and add your name into our wiki page for the Translation project.

Links

* Translation Project http://wiki.lxde.org/en/Category:Translations

* Translation Mailing List http://mailinglist.lxde.org/cgi-bin/mailman/listinfo/translation

* LXDE Online Translation of components http://pootle.lxde.bsnet.se

xkb: New Applet for LXPanel

PCMan has added a new branch named lxpanel-xkb in the LXDE Repository.

svn co https://lxde.svn.sourceforge.net/svnroot/lxde/branches/lxpanel-xkb

It’s a new applet for lxpanel which will be a keyboard layout switcher. The original one in lxpanel is broken, and will be removed. The new one will be based on libxlavier, a good library handling xkb. However, we’re from Taiwan, and we don’t know how keyboard layouts work. So help is needed. If you’re a developer living in Europe or some other places requiring switching between different keyboard layouts, please help. (PCMan)

If you are interested in the development of LXDE, please also join our developers mailing list.

Links

* http://wiki.lxde.org/en/LXPanel

* https://lists.sourceforge.net/lists/listinfo/lxde-list

If you don’t like to be forced to use gnome standards, please join xdg mailing list.

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.

lxde-fdoFreedesktop.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 .

PCManFM: OpenSolaris distribution Milax with LXDE component

The first LXDE component has been included in an OpenSolaris distribution. Milax includes PCMan File Manager in its new release. The LXDE/OpenSolaris project was started last year. Alfred Peng from China is responsible for porting LXDE components to OpenSolaris.

Milax OpenSolaris with LXDE components

Links:

* http://www.milax.org/?p=218

* PCManFM http://wiki.lxde.org/en/PCManFM

* http://opensolaris.org/os/community/desktop/communities/lxde/

* http://wiki.lxde.org/en/OpenSolaris

Please vote for the future of PCManFM.

Please visit the following URL to vote for the future of PCManFM.
http://forum.lxde.org/viewtopic.php?f=0&t=456

Hi, all LXDE users,
After more than two years of development, now LXDE became very active and more and more mature.
Recently, some developers joined us, and many new changes were made in our svn repository.
However, the core and the origin of the desktop, the file manager, PCManFM, didn’t get improved for a period of time.
There are originally some plans, but due to dramtic changes in recent GTK+/glib/gnome/freedesktop.org/HAL, we have a dilemma now.
One thing that I hate Linux most is they are always breaking backward compatibilities and trying to ruin others’ work.

The volume management parts is now broken due to incompatibility changes in HAL.
Now many modern distros are using PolicyKit and force the use of it with HAL.
Unfortunately, some related things are now GNOME-specific, and more or less depends on gnome. KDE guys are now trying to develop their own equivalent tools, and its only availble in the latest KDE. The simple gksu, sudo, or other similar tricks no longer works correctly without gnome stuff.

Thunar and XFCE uses their own libexo and exo-mount along with some xfce libs to handle volumes. Not sure about how it handle PolicyKit.

So, a gnome-free clean solution to this is not quite possible at this time.

Second, since glib/gio is now extensively used in gtk+ itself, the GtkFileChooser (Open/Save dialog) now uses gio, too. So, shifting to gio seems to be a reasonable and inevitabe move.
GTK+ already depends on it, so there is no way to prevent the use of gio.

However, though they claimed that gio works without gvfs (fallback to local filesystem), that’s not the truth. File copying, HAL-based volume mouting, and even trash bin…etc don’t work at all without gvfs, which has many dependencies. Using gio extensively means that you’ll need gvfs, too. Current gvfs depends on some gnome stuff, such as gnome-mount and gnome-terminal, gconf…etc, and those parts are “hard-coded” in gvfs. So they are not changable.

Bookmarks in GTK+ file dialogs now supports remote URLs. If we don’t use gvfs, we will be incompatible with gtk+ itself. Current PCManFM doesn’t recognize those remote URLs, and this causes problems with more recent gtk+/gnome programs. No matter you like it or not, gtk+ is now depending on gio, which requires gvfs + gnome stuff to be fully functional.
Yes I know it still work without gvfs, but most of the advantages of gio won’t be available without gvfs. Removable devices are not mountable in GTK+ file dialogs without gvfs, too.

Besides, some parts of gio are not efficient and uses much more memory in many places.
Hence using gio along with gvfs (plus its gnome dependencies) seems to be inevitable in the future.

Another solution will be using thunar-vfs implemented by thunar. The advantage is quite apparent. Thunar is very fast and the memory footprint is small. The APIs are easy to use and provides more sophiticated interface to developers. I already reviewed its code, and it’s well written, commented, and optimized. The quality is very good. The author of thunar, Benny, is one of the best gtk+ programmer I’ve ever seen in the free world. However, thunar-vfs depends on several XFCE libs. Besides, in some distros, it’s bundled with thunar. It has no support for remote filesystems, and the compatibliy with gio/gvfs is hence questioned.

In addition, there are some XFCE developers trying to migrate thunar from thunar-vfs to gio.
I think they made a huge mistake since both the design and performance of thunar-vfs are better than gio. Thunar-vfs, however, doesn’t support remote filesystems. This can be compensated by using FUSE-based implementations. Originally this is also the plan of PCManFM, and was once tried in 0.4 branch. Unfortunately, due to lack of good-quality and GUI-friendly FUSE-based remote filesystem implementations, this was removed in 0.5. Moreover, using FUSE-based implementation can only provide POSIX interface to programmers, which is a little bit restrictive to desktop applications.

Apart from those two existing vfs implementations, there is no existing equivalence.
Our own vfs implementation in PCManFM is quite primitive and a little bit buggy. Besides, we’ll be lagged behind freedesktop.org specs since it’s mainly controlled by GNOME and KDE guys.

Before this important issue is solved, further development of PCManFM will make the shift to other VFS more difficult. So a decision should be made here, and we can continue the development of the file manager.

Options are:

1. Shift to GIO + GVFS, and accept the inevitable GNOME dependencies it brings since many gtk+ apps also need them, and we can get full support to remote filesystems with good compatibility with gnome/gtk+. Future breaks in backward compatiblity won’t affect us since those dirty works were maintained by GNOME developers. Then we can focus on the design of desktop environment, not on fixing broken compatibilities. Since XFCE seems to be shifting to GIO, maybe it’s inevitable.

2. Shift to thunar-vfs, and accept the inevitable XFCE dependencies. Then handle all remote filesystems with FUSE-based solutions. However, if XFCE adopted GIO/GVFS in the future, we’ll lose all the supports. Besides, I’m not sure if XFCE solutions can be compatible with future GNOME. Especially when PolicyKit, ConsoleKit, and more things are widely adopted by modern distros, and they are more or less gnome-related.

3. Copy the code of thunar-vfs, and create our fork. We can do what we want, and try to minimize XFCE dependencies. However, it’s difficult to keep sync with XFCE/thunar, and removing those XFCE dependencies is not quite easy. Besides, this can make XFCE guys angry since we only steal their code and rename all the libs, then strip their XFCE dependencies. In addition, our improvement cannot get into XFCE source tree. So duplicated work will be done by both project, and we’ll become out of sync grdually.

4. Keep current work, and try to fix all bugs (Not quite possible). If freedesktop.org specs changes (happens frequently), we just rewrite our programs to fit them (a great waste of time and this definitely blocks our development in other areas). This could even make our work totally broken if they change something in the spec or the future versions of gtk+/gio. Then we’ll be busy fixing broken compatability all the time.

So, it’s a important and difficult decision.
Personally I’ll suggest adopting GIO/GVFS and accept its deps, then try to keep our program lightweight (This is still possible). This will make PCManFM heavier and slower than current implementation, but since the current code is buggy and not functioning well…. It’s not a fair comparison anyways.
Any thoughts or better ideas?

If we start using gio/gvfs, that doesn’t mean we’ll be slow just like current nautilus.
On the contrary, if we use ready-made VFS library like gio, we can focus on what we really want to do. Of course, this includes doing optimizations and adding handy new features.
In the long run I think this is more constructive than fixing old bugs and broken compatibility all the time. I believed that judicious use of gio/gvfs can still make things lightweight and fast “enough”. “Enough” means, it won’t be the fastest, but it will be acceptible by the users.

People think that GTK+ is slow, but we prooved that you can still develop fast and light apps with it. So, I think we can do well with GIO/GVFS or thunar-vfs, too. Having some inevitable dependencies on other desktop environments doesn’t mean that we’ll be slow. That’s totally dependent on how we use them. After all, many other existing applications are using those libraries,too. So it’s not possible to get rid all of them on modern distros. Since they are already there and is now an essential part of the system, why not make judicious use of them? 🙂

For me, provided the performance is still good and the memory footprint is still acceptible,
some (minimal) gnome or xfce dependencies are acceptible. How about the opinion of our users?