1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
---
title: "Call for Participation (1)"
date: "2018-10-10T08:42:06"
tags: [ "linux", " open source", " programming", " rust", " software", " tools", " imag" ]
---
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!
<hr>
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!
# imag modules
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!
## imag-mail
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 `imag-mail`
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)!
## imag-health
Did you ever wanted to implement your own commandline health/workout/diet
tracker? With the imag project, you get the chance!
## imag-todo
(Needs reimplementation)
Right now, `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
`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
A general `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 `imag-entry`.
## TUI
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 -R` on 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, `imag-tui`
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.
## Library organization
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.
## Project management
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.
# Libraries
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
course).
Also, notmuch bindings are missing (more on that later) and libs for reading
and writing Maildirs are not available yet.
## RSS/Atom
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:
* openstreetmap
* openweathermap
* project gutenberg (and similar)
* google scholar
* scihub
* wikipedia
## Bindings
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](https://github.com/matthiasbeyer/notmuch), 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.
## Cursive
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 `Cursive` not 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 (`Cursive` has 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 `Cursive` would be awesome. But I guess
`Ctrl-Z` is 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 `Cursive`.
|
