IMO, GUI applications should be written as agnostic libraries first and GUIs second. That way, anybody with time, skill, and will, can slap on an alternative UI on top.
Firefox in this example should’ve written a library that allow calling a tab.previous(), updating the internal state, sending events like rerenderStarted, rerenderEnded, navigationStarted, navigationEnded, and so on, that the UI responds to like updating what the back button looks like, the rendered page, and so on.
It would then be possible to have firefox Qt, Gtk, egui, or whatever else kind of frontend and it wouldn’t be required for Gtk4 to somehow interfere in the rendering code. Furthermore, it would allow embedding firefox nearly anywhere. But firefox is legacy at this point and such a change would be monumentally large. It’s just a pity that servo (firefox’s WebEngine successor) does the same thing firefox is doing, making it difficult to embed with tight coupling between UI and everything else.
IMO, GUI applications should be written as agnostic libraries first and GUIs second. That way, anybody with time, skill, and will, can slap on an alternative UI on top.
Firefox in this example should’ve written a library that allow calling a
tab.previous(), updating the internal state, sending events likererenderStarted,rerenderEnded,navigationStarted,navigationEnded, and so on, that the UI responds to like updating what the back button looks like, the rendered page, and so on.It would then be possible to have firefox Qt, Gtk, egui, or whatever else kind of frontend and it wouldn’t be required for Gtk4 to somehow interfere in the rendering code. Furthermore, it would allow embedding firefox nearly anywhere. But firefox is legacy at this point and such a change would be monumentally large. It’s just a pity that servo (firefox’s WebEngine successor) does the same thing firefox is doing, making it difficult to embed with tight coupling between UI and everything else.
Anti Commercial-AI license