gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

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