Category Archives: Components

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?

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.

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!

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.

LXPanel 0.4 and menu-cache 0.2.4 released

Hi all, here comes the latest release of LXPanel – version 0.4.

LXPanel 0.4 screenshot

LXPanel 0.4 screenshot

First I’d like to say sorry because this is not a bug-free release.
Some existing problems are not completely solved yet, but most of the bugs causing crashes were fixed. However, we feel it’s right time to have a new release. The menu-cache library is now stable enough for extensive use in LXDE. This will give us a enhanced and faster application menu and lxlauncher. Later, the lib will be used by pcmanfm, too.

The new features and some important bug fixes really deserves a new release of lxpanel.
So here comes version 0.4.

https://sourceforge.net/project/showfiles.php?group_id=180858

To use LXPanel 0.4, you’ll also need following packages:
* menu-cache (lib used to parse freedesktop.org menu file and generate menu)
* lxmenu-data (data files used to generate application menu)

What’s new:
* A whole new application menu generated according to freedesktop.org menu spec.
(faster and more standard-compliant. has tooltips for menu items)
* Enhanced “Run” dialog.
* Auto-resize of application launcher buttons when panel size gets changed.
* Some important critical bug fixes.
* The problematic netstat plugin is now turned off by default. It will be moved to a separate project later.
* Building dynamic panel plugins outside the source tree of lxpanel is now possible.
* and more…

Some bugs are not yet fixed and we know that. We’ll do our best to fixed them later.

LXNM Will Bring Back to Life

So far LXNM(Network Manager of LXDE) was in prototype, LXDE team was just trying to implement a usable network utility. In the beginning, it was expected be enough to work instead of Network Manager of GNOME. But even today, most of people still uses LXDE desktop environment without LXNM due to it is so buggy and poor. Also LXNM has no more improvements in the past, it seems to die for a long time.

It is the truth that LXNM will bring back to life, LXDE team have tried to restart this project and plan on working to implement new architecture of LXNM. Here is a diagram of new structure for next version of LXNM:

LXNM Structure

In principle LXNM will keep original features and most of architecture, but for more requirements of networking device operations, it will be modified or re-designed some parts of that, For communication of Client/Server, LXNM protocol will be re-defined to support more features that something’s just like response of networking status, it means that in the future user can get more complete informations of networking in a moment, and also fixed a critical bug that netstat plugin of LXPanele cannot found out any wireless Access Point as non-root.

For easy to migrate to other platform which is other linux distribution or other Unix-like operating system, LXNM still keep script-based method to handle network device control. Considering that efficiency issue, LXNM will provide a new way to implement that direct call system call to operate network device for each operating system in C language without any scripts, this feature needs more time to be done due to it’s harder and more complicated than script-based method.

With the Google Summer of Code 2009, LXNM is restarting right now. We expect that LXNM will have a great usable version after three month in the future.

LXDE now accessible in local languages for 685 million people

As of yesterday the LXDE and PCManFM repositories are updated and all translations synchronized with there sources. It was a huge task to complete and lasted for almost 5 straight hours but here are the numbers!

LXDE is truly a international project with complete or started translations for most continents (Africa is laking but we are trying to fill that gap too!), as of now we have 35 languages in “official” support (including English). Of these 35 only three are 100% complet at the component level – big ups to Polish, Spanish (Castilian) and Swedish. Together with English these translations make LXDE accessible for about 685 million people (that’s a low count not including those who know and can use English as a second language).
In close range of reaching 100% complete we find Danish, French, Slovenian and Ukrainian at over 90% (adding 120 million speakers to the total).

Since the last update a month ago we have seen two new languages sky rocketing, Slovenian and Lithuanian, a huge effort by the Lithuanian translator and now only LXPanel is left out. For Slovenian we have a sole translator doing a huge work just the last week and I am confident it will be complete soon. At the Pootle server I have added PCManFM as a translateable component for the LXDE project, it is hooked with write access to the SVN server for that project The LXPanel Plugins have been added as a seperate “project” in Pootle too and hooked using the usual mechanisms to the SVN server for LXDE this to maximize the translatable content in the Pootle server.

Allowing translations via Transifex has been started and might be popping up during the spring for those wihing to use that platform instead, subscribe to the translation mailing list for more information about that or hang out at the IRC channel #lxde at irc.oftc.org. In the mean time use Pootle or download PO files from SVN/Pootle and submit to the tracker. One string translated is one string closer to the goal of being 100% translated. We really need some effort in some languages and I am really keen in adding new languages to the project if you are willing to give it a try.

I would like to see progress in the following languages (when they are complete we add another 430 million speakers!)
Russian
Korean
Vietnamese
Malayalam
Norweigan (both Bokmål and Nynorsk)
Dutch
Persian
Pashto/Pushto
Galician

For a quick start in translating LXDE components in Pootle read the illustrated crash course in the wiki.

With regards to the subject then, we are a highly translated DE and the numbers above shows that, the on going development of the LXDEcomponents have changed strings to the extent that while we had six languages completed a month ago we only have four left. And Indonesian and Slovak don’t even pass the 60% marker (mainly due to the addition of PCManFM but still, that’s one of the core pieces of software we have). We have decreased the overall degree of completeness but on the other hand progress have been made in many areas. Keep the good work up!

Translation update!

New week and time for an update regarding the translations for LXDE. During the last week some more users have started the translations in Pootle and by all means have delivered. Significant changes are noted in Danish that are 100% complete by now, good work!

If you are new to Pootle and/or translation in general take a look at the crash course at the LXDE wiki and then go grab some strings. Just some spare minutes are needed to make some languages 100% complete, others could benefit a great deal from just some minutes of work and that coul add up to a complete translation. Start with the low hanging fruit, skip LXPanel if you are not too familiar with doing translations.

By now the following languages are complete:
- Danish
- Indonesian
- Polish
- Portugese (Brazilian)
- Slovak
- Swedish

And in close range of 100% is the following:
- Arabic (one string marked fuzzy in LXPanel)
- Ukrainian (one string marked fuzzy in LXLauncher, in fact it is untranslated!)
- Czech is at 87% (only LXPanel left, over two thirds are already done)
- German at 84% (missing strings in LXPanel, LXLauncher and LXMusic. The last two is small and pretty easy to finish I guess)

For the other represented languages more actions are needed to make them complete, some are close to 80% with others only done in LXMenu-data that we have imported from GNOME.

LXMusic – Minimalist xmms2-based music player

Everyone loves screenshots!

lxmusic.png

LXMusic – The minimalist music player for LXDE. This is based on xmms2, which is lightweight and has server/client design. The user interface is quite simple, clean, and intuitive. At first glance, it looks similar to my favorite player on Windows – foobar 2000. LXMusic only has very few features, and it can do nothing more than just playing a list of music files. However, this is what’s lacking today, a player which doesn’t try to teach you how to listen your own music files. It just plays! That’s all.

It’s still under development and is still in alpha stage, but it’s enough for everyday use. Please grab the tarball or download the hotest code from LXDE svn repo to get it tested!

LXPanel 0.4.0 beta! Testers are needed!

We haven’t have new releases of LXPanel for quite a long time, but the development is still ongoing.

Major Changes:
* Greatly rewrite application menu with our new menu-cache library. Now it’s complete and more user-friendly
* Improved “Run” dialog
* Improved OSS volume plugin
* Image showed on application menu button can be changed with GUI.
* Add new temperature monitor plugin by Daniel Kesler
* Size of icons now can automatically be automatically adjusted according to the height of the panel.
* Numerous bug fixes and more…

Please get it tested since lxpanel 0.4 will be released very soon.

Note that to make the whole new menu work correctly, now menu-cache and lxmenu-data are needed.
LXPanel source tarball

menu-cache library tarball (lightweight library used to generate standard compliant menus)

lxmenu-data tarball (data files used to build the menu)