diff options
Diffstat (limited to 'content/blog/2019-12-08-what-s-coming-up-in-imag-41.md')
-rw-r--r-- | content/blog/2019-12-08-what-s-coming-up-in-imag-41.md | 116 |
1 files changed, 116 insertions, 0 deletions
diff --git a/content/blog/2019-12-08-what-s-coming-up-in-imag-41.md b/content/blog/2019-12-08-what-s-coming-up-in-imag-41.md new file mode 100644 index 0000000..0cca17c --- /dev/null +++ b/content/blog/2019-12-08-what-s-coming-up-in-imag-41.md @@ -0,0 +1,116 @@ +--- +title: "What's coming up in imag (41)" +date: "2019-12-08T14:45:40" +tags: [ "linux", " open source", " programming", " rust", " software", " tools", " imag" ] +--- + +This is the +41th +iteration on what happened in the last four weeks in the +[imag project, the text based personal information management suite for the commandline](https://imag-pim.org). + +<!-- more --> + +Almost half a year since the last update. I could definitively do better, I +know. +But a lot of stuff has happened. +I have a real job now, am not a student anymore. That, of course, takes a lot of +time. + +Anyways, lets get started with what happened in imag in the last months. +Of course, I could just dump the git log, but this would just bore you all. +That's why I list only the stuff that's interesting to the user here. + +* [598b6ec9a](https://git.imag-pim.org/imag/commit/?id=598b6ec9a6f8eb0b878f924df3ebe10ca27d68b0) + Removed the "where-clause-filtering" in imag-ids as well as the + "in-collection" filtering. There's a "imag-id-in-collection" core command now + that does the job. +* [d8df96ad1](https://git.imag-pim.org/imag/commit/?id=d8df96ad1fa99940a07a86cebccaab61b6d1bff1) + Added a new "core" command: imag-create +* [712eda074](https://git.imag-pim.org/imag/commit/?id=712eda074d97b400cb0c35018e72547d5073b616) + Added libimagcalendar, a library for handing calendar data. +* [b7e996ccf](https://git.imag-pim.org/imag/commit/?id=b7e996ccfe148dc002a24697ce1bb299ee8d1725) + Added a new "domain" tool: imag-calendar +* [7a0654465](https://git.imag-pim.org/imag/commit/?id=7a0654465413fb7e447d4a7e80a6bc24adebf605) + Improved the story around building imag commands as a subcommand to the "imag" + binary itself. First of all this was done to be able to generate + autocompletion scripts using clap, but this also improves the story around + building imag as one big binary rather than many small(ish) binaries. This + was contributed by [Leon](https://leon.is.currently.online/master/) - Thanks a + lot Leon! +* [cc6a833ab](https://git.imag-pim.org/imag/commit/?id=cc6a833ab69c8481daa9794c3fb152acf0a22721) + Improved the story on error handling in all "core" commands in imag: The + binaries do not call exit() anymore, but propagate errors up to the main() + function where they are returned. This results in way less boilerplate with + error handling in the implementations of the commands, as well as a cleaner + shutdown if an error happens, because destructors are actually called (and the + program does not simply kill itself). +* [c67f0bbd4](https://git.imag-pim.org/imag/commit/?id=c67f0bbd4bd2bc225cb4d7663d468fa5600408f7) + Included changes in imag-calendar to not call exit() in the code but propagate + errors to main(). +* [fa7e8cc6b](https://git.imag-pim.org/imag/commit/?id=fa7e8cc6b41ad07166655aa024ced20239e3dea9) + Included changes in imag-bookmark to not call exit() in the code but propagate + errors to main(). +* [1f858cf4b](https://git.imag-pim.org/imag/commit/?id=1f858cf4bd88c9f674ca1994c38a12a826b3257e) + Adds an option to imag-link to create a directed link. Before that, links + between entries were unidirectional. Now there's a way for creating directed + links. +* [7b6e5eafb](https://git.imag-pim.org/imag/commit/?id=7b6e5eafbaadd1cd898cd3cf78b7559b98d7af81) + Added a test infrastructure for testing the UI of imag. This is a big step + forward towards a UI that is more concise and reasonable. +* [ead9438c4](https://git.imag-pim.org/imag/commit/?id=ead9438c412c6f14fc6f3d77fb88ca40a7634452) + Rewrote libimagtodo and imag-todo completely. +* [99fedd5ab](https://git.imag-pim.org/imag/commit/?id=99fedd5abd77dd5ea8da5806667fe53680acc879) + Added taskwarrior importing for imag-todo +* [1a25bd2da](https://git.imag-pim.org/imag/commit/?id=1a25bd2da4dafc0768a41b8fe4539dc7e3edb194) + Added a filtering option to imag-tag + +Another big chunk of changes was contributed by +[Philipp Krones](https://github.com/flip1995), who contributed a lot of clippy +fixes. Thank you a lot Philipp! + +# What's happening right now + +I'm in the CLI-Working-Group where we collaborate on the CLI ecosystem. I am +participating in discussions to help improving the ecosystem around CLI +applications. +That, of course, takes some of my time, but I'd say it's a good investment. +More on that subject will be on my personal blog, if I can manage to write +everything up. + +In the imag ecosystem, I'm still working towards imag 0.10.0. I hope I can +publish the release before January 2020. Well,... lets see. + +After the 0.10.0 release, I will start focusing on two subjects: imag-mail and +the TUI infrastructure that is necessary for implementing a TUI for imag. + +First things first, imag-mail. I thought a lot about whether to implement a +complete MUA or just a tool to implement a tracking functionality for mails and +for including mails into the imag ecosystem. +I came to the conclusion that if I want to write a MUA (either a CLI one or a +TUI one), I always need the latter. +So, the imag-mail module will be a two-component module: One part of it being +rather "low-level" for tracking mails (as in Maildir for the first part) and the +second one implementing MUA-like functionality (CLI) on top of that. + +Of course, the next step is to implement a MUA with a Terminal User Interface on +top of that. +For that, I need some more stuff in the land of TUI crates. + +Right now, the TUI crate I want to use (cursive, of course) does lack some +things I want to implement before I want to start implementing a TUI for imag. +The TUI will be a fully-integrated imag, so no individual modules anymore but +one binary that includes all tools in one TUI. Maybe parts will be selectable +for inclusion/exclusion at compiletime, but there won't be a way to load/unload +parts during runtime. I spend some time thinking about whether such a thing +would be possbible and I came to the conclusion that the problem, while +interesting, is not worth the hassle. + +I also am thinking a lot about how to structure a TUI crate for imag, which +would of course contain all imag tools and thus be composed of several modules +within imag. +A concept on how I want to setup the TUI interface and on how to structure the +whole thing is in my pipeline and will probably end up in another post. + +For so long, that's where the journey goes... + |