gtg-contributors team mailing list archive

[Steve Scheel <nmu.sscheel@xxxxxxxxx>]

Well, it would be great to augment the current class. But if it would be of
better benefit I could also write a model class that would simply interface
with the task class, because both ways work. My main worry about augmenting
too much of the way it works is that it could break tasks created and saved
with the old structure. I can definitely try to come up with a prototype
structure for a new task structure though and see what everyone thinks.

On the note of how the stock TextView widget deals with text, I'm thinking
maybe there can be a buffer that holds onto changes and every so often,
when it detects that there has been a change, it can change what is needed
to fit the task model, so as to limit the amount of times it has to go back
and forth between that. The buffer could also help out with adding an undo
function to the editor.

Finally, with the goal of more interfaces, I just think that it would be a
great benefit to be able to only have to deal with GUI code when a new
interface is needed (web being very interesting and one I didn't think of,
but also when GTK makes a major upgrade again came to mind), and so long as
the interface is robust enough we won't have any issues, but I agree that
it will take careful planning.

On Mon, May 21, 2012 at 6:45 PM, Bertrand Rousseau <
bertrand.rousseau@xxxxxxxxx> wrote:

> So, if I get this right, you propose to augment the current task
> class? I guess that what you want to do is to handle task content
> modifications through a better interface than the current. That seems
> indeed a good idea, since at present, I think we basically only
> perform string operations on XML, which is a bit hackish. Task content
> manipulation would certainly greatly benefit from a stronger
> definition of its structure, enforced through a dedicated interface.
> Maybe you should prototype this a bit. Maybe you should also document
> and propose a definition of a task structure, that will certainly help
> you.
>
> Now, note that the GTK stock TextView widget (upon which we built the
> TaskView widget) also comes with its builtin model of a text that the
> programmer has to manipulate to control the text display and edition.
> If I get this right, your approach would mean that you will have to
> translate from the GTG task model to the GTK editor text model back
> and forth whenever something is displayed/edited. Is that what you
> have in mind? (it's maybe not an issue, I'm just pointing this out)
>
> If what you want to do is enable a better multi-view support for GTG,
> maybe you should also imagine interaction scenarios with other
> potential clients (web client being the most interesting one after the
> GTK one), just to check that your approach indeed delivers the
> targeted result.
>
> All this might not be a simple thing to do. So be careful and plan
> your actions. I advise you to take the time to discuss this matter
> with your mentor to decide what to do and how to organize the work.
>
> Bertrand
>
> On Mon, May 21, 2012 at 3:29 PM, Steve Scheel <nmu.sscheel@xxxxxxxxx>
> wrote:
> > Well I'm hoping that I can just use the current Task class as my model,
> > since the Task is where all the data is. But yes, with a view class that
> is
> > pure GTK3, we can plug in some other interface, use the same code, and
> have
> > any kind of front end we want (be it web, Qt, WxWindows, etc.), and the
> > controller will be able to do all the manipulation of the data model and
> > will be called upon based on what the user does. Essentially it will be a
> > clean API-type deal that we can just hook into another interface that
> uses
> > the same calls.
> >
> >
> > On Mon, May 21, 2012 at 8:43 AM, Izidor Matušov <
> izidor.matusov@xxxxxxxxx>
> > wrote:
> >>
> >> On 05/18/2012 08:56 PM, Steve Scheel wrote:
> >>>
> >>> 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.
> >>
> >>
> >> If I understand it correctly, model of the Task will be a representation
> >> of special parts of the task like "this part is a text and that part is
> a
> >> subtask". It will be possible to load from a string or dump to a string
> a
> >> task directly from this model. Controller will handle user inputs and
> modify
> >> that model and TaskView would just display model without any important
> logic
> >> in it? Does it mean that task editor could be easily tested and maybe
> use a
> >> different toolkit for displaying? (e.g. web browser for web version of
> GTG?)
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> >
> >
> > _______________________________________________
> > 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
>