cli_monitor vs launcher vs launchpad

[Nobody III]

Here's my work on a desktop environment for Genode:
https://github.com/NobodyIII/genode-desktop-environment

So far, I have a working file manager and text editor. Feel free to use and
modify my code.

On Fri, Aug 18, 2017 at 7:58 AM, Norman Feske <norman.feske at ...1...>
wrote:

> Hi Jörg,
>
> first, your understanding of the different components is correct. Thank
> for taking the time for the thorough investigation of the existing
> components.
>
> > What I see between the cli_monitor/launcher and launchpad approach, that
> > the configuration of the subsystems is different. But is there even more
> > differences ?
>
> The launchpad and qt_launchpad were intended as quick demos, not a
> serious solutions. In fact, launchpad was one of the very first programs
> developed for Genode - just to showcase the dynamic creation/destruction
> of subsystems. CLI monitor is similar, but uses a textual interface.
>
> Design-wise the disadvantage of the launchpad as well as CLI monitor
> (and even more so qt_launchpad) is the fact that the component is
> potentially complex (as it implements a UI) while being part of the TCB
> of each launched subsystems.
>
> With the launcher, I explored the idea to separate the complex parts
> (i.e., the widget rendering) into a separate sandboxed component called
> menu view. This helps to significantly reduce the complexity of the
> launcher - and thereby the TCB of the launched subsystems. So
> software-design wise, the launcher is much more advanced.
>
> However, all these solutions share one problem that holds them back for
> general-purpose scenarios: They can start and stop subsystems but do not
> allow the user to define any interaction between the subsystems. It is
> not possible to dynamically launch a new service to be used by another
> subsystem.
>
> To overcome this limitation, I am currently investigating the use of a
> dynamic init instance as the host for subsystems. With this approach,
> the launcher merely generates configurations for the init instance and
> consumes reports generated by init. It goes without saying that the
> lessons learned from the menu-view approach can be applied in this
> scenario as well. Please refer to a previous discussion [1] that we had
> on the list earlier this year.
>
> [1] https://sourceforge.net/p/genode/mailman/message/35787965/
>
> > May I asked, what are the future plans of these "launchers"?
> > Cli_monitor is in the OS repo and sounds like the API is what I should
> use
> > to implement some "own" launchers.
> > Launch app in gems repo, as what I understand from the email from Norman
> > (see Friday, 4. August 2017 11:56:38 CEST from Norman Feske) this is
> > outdated.
> > Launchpad is in the demo repo and what I see in the git commit history,
> > this is also the older approach to "launch" subsystems in genode, or?
>
> The launchpad is meant to stay as a quick-start example for exploring
> Genode. However, the other launchers will eventually be replaced by the
> dynamic init approach, once it is there.
>
> > Here some background information, why I asked...
> > I will use genode as a desktop system and for such a use case I need
> > something to launch applications. I notice, that genode is currently
> > implementing a package management and it sounds like for me, in the
> > future I need a launcher that are flexible enough to start an application
> > after I installed a package in genode :-) ... but step by step.
>
> I am currently working in the same direction. If you are interested to
> follow my work, you may have a look at the corresponding branch [2]. In
> my opinion, two particular interesting bits are the depot-query scenario
> [3] and the dynamic-drivers subsystem [4]. Both facilitate the dynamic
> init approach.
>
> [2] https://github.com/nfeske/genode/commits/nitro
> [3]
> https://github.com/nfeske/genode/commit/cc2b7935fbdbe0bd3b342495bcc9d1
> da36e61f55
> [4]
> https://github.com/nfeske/genode/commit/8046e4d2be50c183ad7ad3ba6e68d6
> e0a7240644
>
> But as a word of caution, this is work in progress. ;-)
>
> Cheers
> Norman
>
> --
> Dr.-Ing. Norman Feske
> Genode Labs
>
> http://www.genode-labs.com · http://genode.org
>
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20170818/e640d64b/attachment.html>