Hi,
for testing in the Gems section. Specifically, I have reviewed the "mixer_gui_qt_test" program as a practical example of Qt5.
Afterwards, I decided to add a webview to this program for further practice.
I don't have experience with Qt but maybe I can get the ball rolling by suggesting general ideas:
<config> <vfs> <dir name="dev"> <log/> <inline name="rtc">2018-01-01 00:01</inline> </dir> <dir name="pipe"> <pipe/> </dir> <tar name="qt5_dejavusans.tar"/> <tar name="qt5_libqgenode.tar"/> <tar name="qt5_webengine_qml.tar"/> <tar name="qt5_webengine_resources.tar"/> <tar name="qt5_webengine_translations.tar"/> </vfs> <libc stdout="/dev/log" stderr="/dev/log" pipe="/pipe" rtc="/dev/rtc"/> </config>
However, after building the program and executing it, I encountered the following error when using the QWebEngineView class functions:
[init -> webview_test] Error: no plugin found for read(-1)
Do you have the information as to exactly where in the code the error is issued (QWebEngineView..) ?
If not, these basic techniques come to mind:
1) the mixer_qui_qt code references this file path: "/config/mixer.config" But that path does not seem to be configured in the vfs config above. Is it handled by one of the .tar files ? Better run a comparison of the original vfs config and your variant of it, side by side, re. mixer.config and other paths.
2) if it was me I would go at it the "brutalist" way :-) and add line by line tracing in main.cpp. That is to say, copy-paste the Genode::log("start") line after qpa_init(), changing the log text to "init done", and so on and so forth until I'd find out which routine is responsible for the failed read().
3) best would be to use the debugger ("monitor") to find out exactly which part of the code is involved ; I don't know if the monitor is currently able to set a 'breakpoint' (in this case, the breakpoint would be set in or near read()), I think that's planned for the future
Or you could recompile the Genode libc "vfs plugin" to augment the "no plugin found for read(-1)" error message with a call to Genode::backtrace(), which would be functionally similar to a debugger hitting a breakpoint and displaying the information I guess
Also, rather than build your scenario based on mixer_qt_gui, maybe it could be based on Falkon or (preferably) a more simple scenario that uses QWebEngineView ?
HTH a bit,
Cédric