Launchers 101

[Martin Stein]

May I jump into this discussion with a suggestion?

I very much appreciate the idea of creating launchers more easily.
However, I rather imagened to have the "Add Launcher" button in the
dialog where I determine the routes for a new component. As an
alternative beside the button "Add Component". This would allow for
creating launchers without being forced to actually start the component,
which feels more natural to me. Now, when I set up a Sculpt I tend to
start each component that needs a launcher and remove it immediately
after having created the launcher.

Furthermore, I would say that Sculpt should check whether the name
already exists when adding a launcher or a component and simply
circumvent any complicated interactions by simply creating a new unique
name (recall_fs_1, recall_fs_2, etc.). I don't feel the need for
conveniently updating or removing launchers because I could simply
remove my old launcher via the "Files" tab and then go and create a new
one via the "+" menu.

However, I think it would be nice to be able to rename a launcher
through the "Files" tab.

What do you think?

Cheers,
Martin

On 19.05.22 16:13, Norman Feske wrote:
> that's a good idea. I wonder, what do you think about the following aspects?
> 
> - When creating a launcher for a deployed component, should the
>   start node of the component in managed/deploy automatically be
>   changed to refer to the new launcher?
> 
> - What should happen when deploying a new component that has the
>   same name as an existing launcher? If this is allowed - like today -
>   the start node of the deployed component would differ from the
>   existing launcher. Would Sculpt need to detect this situation,
>   offering an "update launcher" button?
> 
> - Should the reverse operation be supported via a "remove launcher"
>   button - removing a launcher for running component, turning this
>   component into a regular start node of the deploy config?
> 
> Intuitively, I tend to answer those questions with yes to foster the
> consistency of the feature. On the downside, implementing those corner
> cases with their possible intermediate states is not quite easy.
> 
> What do you think?
> 
> I also like your idea to make the config of a component easily
> customizable without manually diving into the config/deploy or
> config/launcher files. Sculpt's underlying mechanisms actually support
> that today: When adding a customized <config> node inside a <start> node
> in config/deploy, the component observes a config update.
> 
> For example, if you have the pkg/sticks_blue_backdrop deployed (and
> copied /config/managed/deploy to /config/deploy), you can add the
> following snippet to the start node in /config/deploy:
> 
>   <config>
>     <libc/>
>     <vfs> <rom name="genode_logo.png"/> </vfs>
>     <fill color="#223344" />
>     <image png="genode_logo.png" anchor="bottom_right" alpha="150"
>                                  xpos="-20" ypos="-20" />
>   </config>
> 
> You can even change all those attributes on the fly and the backdrop
> adjusts. This way, the backdrop can easily be customized without
> touching any depot content. The machinery it there. But I admit that the
> process is not really intuitive. ;-)
> 
> A button that takes the <config> node from /config/managed/runtime to
> /config/managed/deploy and shows the config in a text editor for live
> editing - that would be quite inviting!
> 
> Cheers
> 
> Norman
>