Re: [Gzz] Incomplete PEG: fenpdf spec 1

[Tuomas Lukka]

On Thu, Jul 31, 2003 at 05:01:56PM +0200, Benja Fallenstein wrote:
> >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.

True, it's not an exact match but I couldn't come up with anything better.

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

Hmm... This is a difficult question. The two sides are

1) extensibility, ability to make the system do more stuff

versus

2) stability, having a completely certain interchange format
   between ourselves where no-one will *miss* any of the content
   because their client doesn't happen to show it.

I'm trying to go for 2) for the data in real work, at least for now.

Once we have experience with that and private experiments with extensions,
we can loosen this but I'd like to start while knowing *everything*
that's going on in the system.


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

Yes.

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

It's the same as above 1) vs 2) thing. 

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

I think this might be good to postpone since we don't
have the code and it's not absolutely vital.

> >While the Structure was an important part,
> 
> s/was/is/
> s/part/issue/

Thanks

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

The latter.

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

Which pool a pdf goes, i.e. you need to be able to say what copyrights
it has.

I'm thinking we need to work on a "soft DRM" system, i.e. one that
**warns** you if you're doing something suspect but will **never**, **ever**
disobey a direct order from the user.

The separate pools are a good start.

I think that's a concept we really need to float because it's what could
"save the world" ;)

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

There's something screwy about them in the current code - it needs
to be more transparent.

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

Yes, but not the main view since that makes the text harder to read.
The edge of the main view is what I'm suggesting.

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

Says below that it allows resizing. I'm not at all sure about the restriction
to no PDFs.

> The "Home" key and a "Home" button usable with mouse should move the 
> lower focus to a starting-point-canvas, 

Which is what, exactly? ;)

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

Ahh, need a TREETIME.firstOf?

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

Main view = not-buoy, i.e. focus.

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

Ouch.

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

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

Answers in PEG.

> >Right mouse button:
> >    
> >    click + drag on main view
> >     adjust zoom. Up = zoom out, down = zoom in.
> 
> ISSUE: How to adjust pan? (Key binding?)

The answer is above this in the PEG:

    click + drag on focused node
        pan

> >middle mouse button:
> >
> >    click + drag anywhere
> >     move view separator up / down
> 
> How do do this without middle button?

Added into 1.1 as a question - for 1.0, let's assume 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.)

Added as issues, will take care of

> >Context Menus
> >-------------
> >
> >On struct-connected buoys: "Unlink this buoy"
> 
> ISSUE: How to unlink two nodes on same paper?

Answer in PEG.

> >For any object, "Delete this X" where X is "Text", "Paper", "PDF file", 
> >"transclusion"
> 
> Shouldn't it also be "Delete this link," then?

Ah, good catch!

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

That's what I meant ;)

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

Which is what? ;)

This is moved to 1.1 since it'll take work to implement.

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

Let's look at it and decide then.

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

Added to the resolution, but still keeping just transclusions.

> >- RDF for cursors / bookmarks?
> 
> Don't! The panel focus with a "home" canvas takes care of this.

That, + treetime. Otherwise, the graph can become unconnected.

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

The question is, will one move or select more. I think moving is
more common.

Pressing shift gives you carpal tunnel syndrome ;)

The fundamental conflict, again: usable or learnable.

OTOH, what part of the system should be learnable...
At first, people'd probably like to browse and that's easiest with 
dragging.

ARGH. This is a *DIFFICULT* one.

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

On the interface, sometime back. Probably not relevant any more
after you've looked through this.

        Tuomas