gtg-user team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

The problem is a very complex problem.

When we started GTG, I had, like you, a very precise idea on how to
handle such cases. I was convinced that it was a good idea but really
hard to implement.

I finally implemented it as a prototype :
https://code.edge.launchpad.net/~gtg/gtg/subtask_model

And I discovered that it was unusable. Totally. A complete mess for the
user, counter-intuitive and non consistent. And I discovered that only
because I implemented it.

So I'm now very suspicious about ideas like yours and I will do my old
fart on that subject but before coding anything related, I will ask
you : "show me your patch" or "show me your complete mockup with an user
workflow description". ;-)

Don't get me wrong : it's a really interesting subject (really, it's the
heart of GTG) and I hope that our little growing community will solve
that problem but right now I don't believe that any of us as a solution
(or even the beginning of one).

Lionel


Le dimanche 08 mars 2009 à 23:09 +0100, Julien Baley a écrit :
> "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
>         >> Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
>         >> Unsubscribe : https://launchpad.net/~gtg-user
>         >> More help   : https://help.launchpad.net/ListHelp
>         >
>         >
>         > _______________________________________________
>         > Mailing list: https://launchpad.net/~gtg-user
>         > Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
>         > Unsubscribe : https://launchpad.net/~gtg-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
>