gtg-contributors team mailing list archive

[Steve Scheel <nmu.sscheel@xxxxxxxxx>]

Bertrand, I have noticed that it is somewhat divided between the two
classes, but if I think we could split the TaskEditor into a model where
the Task class itself is the model, with a TaskEditorView class and a
TaskEditorController class (names can be changed if needed, of course),
with the TaskView class simply being a customized widget to do our bidding.
I will start looking through the task class itself to make sure this is
possible, but I think that could lead to a good solution.

On the DBus sidenote, I must say that I have not really messed with DBus,
but I have looked at some tutorials on how it works and it may very well be
possible to make that work, but I will have to research it a little better
over the weekend to see what I can come up with.

On Fri, May 18, 2012 at 4:41 AM, Bertrand Rousseau <
bertrand.rousseau@xxxxxxxxx> wrote:

> Hi Steve,
>
> The present implementation is already somewhat divided between a view
> (TaskView) and a controller (TaskEditor), the text model being also
> mostly burried in the TaskView widget. However, I the clear
> identification of who's doing what is not clear in this
> implementation. Moreover, we don't have a clean "task" model (Title,
> tags, subtask list, etc.) , we merely try to force a specific text
> structure in the generic text model, which lead to a poor API.
>
> So, I guess if you can manage a clean MVC architecture with a nice
> task model and API, it would be great!
>
> On a side note: it would be also interesting to think the editor as a
> standalone component, that would communicate with GTG through DBUS,
> but this can be quite a lot of work to make it work, so feel free to
> ignore. I just mention it for the record.
>
> Bertrand
>
> On Fri, May 18, 2012 at 8:55 AM, Izidor Matušov
> <izidor.matusov@xxxxxxxxx> wrote:
> >> The more I think about how to make the Task Editor easier to maintain, I
> >> was wondering what everyone thinks about using a model-view-controller
> >> type architecture in the rewriting of it? To me this would benefit us
> >> greatly in the fact that all the code will be split up into smaller
> >> pieces, which will make everything easier to read and find bugs. This
> >> will also help in refactoring easier down the line because when a new
> >> GTK+ version comes out and GTG decides to move to that version, we don't
> >> have to rewrite the entire editor, we can just plug our controller with
> >> the new user interface. What does everyone else think about this?
> >
> >
> > Great idea! I think it is must. Could you describe more how it should
> work
> > for our editor? I have clear image of using MVC for web apps. I am eager
> to
> > hear more details :)
> >
> > Izidor
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~gtg-contributors
> > Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~gtg-contributors
> > More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> Bertrand Rousseau
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors
> More help   : https://help.launchpad.net/ListHelp
>