Thank you for the encouragement Norman. That gives me determination to deliver on the 'hype' I posted.. and be useful to the community this coming year.
Now that I'm aware of the upcoming "genodians.org" it seems I should have waited before registering at neocities.org
Anyway here's the micro-blog as it is now:
https://tts-genode.neocities.org/genode.html
Will migrate the entries in there to genodians.org when is ready -- looking forward to it yes. More entries are queued up to help "prime the pump" if need be.
We ultimately should strive for a agreed-upon official way. Right now, however, I feel that it's still too early to take informed decisions. So may we take 2019 as the year for desktop experimentation?
I'll try to do my part, fueled by feedback as well. 'Experimentation' is an interesting perspective:
One key ingredient/catalyzer, I believe, is ease of programming: when things take a lot of time and energy, developers get 'shy', overly cautious, think twice before coding.. Discussions heat up as there is more at stake.
When it's easy to come up with an (at least partial) implementation however, the discussion is less abstract as it moves forward supported by quickly-put together concrete examples.
Over time my 'library' of code and framework have reached a point where I can write GUI code very easily and quickly.. Meaning any given project does not have me too worried about it possibly ending up in the trash later.
(as the Jam/MR guys say, "make simple things simple, make complex things manageable")
We'll see how that factors in!
Indeed. However, we have a rough plan to enable features like screenshots and screen recording. Maybe, these are worth considering for the road map?
Considering the conflicting imperatives -- prioritizing security on the one hand, and some quote-unquote "urgency" to enable developers to "show off" on the other hand... Maybe it would make sense to prioritize implementing (a rough version of) the feature, but keep it hidden behind a compile-time flag? There would be a prominent comment near the if-def, "leave this commented out in production!" Just a thought. I can use a digital camera to shoot the screen in the meantime.
Cedric
Hi Cedric,
Anyway here's the micro-blog as it is now:
https://tts-genode.neocities.org/genode.html
Will migrate the entries in there to genodians.org when is ready -- looking forward to it yes. More entries are queued up to help "prime the pump" if need be.
I'm happy that you are on board with genodians.org. :-) Thanks for the link to your blog, which is good read. Let me briefly comment on a few points you raised there.
Regarding your question of native apps vs. ported apps, I share your sentiment of preferring native apps, mostly because they tend to have a smaller footprint and follow the design philosophy of the underlying system. However, at the current stage, we haven't yet found the "Genode way" of GUI applications. It is great that you support my proposed experimentation phase. During this phase we can explore the pros and cons of multiple approaches. I see three approaches in particular.
First, the reuse of the Haiku API is intriguing to me at the surface level (I admittedly don't really know how it looks like under the hood). I like the clean and consistent design language, the efficiency, and the focus on ergonomics.
Second, the use of Qt bears the biggest potential regarding the reuse of existing software. E.g., I'm thinking of the port of Libreoffice to Haiku, which would certainly be unrealistic without Haiku's Qt support. So in this line of thinking, Qt is certainly the quickest path to a practical desktop environment for Genode, accommodating scenarios like the office clerk described by Guido.
Third, I'm quite eager to further explore the potential of multi-component GUI applications where the (complex and fragile) widget rendering is sandboxed and completely isolated from the application logic. The underlying design principle is currently employed be Genode's custom window manager and the menu-view-based applications (i.e., the Leitzentrale of Sculpt). Right now, the implementation of such applications is quite unusual (if not to say awkward). But maybe the "librarization" of init as requested by Ben would make this approach feasible for a broader use? Now that I'm writing this paragraph, I feel that this topic deserves some coverage at genodians.org ;-)
Maybe we even find that a combination of these approaches is beneficial?
Another area of experimentation is the secure exchange of date between applications (copy-and-paste, drag-and-drop).
I'm very curious towards your planned line of work. The prospect of bringing both projects Haiku and Genode together is very cool!
Regarding your remarks about acpica and usb-hid, please don't hesitate to open issues at GitHub so we can discuss the problem (and solution) there.
Considering the conflicting imperatives -- prioritizing security on the one hand, and some quote-unquote "urgency" to enable developers to "show off" on the other hand... Maybe it would make sense to prioritize implementing (a rough version of) the feature, but keep it hidden behind a compile-time flag? There would be a prominent comment near the if-def, "leave this commented out in production!" Just a thought. I can use a digital camera to shoot the screen in the meantime.
As interim solution, I'm using Intel AMT to take screenshots (one can use AMT to connect to another machine via VNC). For obtaining pictures of individual GUI features, I often start a scenario on base-linux (or running Genode in Qemu) and take a screenshot under Linux.
Cheers Norman
On 1/3/19 6:52 AM, Norman Feske wrote:
Hi Cedric,
[snip]
Third, I'm quite eager to further explore the potential of multi-component GUI applications where the (complex and fragile) widget rendering is sandboxed and completely isolated from the application logic. The underlying design principle is currently employed be Genode's custom window manager and the menu-view-based applications (i.e., the Leitzentrale of Sculpt). Right now, the implementation of such applications is quite unusual (if not to say awkward). But maybe the "librarization" of init as requested by Ben would make this approach feasible for a broader use? Now that I'm writing this paragraph, I feel that this topic deserves some coverage at genodians.org ;-)
Yes, please elaborate on the current situation as well as your thoughts on improving it.
Am I correct to infer that this would also make it easier to add different front-ends to the same "application"?
Maybe we even find that a combination of these approaches is beneficial?
Another area of experimentation is the secure exchange of date between applications (copy-and-paste, drag-and-drop).
Please share your thoughts on this also.
For instance, the VirtualBox Guest Additions have a Shared Clipboard feature. I assumed that this might have to be a Qt-only feature, but if there is a system-wide clipboard, that would be much better.
I'm very curious towards your planned line of work. The prospect of bringing both projects Haiku and Genode together is very cool!
I'll be closely following this also!
-- John J. Karcher devuser@alternateapproach.com
Hi John,
Right now, the implementation of such applications is quite unusual (if not to say awkward). But maybe the "librarization" of init as requested by Ben would make this approach feasible for a broader use? Now that I'm writing this paragraph, I feel that this topic deserves some coverage at genodians.org ;-)
Yes, please elaborate on the current situation as well as your thoughts on improving it.
Am I correct to infer that this would also make it easier to add different front-ends to the same "application"?
Yes. The menu-view approach is a pretty radical take of the model-view-controller pattern. There is an almost "galvanic" separation of the view from the application logic because the view lives in a separate component.
Since the relationship between the dialog elements and pixels is local to the view, the view implementation can be easily swapped out.
If you like to experiment with the concept, please have a look at the gems/run/menu_view.run script.
For instance, the VirtualBox Guest Additions have a Shared Clipboard feature. I assumed that this might have to be a Qt-only feature, but if there is a system-wide clipboard, that would be much better.
This is actually already supported by our version of VirtualBox, but Sculpt does not make use of this feature yet.
Cheers Norman
-
John J. Karcher -
Norman Feske -
ttcoder＠netcourrier.com