Feature request: Quicker command for starting or continuing a previous time entry

[tdnzr]

My most common use case in TogglTrack is to continue or restart a time entry I've used frequently in the past.

Let's take the example from my previous issue: I have a "take a walk" time entry in the "Exercise" project, and want to start or continue a new "take a walk" time entry.

The quickest commands I've found for this are:

• "tgl start Exercise" -> Enter -> "take a walk" -> Enter
• "tgl s" -> Enter -> "Ex" -> Enter -> "take a walk" -> Enter
• "tgl continue ta" -> Enter -> Enter (the second Enter is for the "Start take a walk now" option)
• "tgl c" -> Enter -> "ta" -> Enter -> Enter (the second Enter is for the "Start take a walk now" option)

I wish there were quicker commands to do this.

Here are the kinds of commands I wish for. I don't care about the specifics, just about the number of characters and Enters required.

1. The ability to continue a time entry without needing the final Enter, e.g.:

• "tgl continue ta" -> Enter
• "tgl c" -> Enter -> "ta" -> Enter

2. Plus maybe the ability to start a time entry by referring to a previous entry, without having to first specify the project (but maybe this is just what the "continue" command is for):

• "tgl start take" -> Enter

3. Plus maybe the ability to start a new, never-before-used time entry (like "mow the lawn"), without having to first specify the project:

• "tgl start mow the lawn" -> Enter

EDIT: Or maybe even:

4. The ability to continue a time entry without needing the "continue" command at all: (I assume that if this was implemented, it would have to be as a plugin setting.)

• "tgl ta" -> Enter

5. Plus maybe the ability to start a new, never-before-used time entry (like "mow the lawn"), without needing the "start" command at all: (I assume that if this was implemented, it would have to be as a plugin setting.)

• "tgl mow the lawn" -> Enter

[JamesNZL]

@tdnzr again, thanks heaps for the thorough suggestion.

Plus maybe the ability to start a time entry by referring to a previous entry, without having to first specify the project (but maybe this is just what the "continue" command is for):

Yeah, this is basically the only purpose of the continue command.

Plus maybe the ability to start a new, never-before-used time entry (like "mow the lawn"), without having to first specify the project:

What would you suggest the default project to be, in that case?
My concerns are that regardless of whether the plugin assumes No project or the last-used project, the user is still likely to need to launch Toggl and amend the project—something that will take much longer than just selecting the project at creation.

EDIT: Or maybe even:

Noted all these, really appreciate your suggestions and specifications.

I've kept this issue in the back of my head over the past few days and come up with some potential suggestions—I'd appreciate your feedback and thoughts.

Possible Solutions

1. tgl now

Start a new time entry now, with the same flow as tgl start except skipping the final selection.

Settings

Setting	Default	Description	Remarks
Command Enable	false	Enable the command.	Default disable as I feel this overlaps too heavily with tgl start and is likely to be confusing and cumbersome for regular users.
Skip Project Selection	false	Skip project selection.	If true, a 'default' project is inferred.
Default Project	No project	Default project.	If Skip Project Selection is true, the time entry is created under this project.

2. Saved timers

Allow saving timers with a numeric identifier (or description if that is what you want?).
Created with tgl <id>.

Settings

Setting	Default	Description	Remarks
Skip Start Time Selection	false	Skip start time selection.	Whether to always skip the final start time selection and start the time entry now.

3. tgl <description>

The list of results will contain:
a. a fuzzy match of the plugin commands that match <description>,
b. a fuzzy match of the previous time entries that match <description>, and
c. the start option for <description>.

Settings

Setting	Default	Description	Remarks
Feature Enable	false	Enable the feature.	Default disable as it is likely to be confusing and cumbersome for regular users.
Default Project	No project	Default project.	If creating a new time entry, it will be created under this project.
Skip Start Time Selection	false	Skip start time selection.	Whether to skip the final start time selection for the new/previous time entry.
Hide Commands	false	Hide standard plugin commands.	Whether to hide standard plugin commmands (eg start, stop, edit) behind a flag (eg -c).

Let me know what you think!

[tdnzr]

Wow you've thought this issue through! I'll have to ask a bunch of clarifying questions, though.

Regarding your solutions

Re: solution 1:

[tgl now:] Start a new time entry now, with the same flow as tgl start except skipping the final selection.

I don't quite understand what this command is doing. The start flow is tgl start project_name -> Enter -> time_entry_name -> Enter.
So if the new command is supposed to skip the final selection, is the command intended to be tgl project_name -> Enter, in order to create an unnamed time entry in a chosen project? Or is it supposeed to be tgl time_entry_name -> Enter, in order to create a new time entry without a project / in a default project?

Or is now a command, rather than a time_entry_name, and it's tgl now time_entry_name -> Enter? Ah, I think it must be that.

Re: solution 2:
I personally wouldn't really make use of saved timers. The thing I like about using a time-tracking service like TogglTrack is that all entries I've ever tracked are searchable including auto-complete. And if I use the same phrasing each time, then the reports become more meaningful. E.g. if I always call the time entry "take a walk", rather than occasionally calling it "go for a walk", then I can easily see how much time I spend on this during each time period. So how I mostly use TogglTrack is to use the desktop or Android app, type part of the time entry, then select an option I've tracked previously. See this screenshot for an example. This also means that my projects are usually pre-selected, and I only have to manually select a project whenever I decide to create a new time entry.

Re: solution 3: I'm not sure I understand this right, and might need examples. Maybe the thing I'm suggesting below comes somewhat close to it?

---

In general, I like the option to skip the "start time selection" at the end, because usage of it might differ a lot by user, and for those who don't use it, it currently costs an extra keypress. But it doesn't have to be a setting, and it might be desirable in general if such problems can be solved without adding settings. Something like your "now" command seems like a decent alternative to creating a new setting. Or maybe you could skip the start time selection by default unless a user appends -t or something? Based on the philosophy that the default UI should be as quick as possible, whereas it's fine if special cases require more clicks.

Another angle of attack

Looking at this topic from another angle, have you considered taking inspiration from, or outright copying, the official TogglTrack syntax / flow? The official devs of a time-tracking service have presumably thought a great deal about topics like "how do I create a time entry and quickly assign a project to it". In this case, here is their solution:

To quickly add information to a time entry, use @ for Projects and # for Tags while entering a description. This setting can be disabled from your Profile page.

So if you type "take a walk @" in TogglTrack web, then the Projects selection opens, you select a project, and then you're back at "take a walk", except that now the selected project has been assigned. Similarly, if you type "take a walk #", then the tag selection menu opens, you select any number of tags, and then you're back at "take a walk", except that now the selected tags have been assigned.

So here's a sketch of how something like this could look like in the FlowLauncher plugin:

1. tgl time_entry_name -> Enter

If time_entry_name already exists, continue it. If it doesn't, start it with no project or a default project.

2. tgl time_entry_name @

As soon as the @ (or another chosen keyword symbol) appears, FlowLauncher displays the same project selection menu as it currently does when typing tgl start, including the ability to quickly search a project via typing part of the project name.

I'm not sure how to conclude the project selection via this suggested command, though. I'd prefer to select the project and directly start the time entry with a single Enter, because that's less clicks. But then one can't continue with the potential tag selection.

Ah, maybe it could work like this:

tgl ta -> Enter to autocomplete to 'take a walk' and start the time entry.
tgl ta -> Tab to autocomplete to 'take a walk' and not start the time entry -> "@Ex" -> Enter to autocomplete to "Exercise" and start the time entry with the assigned project.
tgl ta -> Tab to autocomplete to 'take a walk' and not start the time entry -> "@Ex" -> Tab to autocomplete to "Exercise" and not start the time entry. So now we could even add tags as desired.

3. tgl time_entry_name #

Optionally, tag selection could happen via the same logic. However, time entries can have multiple tags, and each tag can consist of multiple space-separated words, so I'm not sure how the flow or syntax here would have to look like. Maybe #tag_1_name, tag_2_name, tag_3_name, incl. stripping whitespace after the commas.

---

Overall I'm not married to this specific syntax suggestion, though it does sound pretty fast. I just find the default flow of "select project" -> "optionally name time entry" less intuitive than "name time entry" -> "optionally select project". Though now that I think about it, if you used an @-syntax, then I guess both variants could be supported, i.e. both tgl time_entry_name @Exercise, as well as tgl @Exercise time_entry_name.

Such a syntax would also allow both creating projects with unnamed time entries, and time entries without assigned project. And the syntax based on optional keywords would obviate the need to implement a bunch of extra settings.

[JamesNZL]

Or is now a command, rather than a time_entry_name, and it's tgl now time_entry_name -> Enter? Ah, I think it must be that.

Yeah, this was what was intended.

I've also just now realised that this wouldn't actually be any less keystrokes (unless Skip Project Selection is true) than tgl start—just less start options at the end.

Probably not this solution.

---

I personally wouldn't really make use of saved timers.

Fair, neither.

Also agree with the rest of your statements; that's primarily how I use Toggl too.

---

Re: solution 3: I'm not sure I understand this right, and might need examples. Maybe the thing I'm suggesting below comes somewhat close to it?

Think of this as a different plugin 'mode'; one that is suited for advanced users who are specifically looking for ⚡ blazing fast time entry creation.

Hence, this mode needs to be explicitly enabled in the settings.

tgl triggers the plugin, as it does currently.
tgl ta will continue fuzzy searching for matching commands, in this case, start.
But, there will be a new result to Start ta now, using the configured Default Project.
And, the results will include a fuzzy match for previous time entries matching 'ta', ie the list of results currently shown by tgl continue ta.

In this case, selecting a time entry will either pull up the standard start time selection (so this skips the keystrokes needed to enter the continue command), or it will immediately start the time entry now, depending on the Skip Start Time Selection setting.

If you want to specify a project for a new time entry, you will have to use the standard tgl start command; this express flow will always just use the Default Project.

Hide Commands just controls whether plugin commands are included in the fuzzy search, or if the default behaviour is only to start/search previous time entries.
In this case, plugin commands can be accessed by eg tgl -c stop.

---

In general, I like the option to skip the "start time selection" at the end, because usage of it might differ a lot by user, and for those who don't use it, it currently costs an extra keypress. But it doesn't have to be a setting, and it might be desirable in general if such problems can be solved without adding settings. Something like your "now" command seems like a decent alternative to creating a new setting. Or maybe you could skip the start time selection by default unless a user appends -t or something? Based on the philosophy that the default UI should be as quick as possible, whereas it's fine if special cases require more clicks.

Noted.

One thing I think to acknowledge with this discussion though is that removing start time selection wouldn't actually save any keypresses for tgl start—there ultimately needs to be a final Enter once the user has finished typing their time_entry_name.

What it would save is on tgl continue, where it'd just immediately restart the selected time entry now.

---

Looking at this topic from another angle, have you considered taking inspiration from, or outright copying, the official TogglTrack syntax / flow? The official devs of a time-tracking service have presumably thought a great deal about topics like "how do I create a time entry and quickly assign a project to it". In this case, here is their solution:

I have; this was what I first had in mind.

I'll outline the primary reason I had for not implementing this in flow-toggl-plugin; consider the following scenario:

You want to create a time entry called Email support@jamesnzl.xyz.

1. You launch Flow.
2. You type tgl to trigger the extension.
3. You type start to start a new time entry.
4. You start typing Email support@.

   This now pulls up the project selection panel.

5. You hit Esc to exit the project selection panel.

   While this works fine on Toggl as they have full control over their UI, this keystroke in Flow causes the entire search to be lost.

Furthermore, I also came at this from the perspective that setting projects was the norm, and not the exception—it saves keystrokes by automatically entering project selection at the start, rather than requiring an extra @ keystroke every time you want to assign a project.

Do you think this an incorrect assumption?

I suppose I could take further inspiration from Toggl and implement the ability to

This setting can be disabled from your Profile page.

but this does not feel like the right solution; it simply hides painful behaviour behind a sign-up form.

---

"@ex" -> Tab to autocomplete to "Exercise" and not start the time entry. So now we could even add tags as desired.

While this is great in theory, I'm afraid this isn't currently possible to implement.

Tab auto-completion/Enter actions are part of Flow's APIs—while Action takes a full function that can perform side-effects and contain any internal logic you might want, AutoCompleteText is limited to only a string that Flow will auto-complete for you.

This would not work for auto-completion as project names are not unique, so there must be some internal state coupled with project selection to remember the project's unique id, and not just its name (hence why I display the selected project name in kebab-case, as it's not actually used to identify the project).

The only way I could do this is by auto-completing the project id directly, and parsing this later—but that would give tgl take a walk 781233 —not exactly the friendliest UI.

Note
Do you disagree? Thoughts?

---

However, time entries can have multiple tags, and each tag can consist of multiple space-separated words, so I'm not sure how the flow or syntax here would have to look like.

Yeah, this is exactly why I've just completely avoided tags thus far.
CSV could work, but only if tag names cannot have commas in them.

I personally don't use tags so this is not a problem for me, but please do let me know if this is a feature you are in need of.

---

I just find the default flow of "select project" -> "optionally name time entry" less intuitive than "name time entry" -> "optionally select project".

That is fair.

Another consideration I had for the existing flow is ease of implementation, as well as ease of use:

1. It is much easier if the project name (or no-project for the lack thereof) is guaranteed to be a single string at the first index after the command.

If the project can be specified anywhere in the query with the @ symbol, I see this providing two possible issues:

2. If @Project selects the project, but does not include it in the query, then there is no way for the user to remove/change the project.

   Unless all subsequent @ symbols restart project selection—but then there is no way for an @ symbol to be included in the time_entry_name.

   Unless we then implement \@ escaping, but... ease of use?

3. If @Project selects the project, but does include it in the query, it becomes very difficult to parse what is time_entry_name, and what is project_name.

   We could use the @ symbol, but this causes issues again if there is a @ in the time_entry_name.

   We could update the query once the project is selected to prepend the project name—eg tgl time_entry_name @Exercise -> tgl exercise take a walk.
   This would let me keep the same parsing logic, and still let you specify the project after the time_entry_name with @.
   But see the previous points about permitting @ symbols in the time_entry_name.

---

I must admit, I am personally of the opinion to prefer adding settings to hide this more advanced, 'need-to-rtfm' behaviour from 'typical' users that just want something simple that works.

Note
Keeping in mind, the user will have to visit the settings panel to set their API token.

For the most part, Tab auto-complete and Enter currently do the exact same thing except for the final action (except project selection, for the reasons outlined above—have you noticed this?).

I'd be hesitant to change to an implementation where the user needs to rely on Tab for functionality, as I suspect there would be a non-zero user base that just uses the mouse to make selections—ie analogous to the Enter key.

---

I know this comment is a little verbose, but I hope it gives some insight into the design constraints and philosophy!

Please let me know any thoughts you have.

Personally, I am leaning towards my original solution 3.

[tdnzr]

Preface: We might be reaching a point in this discussion where it has become technical enough that my ability to meaningfully contribute is limited, because I'm not familiar enough with the design constraints of FlowLauncher plugins.

With that being said:

Think of this as a different plugin 'mode'; one that is suited for advanced users who are specifically looking for ⚡ blazing fast time entry creation.

Hence, this mode needs to be explicitly enabled in the settings.

I'm still envisioning an implementation that's better for everyone, not just power users, so that no extra settings need to be enabled. For example, my personal impression of the current "start" workflow was that it was unintuitive for new users and hence necessitated a tutorial or explanation; a different flow might not have had that problem.

But maybe there's no such implementation that would make everyone happy.

You want to create a time entry called Email support@jamesnzl.xyz.

Is this a common use case?

If it isn't common, it's fine to implement a workaround like escape characters (to type @ in a time entry, you must type \@), or to provide a setting where you can choose the keyword character (and e.g. replace @ with §).

If it is common, but this is the only case where an @ is annoying, then an alternative would be to have FlowLauncher only react to the @ if it's preceded by a space, i.e. tgl time_entry_name @.

Furthermore, I also came at this from the perspective that setting projects was the norm, and not the exception—it saves keystrokes by automatically entering project selection at the start, rather than requiring an extra @ keystroke every time you want to assign a project.

Do you think this an incorrect assumption?

It is for me, but that's just anecdotal and doesn't mean anything. However, this assumption is also contrary to how TogglTrack natively works: whether in mobile, desktop, or browser, the default UI is always to name the time entry and then optionally assign a project or continue a previous task.

... Though now that I think about it, that might not be quite correct: the TogglTrack UI is even more focused on speed than me, and provides a ton of ways to start a time entry that lacks both a name and a project. E.g. on desktop, this can be done via either Ctrl+N, or by directly clicking on the white-in-purple TogglTrack arrow in the app. And on Android, both the in-app UI and its widgets support the same. I'm not sure whether to consider that TogglTrack's default workflow or the one where you only name the time entry, but there's no comparable one where you must first select the project.

Tab auto-completion/Enter actions are part of Flow's APIs—while Action takes a full function that can perform side-effects and contain any internal logic you might want, AutoCompleteText is limited to only a string that Flow will auto-complete for you.

Point taken, then that implementation doesn't work, and I'm not familiar enough with the APIs to see whether it could be adapted to make it work. I don't see the point of auto-completing project ids.

I personally don't use tags so this is not a problem for me, but please do let me know if this is a feature you are in need of.

I don't use them much, but TogglTrack copies them when I continue a time entry. (So if my "take a walk" time entry had the project "Exercise" and the tag "outside", then continuing it would copy both the project and all its tags.) So as long as this plugin does that part correctly, I wouldn't personally be missing the ability to manually add or edit tags. If it didn't copy tags, then the problem would IIRC be that TogglTrack proper only groups time entries together if they have the same name, project, and tags. So if the tags for continued time entries aren't copied, then the grouping in the Reports view would no longer work entirely correctly.

---

Finally, I had another thought re: optionally assigning projects: Is the following adaptation of your solution 3 possible?

tgl <description>
The list of results will contain: (in order of prioritisation)
a. a fuzzy match of the plugin commands that match <description>, (though I'm not sure how highly this should be prioritised in the results)
b. a fuzzy match of the previous time entries that match <description>, and to then directly continue this time entry (as in Continue <description>)
c. the start option for <description>, and to then directly start this time entry (as in Start <description>)
d. the start option for <description>, and to then assign a project (as in Assign project to <description>)

[JamesNZL]

Preface: We might be reaching a point in this discussion where it has become technical enough that my ability to meaningfully contribute is limited, because I'm not familiar enough with the design constraints of FlowLauncher plugins.

Fair, I'll try to keep the discussion higher-level and design-focussed.

---

I'm still envisioning an implementation that's better for everyone, not just power users, so that no extra settings need to be enabled. For example, my personal impression of the current "start" workflow was that it was unintuitive for new users and hence necessitated a tutorial or explanation; a different flow might not have had that problem.

But maybe there's no such implementation that would make everyone happy.

I'll admit, I think I am coming around to the idea that, if properly implemented, I agree—this might not need to be hidden behind a setting.

I can see this removing the start and continue commands in the commands list.

With a new Usage Tip instead saying to start typing to create a time entry, and now I think the flow makes much more sense—the process for starting a time entry (ie the most common usage) is to just start typing, while commands are available to perform operations on an existing time entry.

You're right; this also much better matches Toggl, where there is no separation between 'starting a new' time entry and 'continuing an existing' time entry. You just start typing, and it suggests a fuzzy match of past time entries.

---

However, this assumption is also contrary to how TogglTrack natively works: whether in mobile, desktop, or browser, the default UI is always to name the time entry and then optionally assign a project or continue a previous task.

... Though now that I think about it, that might not be quite correct: the TogglTrack UI is even more focused on speed than me, and provides a ton of ways to start a time entry that lacks both a name and a project. E.g. on desktop, this can be done via either Ctrl+N, or by directly clicking on the white-in-purple TogglTrack arrow in the app. And on Android, both the in-app UI and its widgets support the same. I'm not sure whether to consider that TogglTrack's default workflow or the one where you only name the time entry, but there's no comparable one where you must first select the project.

Hm, that's a really good argument.

I could do this by simply including a blank Start now option in the default options rather than waiting for the user to start typing before giving a start option.

---

Finally, I had another thought re: optionally assigning projects: Is the following adaptation of your solution 3 possible?

tgl
The list of results will contain: (in order of prioritisation)
a. a fuzzy match of the plugin commands that match , (though I'm not sure how highly this should be prioritised in the results)
b. a fuzzy match of the previous time entries that match , and to then directly continue this time entry (as in Continue )
c. the start option for , and to then directly start this time entry (as in Start )
d. the start option for , and to then assign a project (as in Assign project to )

This sounds like a great idea, actually.

It keeps the flow of <description> then <project>, but doesn't have any of the caveats of using @.

I am curious though—how do you see the start-time selection working for continuing a previous time entry?

New entries are fairly straight-forward; just add another option alongside Start now, but we can't have 2/3 start options for each previous time entry all on the same level.

I get the impression you don't use this feature; if so, the solution would probably to add a setting to skip the start time selection to save keystrokes.

Personally, almost every time entry I start stop uses custom start/stop times, so it's absolutely an essential feature for me.

---

Thanks again for all your input!

[tdnzr]

Thanks again for all your input!

This thread which began with my mere UI request eventually transformed into a surprisingly in-depth design discussion, so thanks for that :).

Personally, almost every time entry I start stop uses custom start/stop times, so it's absolutely an essential feature for me.

I'm not sure how useful this explanation is, but here's how I personally do vs. do not use custom starting times:

• Scenario: I'm at my PC and have an intention to do something right now. Then I start the timer at my PC, do the thing, and eventually stop the timer once I'm done (or, in case of a non-PC task, once I've returned to my PC). No custom start time necessary.
• Scenario: I'm at my PC and looking through my tasks list for something that catches my fancy. A while later I notice that I've apparently begun working on a task. Then I start a time entry in TogglTrack, and backdate it (in the Calendar tab, by dragging via the mouse) to whichever starting time seems most suitable based on the automatically recorded "activity timeline". Here I do use a custom starting time, but kind of need access to the visual calendar and activity timeline of the desktop app.
• Scenario: I'm doing something at my PC and am interrupted and asked to do something in another room. I usually remember to stop my current time entry, but don't necessarily remember or have the time to start the new time entry. In this case, I start the time entry a few minutes later in the Android app, and then do backdate it via the app's "set [Start time] to last stop time today" feature.

I am curious though—how do you see the start-time selection working for continuing a previous time entry?

New entries are fairly straight-forward; just add another option alongside Start now, but we can't have 2/3 start options for each previous time entry all on the same level.

I get the impression you don't use this feature; if so, the solution would probably to add a setting to skip the start time selection to save keystrokes.

Barring better alternatives, a setting seems like a decent solution here.

I considered an alternative like appending "-t" or something to let you specify a custom starting time. But that won't work, because the Enter command used to select the time_entry_to_continue is the one meant to either start it or to assign a project to it.

If the use case of backdating time entries was rare enough, then another alternative would be to lock backdating behind a new keyword (like a shorter synonym for "backdate"; or something like "running", to indicate an already-running time entry). In that case, the keyword-less command tgl <description> would always skip backdating, while tgl backdate <description> might follow the same flow as tgl <description>, except that its final step would always require backdating.

Or maybe we could skip the final step in that last suggestion by making the keyword itself do the backdating? I'm still not really happy about this solution, but it at least sounds a bit more elegant than requiring both a keyword and an extra step at the end. Something like: the keyword is actually backdate#, where # is a number in minutes. If # is omitted, then tgl backdate will always backdate to the last stop time. If # is not omitted, then e.g. tgl backdate27 <description> will backdate <description> by 27 minutes. If one wanted to be very cheeky, one could even let # be a negative number (e.g. tgl backdate-5 <description>), which would correspond to the "start N minutes from now" option in the plugin.

But I'm not enamored with my own suggestions here, so a setting seems fine.

[JamesNZL]

This thread which began with my mere UI request eventually transformed into a surprisingly in-depth design discussion, so thanks for that :).

Just goes to show that more perspectives and input always helps towards a better design :)

---

I'm not sure how useful this explanation is, but here's how I personally do vs. do not use custom starting times:

• Scenario: I'm at my PC and have an intention to do something right now. Then I start the timer at my PC, do the thing, and eventually stop the timer once I'm done (or, in case of a non-PC task, once I've returned to my PC). No custom start time necessary.
• Scenario: I'm at my PC and looking through my tasks list for something that catches my fancy. A while later I notice that I've apparently begun working on a task. Then I start a time entry in TogglTrack, and backdate it (in the Calendar tab, by dragging via the mouse) to whichever starting time seems most suitable based on the automatically recorded "activity timeline". Here I do use a custom starting time, but kind of need access to the visual calendar and activity timeline of the desktop app.
• Scenario: I'm doing something at my PC and am interrupted and asked to do something in another room. I usually remember to stop my current time entry, but don't necessarily remember or have the time to start the new time entry. In this case, I start the time entry a few minutes later in the Android app, and then do backdate it via the app's "set [Start time] to last stop time today" feature.

Makes sense.

I've personally never found the desktop apps nice to use (hence why this plugin was born).

---

Barring better alternatives, a setting seems like a decent solution here.

But I'm not enamored with my own suggestions here, so a setting seems fine.

I must admit, this idea

Something like: the keyword is actually backdate#, where # is a number in minutes. If # is omitted, then tgl backdate will always backdate to the last stop time.

actually sounds pretty cool.

But I agree, I'm not sure that it would work better in practice.

Do let me know if you think of anything else, but I think we've converged on a pretty nice solution.

I'll get around to working on this after I'm done with exams in 3 weeks, and let you know when I have a beta release so you can do some pre-testing if you'd like to.

PS notification settings were pushed in v2.4.0, this should be available to download in pm in the next day or so.

[JamesNZL]

Hey!

I've just merged something that I think ticks every box you mentioned!

Note
The only exception is that I decided to always prioritise Start ... now even if there is a matching past time query, just to ensure a constant frame of reference for the user—I don't really want the Start ... now action to get buried as soon as the user types any query :)

Please, please let me know what you think, and if you have any feedback!

I'm just in the process of putting up a pre-release, but this might not happen until tomorrow.

Regardless, here's a little recording:

2023-07-04.22-58-59.mp4

In terms of what is happening:

1. tgl take a walk > Enter

💡 This creates take a walk.

1. 1 keystroke for Enter.

2. tgl take a walk@flow > Enter > Enter

💡 This creates take a walk in flow-toggl-plugin.

1. 1 keystroke to select the project, and
2. 1 keystroke to create the time entry.

3. tgl take a walk@flow > Alt + Enter

💡 This directly creates take a walk in flow-toggl-plugin and skips the confirmation screen.

Note -t offsets will even still work, provided they were in the query before the @.

1. 1 (pair of) keystrokes to select the project & create the time entry.

4. tgl take > Select from results > Enter

💡 This continues talk a walk in flow-toggl-plugin.

Note
Selection of the result can be done with:

1. the mouse,
2. the arrow keys,
3. Ctrl + J, or
4. Flow result modifier (the specific one depends on your Flow settings):
   • Alt + num,
   • Ctrl + num, or
   • Ctrl + Alt + num.

Note Usage Tips can be disabled in the settings to reduce the clutter/distance to the continue results.

1. 1 (set of) keystroke(s) to select the result to continue, and
2. 1 keystroke to create the time entry.

5. tgl take > Alt + Enter

💡 This directly continues take a walk in flow-toggl-plugin at the present time and skips the confirmation screen.

1. 1 (set of) keystroke(s) to select and continue the time entry.

6. tgl take a walk -t 5@flow > Alt + Enter

💡 This directly creates take a walk in flow-toggl-plugin 5 minutes (4:59:59 by the time the result populates) in the future and skips the confirmation screen.

1. 1 (pair of) keystrokes to select the project & create the time entry.

9. tgl stop and tgl \stop

💡 tgl stop will enter the stop command as before, and only show stop actions.
To create a time entry beginning with 'stop' (or any other command), you can escape it as tgl \stop.

10. tgl @ and tgl \@

💡 As above for tgl \stop, but for project selection.

Note Project selection with @ doesn't need to be proceeded by a whitespace , so any desired occurrence of @ will need to be escaped as \@.

---

With respect to your initial request:

Here are the kinds of commands I wish for. I don't care about the specifics, just about the number of characters and Enters required.

1. The ability to continue a time entry without needing the final Enter, e.g.:

   • "tgl continue ta" -> Enter
   • "tgl c" -> Enter -> "ta" -> Enter

2. Plus maybe the ability to start a time entry by referring to a previous entry, without having to first specify the project (but maybe this is just what the "continue" command is for):

   • "tgl start take" -> Enter

3. Plus maybe the ability to start a new, never-before-used time entry (like "mow the lawn"), without having to first specify the project:

   • "tgl start mow the lawn" -> Enter
     EDIT: Or maybe even:

4. The ability to continue a time entry without needing the "continue" command at all: (I assume that if this was implemented, it would have to be as a plugin setting.)

   • "tgl ta" -> Enter

5. Plus maybe the ability to start a new, never-before-used time entry (like "mow the lawn"), without needing the "start" command at all: (I assume that if this was implemented, it would have to be as a plugin setting.)

   • "tgl mow the lawn" -> Enter

these are all implemented now, with no extra settings.

With respect to project selection:

So if you type "take a walk @" in TogglTrack web, then the Projects selection opens, you select a project, and then you're back at "take a walk", except that now the selected project has been assigned. Similarly, if you type "take a walk #", then the tag selection menu opens, you select any number of tags, and then you're back at "take a walk", except that now the selected tags have been assigned.

So here's a sketch of how something like this could look like in the FlowLauncher plugin:

1. tgl time_entry_name -> Enter
   If time_entry_name already exists, continue it. If it doesn't, start it with no project or a default project.
2. tgl time_entry_name @
   As soon as the @ (or another chosen keyword symbol) appears, FlowLauncher displays the same project selection menu as it currently does when typing tgl start, including the ability to quickly search a project via typing part of the project name.

I'm not sure how to conclude the project selection via this suggested command, though. I'd prefer to select the project and directly start the time entry with a single Enter, because that's less clicks. But then one can't continue with the potential tag selection.

Done.

With respect to creating a blank entry:

... Though now that I think about it, that might not be quite correct: the TogglTrack UI is even more focused on speed than me, and provides a ton of ways to start a time entry that lacks both a name and a project. E.g. on desktop, this can be done via either Ctrl+N, or by directly clicking on the white-in-purple TogglTrack arrow in the app. And on Android, both the in-app UI and its widgets support the same. I'm not sure whether to consider that TogglTrack's default workflow or the one where you only name the time entry, but there's no comparable one where you must first select the project.

Also done.

[JamesNZL]

@tdnzr

[JamesNZL]

You can also check out the updated Command Reference.

[JamesNZL]

A pre-release is available on the Releases page.

To test:

1. Download Flow.Launcher.Plugin.TogglTrack.zip
2. Open your Flow Launcher folder by typing userdata into Flow
3. Navigate to [userdata] > Plugins
4. Delete the existing Toggl Track-x.x.x folder (you may need to exit Flow first)
5. Unzip the contents of Flow.Launcher.Plugin.TogglTrack.zip into a new folder in [userdata]/Plugins (name doesn't matter)
6. Restart Flow

😄

[tdnzr]

Hey there, thanks for the update! I apologize for the belated reply; I've unfortunately been sick for the past few weeks.

I've already updated to the new TogglTrack plugin version (v4.0.0-0 according to FlowLauncher), and am currently using both the FlowLauncher plugin and the TogglTrack desktop app to track my time.

IIRC I liked the TogglTrack desktop app more than you did, but I've noticed one case where I already prefer the updated FlowLauncher plugin: When I have a TogglTrack window open, switch to a different virtual desktop in Windows 11, and then click on the TogglTrack icon to track my time, then I'm brought back to whichever virtual desktop the TogglTrack window is on. This problem does not occur with FlowLauncher plugins.

I still intend to read your preceding comment and to systematically test the new command flow, but I don't want to make any promises on the timeframe.

[JamesNZL]

No worries!

Take it easy :)