Hi, Before getting into detail I should lead with the fact that on one hand, a program like Glade is complex, more so than most would expect, on the other hand; Glade has never really been a funded project, we've had a couple of brief sponsorships mostly thanks to Murray and Openismus but the bulk of the work has been done years ago in my downtime between contracts. There is still huge potential for Glade to become better and there are also some really nasty bits which desperately need refactoring & re- architecture, this is all however very expensive. On to your proposal... On Fri, 2017-03-03 at 17:16 +0300, LRN wrote: > Yet another report of Glade crashing prompted me to think about a way > to fix > this, as i've experienced something similar. I've also looked at > Glade source > code, and didn't really understand it all that well (which prevented > me from > fixing a bug that i wanted to fix). > > Here's my pitch: take the "preview" functionality (where Glade runs a > separate > process that constructs the UI based on current project) and take it > up to 11. > Base the whole Glade around that idea, and instead of running a live > preview > manually, on request, just have a slave process running all the time, > and have > it do everything with the widgets, the same way a real GTK > application would. > Obviously, it will have to render that into some kind of buffer owned > by Glade, > and there will have to be a protocol to communicate with it, to make > it capable > of receiving input, for example. This would probably require to use > GI more > than it is used already, and baking some of the formerly-Glade > functionality > either into GTK itself, or into the slave process. The instability of Glade is mostly due to two things: a.) Glade's data model is tied to GTK+, which is wrong. This is the single point which is most desperately in need of a refactor. To clarify: Glade has forever relied on GTK+ for the widget hierarchy, while wrapping GladeWidgets around a GtkWidget instance, this means that whenever we do gtk_container_add(parent, child), we have always relied on "gtk_widget_get_parent(child) == parent" to be a TRUE statement. GTK+ is no longer abiding by this rule. Another source of bugs tied to this design problem relates to cut/copy and paste, especially when these copy/paste activities happen on a cross project level (You might have 2 different glade files open and when copying a hierarchy over, we need to make sure that it does not have object property references referring back to the source project you copied from). This design flaw also makes things tightly coupled in a nasty way, untangling this will open the door to better stability and to doing workspace features more cleanly and independently of the data model. b.) As you mention, there is a huge vector of non-mitigable crashes which stem from GTK+ bugs which would never occur under normal usage of GTK+. This include crashes where widgets end up crashing when their properties are explicitly set to their default values, also some side effects generally occur due to GTK+ failing to report properly introspectable default values (often this is the case for derived widgets which do property settings at _init() time without ever overriding the corresponding GParamSpec for their class). So, yes; after years of suffering (b) it has always been desirable to me to run the workspace out of process, pretty much as you suggest, but without gutting the workspace and it's features or potential features; the way a user can interact with widgets in the workspace, aside from the editor widgets, is Glades greatest opportunity to shine and be useful to the user (we should by now, at _least_ have workspace support for editing text labels directly in the workspace, without ever making the arduous journey all the way to the property editor). I'm pretty certain that reconstructing the workspace UI on every change is a bad idea, though, because then we add some huge complexity in maintaining superfluous UI state between rebuilds (if it were even found to be performant enough). I.e. one example is the size of a widget that is toplevel in the workspace is usually not encoded into the data model, bits and pieces like this would have to be recorded and restored across reconstructions. Now, before we even start considering running an out of process workspace with which we can at least (1) try to reconstruct in the case that the process crashes and (2) forcefully revert the project to the last known working state in cases where (1) fails, we _have_ to address the tight coupling mentioned in (a) above. Doing (a) is not a big deal in the scope of things. I would hazard a guess that as the primary author of Glade, it might take me 2 or 3 weeks of full time work to refactor and hopefully have something more stable and without regressions as a result, perhaps 4 weeks for a competent and driven developer that is already intimately familiar with GObject and GTK+. As I said, in the scope of things this is what I would call "not very much work". On to the next challenge, so we dont want to break the one window UX, back in 2004 when I started working on Glade it had a gimp-like interface with a palette, "widget tree" and workspace all in separate windows, Vincent Geddes spent a lot of work making Glade a one window UX which was a huge improvement (even though we still keep to this day an option to undock things in the 'View' menu). So, running the workspace out of process points back to GtkPlug and GtkSocket, which unfortunately have never gained the required support for Windows and Quarts native OSX platforms. Seeing as there is certainly some prior art, I think firefox is/was able to recover from a crashed browser tab (not sure that's the case anymore as today a browser tab seems to hang the whole app) - there should be a way to implement GtkPlug/GtkSocket in a cross platform way, and an uphill battle to get that functionality upstream into GTK+ proper (seems there has never been much interest in improving those, and considerable desire to even deprecate them). Alternatively, Glade could maintain a dual code path for platforms which do not support GtkPlug/GtkSocket by allowing the workspace to pop up as a separate window on those, or perhaps a half way compromise would be to maintain our own homegrown GtkPlug/GtkSocket in Glade if we can solve the problem on win32 and Quartz, in the absence of willingness to maintain this in GTK+. So yes, in closing, out of process workspace is very interesting for Glade, and the required refactoring in Glade to get there is also very desirable to make Glade more manageable and pay some technical debt, it can be done and the work required to reach the end goal is not much... ... all things told, it's probably _only_ going to take around 3 or 4 months of full time development, assuming you have an expert doing all of this. It's overall the right direction, and a great cost/benefit ratio, it's also a pretty small project: only a hand full of months of full time dedication. Cheers, -Tristan Another thought here is that with an advertised shorter life span for GTK+ major point versions, the project outlined above may also open the door to supporting multiple GTK+ versions in the same application, we would only have to maintain one Glade for GTK+ 2, 3 and 4... so long as we can decouple the data model from GTK+ widgets and run the workspace process against the target GTK+ API/ABI version. > > I think that crashes will be easier to deal with that way, as Glade > won't have > to juggle both widgets and their meta-structure at the same time. > Also, > extending Glade to support new GTK widgets will be easier. > > Also, this might or might not bring some benefits to GtkInspector, > depending on > how much of that code goes into GTK, making it available to > Inspector. > > Does this make sense? Was this already considered during previous > Glade > rewrites? If yes, why was it discarded? Thoughts? > > P.S. This proposal was not well-received on #gtk+, so there's that. > > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
