Hello: PCMan actually, this is "architecture" is my thesis work. I graduated the past month of Informatics Engineering with it. About the things you point out all except for the crash recovery system are already implemented and tested.
There is a main application that I call "core" which handles the loading, activation, deactivation and unloading of modules. This can be configured using profiles such as lxpanel to load modules (pluggins) that you need. The communication between modules is established using a services system in this way one module can use a service provided by other without knowing it, it only must know the service interface. Also as the services are based on common interfaces (abstract c++ classes) they can be exported by D-Bus. I have already ported some of the lxqt components (panel, runner, file manager, notifications daemon and globalshortcuts daemos) to this architecture. It is at https://github.com/MoonLightDE/MoonLightDE So I think that will be a good idea implement this in lxqt, and of course I will be glad to help. I have to say that I'm not alone in this task some friends are helping and even we have an small community of "fans". So if you want to merge our projects it will be great!, but sadly I will no longer see the version 1.0.0 of "MoonLightDE". Also I would like to share with you some ideas respecting the design and behaviour of the desktop. We were working in a new design, I also mentioned this in the list some months ago, take a look at the images at this address http://humanos.uci.cu/2014/03/resultados-de-la-encuesta-para-determinar-la-apariencia-de-moonlight/ I is a merge between the major desktop environments that exist right now, but focusing in simplicity. If you like we can discus this later. Best Eng. Alexis López Zubieta Nova Light Development Team University of Informatics Sciences. El 01/07/14 23:15, PCMan escribió: > On Wed, Jul 2, 2014 at 4:16 AM, Alexis López Zubieta > <azubi...@estudiantes.uci.cu> wrote: >> Hello friends: >> This will be bit long mail, but please take a look a it. >> >> Some time ago we were discussing in this list the possibility of making >> a modular and integrated version of LXDE. For this goal the main >> applications of the desktop, panel, filemanager and daemons, will have >> to be transformed into shared libraries or plugins. >> At that moment this idea was rejected under the argument of stability, a >> crash in a module will produce a general crash in the desktop. >> >> Despite of that, I keep working on it, inspired by the though that >> limiting the functionality of the applications were not enough to grant >> the lightweightness of our system. With the pass of time new >> functionalities will be required, and new applications will be added in >> result the overall resource consumption will be increased. >> >> So, how we can reduce the impact in system resource consumption due the >> addition of new functionalities in order to grant that the future >> versions of lxqt will keep lightweight ? >> >> The answer to this question is: interoperability. The exchange of data >> and funcitonalities. >> >> Usually this is achieved using IPC such as D-BUS or "shared memory" but, >> are they compatible with our context were the resources consumption must >> be keep at minimum? >> >> Let's take a look at D-Bus. This mechanism requires the serialization of >> the data to be transmitted so you will never use it to share by example >> the icons of the applications between the panel-menu, the file-manager >> and the runner instead of that every applications gets it's own copy. >> >> In other hand "shared memory" allows us to share such kind of data >> without replicating it but doesn't allows the call of remote procedures. >> So our applications will have to re-implement the procedures related to >> the data manipulation or delegate then into a shared library as >> libmenu-cache does. >> >> As you know, the interoperability between applications in LXDE right now >> is limited to the essential parts but, what if we were able to share >> every single bit with out using dbus, "shared memory" or other similar IPC? >> >> In this case there will be not duplicated data or procedure in our >> system. There will be only one instance of each Icon, one implementation >> of the "execute_deatached" procedure, one QT main cycle (I invite you to >> measure how much memory consumes a qt application without >> functionalities), one logging service, etc. So we will be able to reduce >> the resources consumption to the minimum. >> >> This could be achieved by doing what was mentioned at the beginning of >> this mail, the integration of the main components of our desktop >> environment as pluggings into a single application. >> >> After this explication I would like to present the implementation of >> such idea, It was named MoonLightDE, and it aims to be a lightweight and >> fully integrated DE with out space for data or procedures duplication. >> >> Basically it is formed by a core wish implements a service oriented >> architecture in order to ease the communication between components, >> heavily inspired by the eclipse architecture, and a set of modules wish >> provides the functionalities. The components of LxQT were take as start >> point for the development, right now are transformed into modules >> (plugins) the panel, the file manager, the runner, the >> globalshortcuts-daemon and the notification daemon. So we have something >> functional. >> >> It is available at: >> https://github.com/MoonLightDE/MoonLightDE >> If interested take a look at the wiki for build instructions. >> >> I would like to invite you to take a look at it and if you can do some >> benchmarking. Thanks for your time. >> >> Best >> Eng. Alexis López Zubieta >> Nova Light Development Team >> University of Informatics Sciences. > > This is always what I have in my mind and researching the possibility > of doing this is on my TODO list. > In the past, I have tried merging runner and panel and noted that we > can chop down the memory usage. > I really liked the idea and wanted to do it, but some of other project > members did not agree. > However, I have a plan to solve this by supporting both ways at the same time. > The following points are my thoughts on this issue. > > 1. Add a new process called "lxqt-shell" > 2. Make major modules (desktop icons, panel, runner, ...) loadable plugins. > 3. Let lxqt-shell process load all of the plugins so they all run in > the same process. > 4. If a plugin crashes, lxqt-shell will crash, too, but lxqt-session > can re-start the lxqt-shell process again. This is annoying and might > cause flickering of the screen, but this normally will not cause loss > of data. The crash of the panel basically won't affect the documents > you're editing or the webpage you're browsing. > 5. For those who don't want the plugin-based architecture, they can > still run each of the component separately. For example, the command > lxqt-runner is a thin wrapper for its plugin and will load the plugin > in a separate process. So you can still run these tools as separate > processes if needed. > 6. Or, lxqt-runner can detect if lxqt-shell is running. If it's > running, it send a dbus message to lxqt-shell and ask it to load the > runner plugin. Otherwise, it loads the plugin itself and run in its > own process. > 7. Since Qt5, compiling to PIC code using is mandatory so making them > plugins becomes even easier. Plugins require PIC code, which could > generate less efficient code. Since we're forced to use PIC now, not > making them plugins won't save you anything. > > The above are about implementation details. This plugin-based > architecture not only can reduce memory usage significantly, it also > speed up the startup time. If all of the components are running in the > same process, name resolution when dynamically linking only takes > place once and no more relocation is needed. The icon cache is shared, > too. This can speed the startup a lot. Hence I'm all for it. > Cheers! >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft
_______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
