On Tue, Nov 30, 2010 at 09:12:02AM -0800, [email protected] wrote: > Hello, > On Mon, Nov 29, 2010 at 6:55 AM, Lionel Dricot <[email protected]> wrote: > > I'm with Bertrand ATM, discussing how to get GTG out of my shit. > > > > With Bertrand, we came to the following proposition for you guys: > > > > Given that: > > A) it looks that liblarch is, itself, a good thing > > B) our bug are coming from liblarch-gtk (because gtk is stateful when it > > comes to its TreeModel) > > > > We propose to abandon the idea of a direct TreeModel/Liblarch > > interaction. Instead, liblarch-gtk will maintain a gtk.TreeStore that > > will be in sync with Liblarch.ViewTree. > > That's exactly what I was writing a few days ago, just to see if it > was feasible. > It seems pretty straightforward, and we don't need to deal with signals at > all. > Plus, adding the ability to remember subtask ordering seems also easy. > I've sketched a multithreaded example in [0], in case you want to take a look. > > By the way, since we don't need to write all the methods required by > the gtk interface anymore, > we can also simplify liblarch a lot (which might be good for maintainance).
I like the sound of all of this. Fwiw, I've been finding that the filters stuff works amazingly well through gtcli using the dbus interface. It's really quick, reasonably easy to extend with new filters, and has been working quite reliably for me. >From this experience, I've also concluded that the problems seem to be in the gtk layer, and that decoupling them would probably alleviate a lot of problems. One other idle thought I've had... What if the UI was built atop dbus api calls, with the backend running as a service? Bryce _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
