On Fri, Jul 4, 2014 at 4:45 PM, <u-c...@aetey.se> wrote: > Hello, > > And thanks for your hard work on LXxx. > > On Fri, Jul 04, 2014 at 11:15:57AM +0800, PCMan wrote: >> Last time I did the test for LXQt Qt4, it used 37 MB more than >> openbox. Now it increased a little (3MB). Of course this can be caused >> by the differences of autostart apps since openbox does not start some >> of them by default, the memory usage of LXQt is not satisfactory >> enough. >> Besides, the startup of the desktop is really slow. It takes about >> twice the time of LXDE gtk+ to load. I haven't came up with better >> ways to get these numbers down. >> Some simple profiling did not show any single bottle neck, so this is >> not an easy task. > > Last times (2011 and 2013) fltk was mentioned on the list it > was critisized for the > > - lack for glib mainloop support > - insufficient support for non-latin scripts > - not enough eye-candy > > Besides the first one (mainloop) where I am unsure about the impact, > the other two seem to have been improved since then. > > For one of the main goals of LXxx, to be lightweight, > fltk looks like a far better choice than either GTK or Qt.
Actually, I followed the development of FLTK for sometimes and I'm aware of the improvement. However, it's still not an ideal option for DE development. 1. Able to render unicode strings is far from adequate i18n support. It should handles RTL layout correctly, such as the Arabic language, complicated composition and layout of characters such as Tibetan language, word wrapping rules in different languages, and much more. Having unicode support only fulfills the most basic requirement. FLTK does not have good enough support for non-latin text layout. (To solve this, you can use cairo + pango from gtk+ with FLTK, since it has cairo support now.) 2. FLTK is not really themable. The appearance is hard-coded and cannot be extended. I tried to hack FLTK to see if I can help, but FLTK is not designed with this in mind so it's too much work. 3. No input method module support, which is required for Asian languages. It supports XIM to some degree, but that's almost deprecated and has limited usability. 4. The widget set is more limited. For example, it does not has a TreeView. 5. No native look in other platforms. (not a problem for us, but it's a problem for other app developers) 5. Hard to track releases. (People are waiting for FLTK 2, but soon it's deprecated) 6. Other applications are developed with Qt and gtk+, not FLTK. So you will have either Qt or Gtk+ running in your desktop session. Developing your DE with FLTK does not prevent loading gtk+ or Qt into your memory since other apps still use them. 7. It's hard to find new developers who use FLTK. (Qt is very popular and many commercial or non-commercial projects are using it. For the future of a project, this is very crucial.) I can list more but I think it's good enough to stop here. FLTK is a very good toolkit and personally I like it much. I even tried to use it previously. However, for the case of LXQt, I believe that migrating to Qt is a better move for the future of the project. If you want to work on an FLTK-based DE, EDE is a good starting point. http://equinox-project.org/ It's really light and fast, but I don't like the Windows 95 look & feel. It will be nice if you can join them and help the development. That will be cool. Cheers! ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
