This repository has been archived by the owner on Sep 18, 2019. It is now read-only.
Handle content load errors #1
Assignees
Labels
Comments
aperezdc
added a commit
that referenced
this issue
May 14, 2018
This adds a new --platform/-P command line flag which allows specifying the name of the platform plug-in to be loaded. If none is specified, a fall-back to the default WPE backend is used, which allows usage of e.g. WPEBackend-rdk and others. This also adds a few g_debug() calls sprinkled here and there. This makes it easier to figure out which WPE backend is being used, and contributes a bit to fix issue #1
aperezdc
added a commit
that referenced
this issue
May 14, 2018
This adds a new --platform/-P command line flag which allows specifying the name of the platform plug-in to be loaded. If none is specified, a fall-back to the default WPE backend is used, which allows usage of e.g. WPEBackend-rdk and others. This also adds a few g_debug() calls sprinkled here and there. This makes it easier to figure out which WPE backend is being used, and contributes a bit to fix issue #1
aperezdc
added a commit
that referenced
this issue
Jul 20, 2018
This improves the FDO platform plug-in by: - Making the init_* functions return errors, which get bubbled up from cog_platform_setup(). This includes more informative error strings, plus fetching and reporting EGL errors as well. - The added error handling alone removes many assertions, which is quite a good improvement when it comes to knowing what went South during initialization. Also this means that other fallbacks can be used on failure (e.g. a Wayland compositor is not available), instead of aborting the process miserably with an assertion message. - The clear_egl(), destroy_window(), and clear_input() functions are idempotent, and safe to use on partially initialized data. This allows using them to free resources at different stages of initialization in the event of a failure. - Wherever possible, g_clear_pointer() is used for brevity and clarity. While there are still many assertions remaining, most of them are quite unlikely of being ever hit, so this is a good stab at mostly fixing issue #1 — reviewing the remaining assertions later on would not hurt, though.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently if some page load fails, there is no way of knowing what went wrong — or to know that something went wrong. Dinghy should provide a simple load error handling implementation in
libdinghycoreand use it by default.The text was updated successfully, but these errors were encountered: