Hi Norman,
that kind of small-to-medium
size Be ports to Genode is quite easy now that most pieces of the Be
puzzle are in place.
The screenshot nicely shows how far your work has come by now. Speaking of the porting of Be applications, I wonder how Goa could be applicable in these cases? Should we succeed to eventually bridge the gap between your customized version of Genode (xattr) and the regular Sculpt OS while fostering the use of Goa for such porting efforts, developers who enjoy casual porting work may become able to join the fun, building upon your H/o/G layer as a library.
Was hoping you'd suggest so! This could be mutually beneficial. This morning I'm pushing a series of commits to chiselapp with a couple of simple apps/applets (a desktop calculator...) to get our feet wet, should we proceed. One of the commits hides the call to xattr-patched-Genode vfs behind an #ifdef. When running the test suite I see that this breaks only what it is supposed to break and the rest of the test-suite is in the green, and the applets still run fine.
I'm going to open a ticket in the appropriate place (probably genode-world ?) with a possible game plan, titled "Goa: add support for Jam and h/o/g ?". Anyone who is tickled curious by that can pick up on it any time they like, I'll be there.
Once the initial hurdles are overcome, now that I have a bit more time on my hands I'd be able to spend time 'scouting and porting', i.e. looking for apps (IRC client ? utilities ?) that don't require the whole Be shebang with xattr et al but would still be useful additions to the Genode depot and useful to the community.
(and one could imagine a third step in the mid to long term aiming at getting access to the remainder of Be apps : maybe the xattr dependancy should be moved to a "file system add-on", just like the implementation for socket() currently resides in vfs_lxip.lib.so, if doing so resolves the filedesc-to-file-path-mapping-is-Private-access-only conundrum ?)
But Genode currently looks like it could handle an awful lot of part #2 --
provided I port the necessary software of course.
Wow! The stars seem to be aligning. :-) With that I mean that my personal ambition to streamline the use of Sculpt OS on the desktop will hopefully benefit your ambition. Since you have integrated Genode's depot/deploy mechanism now, you can finally draw on the full potential of our community (given the increasing arsenal of delightful packages maintained by individuals). Vice versa, I'd be thrilled to be able to fetch an index of nice Be applications from your depot one day.
Right now I'm in a bit of a bind for Goa : there is so far marginal Be support for 'expect' and 'tcl', which I understand are needed by Goa for building, packaging, and maintaining the depot. So I'd need to team up with someone on Linux (where those tools can be safely taken for granted) and let them publish the packages, do the Goa legwork at the end of the journey, after I've done the C++ and Jam porting work.
But I'm not giving up on being a "first class citizen" so to speak, some day I'll run all those tools myself, either in a VM hosted on Genode or in Genode itself ^^.
The discoverability remains unaddressed. The existing "components overview" [1] does not do justice to the current (and emerging) situation where more and more Genode software resides outside our central repository. Maybe a community-managed plain list of links to projects (be it in the form of Goa projects or components hosted at the world repository or in other forms) would be good start? Still, someone would need to assert the responsibility to host and curate such a list.
That list's a good case in point : it does not mention Falkon or Morph ;-) Just thinking off the top of my head : what if Genodians.org could contribute to the discoverability ? After all, it is to HTML documents what the depot is to .tgz packages : a decentralized aggregation. That is to say, multiple providers agree to publish their contents (html or tgz) in a selected room of the "mothership". Well, more so for genodians article which all share the same base URL. But that's the point indeed :
What if people with a repo decided to also create a genodians profile (if not already done), publish an article in there titled "My Depot Packages (Index)" or such, and used the editability feature ? If I'm not mistaken, a page published on Genodians can be edited and modified ad infinitum after its initial publication. So there'd be a "My Packages" page maintained by the official Genode Labs account, one by cproc, and so on. There could even be a special-handling of those pages, where they can be aggregated all-in-one by clicking a special link (currently if you click a particular author you get an aggregation of their articles, so something orthogonal to that, where you select a theme and get an aggregation of the one post of each author that shares that title/theme).
That would immediately help with discoverability for the "power user" types (and even the public at large might find it helpful as is, or if later augmented with screenshots and the like... but you'll probably want to wait until it is "worth it" investing that kind of time).
Even if each page was just HTML code generated automatically from the XML index file of each repo/author (i.e. no further work after the initial time invested in writing the generating scripts), I could see that providing big discoverability benefits -- provided every depot creator plays ball and creates a genodians account with an "My Index" page invoking that script.
Or.... use the "wiki" feature of GitHub ? That is, each dev maintains a wiki. On the other hand, on Genodians all "index" style articles would be close to each other, easily accessible in sequence, now sure how to produce the same effect on github (and is it possible to run scripts on wikis ?)
By contrast, a one-stop-shop centralized page with a curated list has more potential for user-friendlyness than a decentralized one, but requires solving responsibility/times issues indeed.
- same thing with (if I understand correctly) creating a
"nitpicker_primitives.lib.so"
that can be re-used by other components : color me curious and
interested.
The foundational work is already done and found its way into the 23.11 release [2] but I deliberately don't overly advertise it to avoid wrong expectations. However, if you are curious about the use of this approach, you may risk a look at gems/src/app/sculpt_manager/ and the view/ sub directory in particular. Over the next year, I plan to successively complement the API with the features needed for more general use. One key feature will be the ability to integrate existing nitpicker clients into applications (similar to xembed), thereby
At a glance, the wording sounds familiar to me, like the "Replicants" add-ons of the Be API.
clearing the path to augment existing full-screen applications (think of mupdf or avplay or VMMs) with UI controls. I think that this idea will fit Genode's capability-based component architecture like a glove.
Was curious of what Dialog looks like for an API 'end-user' like me so I took a look at test/main.cc, It's out of the beaten path indeed ^^. Though many of the paradigms will be familiar to all UI coders, like implementing a click() hook for when a button is invoked. While exploring the Depot last month I noticed some components are already making use of the dialog package if I'm not mistaken (like the power management ones), planning to try these packages out.
Anyhow, making µpdf or AVPlay use that new lightweight UI instead of qt5 is something I'm looking forward to. Will nudge me into making them part of my 'distro'. Consider yourself gently "nudged" forward ;-)
Thank you again for the captivating write-up.
All the best!
And all the best to you and your team of fellow ass-kickers, if I can be so bold :-)
Cedric
P.S. Also curious to learn more about that new Ge/Linux project discussed yesterday. The teaser video looks good.