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. > The only sensible way to get memory usage down and speed up startup > seems to be a single process + loadable module approach, like the one > proposed by Alexis López Zubieta and their MoonlightDE. I'd like to > ask again if you guys support the idea? As a "system integrator" I am not fond of solutions which rely on loading their parts as shared libraries. This implies coordinated compilation of the parts/modules - not only in the sense of using the same toolkit but it also postulates binary compatibility of _all_ of the libraries used by _all_ of the components. This may include third parties' libraries, which may even include non-OSS ones. E.g. lots of Linux installations use nvidia drivers - what about building a DE against uclibc to make it compact, if one of the modules will want to use GL? I guess the only available form of nvidias libraries is built against glibc. This is just an example, OSS-libraries can be extremely painful too! One may be unfamiliar with the cases where there is no such thing as "the" compilation environment - but this is a real and a very useful scenario when components do not have to be compatible library-wise. For a truly modular system the interface between modules should be via data passing - without sharing the address space. The latter introduces a lot of constraints and problems - all for the sake of efficiency. Everyone seems to realize that there is some price to pay but possibly not its full degree. I am convinced that the price is too high, undermining what "modularity" means. > If there are no objections, I'd like to start doing some experiment > with that. (in their own branches, of course) > Comments are needed. Please share your ideas. It is your time and your decision. If I could find some time for actual DE development I'd start with checking fltk. If it is still not up to the task I'd possibly see how much it would take to add the missing pieces. Thanks again PCMan, Rune ------------------------------------------------------------------------------ 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
