Hello,
Is there an introductory article about creating launchers in Sculpt, preferably from the config for a running component? I thought I saw something like that, but I can't seem to find it.
Thanks!
Hello John
On 17.05.22 19:14, John J. Karcher wrote:
Hello,
Is there an introductory article about creating launchers in Sculpt, preferably from the config for a running component? I thought I saw something like that, but I can't seem to find it.
If you have a component running (see /config/managed/deploy), it is relatively easy.
- Copy the whole start node of the component in to a new file (/config/launchers). - replace `start` with `launcher` and remove the name attribute (this is determined by the name of the launcher file). - if it works store it in the persistent config.
Regard, Pirmin
Hello John
On 17.05.22 19:14, John J. Karcher wrote:
Hello,
Is there an introductory article about creating launchers in Sculpt, preferably from the config for a running component? I thought I saw something like that, but I can't seem to find it.
If you have a component running (see /config/managed/deploy), it is relatively easy.
- Copy the whole start node of the component in to a new file (/config/launchers). - replace `start` with `launcher` and remove the name attribute (this is determined by the name of the launcher file). - if it works store it in the persistent config.
Regard, Pirmin
Hello John
On 17.05.22 19:14, John J. Karcher wrote:
Hello,
Is there an introductory article about creating launchers in Sculpt, preferably from the config for a running component? I thought I saw something like that, but I can't seem to find it.
If you have a component running (see /config/managed/deploy), it is relatively easy.
- Copy the whole start node of the component in to a new file (/config/launchers). - replace `start` with `launcher` and remove the name attribute (this is determined by the name of the launcher file). - if it works store it in the persistent config.
Regard, Pirmin
Hello John,
On 5/18/22 08:09, Duss Pirmin wrote:
Hello John
On 17.05.22 19:14, John J. Karcher wrote:
Hello,
Is there an introductory article about creating launchers in Sculpt, preferably from the config for a running component? I thought I saw something like that, but I can't seem to find it.
If you have a component running (see /config/managed/deploy), it is relatively easy.
- Copy the whole start node of the component in to a new file (/config/launchers).
- replace `start` with `launcher` and remove the name attribute (this is
determined by the name of the launcher file).
- if it works store it in the persistent config.
As an addition, you can copy your launcher to:
'<used-file-system>/config/<Sculpt-Version>/launcher/' , for example,
! cp /config/launcher/test /rw/config/22.04/launcher/
when using the system shell.
This way the launchers will be restored to '/config/launcher' upon next usage of the file-system (in case it is persistent). The same goes for the 'deploy' file. In case you want to restore your whole setup upon next usage copy:
/config/managed/deploy to /rw/config/22.04/deploy
Note that you have to update these files with each Sculpt release because the packet versions will change.
Regards,
Sebastian
On 5/18/22 15:39, Sebastian Sumpf wrote:
Hello John,
On 5/18/22 08:09, Duss Pirmin wrote:
Hello John
On 17.05.22 19:14, John J. Karcher wrote:
Hello,
Is there an introductory article about creating launchers in Sculpt, preferably from the config for a running component? I thought I saw something like that, but I can't seem to find it.
If you have a component running (see /config/managed/deploy), it is relatively easy.
- Copy the whole start node of the component in to a new file
(/config/launchers).
- replace `start` with `launcher` and remove the name attribute (this
is determined by the name of the launcher file).
- if it works store it in the persistent config.
As an addition, you can copy your launcher to:
'<used-file-system>/config/<Sculpt-Version>/launcher/' , for example,
! cp /config/launcher/test /rw/config/22.04/launcher/
when using the system shell.
This way the launchers will be restored to '/config/launcher' upon next usage of the file-system (in case it is persistent). The same goes for the 'deploy' file. In case you want to restore your whole setup upon next usage copy:
/config/managed/deploy to /rw/config/22.04/deploy
Note that you have to update these files with each Sculpt release because the packet versions will change.
Thanks Pirmin and Sebastian! I thought it was something like that, but I couldn't remember the details (or where I read it).
This seems like it would be a neat function to add to the Leitzentrale GUI - maybe a "Create Launcher" button inside the Component detail, beside "Restart" and "Remove". ("Edit Config" would probably be nice also.)
Happy Sculpting!
John J. Karcher devuser@alternateapproach.com
Hi John,
This seems like it would be a neat function to add to the Leitzentrale GUI - maybe a "Create Launcher" button inside the Component detail, beside "Restart" and "Remove". ("Edit Config" would probably be nice also.)
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
On 5/19/22 10:13, Norman Feske wrote:
Hi John,
This seems like it would be a neat function to add to the Leitzentrale GUI - maybe a "Create Launcher" button inside the Component detail, beside "Restart" and "Remove". ("Edit Config" would probably be nice also.)
that's a good idea. I wonder, what do you think about the following aspects?
I will be happy to give my thoughts, but I'm still learning and experimenting, so I hope more knowledgeable users give theirs also.
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?
Yes, those are good questions - finding the balance between flexibility and complexity.
Because sometimes we might want to just "save" the current config but other times create a "copy" launcher, my initial idea was to ask for the launcher name, and maybe a checkbox for "copy" vs. "take over". Does that make sense?
Along those lines, is it possible to display in the component detail the name of the launcher it is using, if applicable? (I don't know if that info is readily available or not.) That might help distinguish between the three cases of "create new launcher", "edit running launcher", and "copy launcher".
The "Remove Launcher" option seems like a good idea also.
I'm curious about your thoughts on how much of this you want to incorporate into Leitzentrale, and where you think an external "Launcher Gallery/Editor" tool might make more sense.
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!
Yes, that's exactly what I was thinking also. All that dynamic power is right there, and popping up just the applicable node in the text editor would be really handy.
Thanks!
John J. Karcher devuser@alternateapproach.com
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