gtg-user team mailing list archive

[Julien Baley <zhulian.balei@xxxxxxxxx>]

"If I understood
well, the problem comes from the fact that, at the moment,
dependancies can only be described by creating subtasks of subtasks."

That's it, exactly!

However, I'm not sure numbered lists would be the best way to implement it.
I'm not knowledgeable when it comes to task ordering (hmm, "ordannancement
des tâches", sorry for the French, but as it may be better understood by
you..), but I guess a task should have, as a "immediately possible"
condition a list of other tasks + a date.
Indeed, if the list of sub-tasks of a project becomes too big and the stream
of sub-tasks get divided, numbers will be confusing (and impossible). As
this may not be clear, a little example.
I have a task A, that contains sub-tasks B, C and D. B and C can be done at
anytime, but D requires B and C to be completed. In this situation, it would
probably be better if D had a list of dependencies : [start_time,
task_to_be_completed_before_1, ..., task_to_be_completed_before_n]. Here, we
couldnt give the three tasks numbers (or we could give the same number to B
and C, but it seems complicated, especially in case we introduce some new
sub-tasks prior to B or C).

Such a dependency list probably wouldn't be that difficult to implement
(just a few tests to do, that already exist for the task / sub-task
relation). In conclusion, it would be just like the current task / subtask
scheme, but instead of a level approach (which is of course still
necessary), there would be  a same-level dependency mechanism. Hmm, this is
of course just a suggestion, but if ever you like that idea, we can discuss
it further, and if I find enough time these days to read a bit more the code
of GTG, I could try and think of a solution locally.
(any further idea, but that might seem a bit absurd : if date could be
considered as an automatically done task, the mechanism of "immediately
possible / impossible" task would only rely on the dependency scheme.)

If any idea or suggestion, I'd gladly read it. I've started using the
software tonight and I think it's going to be really useful for me (and it
already is!), so if I could be of any help for improving its features, I'd
gladly do it!

Julien

2009/3/8 Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>

> On Sun, Mar 8, 2009 at 8:05 PM, Julien Baley <zhulian.balei@xxxxxxxxx>
> wrote:
> > "What you want is, if I understand you correctly, the workview. By making
> > B a subtask of A, A will never be in the workview as long as B is not
> > completed. Personally, I'm nearly always in workview mode to have the
> > behaviour you described."
> >
> > Not particularly. In fact, I have understood I could use sub tasks, but
> in
> > terms of semantics, it sounds strange.
> > Imagine I want to make a cake. Let "make a cake" be the Task.
> > Then the sub-tasks : "buy the ingredients", "prepare the mix", "put in
> the
> > oven", "take out of the oven" (please don't procrastinate for this last
> > one!) should do in that order.  However, it would be strange to list them
> as
> > "take out of the oven" be a sub task of level 1 and "put in the oven" be
> a
> > sub task of it (thus, of level 2). Though it works, it's not really
> > meaningful and rather disturbing in terms of organization.
> > I hope my example was understandable enough. But maybe there would be a
> > problem in dealing with dates and other task ID as a "start date" ?
>
> Hmm, we actually already discussed about this Lionel and me (remember
> Lionel? it's your "Replace the lightbulb" thing ;-) ). If I understood
> well, the problem comes from the fact that, at the moment,
> dependancies can only be described by creating subtasks of subtasks.
>
> GTG currently lacks the notion of order you talk about. We have to
> find a way to implement, since I think it is clearly required. We
> should be able to declare a list of tasks as being a sequence of
> actions. Maybe we could introduce two kind of lists: unordered (bullet
> point) lists and ordered (numbered) lists. Ordered lists would imply a
> dependance between tasks on the same level.
>
>
> > "Yep, Undo/redo should be nice but it's not an easy thing to do."
> > I guess it's not easy! If this ever comes to be on your agenda again
> soon,
> > I'd gladly give ideas about it!
> >
> > "Simply do :
> > bzr branch lp:gtg"
> >
> > Thanks! I will try to see how all this works (creating patch files, etc),
> > never used before.
> >
> > Julien
> >
> > 2009/3/8 Lionel Dricot <ploum@xxxxxxxxx>
> >>
> >> Le dimanche 08 mars 2009 à 19:34 +0100, Julien Baley a écrit :
> >> > Hi all,
> >> >
> >> > sorry if I'm not using properly this mailing list, but I had some
> >> > questions and suggestions about Getting Things Gnome!
> >>
> >> Hello Julien. You are on the perfect place to discuss GTG so welcome :-)
> >> >
> >> > First, I am wondering if it was possible to order some tasks. It looks
> >> > like I can use sub-tasks, or set a start date according to the
> >> > calendar, but I've found nothing to set a start date on another task's
> >> > "task done" flag, which seems to me to be rather important (especially
> >> > when slicing my "to do" tasks). Is there a way to do that, is it
> >> > planned, or is it a new idea?
> >>
> >> What you want is, if I understand you correctly, the workview. By making
> >> B a subtask of A, A will never be in the workview as long as B is not
> >> completed. Personally, I'm nearly always in workview mode to have the
> >> behaviour you described.
> >>
> >> >
> >> > Second, usability : it would be very nice if something like a cancel
> >> > button (+ shortcut ctrl + Z) could be added, wether it be in the text
> >> > area of a task / sub-task (oh no! I've deleted the text of a task and
> >> > cannot get it back, unfortunately) or for tasks themselves (though
> >> > there, it seems less important as a dialog asks if I really want to
> >> > delete the task).
> >>
> >> Yep, Undo/redo should be nice but it's not an easy thing to do. We
> >> planned it (Bertrand even added the icons) but we never did the
> >> implementation. It's also not really clear what undo should do. For the
> >> delete function, I think it's closely related to the following
> >> discussion :
> >> https://lists.launchpad.net/gtg-user/msg00004.html
> >>
> >> >
> >> > Finally, after a short look around, I couldnt find a tarball archive
> >> > of the project (as you seem to be looking for contributions), did I
> >> > miss it?
> >>
> >> Tarballs are linked here :
> >> http://gtg.fritalk.com/pages/download
> >>
> >> But if you plan to play with code, I strongly suggest you to use bzr.
> >> Simply do :
> >>
> >> bzr branch lp:gtg
> >>
> >> and you will have the full source. You can play with it, even commit
> >> your stuffs locally and if you developed something interesting, it's
> >> really easy to send your patch as a merge. Really, DVCS (and bzr)
> >> rocks ! :-)
> >>
> >> Lionel
> >>
> >> PS : note to everyone : don't forget to reply-all when replying to this
> >> list.
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~gtg-user<https://launchpad.net/%7Egtg-user>
> >> Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~gtg-user<https://launchpad.net/%7Egtg-user>
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~gtg-user<https://launchpad.net/%7Egtg-user>
> > Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~gtg-user<https://launchpad.net/%7Egtg-user>
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
>
>
>
> --
> Bertrand Rousseau
> Place communale 1, 1450 Chastre, Belgium
> e-mail : bertrand.rousseau@xxxxxxxxx
> tel : +32 485 96 69 86
>