gtg-contributors team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Tue, Nov 30, 2010 at 09:12:02AM -0800, invernizzi.l@xxxxxxxxx wrote:
> Hello,
> On Mon, Nov 29, 2010 at 6:55 AM, Lionel Dricot <ploum@xxxxxxxxx> 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