nikolassv / bartib Goto Github PK

I suppose that Bartib will not calculate the seconds.

however, it will record the tasks that took only a few seconds and show 0s in it's duration.

this is tricky. I will suggest either not to record such an activity or calculate also the seconds.

here's an example

PS C:\Users\me> date
Monday, March 20, 2023 1:08:52 PM
PS C:\Users\me> bartib start -d "task1" -p "project1"
Started activity: "task1" (project1) at 2023-03-20 13:09
PS C:\Users\me> date
Monday, March 20, 2023 1:09:11 PM
PS C:\Users\me> bartib stop
Stopped activity: "task1" (project1) started at 2023-03-20 13:09 (16s)
PS C:\Users\me> date
Monday, March 20, 2023 1:09:21 PM
PS C:\Users\me> bartib list
Started Stopped Description Project  Duration

2023-03-20
13:09   13:09   task1       project1 0s      

Thanks for the great application. I love it's simplicity.

Though, I'd love to make it a tad less simple, by introducing a "round" feature.

I build invoices from my timetracking, and I copy it to other time-trackers when clients need that. Many of those have minimum timespans. For invoicing, I never work less than 15 minutes. One system I'm working in, only works with 10 minutes. And so on.

I'd love to add a flag to both report and list that rounds to the nearest whole N.

e.g. `bartib report --round="10m" which would round to 10 minutes. So, say we have:

    guidelines............ 1h 40m
    meeting ..............    29m
    research project scope 1h 12m

And we run it with --round=10m it would show:

    guidelines............ 1h 40m
    meeting ..............    30m
    research project scope 1h 10m

But when we run it with --round=1h it would show:

    guidelines............ 2h
    meeting ..............    0h
    research project scope 1h

Obviously, time tracked is as granular as it is now. Just the output is rounded.

Would this be a feature you'd accept? If so, I'll make a PR for it, and add some tests for it.
In that case: should I be aware of any on-going refactorings that I'd best wait for?

The current output of bartib help start makes it seem like the project and the description are optional, but they aren't. If you try to run bartib start -d "Description", bartib replies with a panic. I had to go to the source code to understand what was happening.

❯ bartib start -d "Description"                                    
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/italo/.cargo/registry/src/github.com-1ecc6299db9ec823/bartib-1.0.0/src/main.rs:207:58          
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace  

You can fix this by marking the arguments as required on clap, or at least print a nice message explaining the problem.

For projects, I use scope-inspired area::project-name syntax, for example an area in my life is maintainer/maintenance. One project is rustic. So for that I would use: maintenance::rustic.

bartib report

maintenance::github.............................. 1h 09m
    Updated dependencies of different projects... 1h 09m

maintenance::rustic..............................    16m
    Collected thoughts about a possible GUI impl.    16m

Total............................................ 1h 25m

But there are other projects in that area and in a report I would like to filter for one area with its projects. For example, report -p maintenance* or report -p maintenance::* doesn't work to show me a report for all projects within a certain area.

I'm aware, that adding another parameter to the report command and even an addition like area to the bartib activity file is too much of an ask. So my idea was to use wildcards for matching in a project, so people can implement their own scoping rules.

One library that might be useful for that, might be: https://github.com/becheran/wildmatch

I see that you are using clap for the CLI, there is https://crates.io/crates/clap_complete to automatically generate shell completions. It would be nice, to be able to generate completions for different shells by just calling bartib completions >> {my_shell_profile}. Here is a possible implementation: https://github.com/rustic-rs/rustic/blob/main/src/commands/completions.rs

Depending on if you want to further generate other files (e.g a bartib.toml for configuration of e.g. style of reports, default timezones etc.) it would be useful to have that under bartib gen completions (in the future maybe there could be a bartib gen configor just the top-level bartib completions.

Currently, the week report looks like this:

project........ 1d 3h 12m
    Task_1    8h 35m
    Task_2   18h 37m

Total....... 1d 3h 12m

To me, a report in hours makes more sense, but maybe it can be just configurable instead of just changing it to hours, with something like --format={days,hours}.

Would you be open to a PR where I refactor this project to abscissa (microframework for building Rust applications)? I think it has really good abstractions and will make development easier going forward. As new commands are just implementing a trait for a struct etc. Also, it uses the newest Clap version, and I see clap is heavily outdated in this project. So it would need a refactor nevertheless.

As an example, you can see the general project structure here: https://github.com/rustic-rs/rustic/tree/main/src

$ touch ~/activities.bartib
$ echo $BARTIB_FILE
~/activities.bartib
$ bartib start -p "proj" -d "act"
Started activity: "act" (proj) at 2021-11-16 14:22
Error: Could not write to file: ~/activities.bartib

Caused by:
    No such file or directory (os error 2)

$ which bartib
/home/username/.cargo/bin/bartib

Context: cloned repository, used cargo install --path .

Basic integration with time tracking services like Toggl can be implemented, I'm planning to implement that under this issue.

Hi,
I recently downloaded it from crates.io. I created the file and added the file directory to the BARTIB_FILE env variable. CMD gave me an OS Error 5 when executing

bartib -f ~/Users/username/bartib_logger.bartib report
Error: Could not read from file: /Users/username/bartib_logger.bartib

Caused by:
    No such file or directory (os error 2)

1. I have created bartib_logger.bartib file in the home directory

Hey,
could you please publish this at crates.io so installing it is as easy as cargo install bartib. Updating with cargo-update will be as easy as cargo install-update -a.

Thank you

I know we can use the --from and --to, but having a bartib report --week would be very convenient.

At first I thought --time, in this case, means the target time I wanted to finish the task so I set that to a time in future. Bartib (incorrectly?) accepted that. Then I stopped the task before that start time only to end up with end time earlier than start time.

My problem is the following:

I do work for customers, tracking my time.
Once every X time (week, month etc) I bill these customers.
With bartib, it is hard to keep track of which hours/entries are billed and which are still open.

I see several solutions for this. And am wondering if there is need for a solution inside of bartib and if so, which one.

1. I keep a separate administration in e.g. a spreadsheet or textfile to mark the billing status of entries.
2. I edit entries to add some "tag". e.g. "status: billed" or "status: pending"
3. I create different "projects" for each billing round (It's what I do for project and milestone based billing already). e.g. "-p acme-month01"
4. I create an "Archive" feature in bartib. Where I "misuse" the "archived" state to also mean "billed".

The details and up- and downsides of these features are unclear to me yet. :)

Does the name come from / mean anything? Just curious.

Love the software! Thanks!

It would be nice if bartib could output JSON for use in scripts.

Problem :

When we start bartib without specifying file in which activities will store ,
and run command , bartib stuck without any error message .

Solution :

bartib exist and show corresponding error.

hint :

Guide what bartib extension means.

Looks like on line 93 of src/main.rs, you set the version manually, but the cargo.toml says it should be 1.0.1.

I kept thinking I was out of date, or the crate was out of date, until I cloned git and built it and got the same response of bartib 1.0.0 from bartib --version; probably need to bump that in the next release as well.

Someone could say that midnight is usually a good moment not to be at the keyboard and sleep...

Apart from this

2023-10-12 18:45 - 2023-10-12 18:50 | difficult_prj | Doing something long
2023-10-12 23:31 - 2023-10-13 00:09 | difficult_prj | Doing something long
2023-10-13 00:10 - 2023-10-13 01:13 | difficult_prj | Doing something long

At 00:09 I run bartib report --today and the response was not ok. (so I stopped and started it to attempt to understand what was going on)

I'm not sure what to ask here, is there a bug when we cross date? maybe we can add --last24 near of --today ?

Hello everyone,

First of all thank you very much for making such a nice and simple time tracker. I only discovered bartib two days ago and have been loving it ever since. Although, it is overall quite a robust piece of software, I find myself missing two sub-commands. The first one would be an add command allowing the user to add a time entry by specifying a start and stop time. The second one is an export feature which outputs the activity log in either JSON format or CSV format.
Thank you very much in advance and keep up the awesome work.

As a user, I want to be able to interrupt an activity and record it as a break, so that I can easily get an overview of the amount and lengths of my breaks during e.g. a work day.

I tend to use the Pomodoro principle more often, these days. And for that, it would be also nice to be able to track my breaks as well. It would be also just good to have that as a statistical value, for later analysation.

How I would imagine it to work is the following:

1. bartib start - start activity
2. bartib break - stop activity && start predefined break "activity"
3. bartib continue - stop break "activity" && start last activity before break
4. if bartib start called instead of continue, warn for ongoing break and ask if last activity + break should be stopped

Hi,

Thanks for the great software! Very much appreciated that you put it out there!

I'm not sure where I can put this, so I'll leave it in a ticket for now. Let me know if you want it in a special place and I'll whip up a PR.

I'm using starship to fancyfy my console. I've added bartib to that, and thought maybe others can benefit too.

I thought I'd share my setup. It's simple but wiring up required some trial-and-error, grep/pipe stuff.

The idea is simple, just add a custom command to starship.toml config.

[custom.bartib]
style = "bg:#06969A"
format = "[$symbol ($output) ]($style)"
command = "bartib current | head -n 3 | tail -n 1 | tr -d '\n'"
when = "bartib current | grep -q -v 'No Activity is currently running'"
symbol = "⏲️ "

Then use it in the prompt somewhere. E.g.:

format = """
.... your other format strings.... |${custom.bartib} >
"""

What it does is ugly. And I'll clean it up once I can propose some features to bartib ;).

• Get the first running current item from the table. Using head/tail to just get line 3 and trim newlines.
• But only if we have a running task. Check this by grepping for the placeholder text and using its exit code (0 if placeholder text was not found).

Hope it helps someone. Feel free to close if this is not needed or wanted.

I've been bitten quite a few times by typing in bartib FLAGS_FOR_START and getting errors because I didn't type bartib start FLAGS_FOR_START.

Would it be possible to have start be the default command if no sub command is explicitly provided?

Better yet, could that be configurable, so that those folks that want list or report to be the default can have their way too?

Often I want to start more work on an existing project—non-contiguous, so bartib continue isn't a good fit—and I don't want to retype the name of the project.

I've been doing this with fzf but I have to manually scrub-out the quotes, eg.

bartib start -p "`bartib projects | fzf | tr -d '"'`" -d "whatever"

What I'd like to do is this:

bartib start -p "`bartib projects | fzf`" -d "whatever"

... but presently that double-quotes the project name in the bartib file.

Maybe I'm getting some shell wizardry wrong, but I feel like this would all be easier of bartib projects just outputted lines of text instead of quoted lines of text.

First of all, I want to say thank you very much for such a wonderful project. I have been using it for almost 7 months, it is a very simple and powerful time management tool.

I have found some spelling mistakes in the comments or in the returned lines, which may complicate the process of working with bartib. I am willing to fix them in this issue with your permission, if you don't mind to give me permissions push my branch with the fixes.

Hey there,
bartib inspired me to build https://github.com/pace-rs/pace because I felt my use case for tracking work and break times is not fulfilled by a lot of tools out there. I do see that you also spend a lot of time thinking about time management techniques. Earlier, you said you consider bartib to be feature-complete so I started implementing pace based on my own ideas and inspirational things from bartib, timetracking, vayu and work-break.

Doing the same work should be discouraged. Working together should be applauded.

Based on that, I wanted to ask if you feel - despite your work on bartib - like joining the cause and help to implement pace. :) There is a discord link in the repository, if you want to discuss further, would be happy to see you there.

Cheers,
Simon

Please see the output:

$ RUST_BACKTRACE=full bartib start -d "checking some github stuff"
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:207:58
stack backtrace:
   0:     0x557ece2b6580 - std::backtrace_rs::backtrace::libunwind::trace::h25e12e0d899beba0
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x557ece2b6580 - std::backtrace_rs::backtrace::trace_unsynchronized::h70e61195d6ae3df6
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x557ece2b6580 - std::sys_common::backtrace::_print_fmt::hba93ab80d779695a
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x557ece2b6580 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf092b5883b4b2e50
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x557ece2d275c - core::fmt::write::hf68bc350a8f2f0dc
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/fmt/mod.rs:1078:17
   5:     0x557ece2b38a2 - std::io::Write::write_fmt::hf66811b1bc767436
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/io/mod.rs:1517:15
   6:     0x557ece2b8505 - std::sys_common::backtrace::_print::hd425a11bfe1f20f8
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x557ece2b8505 - std::sys_common::backtrace::print::h6d678795c1e61e13
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x557ece2b8505 - std::panicking::default_hook::{{closure}}::h78a02a4a0dee5e7e
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:208:50
   9:     0x557ece2b805a - std::panicking::default_hook::h56eb7eda02f355a7
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:225:9
  10:     0x557ece2b8ca1 - std::panicking::rust_panic_with_hook::hb27ea14285131c61
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:591:17
  11:     0x557ece2b87b7 - std::panicking::begin_panic_handler::{{closure}}::hc552fcee62aad17f
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:495:13
  12:     0x557ece2b6a3c - std::sys_common::backtrace::__rust_end_short_backtrace::hb9f0aa9a78e885a0
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x557ece2b8749 - rust_begin_unwind
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:493:5
  14:     0x557ece2d1b31 - core::panicking::panic_fmt::h12ac4570ea43d06f
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/panicking.rs:92:14
  15:     0x557ece2d1a7d - core::panicking::panic::h72bd72f6f4a70105
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/panicking.rs:50:5
  16:     0x557ece2146f5 - bartib::main::h6a32311aa284d027
  17:     0x557ece215c33 - std::sys_common::backtrace::__rust_begin_short_backtrace::h0a40a47f68234f03
  18:     0x557ece215c4d - std::rt::lang_start::{{closure}}::h2170525524f8154e
  19:     0x557ece2b90c7 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h78040f802d89ccdc
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/ops/function.rs:259:13
  20:     0x557ece2b90c7 - std::panicking::try::do_call::h6853cad536dd09a1
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:379:40
  21:     0x557ece2b90c7 - std::panicking::try::h827495f03a9fbb9a
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:343:19
  22:     0x557ece2b90c7 - std::panic::catch_unwind::h4bdf17571090eb17
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panic.rs:396:14
  23:     0x557ece2b90c7 - std::rt::lang_start_internal::h2f319c33bb013f29
                               at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/rt.rs:51:25
  24:     0x557ece214c72 - main
  25:     0x7f3eb733ab75 - __libc_start_main
  26:     0x557ece2106ea - _start
  27:                0x0 - <unknown>
$ RUST_BACKTRACE=full bartib start -p leisure -d "checking some github stuff"
Started activity: "checking some github stuff" (leisure) at 2021-11-17 13:52
$ bartib --version
bartib 1.0.0

So bartib report -p *proj1* -p *proj2* would give the report for everything that contains proj1 or proj2.

I discovered bartib a few years ago, but started it using more frequently just recently.

I like the fact, that you can edit your activities with an editor and just add them by hand, if needed. The problem with that is, that statistical evaluation is made harder with it. It would need to either implement a converter or use some custom separator options to parse when e.g. importing to LibreOffice Calc, in this case importing to LibreOffice Calc ( |) and deleting some empty columns.

The proposal of this issue is to either implement an export command to export such data to csv (and other formats if required, people could contribute that). Or to actually switch the format of the activity protocol to csv directly, so it can be opened in a text editor and imported to statistical tooling more easily. For this, a one-time conversion to csv of the activity file would be also beneficial for UX reasons.

Hi, thanks for development of this useful CLI tool.
I had a problem using the Bartib in the early steps, so I decided to open this issue.

When i define the log file with bartib -f /home/iman/activities.bartib report after calling start i get Error: Could not write to file: /home/iman/activities.bartib

but export BARTIB_FILE="/home/iman/activities.bartib" works fine.

I installed Bartib by cloning the project and building with cargo, then moved binary output to /usr/local/bin.

https://docs.rs/crate/bartib/misc/bartibCompletion.sh

this link is not exist but it was mentioned in doc beneath How to activate auto completion

I appreciate the leader lines on wider displays, but they are quite noisy on narrower displays:

Can something be done about that?

I think task is more descriptive of what this flag really does.

I will try to investigate further later but:
When I invoke shell completions on the "continue" command and I have a german umlaut in my description the description gets cut off there and the part after it is used as a project name.

So when I have an entry
<time> - <time> | Gut Ding | Wägt sich in Sicherheit
it shows up as (gt sich in ->W) in the completion selection.

System:

• fedora 38
• fish
  Version:
• main branch (cargo install --git ...)