PCManFM Qt 0.1.0 released.

[PCMan]

On Sat, Apr 27, 2013 at 9:20 AM, IgnorantGuru <ignorantg at gmail.com> wrote:
> Great work PCMan!  And thanks for the conversion wiki.  I've been shopping
> for a GUI toolkit myself - perhaps to take SpaceFM there eventually - though
> I'm not sure I like qt.  Is there a discussion somewhere of why LXDE and/or
> you are choosing to migrate to qt?  I understand the desire to move away
> from Red Hat's poisoning of the GTK well, but why did you choose qt?  And
> what other toolkits did you review?  I would like to see the discussion or
> analysis.
>
> Also, what are the current thoughts on gvfs now that you're moving in a more
> qt direction?  Any plans for change there?
>
> I've dropped you a link
> http://igurublog.wordpress.com/2013/04/26/lxde-and-calculate-snub-gnome-3/

About gvfs, I'll keep using it for now. Mixing GIO and Qt works
perfectly and Qt has built-in glib integration.
Gvfs has more and more backends and many of them has no FUSE-based equivalence.
An alternative would be to use KDE's KIO slave, if you're OK with the
KDE dependencies.
In comparison, gvfs is "relatively" more desktop-independent.
When the backends are carefully separated by packagers, it's actually
desktop independent and only brings few gnome deps.
If your gvfs installation depends on the whole gnome, blame the
packager of your distro.

Since people are curious about the GUI toolkit issue, I wrote down
another wiki page (not completed).
http://wiki.lxde.org/en/GUI_Toolkit_Comparison

There is no perfect toolkit. So it's all about a balance between cost
and benefit.

What I considered important:

1. It should be fast and light:
If you insist on this point, then Qt and Gtk+ are out. But when you
also consider the following points, things become different.

2. It should have good i18n support, including unicode, RTL, and other
complicated text layout.
GTK+ and Qt have exellent support in this fields while FLTK and FOX
toolkiit only have very basicones. Enligtenment, I'm not sure.
If your program is going to be used in non-English speaking countries,
this is a critical issue.

3. It should accept text input from an input method editor
Again, it's an essential feature for people from countries like China,
Japan, Korea, and Taiwan (where I come from).
So, I think only Gtk+ and Qt have good enough support for this.

4. It'll be better if it has accessibility support.
Undoubtedly, Gtk+ is the best one here, and Qt follows. The others are
irrelevant.

5. It should be really easy to program with, making us more productive.
I'll never call "writing C with GObject" easy and efficient. So GTK+
is out. (I know vala, but it has many issues, like generating
"incorrect" C code that's hard to debug). If you're doing OOP, why not
use a language with "native" OO support and compiler optimized for the
task?

6. It should supports glib integration, so I can use all of the nice
non-GUI libraries based on glib. Qt, GTK+, and E17 are the ones that
support glib. Others cannot do this.

7. It should be well-maintained:
Qt and Gtk+ win. E17 has slower development, and FLTK is now splitted
into two incompatible branches and each of them have many supporters.
The future is uncertain.

8. It should be themable and looks good.
Then apparently FLTK and FOX are not the right choice. FLTK has some
"so-called" themes, but it's very primitive and limited, not really of
the same level as Gtk+/Qt.

If you consider 2 - 8 required and also want it to stay
ultra-lightwight, then there is no such toolkit.
If you make some compromise, then Qt is probably a good one.
Consider the rich feature set it provides, it's not that heavy.
To get the same feature set, you need to install tons of other
libraries in the G universe.
Besides, Qt is modular. If you only need the core features, link with
QtCore and other modules won't be loaded.
The whole library of course is huge, but you only need to link with
the module you really used.

Hope this answer your questions.