Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

master

1.mdwn

[[!template id=ticket class=task assigned=fr33domlover]]

[[!meta title=“Initial plans”]]

Issue

What is the scope and what are the features of this project?

Process

Without looking at all my writing about it, here’s an initial simple list of possible features:

[[possible-features]]

This looks complicated enough to justify:

A library for task management
Some kind of monad to manage the state

Also see the Kiwi diagram, [[/projects/kiwi/data/issues/issues.dia]].

Since there is no way yet to parse Idan files and generate Haskell vocabularies and so on, here’s what I’m going to do:

Start an ontology using the current version of Idan syntax rules
Manually write a vocabulary package with the minimum needed
Plan UI elements needed for the application
Plan the API according to the needs

I created a simple ontology which supports the following:

Tickets with IDs, titles, descriptions, progress diaries and results
3 dependency types: requires, recommends, suggests

What would the user want to see in an application based on these rules?

Display a task tree according to dependencies
- Allow folding and unfolding subtrees
- Colorize tasks with multiple parents to make them easier to see
- Show IDs and titles
Display a task
Edit a task field, such as the description

Idea for views:

[[views]]

The parameters which set the view mode are:

Vertical/horizontal
First-second flip switch
Which view is separate in 3-view mode (i.e. gets half screen)

These parameters are enough assuming a tree-taskview-taskedit priority ordering.

Actually, hold on… what if we want to see the tree and a task editor, without the task view? Also, why are the view and the editor separate? Why not have a single edit+view frame?

IDEA: Have several widgets and compose them in a separate layer.

There is a little problem with the view+edit idea. Each task has 4 fields that can be edited:

Title
Description
Diary
Result

Some possible view/edit modes are:

View+edit a single field at a time, allow cycling between them
Same as above, but there’s also a task view which concatenates them all
View+edit a concatenated form, later extracting the 4 fields from it

A possible unified model is to have the task view field display all 4 parts (or less, if some are empty) in a column, and allow the editor cursor to jump between them.

Operations: [[operations]]

No API can cover the full flexibility of direct data access. But it can still be provided for use by UIs.

UI plan: [[ui]]

Results

None yet.