[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] Incomplete PEG: fenpdf spec 1
Re: [Gzz] Incomplete PEG: fenpdf spec 1
Thu, 31 Jul 2003 17:01:56 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2
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.
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
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
I think that this should more sensibly read, FenPDF may not create other
stuctures besides those specified here.
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
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.
While the Structure was an important part,
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
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!
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
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:
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.
Left mouse button:
click + drag on main view
"On main view?" What is "main view"? It seems unnatural that this
wouldn't work on *all* views.
shift + click + drag on main view
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
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
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",
Shouldn't it also be "Delete this link," then?
Action buttons everywhere:
Make that "Save & Quit"
Add "Home" or "Go home" button.
s/Fancy papers/Show backgrounds
Toggles in pdf mode:
What is "PDF mode"? I think the toggle should be shown whenever a PDF is
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
be relatively small (10-15pixels high)
Hm, not sure whether this is big enough to be easily readable...
- Should ``CONTENTLINK`` RDF vocabulary be included?
We should be as conservative as possible; we shall have
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
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.
- 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