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.


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.


* 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.


* 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


* 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.

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?

Nominate LXDE for the Community Choice Awards 2009

cca_nominatePlease nominate LXDE for the Community Choice Awards 2009 till May 29, 2009.

LXDE was started already in 2005 in Taiwan and has spread all over the world. During the last year the project made big advances. New components have been added and older ones were updated. We have formed a viable translation project with people translating components from Peru to Egypt to Japan to Germany and all around the globe. LXDE is now included in many Linux distros, was ported to Google Android, has been shown to work on BSD, and was established as a Desktop Project for OpenSolaris.

During my recent travel to China I discovered that many of the small Chinese hardware producers customize LXDE and use it on their devices. LXDE offers new business opportunities for these producers. I have received many emails of people using LXDE like in whole universities in Brazil.

Please tell us your story how you use LXDE or participate in the project and please show your support for LXDE and the growing community by nominating the project for the community choice awards 2009. The LXDE project is still a project of a small community, but looking to who is participating, we already achieved to form a truly international project, which inspires me to continue supporting the project and freely licensed Open Source projects in general.

The message of LXDE: International Free and Open Source development across cultures and regions works! Faster, more lightweight and energy efficient systems are possible!

There are many projects that deserve to get this awards. I certainly believe LXDE should be one of them. I nominated LXDE for:

  • Best Project
  • Best Commercial Open Source Project
  • Most Likely to Change The Way You do Everything

Please join us. Thank you for your support!

Important Dates

  • May 6 – Nominations open
  • May 29 – Nominations close
  • June 22 – Finalists announced, voting opens
  • July 20 – Voting closes
  • July 23 – Winners are announced at OSCON

LXDE speaks 13 languages!

Three weeks have passed (was supposed to deliver some statistics last week but not that much had happened so I took the weekend to rest =)) since last report and we have had another huge progress in the code, most of it has happened the last week though.

As we approach the imminent release of GPicView the translators have been busy to complete the new strings and most of them have also completed and updated other parts of the project. It’s nice to see how interested the community are in completing the translation effort for their language. In early May we had four languages (and English) completed – Arabic, Spanish, Japanese and Swedish. I am pleased to be able to report that we have twelve (not including English!) individual language codes fully translated. We even got some new languages added these weeks that are completed. That’s a really fulfilling experience. Big up to Urudu (a sole maintainer does both Urdu and Urdu as spoken in Pakistan).
Another great achievement this last week was the progress from Dutch and Indonesian, Dutch was placed in the need work category (less than 50% completed) and are now completed. Indonesian wasn’t that far off but not in the runners up category (90% or more done).

Let’s get down to the figures for real then, the completed translations enable 1200 000 000 people to use LXDE in their native tounge. We have doubled the numbers in just about a month work! By completing the runners up category we will add another 411 200 000 native speakers. And by all you who get around by using a secondary language (English, Spanish, French?) the number of enabled users are truly amazing! The translators really deserv a big hand for their great work in connecting people.

I always try to get some languages to deliver, we have a sad category I call “Needs work“. These are not by any means minor languages but their progress is stalled and their completion rate is under 50%. We call members of the community who speak Afrikaans, Bulgarian (new language added just yesterday!), Galician, Korean, Norweigan Bokmål, Norgweigan Nynorsk, Farsi/Persian, Turkish or Vietnamese to the stands. If you show up and can complete the translation effort we could add another 275 000 000 people to the stash. Please note here that the Chinese translations (as spoken in China and as spoken in Taiwan) are not completed and would bring another 1 000 000 000+ people to the totals. We are a large community, but why stop at large when great is near?

If you know any of the not completed languages or want to translate LXDE in to a new language that we at this stage not try to support please contact us (via the mailinglist, the forums, me directly or by IRC, any means would probably do – e-mail is the best because of time zones=)).
If your language is already in LXDE in some state it is enabled in the Pootle server and it’s easy as reading the guide to get started. Or if you rather would like to get the files and use a PO-file editor there are guides for that approach. Help us become a well translated and enabled Desktop Environment.

Improving the translations workflow with Transifex

Roughly about a month ago Martin Bagge mentioned that we were researching the possibility of using Transifex as a translation platform for all of the LXDE components. That is not to say that our Pootle server won’t be around, but we felt that our translators could benefit from a few handy features that Transifex has to offer.

So what exactly is Transifex you may ask? I guess the best way to describe it is as a bridge between source code that needs to be localized and people who know how to translate it. But that was a rather simple description of what this amazing tools does! I could go on and on about the cool features, but for this post I’ll try to keep it simple and go directly to the point.

For the administrators: Nothing needs to be done! That’s right, nothing! No more local user accounts, ssh keys and all of that nonsense! Put your feet up and relax!

For the translators: At first glance it may seem like there is yet another entry point for you to do your work, but bear with me for a bit. If you love how Pootle works and that does the trick for you, then nothing has changed. The same goes for those who like me have direct commit access and like to use the command line! Keep up the good work! However, if you crave for some some type of management and up to the second information about your translations, then you’re going to enjoy what Transifex has to offer!

As I mentioned before, Transifex acts like a bridge between your source code and translators. It doesn’t really matter what type of versioning control system is used to store the source code (by the way, we use subversion). All this tool needs to know is: where does the code live, who is entitled to work on translations, and if translations that are uploaded can be automatically committed upstream.

Transifex workflow
Transifex workflow

So your job as a translator will be:

  1. to create a (free) account in the Transifex server;
  2. associate yourself with the LXDE project and the specific language you want to work on;
  3. and use the web interface to reserve a file for translation. This file can then be downloaded and translated offline and then submitted back via the same interface. The translation is then validated and committed upstream into the official repository.

If you are responsible for managing one of the language teams or just want to make sure you know what is happening with the project as a whole, you can choose to be notified every time someone reserves a file for translation, writes down a comment, reviews someone’s work, or a commit takes place. Since people will have to reserve a file for translation, you can make sure that no two people work on the same file at the same time, in the end saving time, headaches and redundancy. Best of all, since your work can be committed automatically when you upload your translation, you can see in real time your progress and that of your teammates.

Reserving and submitting translations
Reserving and submitting translations

In the next few weeks we will have a LXDE project officially set up and hosted by our friends from the Transifex project and we will then make a call to arms so that those who want to use this new platform can get the proper permissions configured, but I kindly ask everyone to wait until we make another announcement here.

In the meantime, keep up the excelente work you’ve  been doing and let us know how we can make your lives easier! Comments, concerns and suggestions are more than welcome!

GPicView 0.2 beta is coming with GIF animation support!

Finally, we have yet another new release of GPicView.


Really glad to announce the upcoming release of gpicview 0.2.
With the help from Marty Jack and Louis Casillas, some new features are added.
* GIF animation support!!
* Save jpeg and png files with different compression ratio.
* Background color can be freely changed.
* Some bug fixes.
* UI polishing.
* New translations

So, we’re going to release gpicview 0.2 soon.
Currently a beta version 0.1.99 will be released first for testing.
If there are typos or inappropriate text on UI, feel free to bug report.

Once everything goes fine, the strings in the UI will be frozen.
Then it’s the time for translators to get all of them translated, and
we can make a 0.2 stable release.


Making LXDE packages at Coding for Fun in Beijing

I am meeting up with some folks from the Beijing Linux User Group at Coding for fun at the Thiz Linux office in Beijing.


It is great to see how dedicated everyone is. eMBee is teaching Guang Yudong how to actually create packages. Besides that we have Zhang Sen working on his Google Summer of Code project, folks working on OpenMoko and supporting Chengying in her first steps with Linux. Xuedi is discussing with Anthony Fok and Ollo about other cool staff in the FOSS/Open Source community. Thanks for a great time in Beijing!

Xuedi with Beijinglug T-shirt