On Sat, Apr 27, 2013 at 9:20 AM, IgnorantGuru <ignora...@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. -- Lubuntu-users mailing list Lubuntu-users@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/lubuntu-users
