From: John Hendy <jw.hendy@gmail.com>
To: Christian Egli <christian.egli@sbs.ch>
Cc: emacs-orgmode@gnu.org
Subject: Re: taskjuggler (tj3) export issues and proposals
Date: Wed, 1 Feb 2012 09:07:29 -0600 [thread overview]
Message-ID: <CA+M2ft8BAQNOcgZwRBOZP_EA=LEuesx_tOOC105_uVM8oT9j_w@mail.gmail.com> (raw)
In-Reply-To: <871uqesl0u.fsf@sbs.ch>
On Wed, Feb 1, 2012 at 8:09 AM, Christian Egli <christian.egli@sbs.ch> wrote:
> Hi John
>
> John Hendy <jw.hendy@gmail.com> writes:
>
>> Leading my first project and decided to dig into taskjuggler again. It
>> just seems so natural to have everything in org if possible, so I took
>> another look at the exporter, manual, and worg tutorial. [1][2]
>
> Cool.
>
First off, thanks for the input!
>> As is, as far as I can tell, the exporter does not work out of the box
>> with tj3. I /think/ I could get it to work if I added in a massive
>> report definition (which now seems mandatory for tj3) under
>> =org-export-taskjuggler-default-reports=, but that just feels clumsy.
>
> First off let me say that I'm using the taskjuggler exporter with tj3,
> so it should work.
>
This statement seems to indicate that org may work out of the box with tj3.
> As far as I know setting the org-export-taskjuggler-default-reports
> should work. As I agree that this is a bit clumsy and sets the reports
> for all projects. I'm setting the variable in a file variable like so
> (the compile-command is optional but you need to adapt it to match the
> location of your tj3 binary and your file name):
>
> # Local Variables:
> # org-export-taskjuggler-target-version: 3.0
> # org-export-taskjuggler-default-reports: ("include \"reports.tji\"")
> # compile-command: "~/.gem/ruby/1.9.1/bin/tj3 yourfilename.tjp"
> # End:
>
This seems to indicate that org does *not* work out of the box with
tj3, but only if you use this tweak for the reports definitions.
That's fine, I just want to be clear with whether org does or not work
out of the box by just setting =org-export-taskjuggler-target-version:
3.x= I'm thinking it does not and you'll get a failed build with no
output.
And... sigh. I had never thought to define reports /as/ =include
"reports.tji=. How simple.
> Then I define the reports in a separate file which is included similar
> to the solution you outline below.
>
> I guess I should have some default report definitions for tj3 in the
> exporter itself. The tj3 reports are quite massive and it is hard to
> come by some which could be included in the Emacs source (you need
> copyright assignments). Maybe the ones I have in my reports.tji could
> qualify.
Since these can vary, I actually think it would be fine to specify in
the manual that you need a separate definition. But maybe a brand new
tj user wouldn't like that?
>
>> For one, not every project will have the same report. Secondly, it
>> seems odd to tweak report definitions through my .emacs file?
>
> Yes I agree, see above.
>
>> Based on my fiddling tonight, here are some suggestions/inquiries:
>>
>> 1) Could there be something equivalent to #+latex/#+begin_latex that
>> would let me export some literal taskjuggler syntax into a file?
>> Perhaps throw everything between a #+begin/end_taskjuggler just before
>> the closing "}" for the task?
>
> I can see a use case for this with regards to reports. But what is the
> use case if you'd place this inside tasks? The problem with literal
> sections of taskjuggler is where to place them. Something might me
> related to the project header, other stuff to the reports, etc.
>
Maybe that wasn't well thought out. I was thinking it could be useful,
but I guess the primary use was for include reports.tji.
>> 2) Could a different naming convention be used? It seems the currently
>> it's either what is defined by the property :task_id: or defaults to
>> the first word of the headline. If the default were more likely to be
>> unique, it would spare having to define a ton of =task_id= properties;
>> instead one could define dependencies based on headline names because
>> the syntax for naming was known and not likely to clash with another
>> headline's ID.
>> --- First word of the parent headline + "_" + first word of actual headline?
>> --- Bump it to the first two words of each headline?
>
> The exporter just makes the task_id locally unique. That's what tj
> expects. From your usage I guess that you have a lot of tasks with the
> same name (probably within different hierarchies). Both methods you
> outline could be implemented. Which one is more general?
>
Maybe "parent_headline_task_headline"? But that gets tricking for:
* Task Container
** Send product samples to X
** Send product samples to Y
** Send product samples to Z
Append a number? My files are not [too] complex; perhaps the exporter
should be done while thinking of how org might have worked for the
Fedora tj example
(http://www.taskjuggler.org/tj3/examples/Fedora-20/f-20.tjp).
>> 3) As a piggyback on #1, I am successful with the following process:
>> -- create reports.tji with my report definitions
>> -- org-export-taskjuggler-default-reports set to nothing
>> -- export from orgmode
>> -- edit exported-file.tjp and add: include "reports.tji" to the end
>> -- run =tj3 filename.tjp=
>
> Could you not set org-export-taskjuggler-default-reports to "include
> \"reports.tji\""? Otherwise you can use file variables as I outlined
> above.
Again. Yes. So simple. So overlooked by me...
>
>> Simply allowing the addition of =include "reports.tji"= or even
>> mandating that it exists would allow the use of tj3 with the current
>> exporter.
>>
>> I don't know lisp and feel a bit guilty making potentially code-heavy
>> suggestions about this... That said, I'm happy to pitch in with the
>> manual/worg since they're a but outdated anyway.
>
> I'm happy to take you up on this offer. The worg page is a lot of work,
> as it has all these screen shots. I'd be happy if you could update it
> once you get all of this working.
>
I'm down and sounds good.
>> I don't see an obvious place where one can even download tj 2.x.x
>> anymore.
>
> I have it installed on an old machine.
>
Gotcha.
>> The tj team seems to have left that version behind; perhaps
>> the org exporter should to?
>
> I still prefer the old reports. But I guess yes, the exporter should
> move on and support tj3 out of the box. The two main problems are
>
> 1. default reports with copyright assignments. As I include this in the
> Emacs source we need to have assignments. I can't just take the ones
> from the tj3 manual (I'd have to ask the author first).
>
Gotcha. I started with the tj example and built my own... could I
provide it without these issues?
> 2. A way to invoke the view (as seamless as before). For tj 2.4 I was
> able to just invoke the taskjuggler gui with the exported tjp file.
> For tj3 the exporter needs to somehow find out which reports are
> generated (HTML, text, csv) and then invoke the appropriate viewer.
> This might be simplified I take some assumptions, but I haven't come
> up with a clever way to do this.
I've never used csv or text... maybe
org-export-taskjuggler-format-html/csv/text? And then something like
=org-export-taskjuggler-default-export-format=? Default=html but could
be changed with a file option?
>
> Thanks
> Christian
Thanks a ton for the response and effort.
John
>
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
>
>
next prev parent reply other threads:[~2012-02-01 15:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-01 4:59 taskjuggler (tj3) export issues and proposals John Hendy
2012-02-01 14:09 ` Christian Egli
2012-02-01 14:18 ` Rainer M Krug
2012-02-01 15:20 ` John Hendy
2012-02-01 15:54 ` Christian Egli
2012-02-01 17:47 ` John Hendy
2012-02-02 7:10 ` Christian Egli
2012-02-02 15:49 ` John Hendy
2012-02-02 16:08 ` OT: taskjuggler question [was: Re: taskjuggler (tj3) export issues and proposals] Nick Dokos
2012-02-02 16:22 ` John Hendy
2012-02-02 16:24 ` OT: taskjuggler question Christian Egli
2012-02-02 17:13 ` Nick Dokos
2012-02-01 18:36 ` taskjuggler (tj3) export issues and proposals Rainer M Krug
2012-02-01 15:07 ` John Hendy [this message]
2012-02-02 8:23 ` Christian Egli
2012-05-07 4:26 ` Eric S Fraga
2012-05-08 8:16 ` Bastien
2012-05-08 9:14 ` Eric Fraga
2012-05-08 14:36 ` John Hendy
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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='CA+M2ft8BAQNOcgZwRBOZP_EA=LEuesx_tOOC105_uVM8oT9j_w@mail.gmail.com' \
--to=jw.hendy@gmail.com \
--cc=christian.egli@sbs.ch \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).