emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Christian Egli <christian.egli@sbs.ch>
To: emacs-orgmode@gnu.org
Subject: Re: More generic taskjuggler export proposal
Date: Fri, 12 Apr 2013 15:08:17 +0200	[thread overview]
Message-ID: <87obdjvqv2.fsf@sbs.ch> (raw)
In-Reply-To: 515C901D.50500@web.de

Hi Buddy

Buddy Butterfly <buddy.butterfly@web.de> writes:

> I would like propose the following for taskjuggler export
> as base for a discussion to change export functionality.

Thanks for your detailed proposal. It's been a few years since I wrote
the taskjuggler exporter and I don't remember all the design decisions.
Your idea with the prefix to the attributes is an interesting one.

However, the fundamental problem here is that IMHO there is no
one-to-one mapping between all the concepts in taskjuggler and org-mode.
Fundamentally taskjuggler is a system to plan and track a multi-resource
project. I see org-mode more geared towards planing and tracking a
single user. Taskjuggler has the concept of scenarios where you can
compare a plan against another plan or an actual execution (based on
reported effort). This might be doable in org-mode but is not really a
natural thing to do.

So in essence what I'm trying to say is that the goal behind the
taskjuggler exporter was never to give you a complete taskjuggler
development environment. For that you are probably better of just
editing the tjp files directly. Instead the goal was to let the user
take their "normal" org-mode files and have them export to taskjuggler
with minimal changes (i.e. mark the tasks, efforts and the resources).

The same holds for the dependency system. As far as I remember it was an
explicit decision not to support the taskjuggler dependency system and
use the one provided by org-mod instead. I think taskjuggler's
dependency system is very low level. The one provided by org-mode fit my
use cases (for the occasional dependency) much better (and have support
for higher level concepts such as the ORDERED or previous-sibling

>  The dependency between tasks is one thing that should be supported by org.
>  I do not know what would be the best solution here. Maybe we could get
>  a completion list for the values when adding :tj_depends: properties.

I don't quite understand this part of your message. As I said above I
think the support for dependencies in the taskjuggler is IMHO quite nice

> Here I would suggest that one can place this data inbetween

This is something I'd like to add support for. I just never got around
to look at how this could be implemented. It has some implications as
you could destroy your otherwise valid tjp file. But it might cover some
of your use cases above. Do you know how this could be done in the new

> I still would like to discuss the organisation with multiple projects.
> What do you think about it?

Are you referring to the problem of handling multiple projects and
similar resources? I have never done this. How do you do it in plain


Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

  reply	other threads:[~2013-04-12 13:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03 20:25 More generic taskjuggler export proposal Buddy Butterfly
2013-04-12 13:08 ` Christian Egli [this message]
2013-04-14 12:51   ` Suvayu Ali

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87obdjvqv2.fsf@sbs.ch \
    --to=christian.egli@sbs.ch \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).