PCManFM Qt 0.1.0 released.

[Alexis López Zubieta]

El 28/04/13 07:47, PCMan escribió:
> 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.

Nice work!!
I'm agreed with you, we will have to decide between an extra slim and 
low functional desktop and a functional and no so slim (this doesn't 
means fat) desktop.
http://www.uci.cu