On Wed, Nov 20, 2013 at 12:49 PM, Kuzma Shapran <leaf.on.w...@gmail.com>wrote:
> 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 ;-)
>
I have exactly the same problems. So I missed some mails frequently. :-(
One additional problems I can figure out with this approach is parallel.
When the components are different processes, they can be started
concurrently.
When they're in the same process, unless we use multi-threading to start
them, they can only be launched sequentially.
However, making the components running in different threads means all
shared resources require proper locks and synchronizations and this can be
complicated.
So, sequential start is more reasonable and easy to implement.
Real profiling is needed to know the impact of loss of paral parallelism.
Cheers!
>
>
>> 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
