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 < [email protected]> 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 > <[email protected]> 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 : [email protected] > > Unsubscribe : https://launchpad.net/~gtg-contributors > > More help : https://help.launchpad.net/ListHelp > > > > -- > Bertrand Rousseau > > _______________________________________________ > Mailing list: https://launchpad.net/~gtg-contributors > Post to : [email protected] > Unsubscribe : https://launchpad.net/~gtg-contributors > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
