lxqt / lxqt

Checkout all LXQt components at once by using git submodule. Discussions, Wiki and general issues are here.
https://lxqt-project.org
1.62k stars 131 forks source link

Experiment with single-process + loadable module architecture #225

Open PCMan opened 10 years ago

PCMan commented 10 years ago

Make the main components loadable modules and load them into the main process. This is what MoonLightDE is doing so cooperation is possible.

maverick74 commented 8 years ago

Hi... sorry to use this method of contact but, since you too were experimenting whit it... any news on this area?

paulolieuthier commented 8 years ago

@maverick74 I don't think there has been any advance with this, apart from what the MoonLightDE guys have done (which is now sadly more than one year old).

maverick74 commented 8 years ago

@paulolieuthier I knew Alexis does not have time to continue his work on this, but i was hopping someone had picked it up... i really thought this would be a great improvement to LXQt.

it's sad such a nice idea is ending up in the trashcan...

paulolieuthier commented 8 years ago

That's because we don't have enough manpower. Anyway, this idea, although nice, has its downsides.

maverick74 commented 8 years ago

Out of curiosity (since i'm not an expert), what downsides are you referring to?  -----Original Message-----From: notifications@github.comSent: Wed, 24 Feb 2016 18:29:55 -0800To: lxqt@noreply.github.comSubject: Re: [lxqt] Experiment with single-process + loadable module architecture (#225)That's because we don't have enough manpower. Anyway, this idea, although nice, has its downsides.

—Reply to this email directly or view it on GitHub.

Free 3D Earth Screensaver Watch the Earth right on your desktop! Check it out at www.inbox.com/earth

paulolieuthier commented 8 years ago

I may be wrong, but two things that come to my mind are: some users want to use only some components of LXQt, not all, and a crash in a component code would crash the whole DE.

maverick74 commented 8 years ago

I actually thought that this approach would do exactly the opposite from that. In another words: i thought it would load the modules "on demand" (only when a user needed them), and that, if a module crash, it would prevent that same crash from expand to the rest of the DE.

This only shows that my understanding is actually limited in this field...

Thanks for clarifying that for me. :)

-----Original Message----- From: notifications@github.com Sent: Thu, 25 Feb 2016 17:29:32 -0800 To: lxqt@noreply.github.com Subject: Re: [lxqt] Experiment with single-process + loadable module architecture (#225)

I may be wrong, but two things that come to my mind are: some users want to use only some components of LXQt, not all, and a crash in a component code would crash the whole DE.

—

Reply to this email directly or view it on GitHub [https://github.com/lxde/lxqt/issues/225#issuecomment-189071936].


Can't remember your password? Do you need a strong and secure password? Use Password manager! It stores your passwords & protects your account. Check it out at http://mysecurelogon.com/password-manager

azubieta commented 8 years ago

Hello Guys! Is Alexis from MoonlightDE. First I would like to apologize with all of you guys, for been more than a year with out putting any new code on MoonlightDE, my company decided that it's no longer a priority so I was assigned another task which is taking a big part of my time.

Now let's talk about modules, @paulolieuthier you are right, as we are using c/c++ a crash in a component would cause the whole DE to came down. Also there is other downside that show up while working on it. In order to allow the loading, unloading, tracking and communication between modules it's require a certain amount of "glue code" that sometimes can be even larger than the functionality provided by the module, and that is not nice because the idea is to "keep it simple" in order to ease maintenance and development.

But the idea of integrating the different parts of LxDE/QT in order to gain performance still is valid and worth the pain. After some time and looking the idea from the outside I get to the conclusion that making everything a module and load it on run time is nothing more than over-design, because at the end there would be more glue code than functional code.

So is possible to improve the overall DE performance, reduce it's memory footprint and make it customizable? The answer is yes ! We actually can achieve this by making instead of dynamic modules, static modules and you can configure your DE at build time.

I will continue on this latter, in the mean time let your thoughts down

Best