diff options
author | Matthias Beyer <mail@beyermatthias.de> | 2018-06-03 03:59:02 +0200 |
---|---|---|
committer | Matthias Beyer <mail@beyermatthias.de> | 2018-10-10 10:45:10 +0200 |
commit | f91488e6b84b679ab6e3658e8233937dd35b3dd4 (patch) | |
tree | 36c3187726ce42cb55d93900420a238991f5c924 | |
parent | 991a5b3732bfb65b4f0b0105687b1e2fa5800e78 (diff) |
Add post: Call for Participation (1)
-rw-r--r-- | content/blog/2018-10-10-call-for-participation-1.md | 248 |
1 files changed, 248 insertions, 0 deletions
diff --git a/content/blog/2018-10-10-call-for-participation-1.md b/content/blog/2018-10-10-call-for-participation-1.md new file mode 100644 index 0000000..37744a8 --- /dev/null +++ b/content/blog/2018-10-10-call-for-participation-1.md @@ -0,0 +1,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`. + |