Hi all,<br><br>I'm a long time pythonista, *nix addict and CTO of a java developpement team working on a healthcare<br>system based on an apple framework named WebObjects.<br><br>I'm intensively using yokadi for a few days now (since the post on <a href="http://linuxfr.org">linuxfr.org</a>), and I found it very very useful.<br>
<br>I think that Aurelien is right when he says "Yokadi would be more usable if it featured a<br>
natural language". <br><br>In my usage, I always have yokadi opened on one of my screens, in order to log some work items while developping. The quicker the task is logged, the quicker I can go back to my developpments?<br>
<br>Logging tasks using natural language would be great, I already started to think about it, I will post some more thoughts a little later.<br><br>Just an exemple, logging some work items :<br>Add task Refactor javadoc comments on class ZZZ to project Medical file.<br>
<br>In this case this would trigger the command do_add, extract the first word to check the kind of data the user wishes to add (task, project, bug). <br>The problem here will be the project definition, the "to" keyword is commonly used and would turn impossible an accurate data extraction of the project name. It could be replaced by a camelcased keyword like "toProject", this will also allow multi word project name.<br>
This could easily be achieved using regexp, to match instructions and to extract the data.<br><br>Thanks for this good little piece of software<br><br>Regards<br><br>FJ<br><br><br><br><div class="gmail_quote">On Tue, Feb 10, 2009 at 10:56 PM, Aurélien Gâteau <span dir="ltr"><<a href="mailto:aurelien.gateau@free.fr">aurelien.gateau@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sébastien Renard wrote:<br>
>> I do not think it is a good idea: it complicates the parser,<br>
><br>
> That's not a nice part. I admit.<br>
><br>
>> and add<br>
>> more than one-way-to-do-it.<br>
><br>
> Do you want to remove the -k ?<br>
<br>
I would rather revert the change :/. If we want to go for @keyword, then<br>
I believe we should have a reflexion on our usage of OptionParser. I<br>
sometimes wonder whether Yokadi would be more usable if it featured a<br>
natural language.<br>
<br>
>> I agree it saves two keystrokes ("@" vs "-k<br>
>> "), but we could save more by implementing keyword tab completion.<br>
><br>
> We do have ;-). Try it with t_list. But it does not work for t_add for now. It<br>
> needs more work.<br>
<br>
Indeed, I miss it for t_add. I just added it to my TODO list.<br>
<br>
>>> - project are not mandatory. Yes, we have the default project, but it<br>
>>> could be better.<br>
>> Right now the default project is not very useful: to add a task to the<br>
>> default project one need to create a one word task with "t_add", this<br>
>> does not happen really often. To allow project-less tasks, we would need<br>
>> to make the project name an optional parameter.<br>
><br>
> Yes. But the "first word" position of project is a problem for that... And in<br>
> the other hand, it is a simple solution to manage project. The t_edit make it<br>
> easy to change project.<br>
> Could we say that project are just a special keyword named project ?<br>
<br>
I am not sure I understand what you mean. Early versions of Yokadi did<br>
not have projects: I thought projects could be implemented as keywords.<br>
It turned out to be annoying to use... I can't remember why, though.<br>
<br>
>>> - allow to add keyword to project, so I can declare a project @work or<br>
>>> @dev or @buy. It save me to put the keyword on each tasks. Every tasks in<br>
>>> the project inherit from project keyword. This will change the database<br>
>>> model. No patch provivded for now, I am waiting for your thought and<br>
>>> approval first.<br>
>> I am not sure I understand. Can you give a more explicit use-case?<br>
><br>
> I have some project related to work. I don't want to add keyword "work" to all<br>
> of tasks in those project. And I would like to make a t_list -u @work<br>
><br>
> Same things for dev project or linux or kde project...<br>
><br>
> I could use project hiearchy for that, but that's unidimensional...<br>
<br>
OK I see. So "t_list -k work" would list all tasks with the "work"<br>
keyword and all tasks whose projects have the "work" keyword, am I correct?<br>
_______________________________________________<br>
Ml-yokadi mailing list<br>
<a href="mailto:Ml-yokadi@sequanux.org">Ml-yokadi@sequanux.org</a><br>
<a href="http://sequanux.org/cgi-bin/mailman/listinfo/ml-yokadi" target="_blank">http://sequanux.org/cgi-bin/mailman/listinfo/ml-yokadi</a><br>
</blockquote></div><br>