Re: [O] What happened to clocktable in pdf export?
Hi Nicolas, updated via elpa and got the nice table back again in pdf. Also in ASCII and HTML export it is nicely indented now. A drawback, though is that the \_ in the emacs editing is now gone! The lines now look like \emsp\emsp\emsp Task2 Which is also not very nice. The editing style \_ was quite nice, though, not for export. Is there a way to make the \emsp invisible within Emacs? Also, any Idea how to get the column separator lines also in ASCII export? PDF works because of the extra header line. HTML and ASCII I do not know. Cheers, Matt Am 25.07.2014 um 13:16 schrieb Nicolas Goaziou: Buddy Butterfly buddy.butter...@web.de writes: How can I easily fix it in my Ubuntu dist? I am running the standard repo version from Ubuntu 14.04. Any .el or something like that? Since it is fixed in maint, you can update Org from ELPA. It will be updated in a few hours. Just a small one. As now the line for the clocktable becomes longer, is there a method to break up the clocktable header into multiple lines? Not yet, but ultimately :header property should probably be moved to #+HEADER: keyword above the dynamic block, much like source blocks: #+header: #+attr_latex: :align l|r|r|r :environment longtable #+header: :fontsize \footnotesize #+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t ... Though, there's no standard syntax to include a newline there, e.g., #+header: #+attr_latex: :align l|r|r|r :environment longtable #+header: :fontsize \footnotesize\n#+caption: Some caption #+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t ... Regards,
Re: [O] What happened to clocktable in pdf export?
Hi,
this is sooo cool! Was not aware of this syntax change.
It works now as expected.
Regarding
\__ syntax doesn't exist anymore, so no exporter will recognize it.
The replacement is \emsp. I fixed it in maint. Thank you for reporting
it.
How can I easily fix it in my Ubuntu dist? I am running the standard
repo version from Ubuntu 14.04. Any .el or something like that?
Just a small one. As now the line for the clocktable becomes longer,
is there a method to break up the clocktable header into multiple lines?
Thanks a lot man, you saved my docs ;-)
Cheers,
Matt
Am 25.07.2014 um 11:06 schrieb Nicolas Goaziou:
Hello,
Buddy Butterfly buddy.butter...@web.de writes:
1. Even though the column separators are given in latex, they are not
printed
anymore. Only when using the org-table standard feature ||. But such
an additional line will be deleted after a clocktable refresh.
This is because syntax has changed. Attributes specific to the table
have to be inserted above the table, not above the dynamic block. What
you really want is (note the differences in attr_latex line)
#+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t
#+ATTR_LATEX: :environment longtable :align l|r|r|r
| Headline | Time | | |
...
#+END:
Since the table is auto generated, you have to send this line through
the :header property:
#+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header
#+attr_latex: :align l|r|r|r :environment longtable\n
...
#+END:
Now you can also avoid using both #+latex: lines with appropriate
properties:
#+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header
#+attr_latex: :align l|r|r|r :environment longtable :center t :font
\\footnotesize\n
...
#+END:
Eventually you can also insert a caption with, e.g.,
#+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header
#+attr_latex: :align l|r|r|r :environment longtable :center t :font
\\footnotesize\n#+caption: Clock summary at {{{time(%c)}}}\n
2. The indentation underscores are printed, which did not come before.
Especially
this makes it ugly. Before the _ have not been exported.
\__ syntax doesn't exist anymore, so no exporter will recognize it.
The replacement is \emsp. I fixed it in maint. Thank you for reporting
it.
Regards,
Re: [O] What happened to clocktable in pdf export?
Hi, sorry, for the delay (;-) but Problem still exists. In the past we used to use the clocktable for quick effort estimation because of the very nice table structure in a pdf export. The current state you can see in the attachment. The following issues arise 1. Even though the column separators are given in latex, they are not printed anymore. Only when using the org-table standard feature ||. But such an additional line will be deleted after a clocktable refresh. 2. The indentation underscores are printed, which did not come before. Especially this makes it ugly. Before the _ have not been exported. Cheers, Matt Am 28.04.2014 um 13:33 schrieb Nicolas Goaziou: Hello, Buddy Butterfly buddy.butter...@web.de writes: Any idea what could have caused the change? Is it texlive or within Emacs? Would you mind posting a simple example? Regards, ugly_clocktable_pdf.org Description: application/emacs-org-mode ugly_clocktable_pdf.pdf Description: Adobe PDF document
Re: [O] What happened to clocktable in pdf export?
Am 25.04.2014 16:07, schrieb Buddy Butterfly: Hi, what happened to the pdf export of clocktables? After the upgrade to Ubuntu 13.10 (emacs 24.3.1), the clocktable export looks ugly as hell. With the latex headers aligne=l|r etc. and the indentation in the clocktable I got a very nice export before. The lines where also indented and I had vertical separators for the columns. Now, in the new version I get in the PDF for the indentation (\_) and there are not separator lines between columns. What changed? Is it just configuration or did change completely? Cheers, Matt Any idea what could have caused the change? Is it texlive or within Emacs?
[O] What happened to clocktable in pdf export?
Hi, what happened to the pdf export of clocktables? After the upgrade to Ubuntu 13.10 (emacs 24.3.1), the clocktable export looks ugly as hell. With the latex headers aligne=l|r etc. and the indentation in the clocktable I got a very nice export before. The lines where also indented and I had vertical separators for the columns. Now, in the new version I get in the PDF for the indentation (\_) and there are not separator lines between columns. What changed? Is it just configuration or did change completely? Cheers, Matt
Re: [O] How to get rid of clocktable summary time in the form 2d 02:00
Anyone? Still have no clue Am 01.04.2014 00:59, schrieb Buddy Butterfly: Am 31.03.2014 10:46, schrieb Sebastien Vauban: Bastien wrote: Buddy Butterfly buddy.butter...@web.de writes: I would like to have the summary times in a clocktable be displayed only in hours, like 48:00 instead of 2d. Or, is it possible to define that 1d corresponds to 8:00 as a working day? So in the above example I would rather like to see 5d (workingdays) corresponding to 40:00. Clocktable counts 1d as 24h (which is right ;-) but not in business. See `org-time-clocksum-use-effort-durations' and `org-effort-durations' for a start. Eventually take a look at related posts: - Multiple notions for what's a day http://lists.gnu.org/archive/html/emacs-orgmode/2012-12/msg01093.html - Computations on efforts expressed in days http://lists.gnu.org/archive/html/emacs-orgmode/2012-05/msg00049.html It looks like this links are describing exactly the same issue. But I still have no clue how to change it. I upgraded to Kubuntu 13.10 from 12.10. This is where the change came in. Ubuntu 13.10 uses Emacs 24.3.1. Will it be fixed in a later version? Best regards, Seb
Re: [O] How to get rid of clocktable summary time in the form 2d 02:00
Solved it. If anyone is interested, here it goes: Neither the 2 settings given below nor the links helped very much. Instead I customized the variable org-time-clocksum-format and switcht off (deselected) the Days entry completely. Cheers, Matt Am 02.04.2014 10:09, schrieb Buddy Butterfly: Anyone? Still have no clue Am 01.04.2014 00:59, schrieb Buddy Butterfly: Am 31.03.2014 10:46, schrieb Sebastien Vauban: Bastien wrote: Buddy Butterfly buddy.butter...@web.de writes: I would like to have the summary times in a clocktable be displayed only in hours, like 48:00 instead of 2d. Or, is it possible to define that 1d corresponds to 8:00 as a working day? So in the above example I would rather like to see 5d (workingdays) corresponding to 40:00. Clocktable counts 1d as 24h (which is right ;-) but not in business. See `org-time-clocksum-use-effort-durations' and `org-effort-durations' for a start. Eventually take a look at related posts: - Multiple notions for what's a day http://lists.gnu.org/archive/html/emacs-orgmode/2012-12/msg01093.html - Computations on efforts expressed in days http://lists.gnu.org/archive/html/emacs-orgmode/2012-05/msg00049.html It looks like this links are describing exactly the same issue. But I still have no clue how to change it. I upgraded to Kubuntu 13.10 from 12.10. This is where the change came in. Ubuntu 13.10 uses Emacs 24.3.1. Will it be fixed in a later version? Best regards, Seb
Re: [O] How to get rid of clocktable summary time in the form 2d 02:00
Am 31.03.2014 07:50, schrieb Bastien: Hi buddy, Buddy Butterfly buddy.butter...@web.de writes: I would like to have the summary times in a clocktable be displayed only in hours, like 48:00 instead of 2d. Or, is it possible to define that 1d corresponds to 8:00 as a working day? So in the above example I would rather like to see 5d (workingdays) corresponding to 40:00. Clocktable counts 1d as 24h (which is right ;-) but not in business. See `org-time-clocksum-use-effort-durations' and `org-effort-durations' for a start. Tried to set org-time-clocksum-use-effort-durations to on but no luck! Any other hints? HTH,
Re: [O] How to get rid of clocktable summary time in the form 2d 02:00
Am 31.03.2014 10:46, schrieb Sebastien Vauban: Bastien wrote: Buddy Butterfly buddy.butter...@web.de writes: I would like to have the summary times in a clocktable be displayed only in hours, like 48:00 instead of 2d. Or, is it possible to define that 1d corresponds to 8:00 as a working day? So in the above example I would rather like to see 5d (workingdays) corresponding to 40:00. Clocktable counts 1d as 24h (which is right ;-) but not in business. See `org-time-clocksum-use-effort-durations' and `org-effort-durations' for a start. Eventually take a look at related posts: - Multiple notions for what's a day http://lists.gnu.org/archive/html/emacs-orgmode/2012-12/msg01093.html - Computations on efforts expressed in days http://lists.gnu.org/archive/html/emacs-orgmode/2012-05/msg00049.html It looks like this links are describing exactly the same issue. But I still have no clue how to change it. I upgraded to Kubuntu 13.10 from 12.10. This is where the change came in. Ubuntu 13.10 uses Emacs 24.3.1. Will it be fixed in a later version? Best regards, Seb
[O] How to get rid of clocktable summary time in the form 2d 02:00
Hi, I would like to have the summary times in a clocktable be displayed only in hours, like 48:00 instead of 2d. Or, is it possible to define that 1d corresponds to 8:00 as a working day? So in the above example I would rather like to see 5d (workingdays) corresponding to 40:00. Clocktable counts 1d as 24h (which is right ;-) but not in business. Thanks a lot, Matt
Re: [O] Emacs org-mode mailing list filter by category / tag?
Am 09.04.2013 13:02, schrieb Buddy Butterfly: Hi Bastian, true ;-) I just wanted to know the best method. Thanks, Matt Am 09.04.2013 11:52, schrieb Bastien: Hi Buddy, Buddy Butterfly buddy.butter...@web.de writes: how to configure the group to subscribe to in gnus directly (.emacs file)? When configuring news.gmane.org as server gnus hangs for long time and server closes connection. I guess it times out requesting all groups. Please take this discussion to the Gnus mailing list: http://www.gnus.org/resources.html You cannot both complain that there are too many messages on this list and add new off-topic ones ;) Thanks! test
Re: [O] Emacs org-mode mailing list filter by category / tag?
Hi Bastien, thanks for the info. This is indeed a good proposal. I will switch to the newsgroup for reading. Thanks a lot and best regards, Matt Am 08.04.2013 21:21, schrieb Bastien: Hi Matt, Buddy Butterfly buddy.butter...@web.de writes: obviously this is a very active forum. But due to the activity I am getting too much emails. I would like to filter by tag/category when registering. I think this is definitely needed to reduce the amount of mails before (!) it arrives. We already encourage some soft labelling but we cannot enforce anything here. Is this possible right now? If so, how? If not, could this list be enhanced to provide it? I don't think the list can be enhanced. One solution for people who don't want to receive tons of emails is to follow the list through gmane.org: you just need a news reader (Gnus comes to mind) and to subscribe to the gmane.emacs.orgmode newsgroup. HTH,
Re: [O] Emacs org-mode mailing list filter by category / tag?
Hi, how to configure the group to subscribe to in gnus directly (.emacs file)? When configuring news.gmane.org as server gnus hangs for long time and server closes connection. I guess it times out requesting all groups. Cheers, Matt Am 08.04.2013 21:21, schrieb Bastien: Hi Matt, Buddy Butterfly buddy.butter...@web.de writes: obviously this is a very active forum. But due to the activity I am getting too much emails. I would like to filter by tag/category when registering. I think this is definitely needed to reduce the amount of mails before (!) it arrives. We already encourage some soft labelling but we cannot enforce anything here. Is this possible right now? If so, how? If not, could this list be enhanced to provide it? I don't think the list can be enhanced. One solution for people who don't want to receive tons of emails is to follow the list through gmane.org: you just need a news reader (Gnus comes to mind) and to subscribe to the gmane.emacs.orgmode newsgroup. HTH,
Re: [O] Emacs org-mode mailing list filter by category / tag?
Hi Bastian, true ;-) I just wanted to know the best method. Thanks, Matt Am 09.04.2013 11:52, schrieb Bastien: Hi Buddy, Buddy Butterfly buddy.butter...@web.de writes: how to configure the group to subscribe to in gnus directly (.emacs file)? When configuring news.gmane.org as server gnus hangs for long time and server closes connection. I guess it times out requesting all groups. Please take this discussion to the Gnus mailing list: http://www.gnus.org/resources.html You cannot both complain that there are too many messages on this list and add new off-topic ones ;) Thanks!
[O] Emacs org-mode mailing list filter by category / tag?
Hi, obviously this is a very active forum. But due to the activity I am getting too much emails. I would like to filter by tag/category when registering. I think this is definitely needed to reduce the amount of mails before (!) it arrives. Is this possible right now? If so, how? If not, could this list be enhanced to provide it? Cheers, Matt
Re: [O] Item task_id not being used in taskjuggler export tj prefixing
Hi John, regarding your potential IRC date with Christian Egli, I would like to join, if I*ll find the time. For when is it scheduled? I have also posted a base for discussion here on the list. Thanks and best regards, Matt Am 01.04.2013 23:53, schrieb John Hendy: On Mon, Apr 1, 2013 at 3:56 PM, Buddy Butterfly buddy.butter...@web.de wrote: Hi, regarding your example ** Milestones :M: *** Task :PROPERTIES: :task_id: M2 :depends: T8 :END: ** Technical :T: :PROPERTIES: :task_id: T :END: *** Task :PROPERTIES: :task_id: T8 :duration: 1d :END: I would like to discus what I mean with a prefix. At the moment oex tries to mirror some functionality of tj to org mode. From an architectural point of view I would do this only for few selected functionalities. Otherwise you developers have to always adapt code to tj. If you would implement generic tj properties that will be exported as is, then one could easily write the tj stuff itself. The problem becomes obvious with your example above. Herr you expect that T8 would be unique across all tasks. If there are some other task paths with a task of T8 then this will not work. You will always run after tj implementing what they have implemented. Why not write: :depends: !!T.T8 directly? This is what should be done. Leave the tj logic to tj and do not try to map it to org-mode. The more you map the more difficult to maintain, etc. I agree and would prefer this. Especially since folks wanting to export and being allowed to access tj functionality through drawers are probably going to anticipate using actual tj syntax in those drawers. Since tj only forces unique global ids (one can have M.T8, T.T8, etc.), this would solve the issue of ambiguity should one decide to use non-globally unique task ids. In fact, many projects may very well use a lot of repetitive tasks with the same properties. In mine, I have some tasks regarding shipping products to various countries. This way I could just have a bunch of country-specific headlines like: * Country ** Ship product * Country 2 ** Ship product And could give all the ** Ship... tasks the same id since their Country parent would make it globally unique. For now, I'm just happy to have functionality restored so I can use Org and not hand-edit the files after exporting :) I have a potential IRC date with Christian Egli sometime this week... perhaps you should join and add your feedback? One of my other points of input would be that something like C-c l (Org store link at point) would be great. Unique ids could be inserted as depends with some simple key strokes and I would't have to use numbered IDs at all. They'd stay with the tasks no matter where I moved them. For that... I'd actually prefer *not* to have to explicitly name the parent since they could move wherever I put them with no consequence. John
[O] More generic taskjuggler export proposal
Hi,
I would like propose the following for taskjuggler export
as base for a discussion to change export functionality.
Here I will refer to the example project of taskjuggler 3.
Pre-requesites:
- Functionality of tj should be kept in tj as much as possible
- org export should be as generic as possible such that changes
in tj will not impact org.
Suggestions:
- There should be configurable global taskjuggler prefix to define
what shoudl be exported. Here we will take tj_ as an example.
- tj elements of the form
: keyword id name { attributes }
should be implemented as tagged tasks (like already done for resources
and project).
The org tag should be prefixed by the tj prefix and the tag name
should automatically
be exported as the keyword of tj. Org task should go into tj name
and the org
property tj_id should go into id.
The attributes should be org properties prefixed by the prefix (here
tj_).
Example for the project tag:
The tj example project lists the following project keyword header:
project your_project_id Your Project Title 2011-11-11-0:00--0500 +4m {
timezone America/New_York
timeformat %Y-%m-%d
numberformat - , . 1
currencyformat ( ) , . 0
now 2011-12-24
currency USD
# You can define multiple scenarios here if you need them.
#scenario plan Plan {
# scenario actual Actual
#}
# You can define your own attributes for tasks and resources. This
# is handy to capture additonal information about the project that
# is not directly impacting the project schedule but you like to
# keep in one place.
#extend task {
# reference spec Link to Wiki page
#}
#extend resource {
# text Phone Phone
#}
}
This would be written in org like
* Your Project Title :tj_project:
:PROPERTIES:
:tj_id: your_project_id
:tj_timezone: America/New_York
:tj_timeformat: %Y-%m-%d
:tj_numberformat: - , . 1
:tj_currencyformat: ( ) , . 0
:tj_now: 2011-12-24
:tj_currency: USD
:END:
* Plan :tj_scenario:
:PROPERTIES:
:tj_scenario: actual Actual
:END:
* task :tj_extend:
:PROPERTIES:
:tj_reference: spec Link to Wiki page
:END:
* resource :tj_extend:
:PROPERTIES:
:tj_text: Phone Phone
:END:
As we can see, org can export everything in a generic way with mainly
stripping
the prefix tj_ from the tags and properties and export as is to
taskjuggler.
This also maps to the well known resource mapping:
# This is a set of example resources.
resource r1 Resource 1
resource t1 Team 1 {
managers r1
resource r2 Resource 2
resource r3 Resource 3
}
# This is a resource that does not do any work.
resource s1 System 1 {
efficiency 0.0
rate 600.0
}
Would be written in org-mode like:
* Resource 1 :tj_resource:
:PROPERTIES:
:tj_id: r1
:END:
* Team 1 :tj_resource:
:PROPERTIES:
:tj_id: t1
:tj_managers: r1
:END:
* Resource 2
:PROPERTIES:
:tj_id: r2
:END:
* Resource 3
:PROPERTIES:
:tj_id: r3
:END:
* System 1 :tj_resource:
:PROPERTIES:
:tj_id: s1
:tj_efficiency: 0.0
:tj_rate: 600.0
:END:
Here the fact of inheritance of org tags have been taken into account in
org task Team 1 for resource Resource 2 and Resource 3.
For the tasks the same holds:
task project Project {
task wp1 Workpackage 1 {
task t1 Task 1
task t2 Task 2
}
task wp2 Work package 2 {
depends !wp1
task t1 Task 1
task t2 Task 2
}
task deliveries Deliveries {
task Item 1 {
depends !!wp1
}
task Item 2 {
depends !!wp2
}
}
}
Org mode:
* Project :tj_task:
:PROPERTIES:
:tj_id: project
:END:
* Workpackage 2
:PROPERTIES:
:tj_id: wp2
:END:
* Task 1
:PROPERTIES:
:tj_id: t1
:tj_depends: !wp1
:END:
* Task 2
:PROPERTIES:
:tj_id: t2
:END:
Also accounts could be easily generated with this
method:
account cost Project Cost {
account dev Development
account doc Documentation
}
---
* Project Cost :tj_account:
:PROPERTIES:
:tj_id: cost
:END:
* Development
:PROPERTIES:
:tj_id: dev
:END:
* Documentation
:PROPERTIES:
:tj_id: doc
:END:
There is still the question how to implement properties that go into
the global part of a tj file. Here I would suggest that one can place
this data inbetween
#+BEGIN_TASKJUGGLER
# The ProfitLoss analysis
Re: [O] Item task_id not being used in taskjuggler export tj prefixing
Hi,
regarding your example
** Milestones :M:
*** Task
:PROPERTIES:
:task_id: M2
:depends: T8
:END:
** Technical :T:
:PROPERTIES:
:task_id: T
:END:
*** Task
:PROPERTIES:
:task_id: T8
:duration: 1d
:END:
I would like to discus what I mean with a prefix.
At the moment oex tries to mirror some functionality of
tj to org mode. From an architectural point of view I
would do this only for few selected functionalities.
Otherwise you developers have to always adapt code to
tj. If you would implement generic tj properties that
will be exported as is, then one could easily write
the tj stuff itself.
The problem becomes obvious with your example above.
Herr you expect that T8 would be unique across all
tasks. If there are some other task paths with a task of
T8 then this will not work. You will always run after
tj implementing what they have implemented. Why not
write:
:depends: !!T.T8
directly? This is what should be done. Leave the tj
logic to tj and do not try to map it to org-mode.
The more you map the more difficult to maintain, etc.
Also, you will likely only implement subsets of tj
properties.
For example, there are properties missing like
:workinghours:
Lets look at an example. Suppose
we would prefix all taskjuggler properties with tj_
and org-mode would export tj_ properties as is.
People then would directly code the dependency
themself.
Your example would look like
(if directly replaced)
** Milestones :M:
*** Task
:PROPERTIES:
:tj_task_id: M2
:tj_depends: !!T.T8
:END:
** Technical :T:
:PROPERTIES:
:tj_task_id: T
:END:
*** Task
:PROPERTIES:
:tj_task_id: T8
:tj_duration: 1d
:END:
Also, properties to the project tag should go into the
project task. With the functionality above, it would be easy to:
* Project :taskjuggler_project:
:workinhours: mon - fri 08:00 - 17:00
Or give a flag:
** Technical :T:
:PROPERTIES:
:tj_task_id: T
:END:
*** Task
:PROPERTIES:
:tj_task_id: T8
:tj_duration: 1d
:tj_flag: tech8flag
:END:
I have some other points to discuss. Will create a separate thread for it.
Cheers,
Matt
Am 01.04.2013 18:57, schrieb John Hendy:
On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou n.goaz...@gmail.com
wrote:
John Hendy jw.he...@gmail.com writes:
I still have the issue of depending on a task not in the current
subtree, but perhaps I'm just not using the exporter correctly:
There was indeed a bug in the dependencies formatting. It should now be
fixed in master. Could you confirm it?
*** Task
:PROPERTIES:
:task_id: M2
:depends: ??? what goes here to depend on T.T8 ???
It should be :depends: T8
Thank you for the feedback.
That *would* work, but ox-taskjuggler has to correct for the fact that
T8 does not live in M2's bucket (M). Using T8 gives me this:
#+begin_src TJ
task M2 Task {
depends !T8
milestone
}
#+end_src
I cannot reproduce it. With:
* Project :taskjuggler_project:
** Milestones :M:
*** Task
:PROPERTIES:
:task_id: M2
:depends: T8
:END:
** Technical :T:
:PROPERTIES:
:task_id: T
:END:
*** Task
:PROPERTIES:
:task_id: T8
:duration: 1d
:END:
I get:
task project Project {
purge allocate
allocate nicolas
task milestones Milestones {
task M2 Task {
depends !!T.T8
milestone
}
}
task T Technical {
task T8 Task {
duration 1d
}
}
}
which looks correct. Did you reload Org properly after update?
Process:
- Save your patch to ~/Downloads/patch.patch
- cd ~/.elisp/org.git
- git branch tj-test
- git checkout tj-test
- patch -p1 ~/Downloads/patch.patch
- make clean make
- start fresh Emacs session
What perplexes me is that the id's mostly work (showing that the patch
definitely changed from the master branch behavior), but not the same
as you. With no task_id for Milestones, I'm getting:
task nil Milestones {
and you're getting
task milestones Milestones {
I'm also not getting the resolving of non-sibling depends attributes
(getting just !T8 instead of !!T.T8).
Did I not apply the patch or rebuild org properly? I'm pretty bad with
git, and it surprises me that `git status` shows that ox-taskjuggler
is modified when I switch back to master. I would have expected that
my master branch would be oblivious to the changes I made on the
tj-test branch (with `git branch tj-test git checkout tj-test`).
Thanks,
John
Regards,
--
Nicolas Goaziou
Re: [O] Item task_id not being used in taskjuggler export tj prefixing
Correction, see below...
Am 01.04.2013 22:56, schrieb Buddy Butterfly:
Hi,
regarding your example
** Milestones :M:
*** Task
:PROPERTIES:
:task_id: M2
:depends: T8
:END:
** Technical :T:
:PROPERTIES:
:task_id: T
:END:
*** Task
:PROPERTIES:
:task_id: T8
:duration: 1d
:END:
I would like to discus what I mean with a prefix.
At the moment oex tries to mirror some functionality of
tj to org mode. From an architectural point of view I
would do this only for few selected functionalities.
Otherwise you developers have to always adapt code to
tj. If you would implement generic tj properties that
will be exported as is, then one could easily write
the tj stuff itself.
The problem becomes obvious with your example above.
Herr you expect that T8 would be unique across all
tasks. If there are some other task paths with a task of
T8 then this will not work. You will always run after
tj implementing what they have implemented. Why not
write:
:depends: !!T.T8
directly? This is what should be done. Leave the tj
logic to tj and do not try to map it to org-mode.
The more you map the more difficult to maintain, etc.
Also, you will likely only implement subsets of tj
properties.
For example, there are properties missing like
:workinghours:
Lets look at an example. Suppose
we would prefix all taskjuggler properties with tj_
and org-mode would export tj_ properties as is.
People then would directly code the dependency
themself.
Your example would look like
(if directly replaced)
** Milestones :M:
*** Task
:PROPERTIES:
:tj_task_id: M2
:tj_depends: !!T.T8
:END:
** Technical :T:
:PROPERTIES:
:tj_task_id: T
:END:
*** Task
:PROPERTIES:
:tj_task_id: T8
:tj_duration: 1d
:END:
Also, properties to the project tag should go into the
project task. With the functionality above, it would be easy to:
* Project :taskjuggler_project:
:tj_workinhours: mon - fri 08:00 - 17:00
Or give a flag:
** Technical :T:
:PROPERTIES:
:tj_task_id: T
:END:
*** Task
:PROPERTIES:
:tj_task_id: T8
:tj_duration: 1d
:tj_flag: tech8flag
:END:
I have some other points to discuss. Will create a separate thread for it.
Cheers,
Matt
Am 01.04.2013 18:57, schrieb John Hendy:
On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou n.goaz...@gmail.com
wrote:
John Hendy jw.he...@gmail.com writes:
I still have the issue of depending on a task not in the current
subtree, but perhaps I'm just not using the exporter correctly:
There was indeed a bug in the dependencies formatting. It should now be
fixed in master. Could you confirm it?
*** Task
:PROPERTIES:
:task_id: M2
:depends: ??? what goes here to depend on T.T8 ???
It should be :depends: T8
Thank you for the feedback.
That *would* work, but ox-taskjuggler has to correct for the fact that
T8 does not live in M2's bucket (M). Using T8 gives me this:
#+begin_src TJ
task M2 Task {
depends !T8
milestone
}
#+end_src
I cannot reproduce it. With:
* Project :taskjuggler_project:
** Milestones :M:
*** Task
:PROPERTIES:
:task_id: M2
:depends: T8
:END:
** Technical :T:
:PROPERTIES:
:task_id: T
:END:
*** Task
:PROPERTIES:
:task_id: T8
:duration: 1d
:END:
I get:
task project Project {
purge allocate
allocate nicolas
task milestones Milestones {
task M2 Task {
depends !!T.T8
milestone
}
}
task T Technical {
task T8 Task {
duration 1d
}
}
}
which looks correct. Did you reload Org properly after update?
Process:
- Save your patch to ~/Downloads/patch.patch
- cd ~/.elisp/org.git
- git branch tj-test
- git checkout tj-test
- patch -p1 ~/Downloads/patch.patch
- make clean make
- start fresh Emacs session
What perplexes me is that the id's mostly work (showing that the patch
definitely changed from the master branch behavior), but not the same
as you. With no task_id for Milestones, I'm getting:
task nil Milestones {
and you're getting
task milestones Milestones {
I'm also not getting the resolving of non-sibling depends attributes
(getting just !T8 instead of !!T.T8).
Did I not apply the patch or rebuild org properly? I'm pretty bad with
git, and it surprises me that `git status` shows that ox-taskjuggler
is modified when I switch back to master. I would have expected that
my master branch would be oblivious to the changes I made on the
tj-test branch (with `git branch tj-test git checkout tj-test`).
Thanks,
John
Regards,
--
Nicolas Goaziou
Re: [O] Creating Gantt charts by Exporting to TaskJuggler 3.3.0
Hi Guys, long time ago, but I tried again to go into taskjuggling with org-mode. I still feel the lack of the support for all tj properties a major drawback. @Christian: Did you work on something like the prefix proposal below? This would be real cool as we could then just use any property we would like. Thanks and best regards, Matt Am 14.09.2012 18:06, schrieb Buddy Butterfly: Hi Yann, thanks a lot for your effort. This really sound very interesting. And I am willed to report further issues to you. I will try to nail them down more precisely. The biggest change I would do is to make the properties more generic. Something like prefixing all properties with a special prefix (configurable) like tj_ and just pass them all over to tj. This would allow the user to use all properties that are, were and will be available for tj versions and not having the exporter document we support this and that property in this and that version of tj Best regards, Matt Am 14.09.2012 17:55, schrieb Yann Hodique: Buddy == Buddy Butterfly buddy.butter...@web.de writes: Am 14.09.2012 17:09, schrieb: Hi, Seb, almost one month ago Yann Hodique proposed 10 patches for the taskjuggler exporter, please see: http://article.gmane.org/gmane.emacs.orgmode/58851 Bastien has a branch with these patches, but he'll apply them when he will have received the FSF papers signed. I hope soon :-) But I'm pretty sure you can apply them to your file. cheers, Giovanni Hi Giovanni, thanks for info. I will give this a try when I'll find the time. At the moment, because of the scrambled handling of task_ids it is not really usable. Let's see what he fixed in it. Hi, actually, those patches have been merged in master already (now that the paperwork is in order :)) That said, I don't think it'll fix anything regarding task_id handling. I started using TJ with versions 3.x, so I'm not sure what problem you're talking about exactly. At the moment I'm kinda contemplating doing a major rewrite of the TJ exporter to use the org-export framework, which would make it easier to introduce things like task references through org links, and so on. If I can fix a thing or two in the process, I'd be happy to. So, if you have specific limitations in mind, feel free to elaborate. Cheers, Yann.
Re: [O] Creating Gantt charts by Exporting to TaskJuggler 3.3.0
Hi,
tj3 support is still buggy. And tj export gets confused with the task_id
tags.
It does not generate unique IDs nor does it have manual ID marking. So
it gets
scrampled. So, for a bigger project it does not really work.
Verify to use
*Org Export Taskjuggler Target Version:
*
3.0
I have used the following settings with M-x customize-group -
org-export-taskjuggler
and worked for me as a first shot with tj3:
*Org Export Taskjuggler Default Global Properties:
*
shift s40 Part time shift {
workinghours wed, thu, fri off
}
account cost Project Cost {
aggregate tasks
}
account rev Payments {
}
*Org Export Taskjuggler Default Reports:*
# Now the project has been specified completely. Stopping here would
# result in a valid TaskJuggler file that could be processed and
# scheduled. But no reports would be generated to visualize the
# results.
navigator navbar {
hidereport @none
}
macro TaskTip [
tooltip istask() -8-
'''Start: ''' -query attribute='start'-
'''End: ''' -query attribute='end'-
'''Resources:'''
-query attribute='resources'-
'''Precursors: '''
-query attribute='precursors'-
'''Followers: '''
-query attribute='followers'-
-8-
]
textreport frame {
header -8-
== mwit Projects ==
[navigator id=navbar]
-8-
footer
textreport index Overview {
formats html
center '[report id=overview]'
}
textreport Status {
formats html
center -8-
[report id=status.dashboard]
[report id=status.completed]
[report id=status.ongoing]
[report id=status.future]
-8-
}
textreport development Development {
formats html
center '[report id=development]'
}
textreport ContactList {
formats html
title Contact List
center '[report id=contactList]'
}
textreport ResourceGraph {
formats html
title Resource Graph
center '[report id=resourceGraph]'
}
}
# A traditional Gantt chart with a project overview.
taskreport overview {
header -8-
=== Project Overview ===
The project is structured into 3 phases.
# Specification
# -reportlink id='frame.development'-
# Testing
=== Original Project Plan ===
-8-
columns bsi { title 'WBS' },
name, start, end, effort, cost,
revenue, chart { ${TaskTip} }
# For this report we like to have the abbreviated weekday in front
# of the date. %a is the tag for this.
timeformat %a %Y-%m-%d
loadunit days
hideresource @all
balance cost rev
caption 'All effort values are in man days.'
footer -8-
=== Staffing ===
All project phases are properly staffed. See [[ResourceGraph]] for
detailed resource allocations.
=== Current Status ===
The project started off with a delay of 4 days. This slightly affected
the original schedule. See [[Deliveries]] for the impact on the
delivery dates.
-8-
}
# Macro to set the background color of a cell according to the alert
# level of the task.
macro AlertColor [
cellcolor plan.alert = 0 #00D000 # green
cellcolor plan.alert = 1 #D0D000 # yellow
cellcolor plan.alert = 2 #D0 # red
]
taskreport status {
columns bsi { width 50 title 'WBS' }, name { width 150 },
start { width 100 }, end { width 100 },
effort { width 100 },
alert { tooltip plan.journal
!= '' -query attribute='journal'- width 150 },
status { width 150 }
taskreport dashboard {
headline Project Dashboard (-query attribute='now'-)
columns name { title Task ${AlertColor} width 200},
resources { width 200 ${AlertColor}
listtype bullets
listitem -query attribute='name'-
start ${projectstart} end ${projectend} },
alerttrend { title Trend ${AlertColor} width 50 },
journal { width 350 ${AlertColor} }
journalmode status_up
journalattributes headline, author, date, summary, details
hidetask ~hasalert(0)
sorttasks alert.down
period %{${now} - 1w} +8w
}
taskreport completed {
headline Already completed tasks
hidetask ~(plan.end = ${now})
}
taskreport ongoing {
headline Ongoing tasks
hidetask ~((plan.start = ${now}) (plan.end ${now}))
}
taskreport future {
headline Future tasks
hidetask ~(plan.start ${now})
}
}
# A list of tasks showing the resources assigned to each task.
taskreport development {
headline Development - Resource Allocation Report
columns bsi { title 'WBS' }, name, start, end, effort { title Work },
duration, chart { ${TaskTip} scale day width 500 }
timeformat %Y-%m-%d
hideresource ~(isleaf() isleaf_())
sortresources name.up
}
# A list of all employees with their contact details.
resourcereport contactList {
headline Contact list and duty plan
columns name,
email { celltext 1 [mailto:-email-
Re: [O] Creating Gantt charts by Exporting to TaskJuggler 3.3.0
Hi Seb, ah, true, that is pretty anoying. Also is for me. There is no GUI anymore for tj3. It is meant to be only exported. So you should find some html structures being generated. Best regards, Matt Am 14.09.2012 16:38, schrieb Sebastien Vauban: Hi Buddy, Buddy Butterfly wrote: Am 14.09.2012 15:13, schrieb Sebastien Vauban: I'm trying to use the export to TJ3 on Windows (I installed Ruby from Cygwin), but don't succeed to get the first view of the project, as shown on http://orgmode.org/worg/org-tutorials/org-taskjuggler.html. --8---cut here---start-8--- TaskJuggler v3.3.0 - A Project Management Software Copyright (c) 2006, 2007, 2008, 2009, 2010, 2011, 2012 by Chris Schlaeger ch...@linux.com This program is free software; you can redistribute it and/or modify it under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation. org-tj3.tjp:11: Error: allocations is not a known attribute for this property purge allocations org-tj3.tjp:70: Warning: The keyword 'hierarchindex' has been deprecated! See the reference manual for details. columns hierarchindex org-tj3.tjp:70: Warning: The keyword 'completed' has been deprecated! See the reference manual for details. columns hierarchindex, name, start, end, effort, duration, completed org-tj3.tjp:77: Error: Unexpected token 'utilization' found. Expecting one of 'activetasks', 'annualleave', 'annualleavebalance', 'alert', 'alertmessages', 'alertsummaries', 'alerttrend', 'balance', 'bsi', 'chart', 'closedtasks', 'complete', 'completed', 'criticalness', 'cost', 'daily', 'directreports', 'duration', 'duties', 'efficiency', 'effort', 'effortdone', 'effortleft', 'email', 'end', 'flags', 'followers', 'freetime', 'freework', 'fte', 'gauge', 'headcount', 'hierarchindex', 'hourly', 'id', 'index', 'inputs', 'journal', 'journal_sub', 'journalmessages', 'journalsummaries', 'line', 'managers', 'maxend', 'maxstart', 'minend', 'minstart', 'monthly', 'no', 'name', 'note', 'opentasks', 'pathcriticalness', 'precursors', 'priority', 'quarterly', 'rate', 'reports', 'resources', 'responsible', 'revenue', 'scenario', 'seqno', 'sickleave', 'specialleave', 'start', 'status', 'targets', 'wbs', 'unpaidleave', 'weekly', 'yearly' columns no, name, utilization --8---cut here---end---8--- So, it seems that the output file is not up-to-date (tj v3.3.0), or do I miss something? tj3 support is still buggy. And tj export gets confused with the task_id tags. It does not generate unique IDs nor does it have manual ID marking. So it gets scrampled. So, for a bigger project it does not really work. Verify to use *Org Export Taskjuggler Target Version: ... *Org Export Taskjuggler Default Global Properties: ... *Org Export Taskjuggler Default Reports: ... I'm going further: --8---cut here---start-8--- TaskJuggler v3.3.0 - A Project Management Software Copyright (c) 2006, 2007, 2008, 2009, 2010, 2011, 2012 by Chris Schlaeger ch...@linux.com This program is free software; you can redistribute it and/or modify it under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation. Reading file org-tj3.tjp [ Done ] Preparing scenario Plan Scenario [ Done ] Scheduling scenario Plan Scenario[ Done ] Checking scenario Plan Scenario [ Done ] org-tj3.tjp:103: Warning: The report frame has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:109: Warning: The report frame.index has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:114: Warning: The report frame.report3 has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:127: Warning: The report frame.development has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:132: Warning: The report frame.report5 has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:137: Warning: The report frame.report6 has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:190: Warning: The report status has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:198: Warning: The report status.dashboard has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:213: Warning: The report status.completed has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:217: Warning: The report status.ongoing has no 'balance' defined. No cost or revenue computation will be possible. org-tj3.tjp:221: Warning
Re: [O] Creating Gantt charts by Exporting to TaskJuggler 3.3.0
Hi Giovanni, thanks for info. I will give this a try when I'll find the time. At the moment, because of the scrambled handling of task_ids it is not really usable. Let's see what he fixed in it. Best regards, Matt Am 14.09.2012 17:09, schrieb Giovanni Ridolfi: Hi, Seb, Buddy Butterfly wrote: Am 14.09.2012 15:13, schrieb Sebastien Vauban: I'm trying to use the export to TJ3 on Windows (I installed Ruby from Cygwin), but don't succeed to get the first view of the project, as shown on http://orgmode.org/worg/org-tutorials/org-taskjuggler.html. almost one month ago Yann Hodique proposed 10 patches for the taskjuggler exporter, please see: http://article.gmane.org/gmane.emacs.orgmode/58851 Bastien has a branch with these patches, but he'll apply them when he will have received the FSF papers signed. I hope soon :-) But I'm pretty sure you can apply them to your file. cheers, Giovanni
Re: [O] Creating Gantt charts by Exporting to TaskJuggler 3.3.0
Hi Yann, thanks a lot for your effort. This really sound very interesting. And I am willed to report further issues to you. I will try to nail them down more precisely. The biggest change I would do is to make the properties more generic. Something like prefixing all properties with a special prefix (configurable) like tj_ and just pass them all over to tj. This would allow the user to use all properties that are, were and will be available for tj versions and not having the exporter document we support this and that property in this and that version of tj Best regards, Matt Am 14.09.2012 17:55, schrieb Yann Hodique: Buddy == Buddy Butterfly buddy.butter...@web.de writes: Am 14.09.2012 17:09, schrieb: Hi, Seb, almost one month ago Yann Hodique proposed 10 patches for the taskjuggler exporter, please see: http://article.gmane.org/gmane.emacs.orgmode/58851 Bastien has a branch with these patches, but he'll apply them when he will have received the FSF papers signed. I hope soon :-) But I'm pretty sure you can apply them to your file. cheers, Giovanni Hi Giovanni, thanks for info. I will give this a try when I'll find the time. At the moment, because of the scrambled handling of task_ids it is not really usable. Let's see what he fixed in it. Hi, actually, those patches have been merged in master already (now that the paperwork is in order :)) That said, I don't think it'll fix anything regarding task_id handling. I started using TJ with versions 3.x, so I'm not sure what problem you're talking about exactly. At the moment I'm kinda contemplating doing a major rewrite of the TJ exporter to use the org-export framework, which would make it easier to introduce things like task references through org links, and so on. If I can fix a thing or two in the process, I'd be happy to. So, if you have specific limitations in mind, feel free to elaborate. Cheers, Yann.
