Hello people:
Did you ever read my emails? Months ago I tell you about an experiment that i
was doing, did you remember https://github.com/azubieta/lxqt-core. Well this
"experiment" already has a "shell" or a "core" and has some of the components
of the desktop as dinamic libruaries (panel and runner). It is still in a
pretty bad shape but with your help I can improve it a lot. Please let your
ideas in the project wiki and take a look at it. If you are going to try it
check the build instructions at the wiki as well.
About the transformation of the aplications I had some troubles with the
translations, the themes and the settings because of the razor-application
class. It may require some work around to make work well.
PCman, I wasn't able to build and include the file manager at that moment, help
me with it if you can.
Kuzma please take a look a the code and let me know your opinions.
I was a bit unmotivated at the begining due to the poor welcome of the idea but
I will start working on it again. I had plans to present it as my grade project
so i will give it all.
Cheers
Alexis López Zubieta
Nova Light Development Team
University of Informatics Sciences (Cuba)
----- Mensaje original -----
De: "Kuzma Shapran" <leaf.on.w...@gmail.com>
Para: "PCMan" <pcman...@gmail.com>
CC: "lxde-list" <Lxde-list@lists.sourceforge.net>, razor...@googlegroups.com
Enviados: Miércoles, 20 de Noviembre 2013 4:28:20
Asunto: Re: [Lxde-list] [razor-qt] Suggestion: merge lxqt-runner & lxqt-panel
I agree - it's worth a try.
And you have raised an interesting point about IPC.
If the session starts (and monitors) only one instance of lxqt-shell, then it's
not a question - all modules are libraries within the same process, but we
allow to start several separate processes of lxqt-shell (we might even have a
checkbox in session config: "launch components as separate processes"). In this
case modules should find out themselves how to interact with other modules -
through IPC or using direct calls (or signal/slots or whatever) within the same
process.
Fortunately there should not be many of IPC calls, so lxqt-shell can do this by
redirecting requests to another loaded library or by sending them to session or
to another instance of lxqt-shell.
Another point to consider - is singletons. Most (if not all) our modules should
be singletons. So it has to be tracked somewhere. The only stable point is
session, so when a lxqt-shell tries to start a module - it should ask session
whether this particular module is allowed to start.
Cheers,
Kuzma
On 20 November 2013 16:05, PCMan < pcman...@gmail.com > wrote:
Kuzma, I have the same idea in my mind for quite a long time, too.
This can be done easily with the following approach.
1. Replace every main(int argc, int argv) to <Program_name>_main(int argc, int
argv);
2. Modify CMakeLists and replace add_executable() with add_library() so every
components are now libs.
3. Add a thin wrapper binary program around the lib. The binary only contains
main.cpp and only has one function main(), which calls <Program_name>_main().
4. Add a new program such as lxqt-shell, which loads the libs and all component
are running in the same process.
5. If any of the component crashes, the whole shell process crashes, but the
session manager can monitor this, and restart it. Though it's less pleasant for
the users, it should be a rare case and we should fix the bugs anyways. This is
also what Windows explorer.exe does.
6. For those who hates the monolithic shell process, they can still run seprate
components as different processes since we provide binaries in #3 which in
turns call the component libraries.
Pros:
1. all major components are loaded in the same process. So memory, other system
resources, pixmap cache, menu cache, and all other caches in Qt can be shared
among all of them, potentially saving much RAM.
2. Loading will be faster, and synchronization between the components becomes
so easy and does not require IPC.
3. Interaction among the components can be done without IPC when they're not
running as separate processes.
4. Library symbol resolution is only done once by the runtime linker, so
loading should be faster. (However relocation might be increased, so the final
result is unknown).
5. No modification in the session manager is needed. Instead of loading several
components, it only need to load lxqt-shell and monitor it. The only thing
needs to be changed is lxqt-shell should be made configurable so we can select
what modules to load. A lxqt-config-shell tool is needed.
6. All parts can use the same pixmap cache for QIcon, which saves some X
resources and RAM.
Cons:
1. All components are compiled as PIC code, which might be larger and less
optimized.
2. One component crashes, the whole shell crashes. But if we separate the shell
process from the session manager, the user won't loss any data or the processes
they are running. Only the panel and the desktop manager disappears, and if
they can be auto-restarted, that's not a big issue, just some glitches.
3. Since all programs are now using the same pixmap cache for icons, if the
icons used by different components are totally different, the cache will be
full sooner. Some old entries must be removed from the cache in this worst
case. Than, following calls to QIcon::pixmap() will have more missed cache hit.
That's the worst case which I think does not happen most of the time.
So basically, I think this idea is really worth for trying.
This should speed up the desktop a little bit and save much RAM.
What do you think?
On Wed, Nov 20, 2013 at 6:48 AM, Kuzma Shapran < leaf.on.w...@gmail.com >
wrote:
<blockquote>
On 20 November 2013 11:41, Mark Deneen < mdeneen+l...@gmail.com > wrote:
<blockquote>
If one module crashes, won't the entire process be terminated?
Alas, yes.
We should just make sure modules never crash! ;-)
Seriously, if panel or desktop app crashes - this is also not a very pleasant
event. I remember that in Razor session monitors modules (processes) and
restarts them if needed. With this new idea we also can have lightweight
monitor app.
When launcher starts - it register itself in the monitor app, before good exit
it unregisters itself, on crash monitor restarts the launcher with needed
modules.
Actually, maybe the idea is not so bad.
Cheers,
Kuzma
<blockquote>
-M
On Tue, Nov 19, 2013 at 2:11 PM, Kuzma Shapran < leaf.on.w...@gmail.com >
wrote:
<blockquote>
I've just had a weird idea: make every part of DE as libraries and one
application which just runs these parts alone or together:
lxqt-launcher -panel -runner -desktop -whatever
Cheers,
Kuzma
On 12 November 2013 22:41, Alexis López Zubieta < azubi...@estudiantes.uci.cu >
wrote:
<blockquote>
El 12/11/13 09:35, PCMan escribió:
<blockquote>
On Tue, Nov 12, 2013 at 4:58 PM, christ...@surlykke.dk < christ...@surlykke.dk
> wrote:
<blockquote>
2013/11/12 Jerome Leclanche < adys...@gmail.com >
<blockquote>
Yeah you mentioned this before. I'm not a fan of merging the two; the
panel is especially a component users may want to change.
This needs more thoughts but it's a bit too early to care about it
imho. Maybe see what we do in the next 3-6 months and then decide on
the two components.
J. Leclanche
</blockquote>
I'd agree with Jerome. If I understand your mail you can save 6MB, which is
nice for sure but not _that_ much. And in terms of functionality I don't see
the panel and the runner as very closely related. Let's get things working
first. And then, maybe, we can try to figure out how two applications can share
a cache (of icons and such)...
br. Chr.
<blockquote>
On Tue, Nov 12, 2013 at 8:05 AM, PCMan < pcman...@gmail.com > wrote:
> Hello,
> I just did some experiment yesterday.
> On debian, lxde-qt now eats 109 MB of RAM after a cold boot.
> On the same machine, the old lxde gtk+ version only used 85 MB.
> (On archlinux, it uses about 150 - 210 MB depending on the machine.)
> The difference is quite obvious. :-(
> Though 109 MB is good, I think there's room to make it better.
> The most memory hungry programs are pcmanfm-qt, lxqt-panel, and lxqt-runner.
> I already tried to optimize pcmanfm-qt earlier but it's not possible to
> squeeze much from it since the wallpaper is a huge bitmap and must eat some
> RAM.
> Other parts are hard to optimize as well. No obvious memory eater was found
> during the profiling.
> Much RAM was used by the icon pixmap cache, but it's inevitable. Otherwise
> we'll get slow painting.
> The other parts used most RAM were lxqt-panel, and then lxqt-runner.
> I tried to put them together in the same binary, and tested it again.
> If we merge lxqt-panel + lxqt-runner into a single process, the used RAM
> becomes 103 MB after cold boot on the same machine.
> The drawback of this approach is, we cannot have an independent lxqt-runner
> program.
> A simple way to fix this is making lxqt-runner a module - liblxqt-runner,
> and let lxqt-panel load it.
> When a standalone lxqt-runner program is wanted, we can have a simple
> program lxqt-runner which loads the lib. Both lxqt-panel and lxqt-runner
> share the same liblxqt-runner.
> The drawback of this approach is also obvious. To make it a library, the
> compiled code will be PIC, which is more inefficient and less optimized.
> I'm not sure if this will really have impact on perceived performance.
> Some more experiment needs to be done for it.
>
> Any comments?
</blockquote>
</blockquote>
OK, let's make it work first.
Thanks!
</blockquote>
Hello:
PCman, as you, I also did some experiments to merge the different parts of the
desktop such as lxqt-panel, lxqt-runner and even the pcmanfm-qt. My results
tell me that we can save from 2 to 4 mb per application merged so I consider
that this approach should not be dropped. If we make a modular design of each
application we will be able to build then standalone and as module of a big
application. Other problem that I found was that those application mainly the
PcmanFm-qt are a bit unstable when you just put then together. I will keep
working on this approach.
Best wishes
Alexis López Zubieta
Nova Light Development Team
University of Informatics Sciences (Cuba)
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
</blockquote>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
</blockquote>
</blockquote>
</blockquote>
</blockquote>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
