gtg-user team mailing list archive

[Julien Baley <zhulian.balei@xxxxxxxxx>]

Hehe, thanks for these remarks, that's true, I'm more in arguing about some
points that solving the problems myself.

After your answer, I will try to think more precisely to how to do this, but
you're right, this might be a bit counter-intuitive, and I'm not very aware
of the goal of GTG. It may not be a project manager, but more a everyday
life task manager, right?

However, I will consider this question again and if it's really necessary to
implement this, the gains in terms of effectiveness and the loss of
usability.

Julien

2009/3/8 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<https://code.edge.launchpad.net/%7Egtg/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<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
> >
>
>
> _______________________________________________
> 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
>