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?

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
Links

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.

http://www.gnomefiles.org/app.php/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.

Cheers!

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.

img_2110

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

T-shirts and Banners for LXDE

LXDEs popularity is increasing and so people ask for presentation materials and T-shirts. So, lets design some T-shirts and banners together.

We are calling for you to make some T-shirt designs and designs for the display of LXDE at community events with PVC banners. You are a designer or like to become one? Please join
– the design project page http://wiki.lxde.org/en/Category:Design
– the design mailing list http://mailinglist.lxde.org/cgi-bin/mailman/listinfo/design
– and post your designs in the Forum at http://forum.lxde.org/viewforum.php?f=13

We are looking for T-Shirt prints we can use for example at the Linuxtag in Berlin and also for designs for banners of the size of 160×60 cm. Feel free to include screenshots, pictures of the community and anything you can think of :-)

Happy to see your results soon!

New LXDE Components available

PCMan released new LXDE Components and improved settings structure of LXDE.

1. LXInput. This is a config tool used to configure your keyboard and mouse under LXDE.
2. The lxde-settings-daemon: The original lxde-settings is moved from lxde-common to a new separate package and was renamed to lxde-settings-daemon. In addition to the theme, now the settings daemon will configure keyboard and mouse for you. (works with lxinput config tool)
3. lxde-common 0.4: some fixes were done, and unused files are removed. lxde-common is now a noarch, data-only package, and doesn’t contain any binary program in it. The settings daemon is now in lxde-settings-daemon.
4. menu-cache 0.2.5: binaries are now moved to libexec.
5. The original lxsession is deprecated, and will be totally replaced by lxsession-lite since X11 session management is problematic, complicated, and rarely used by applications. GNOME now replaced XSM with dbus, too. So we don’t need that anymore.