Bug 135338 - More options for when keyboard is inactive
Summary: More options for when keyboard is inactive
Status: RESOLVED DUPLICATE of bug 50112
Alias: None
Product: ktimetracker
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Nigel McNie
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-09 13:48 UTC by Nigel McNie
Modified: 2007-09-21 17:59 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nigel McNie 2006-10-09 13:48:28 UTC
Version:           1.6.0 (using KDE KDE 3.5.4)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Hi :). I've just discovered karm, and I like how it detects inactivity and gives you the options "revert and stop", "revert and continue" and "continue".

Sometimes I switch to another task due to circumstances that cause me to not be able to change the task I'm working on (away from desk talking about the task when a new one comes along for example). It would be really nice if I could say "During the away time I was working on _that_ task, but revert to the old one, or even just continue working on the new one.

Otherwise, I'm not sure exactly how long the last idle time was and I have to guess it and do some fancy editing of the tasks.

The UI/dialog for the idle time box would probably have to change a little bit, perhaps to add a dropdown to choose the task I was working on.
Comment 1 Thorsten Staerk 2006-10-09 18:05:01 UTC
Pro: your usecase
Contra: it bloats the UI

I am not really sure this is good, however I neither think this is bad.
Comment 2 Nigel McNie 2006-10-10 13:34:58 UTC
Perhaps I could have a bash at prototyping this feature? I would like to learn a bit more about coding in KDE, and perhaps something like this is an interesting way to get me started :)

If you could point me to a few instructions on how to get set up (where svn is, any special build requirements or instructions etc...), I would be most grateful. (perhaps send by e-mail if they're a bit "off topic" for this bug).
Comment 3 Thorsten Staerk 2006-10-11 12:20:40 UTC
http://wiki.kde.org/ktimetracker should link to all this.
Comment 4 Thorsten Staerk 2007-08-03 09:10:36 UTC
This makes the UI too complicated.
Comment 5 Nigel McNie 2007-08-03 09:47:15 UTC
Fair enough. Sorry I didn't get around to mocking up the UI, I only got as far as a dev version of KDE installed and looking at the code :(
Comment 6 Thorsten Staerk 2007-08-03 10:26:11 UTC
Let's assign this bug to you, then it can stay open.
Comment 7 Thorsten Staerk 2007-08-03 10:27:09 UTC
If you provide a sensible patch, I will add it.
Comment 8 Nigel McNie 2007-08-03 14:01:24 UTC
Probably not worth bothering, I find it most unlikely that I will get back to doing this, as I am tracking my time using other methods.
Comment 9 Hal 2007-09-21 10:27:02 UTC
I have a comment on this.  I just discovered this tool today, and it is just what I need.  I work on a task which is composed of subtasks.  All of the subtasks need to be broken out for billing purposes.   I am using the task tracking mechanism which, as so many others have said, is the most convenient aspect of this tool.  (Great thinking!)

But I have a few nitpicks with this tool.  For one, I think only one task or subtask should be running at any one time in order to assure that all of my subtask work adds up to the total amount of time spent on each main task.  For my work, it would be unethical to double or triple charge.  Is it possible to have an option to enforce that only one level of a main task (that is, either the main task itself or any one of its subtasks) be allowed to run at any one time?

Another issue (I think Nigel was pointing to a similar issue) is that I would like to return to the task I was last working on by default.  At that point, I would like to be prompted regarding the elapsed time, just as it stands now.  But I don't want to have to EDIT each subtask to be able to restart this way.  For one thing, it means all subtasks that are set to task tracking will be started, which again violates the discipline I pointed out in my first complaint, above.

So ... how about this?  What if I can set a global option to track ALL tasks.  That will do 2 things:  (1) Enforce the discipline that only one task or subtask can be running at any one time, and (2) the tool will automatically pick up from the last task or subtask I was timing previously.  The idle time interface does not have to change, and shouldn't change.  This should simplify things a bit, both in programming and user comprehension.  Best of all, the existing behavior of the tool does not have to change for anyone currently using it.

Would this be very difficult to implement?
Comment 10 Hal 2007-09-21 10:32:55 UTC
I need to clarify my idea a bit:  When I say "return to the last task I was working on," I meant in THAT particular desktop.  Again, only one task or subtask timer would be running at one time.  To be most general and save you all coding grief, you might as well do this for any task OR subtask.  That way, you can treat the code orthogonally, and users (if using my global option idea) could have each subtask on a different desktop!

Actually, all of this seems much more natural to me to start with, but I am probably biased or not seeing some problem with my suggestion.  If so, forgiveness requested ahead of time.
Comment 11 Hal 2007-09-21 10:36:51 UTC
Hey (as if I haven't said enough already ...)

What might be REALLY cool is if there were a way so that if I use the tool interface to select a different task (double click), the tool would automatically switch desktops for me.  Maybe that is asking a bit much though.  Just an idea, certainly not a got-to-have.
Comment 12 Thorsten Staerk 2007-09-21 17:59:12 UTC
... and your wish is fulfilled

*** This bug has been marked as a duplicate of 50112 ***