Glade architecture change

2017-03-03 Thread LRN
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 "pre

Re: Glade architecture change

2017-03-03 Thread Michael Torrie
On 03/03/2017 07:16 AM, LRN wrote: > Does this make sense? Was this already considered during previous Glade > rewrites? If yes, why was it discarded? Thoughts? I'm not sure GTK+'s architecture would even allow glade to operate in a manner like you suggest. Besides that, Glade's instability doesn

Re: Glade architecture change

2017-03-03 Thread LRN
On 04.03.2017 6:20, Michael Torrie wrote: > On 03/03/2017 07:16 AM, LRN wrote: >> Does this make sense? Was this already considered during previous Glade >> rewrites? If yes, why was it discarded? Thoughts? > > I'm not sure GTK+'s architecture would even allow glade to operate in a > manner like y

Re: Glade architecture change

2017-03-03 Thread Tristan Van Berkom
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

Re: Glade architecture change

2017-03-03 Thread Tristan Van Berkom
On Sat, 2017-03-04 at 07:11 +0300, LRN wrote: > On 04.03.2017 6:20, Michael Torrie wrote: [...] > No, actually, forget preview. It was a mistake to bring it up, as > people get > the wrong idea. > My limited understanding of how Glade currently works is that it does > some OOP > magic to fool GTK w