This is the first call for participation for the imag project. I have no experience writing such calls for participation, so please bear with me!
Right now, the imag ecosystem has some tools available which are already usable and in rather good shape. There is a contact manager, a diary and a notes tool, a habit tracker and a time tracker are there as well, though those are not extensively tested by now.
Yet, there is a lot to get done. Here I will list what’s missing in the rust crate (library) ecosystem as well as what imag modules are missing to get imag off the ground.
This is the first roundup of “What to do” - I call this “Call for Participation” because I’m effectively asking for help and am looking for contributors with this post.
How can I contribute?
There are several ways how one can contribute. The most important thing right now is to get tools (we call them “modules”) implemented. In the sections below I list a few things we do not have in the imag ecosystem but would really love to have, for example an email tool or a health tracker!
But you can also contribute by testing out imag and reporting your experiences. If you find bugs (and trust me - there are bugs) report them! Report how you use imag and what you think could be improved (docs of course). Also request features, request modules, request the hell out of me!
This first section is about imag tools which are in my personal “pipeline” (in my head). I will write them, if not somebody else steps up and starts writing them for the imag toolchain!
Some of these todos are long-term todos and need a certain level of involvement. Still, I would be more than happy helping and mentoring development!
Did you ever wanted to implement your own commandline email client? With the imag project, you get the chance!
Of course, there are already some thoughts on how I want the
command to behave like, but I’m open to discussions! Reach out to me to get
some details (or, even better: start a discussion on the mailinglist)!
Did you ever wanted to implement your own commandline health/workout/diet tracker? With the imag project, you get the chance!
imag-todo is rather minimal. It is actually not a todo-tracker,
but a way of integrating “taskwarrior” into imag.
I would like that to change. imag should implement its own todo-tool and
taskwarrior (and todotxt) should be importable (and maybe even exportable).
imag-bookmark is another tool which is rather minimal right now.
I would like to provide as many useful features as possible and even a
firefox/chromium plugin, which calls
imag-bookmark for a new bookmark, would
be really nice!
imag-entry command would be nice. It should provide functionality
to read and write header data and create new entries as well.
Thus, it may provide the same features as
imag-edit, as editing would be
another usecase for a tool
Of course, I want to have a TUI for imag in the future. This TUI includes, but is not limited to:
- Dashboard - where a overview of the complete imag store is shown. Of course “overview” is to be defined in that sentence, but I could think of a configurable view into the imag store: Top entries, “new” entries from all modules, a network of entries (imag internal linking creates a network)…
- Tree of entries / Entry graph - A tree of entries would be nice (which is
ultimatively a fancy
ls -Ron the imag store path, but this tree should have several features such as being foldable, show contents and header-data of the entries and so on.
- Entry view/edit - of course a way for viewing and editing imag entries is a must for a proper TUI.
I do not know, yet, how a tool like
imag-tui would work internally, as it
would need to be able to include data (or rather: semantics for the entries)
from all other modules.
One way I could think of would be that a generic
libimagtui provides a way
to create views for
imag-tui and all tools from the imag codebase need to
implement such a view, creating a shared library for it. Then,
searches for those shared libraries at startup and loads them into the
“general” view. This way,
imag-tui itself would be rather minimal, but load
functionality dynamically as it is found at startup time.
I maintain my personal library with git-annex right now. That means: I collect papers and articles in PDF format, but also Novels (fanfiction). With a “library organization” tool for imag, I mean a tool which allows me to keep notes on papers, organise references, tags and so on, and of course make them linkable to the rest of the imag ecosystem.
This is a bit rough and I did not yet think enough of this to give concrete examples. By “project” I mean any type of projects, not only “programming projects” or repositories even. Things like Kanban boards come to mind, but as these are more “collaborative” tools, and imag is a personal information management tool(set), it does not fit well together.
imag ecosystem improvements
Some stuff needs to be improved in the general imag ecosystem (read: non-domain libraries).
- Porting the whole ecosystem to use “impl-trait”, remove all unneeded iterator types.
- Porting to failure (WIP).
- Rewriting/splitting of libimagentrylink into libimagentrylink and libimagentryurl (external linking)
- Rewrite libimagtimeui to use kairos.
- Move edit stuff out of libimagutil
- Rewrite libimaginteraction to not assume stdout.
- Remove libimagentryref. The whole design is rather suboptimal, especially when using imag on multiple devices where paths are different.
Last, but not least: There are certain libraries missing in the rust ecosystem. If these libraries would be implemented (hint, hint!), implementing imag tools would become even more simple!
Icalendar / vcard
The rust ecosystem does not yet have a standard implementation of icalendar and vcard standards. There are - of course - some competing projects tackling this, but none of it has a nice and clean high-level interface and features both a parser and a writer.
I contributed a few patches to “rust-vobject”, which is - in my opinion - the best crate for icalendar and vcard right now, but it really needs a lot more polishing. Also, its parser is hand-crafted, but really should be implemented using some parser framework like “nom”, for example.
Email parsing and writing / Maildir access
There’s “lettre”, which can be used to write emails, but there’s no nice
parser library the last time I searched
(at least not with a high-level interface -
mailparse is there and usable of
Also, notmuch bindings are missing (more on that later) and libs for reading
and writing Maildirs are not available yet.
There are no libraries for reading and writing RSS and Atom feeds. Those would be needed to be able to write a commandline RSS reader (much like newsbeuter/newsboat).
Online resource access
What’s also missing is helper crates for accessing online resources, such as, but not limited to:
- project gutenberg (and similar)
- google scholar
Also, bindings for a lot of programs are missing.
- notmuch (there’s “notmuch-sys”, but there’s no “safe” and high-level interface for notmuch right now. I started one, but do not have enough time to push it forward)
- pandoc (there’s a crate for calling ‘pandoc’ on the commandline, but I wonder whether it would be possible to have a real binding)
- git-annex (bindings for “libgit” exists - a rather good one actually - but not for git-annex)
These are just some bindings I can think of right now.
First: Don’t get me wrong,
Cursive is a great crate (although I haven’t used
it yet, but I am following its development rather closely). But for imag, it
lacks some stuff - some “high level features” - which would make implementing
a TUI on top of imag rather convenient:
- high-level layout stuff - As far as I know does
Cursivenot yet have a high-level layout framework. What I mean by this is: If I were to reimplement “vim” with Cursive, I don’t want to reimplement things like “move buffer to new tab”, but simply call a function “here is the view, move that to a new tab named ‘foo’“. Same goes for splitview, floating windows, moving around floating windows, sidebars and statusbars (
Cursivehas a nice framework for writing a menu bar).
- modal keybinding processor/framework - There is no keybinding processor which could be used to reimplement modal keybindings like “vim”, for example. It would be nice if I could just tell Cursive: If “Ctrl-W” and then “t” are pressed, do the following (move the currently focused buffer to a new window, for example). This is, as far as I know, not possible yet.
- tree view - there is a crate
cursive_tree_view, but as far as I remember, it is only possible to view filesystem trees, not custom ones.
- a view for having a shell inside
Cursivewould be awesome. But I guess
Ctrl-Zis a solution to this problem, right?
- graph drawing - it would be really neat if
Cursive(or an extension crate) would offer a way to draw graphs, like pie charts, bar charts, networks and so on. There is actually a crate which can do this, but as far as I know it is not possible (or rather: it is not easy) to integrate it with