Issues

• Should CONTENTLINK RDF vocabulary be included? We should be as conservative as possible; we shall have transclusions anyway.

  OTOH, clinks have their uses.

  Hmm, for v1.0 maybe we should have either clinks or pdf transclusions but not both?

  RESOLVED: Later. Again, not absolutely vital

  [benja] If we have content links but not PDF transclusions, we need content links to text -> bit difficult to show.

  Or, a way to make a link between a node and an enfilade. That could actually be good... hm. To the user, it would be functionally very similar to a structlink.

  Transclusion is probably better if we have only one of the two, but having both would also be good.

  If we have clinks, when the user has selected a piece of PDF, it would be good to have a "Create link" button which creates a new paper with an empty node that's linked to the PDF. Actually, would also be good to have this when the user is on a canvas and has selected a text node. Then this would be a simple, universal way of creating a new annotation to something.

  Or maybe "make paper" should always work like this if there's a selected node? When making a new paper, you almost always want it to be linked to the current paper?

  For text nodes it could also be in the context menu (if we don't have a way to select them in the interface)...

• RDF for cursors / bookmarks? Is just two views good enough for browsing? Accidental severing of contacts. Need some way to get anywhere.

  RESOLVED: TREETIME for now. The least invasive and easiest way to achieve connectedness.

• "overall view" of the whole space? -- embed to 2D somehow for a map?

  RESOLVED: Later. Needs experiments first

• rmb_action_switch--humppake? Gives more actions for the mouse, but may be confusing; the UI is definitely not self-explanatory then.

  RESOLVED: Later. Needs experiment and is more useful when we have more types of objects.

• Do we need bookmarks and overall views - would simply connecting the previous and next canvas and pageimagescrolls in time order?

  RESOLVED: Use TREETIME and provide interface for it.

• Should the elements in the system contain their insertion time? As wallclock time or a tree (when merging)?

  RESOLVED: Use TREETIME and provide interface for it.

• [benja] I don't like the overloading of click+drag. Isn't there a better way? Maybe Shift+drag to create the transclusion after selecting? Hm.

  What actions destroy the current selection (unselect it)? Should every click destroy the selection? (Even panning?) If so, maybe the click+drag to create transclusion could be tolerable.

  RESOLVED: Shift+drag is not possible, as it needs to start another selection reliably.

  Every click destroys the selection. This way, there will be no annoying things that get easily stuck.

• [benja] How to adjust the view separator position without middle button?

  RESOLVED: Later - in 1.1. In 1.0, assume middle button.

• [benja] How to unlink two nodes on same paper?

  RESOLVED: In v1.0, the nodes would be shown as buoys, so in the usual way.

• [benja] Shift+click+drag is certainly not something you can figure you can just figure out (see requirements). What to do about that?

  PROPOSED RESOLUTION: Show text in the background always: shift-drag to select? Or just treat this as the single thing that people need to be shown about this UI?

• Should left-button click+drag select or move? This is a complicated issue with many arguments for and against. Click + drag for moving relegates selecting to using shift which is not as obvious.

  PROPOSED RESOLUTION: move (i.e. pan). Shift for select. Clicking and dragging for moving feels right.

• [benja] How is TREETIME supposed to be shown?

  PROPOSED RESOLUTION: Buoy-like things which don't move with the center node, on the left and right edge of screen, and go underneath the focused node when it's zoomed..

• [benja] Will transclusions of text be supported, and if so, how?

  PROPOSED RESOLUTION: Later. No experience yet with them, not absolutely vital for 1.0.

• [benja] Can I enter text in both foci, or only in one? [tjl] This question is really "is there a change of focus between the two foci".

  PROPOSED RESOLUTION: Yes, the insertion cursor determines where the text goes.

• [benja] How to move nodes on a canvas? Rearrangement seems quite important, so it would be bad to leave it to a later version. [tjl] Another dragging-like activity. We have three: pan, select, movenode.

  PROPOSED RESOLUTION: two different ways: click&drag on text node with insertion cursor, or Ctrl-drag.

  Transclusions should also be selectable

• [benja] How to create structlinks?

  PROPOSED RESOLUTION: Two buttons between top & bottom views, showing graphically the different directions of connection:

   /       \
  *--*   *--*  
    /     \
  

• [benja] This describes only mouse bindings. How does the keyboard work? How is a new node created? How do I edit an existing node? Is a text cursor shown, and when, and how does it work? These need to be specified.

  PROPOSED RESOLUTION: The way it works now, mostly: new node is created when there is no insertion cursor in the last-clicked canvas, at the center.

  A text cursor is shown in the insertion mode, works like a normal text cursor.

  Clicking on a text node places the insertion cursor there.

  There are no command keys, only normal cursor motion.

• Should there be a plain Quit button or a Save&Quit button?

  RESOLVED: Plain quit. As tuukkah puts it, it's the simplest form of undo ;)

Introduction

This is a PEG that's different from most - it changes the whole perspective. Instead of looking outwards and pushing the envelope, this PEG tries for the first time to actually contain a complete working system.

This PEG will select what goes in and what does not for FenPDF 1.0.

Not having something in this feature set does certainly not mean that it's abandoned or that it's a bad idea: it just means that we will not include that functionality into FenPDF 1.0 even if it is implemented, in order to keep things simple or for some other reason.

FenPDF 1.0 is kind of a "director's cut" (a term Ted sometimes used), and it's expected that there will be parallel versions, with different names and identities that do almost the same thing but differently. These are good for experiments and competition is healthy -- the same components can be assembled differently by different people.

This spec is extremely conservative as to which features are taken in. We need a working baseline 1.0 that remains the same and functional. We need to get using is asap. The policy is that we take in exactly what has to be there for a working FenPDF. Including TREETIME or something like it is because all points of the system must remain reachable.

This is the first spec PEG - once accepted, the specification here will be moved to the main docs/ directory and be amended only through future PEGs.

Note that evolution of the FenPDF PEG is not the only way to add new features and e.g. canvas / document types. FenPDF is only the first applitude we will try to settle. There will be others (fencode, fenwrite, ... ?) which will operate within the same graph.

Implementation

The FenPDF 1.0 client shall be implemented in a new file, org/fenfire/bin/fenpdf10.py. This means that buoying is still free ground for experiments.

It is really strict that this new demo shall never refer, directly or indirectly, to any lava code.

This means that before 1.0 release, all code in lava that is needed has to be PEGged and accepted.

Structure

In a sense, this the most important part of this PEG: this part specifies the structure that will be used within our research group when test-using fenpdf. No other RDF nodes will be allowed in the common data base, until the next version of FenPDF (1.1?), or v1.0 of some other applitude is defined.

Everyone may use their own user interfaces, but the shared structure is set in stone here.

User interface

While the Structure is an important issue, the user interface is the most difficult one. There are several possible directions and we need to select one for FenPDF 1.0 --- one that we will provide as a backwards-compatibility option in later versions of FenPDF if it is seen to be good.

Versioning / Merging

At first, in research use, merge using CVS for the RDF.