On 20 November 2013 17:37, Alexis Lopez Zubieta <azubi...@estudiantes.uci.cu
> wrote:
> Hello people:
>
> Did you ever read my emails?
>
In fact, I have almost hundred unread emails in my inbox. Your message
quite can be there as well. Some day I hope to read them all ;-)
> 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)
>
>
> ------------------------------
> *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:
>>
>>>
>>>
>>> On 20 November 2013 11:41, Mark Deneen <mdeneen+l...@gmail.com> wrote:
>>>
>>>> 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
>>>
>>>
>>>>
>>>> -M
>>>>
>>>>
>>>> On Tue, Nov 19, 2013 at 2:11 PM, Kuzma Shapran
>>>> <leaf.on.w...@gmail.com>wrote:
>>>>
>>>>> 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:
>>>>>
>>>>>> El 12/11/13 09:35, PCMan escribió:
>>>>>>
>>>>>> On Tue, Nov 12, 2013 at 4:58 PM, christ...@surlykke.dk <
>>>>>> christ...@surlykke.dk> wrote:
>>>>>>
>>>>>>>
>>>>>>> 2013/11/12 Jerome Leclanche <adys...@gmail.com>
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>> OK, let's make it work first.
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>
>
------------------------------------------------------------------------------
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
