Re: [Planner Dev] Advanced link tasks version 3.

["lincoln phipps openmutual net" <lincoln phipps openmutual net>]

Richard,
	OK - I'll not work on this right now for 0.12
as it was intended for 0.13 and I want to do it right
and not just expediently....

...and though the dialog works OK it makes it too
easy for people to link tasks in fun ways and thus too
easy to stress Planner e.g. bugzilla 134273 and 140561 :)

So... we'll fix this all in 0.13.

Rgds,
Lincoln.

Richard Hult wrote:

> On ons, 2004-04-21 at 11:49 +0100, Lincoln Phipps wrote:
>
>
> > > Hm, it should be possible to make it internal to the link dialog only,
> > > right?
> >
> > No - the reason being that the planner-task-link-dialog.c uses it
> > to setup the dialog and the planner-task-tree.c uses it to pick out
> > the data->??? structure thats returned by the dialog.
>
>
> The way I would solve that is to extend the API in the link dialog
> instead of just exposing its private data.
>
> So instead of having:
>
> planner_task_link_dialog_new () 
>
> and process the result in the caller to extract the mode etc, I would
> do:
>
> gboolean
> planner_task_link_dialog_{run,show,whatever} (..., *mode,
> *direction, ...) 
> {
>    ...
> }
>
> And return FALSE if the dialog was cancelled and otherwise fill in mode
> and direction. That way nothing internal about the dialog needs to be
> known outside itself.
>
> An alternative solution is to first create the dialog like you do now,
> add add an API like:
>
> planner_task_link_dialog_get_mode (...) etc.
>
> It's essential that we continue to keep this kind of separation
> otherwise we'll end up with something that's very hard to maintain,
> especially as we add lots of code and features. We should really think
> of each separate dialog, view, window as an encapsulated object and not
> directly touch stuff in another object.  
>
> /Richard