Re: [Gzz] Incomplete PEG: fenpdf spec 1

[Benja Fallenstein]

Tuomas Lukka wrote:
> 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.

Ok.

> 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.

ISSUE: How is TREETIME supposed to be *shown*?

> 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.

I don't think 'applitude' is a good word because FenPDF will (at least 
initially) be a separate application and even released separately.

In German, we have "Auskopplung" for a single from a music album that 
was released separately. I don't know what the corresponding English 
word is.

> 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.

Why?!? This makes no sense. We picked RDF because having extra 
connections aren't a problem for interpreting the connections you do 
understand.

I think that this should more sensibly read, FenPDF may not create other 
stuctures besides those specified here.

> RDF
> ---
>
> The structure behind FenPDF consists 
> of the RDF structure in ``CANVAS2D``, ``FF``, ``RDF`` (type), and ``STRUCTLINK``.

The clone issue must be resolved before we can set this in stone.

> As long as FenPDF is the only applitude used,
> all other RDF words are either randomly generated ``urn-5`` words or literals.

Why? I can see no reason for specifying this.

> This means that the structure is: 
>
> - Canvases containing nodes at specific locations
> - directional links between nodes
> - contents for the nodes

Yes.

> Xanalogical
> -----------
>
> As this is FenPDF, version 1.0 will support only text and page spans.
> Content links will not be supported, only transclusions.

Will transclusions of *text* be supported, and if so, how?

> For text spans, URN5 text spans will be used - storing the keystrokes
> in their own blocks is an extra complication for now.

Good.

> While the Structure was an important part,

s/was/is/
s/part/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.

Verb missing. Do you mean "We will provide..."? (Or is this a 
continuation of the last sentence? Then you should only put a comma 
between them and not start a new para, that's confusing...)

> - easy to insert new PDFs - error handling?
>
>     - pool control

Pool control? What? How?

>     - debug mode: show where buoy locations come from!

? explain

> Whatever is under the cursor *shall* show it somehow, e.g. main view by slightly changing color 
> of irregu edges, text nodes by lightening, etc. *EVERYTHING* must do this.

Nice idea. Probably everything should show it in the same way though: by 
lightening up.

> Foci
> ----
>
> Two foci, shown on top 

Which layout? I'd like it to be like currently, so that the lower one is 
wider and "panel-like," and the lower one cannot show PDFs.

The "Home" key and a "Home" button usable with mouse should move the 
lower focus to a starting-point-canvas, which would normally also be the 
root of the TREETIME time tree, making it a good starting place to get 
to every canvas and PDF out there.

> There are several different kinds of buoys in this system:
>
> Canvas-Canvas
>     These are directed and can occur on either side.
>     The buoy should show some context but not too much
>     to avoid going to too small zoom.

Should mention that this is created for STRUCTLINKs and nothing else.

> Bindings
> --------
>
> Left mouse button:
>     
>     click
>         go to
>
>     click + drag on main view
>         pan

"On main view?" What is "main view"? It seems unnatural that this 
wouldn't work on *all* views.

>     shift + click + drag on main view
>         select

On a PDF, this is clear. On a canvas, what does it mean? Does it select 
a piece of the canvas, or a group of spans on the canvas? If I start 
selecting inside a text node, do I select a rectangle or a span of text?

>     click + drag on a selection in main view
>         drag into other view for creating transclusion

Why only in other view? Why not be able to transclude to same view?

Or, oh, do you assume that only page spans can be cloned, and they can 
only be cloned from the PDF onto a canvas? That would make perfect sense 
and invalidate all three points above. If you mean that, please make it 
clear, then the above issues should have been taken care of.


ISSUE, though: 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.

ISSUE: 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.

Also, ISSUE: Shift+click+drag is certainly not something you can figure 
you can just figure out (see requirements). What to do about that?

> Right mouse button:
>     
>     click + drag on main view
>         adjust zoom. Up = zoom out, down = zoom in.

ISSUE: How to adjust pan? (Key binding?)

> middle mouse button:
>
>     click + drag anywhere
>         move view separator up / down

How do do this without middle button?

>     click on main view
>         X11 paste to insertion cursor

ISSUE: You don't discuss how to create structlinks!

ISSUE: 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.

ISSUE: How to move nodes on a canvas? Rearrangement seems quite 
important, so it would be bad to leave it to a later version.

ISSUE: Can I enter text in both foci, or only in one?

(Actually it would be better to say "focus" everywhere and to say "view" 
nowhere, except to distinguish between "PDF reading" and "structure 
browsing/editing" view.)

> Context Menus
> -------------
>
> On struct-connected buoys: "Unlink this buoy"

ISSUE: How to unlink two nodes on same paper?

> For any object, "Delete this X" where X is "Text", "Paper", "PDF file", 
> "transclusion"

Shouldn't it also be "Delete this link," then?

> Visible buttons
> ---------------
>
> Action buttons everywhere:
>
>     Import PS/PDF
>
>     New paper
>
>     Save
>
>     Quit

Make that "Save & Quit"

Add "Home" or "Go home" button.

> Toggles everywhere:
>
>     Fancy papers

s/Fancy papers/Show backgrounds

> Toggles in pdf mode:
>
>     Reading zoom

What is "PDF mode"? I think the toggle should be shown whenever a PDF is 
focused.

> These buttons shall have the ubiquitous 3D look, with the toggles having
> the old Tk look, with a square in them that is lit or unlit based on the state
> (need to distinguish between buttons and toggles somehow).

I don't understand your description of the toggle look. How about using 
the universal checkbox look?

> They shall react to mouseovers and mouse clicks instantly with visual feedback.

Mouseovers: lighting up.

> The buttons shall be placed to the upper left corner, stacked vertically, and 
> shall
> be relatively small (10-15pixels high)

Hm, not sure whether this is big enough to be easily readable...

> Issues
> ======
>
> - Should ``CONTENTLINK`` RDF vocabulary be included?
>   We should be as conservative as possible; we shall have
>   transclusions anyway.

I think it would be ok not to have content links.

>   OTOH, clinks have their uses.
>
>   Hmm, for v1.0 maybe we should have *either* clinks *or*
>   pdf transclusions but not both?

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?

Don't! The panel focus with a "home" canvas takes care of this.

>   Is just two views good enough
>   for browsing? Accidental severing of contacts. Need some way to get anywhere.
>
>   PROPOSED RESOLUTION: TREETIME for now.

Fine.

> - Should left-button click+drag select or move?
>
>   PROPOSED RESOLUTION: move. Shift for select. Clicking and dragging
>   for moving *feels* right.

Although that's definitely true, click+drag for select is easy to figure 
out (clashes with one of the requirements), and click and drag for 
moving isn't *necessary*: you can archieve the same goal with just 
clicking where you want to go...

Strawperson alternative proposal: Left drag selects. Right drag pans. 
Middle drag or Shift+drag zooms. Ctrl+drag changes size of foci (or 
alternatively, changing focus size isn't possible in FenPDF 1). In this 
proposal, it would be much easier to figure out enough of the whole 
system to do full editing.

> - What were benja's suggestions - couldn't find a PEG

Which ones?

- Benja