Hello! John Spencer has written on Thursday, 25 April, at 14:59: >OTOH what the LXDE leaders currently have in mind is even worse:
>now they want to use C++ (!) and Qt (!). >Qt is over 100 MB of compressed sources and takes hours to build, it's >full of templates (yay duplicated code in binaries! yay debug builds >which consume gigabytes of RAM to link!), OOP (dynamic allocation >everywhere) and thus the next gen LXDE will turn into a giant hairball, >basically the next KDE. >btw, according to the wikipedia entry about razor-qt, that one already >consumes more than 100MB of RAM to simply show the panel and a wallpaper... >on sabotage linux i do the same with lxpanel, and mem consumption is >20MB for the entire system: http://i.imgur.com/Lz7Ov.png (early >screenshot, here's a newer one: http://i.imgur.com/2k4Hvzh.png which >doesnt show ram consumption tho) You cannot tell for sure what it will take before you compare it. In case you don't know, in GTK classes very big chunk of CPU consumed for indirect calls and internal table searches (surprise, surpise!) while any good compiler of C++ will make all those calls direct (and it's basically why C++ compilation take so huge resources) which can in theory make Qt application much more fast and less resource consuming than GTK apps (yet again surpise, surprise!). You can tell for sure only when you try to run the same application ported from GTK to Qt or vise versa. And also you should take to consideration that razor-qt setup may be suboptimal at all but rather tasty for someone who wrote that info. And, BTW, I've looked how many memory is used on my desktop with very minimal LXDE-based setup and only IM started - it's almost 200 MB. razor-qt wins, I believe. And I'm sorry but I consider your 20 MB a lie - the kernel, X server and pcmanfm alone will take at least 50 MB. Lxpanel and brother services will spend few more tens of megabytes. I'm sorry but it is so, and if razor-qt setup takes about 100 MB then Qt and GTK memory numbers are comparable and that comparizon (memory, CPU, responsiveness, etc.) should be done before any moves. >> studding the possibility of creating our on lightweight desktop >> environment in order to improve the architecture of LXDE and make it >> more scalable, functional and integrated. But is not wise to start >> another project and duplicate efforts, instead of that we want to join >> forces with you to create a fully functional and lightweight desktop >> environment. >unfortunately you won't achieve this with mainline LXDE, they're heading >down the road of bloat nowadays. Don't try to offence LXDE developers, we don't take your bait. The main goals of LXDE are: 1) make a DE which will work on systems with slow CPU and little RAM; 2) make a DE which will consume less resources that everything else; 3) and that DE should perform most of tasks that monstrous ones can perform, except those tasks that require much more resourses. Don't make a panic, please. That is healthy neither for you nor for anyone else. Thanks. Cheers! Andriy. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
