Re: [Gzz] Revised PEG: fenpdf 1.0

[Tuomas Lukka]

On Mon, Aug 04, 2003 at 06:07:55PM +0300, Tuukka Hastrup wrote:
> On Fri, 1 Aug 2003, Tuomas Lukka wrote:
> > - [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?
> 
> What about showing the instructions for selection when the users do their 
> "obvious" thing and click-drag? OTOH they would still see it way too 
> much. It's no good showing it only for the first time either, because they 
> wouldn't necessarily notice it.

Yes. Maybe this is something we need to think about later on.

> > - [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..
> 
> Interesting. What about using the corners of the screen, as round buoys 
> leave space there? Would we need to show the type of the relation somehow? 

The upper left one is taken by the menu.

> If we're afraid of cluttering the screen, we could have a toggle or two to 
> show and hide the structure and the history.

That could be, but it would also make the interface more complicated.
I'd like 1.0 to have only one view, and that's all.

1.0 should be the "dumbed down" version, going for the least
common denominator always. From that it's easy to extend to having
toggles for whatever, but 1.0 should be simple and with as few options
as possible.

> > Visible buttons
> > ---------------
> > 
> > Action buttons everywhere:
> > 
> >     Home
> > 
> >     Save
> > 
> >     Import PS/PDF
> > 
> >     New paper
> > 
> > 
> >     Save & Quit
> 
> Reading Benja's proposal, I thought he meant combining "Save" and "Quit" 
> into one button. Now I see you can also suggest that there wouldn't be 
> need to quit before saving. Quitting without saving would be the most 
> primitive form of undo (right after kill -9:ing the app).
>
> Would we need some kind of undo facility right from start?

Very good point. Save & Quit is only good if we do have undo.
I'll change that back.

Maybe we should have only two buttons, one of which is a menu.

> > The buttons shall be placed to the upper left corner, stacked vertically, 
> > and shall
> > be relatively small (10-15pixels high)
> 
> Maybe later, consider approximating the visible size by taking the window 
> dimensions into account -- or allow zooming the buttons?

Zooming would be good, but later.

> > Versioning / Merging
> > ====================
> > 
> > At first, in research use, merge using CVS for the RDF.
> 
> There must be better tools than CVS conflicts. Does anyone know of a tool 
> that could do the CVS updating, and visualize the conflicts and help in 
> merge?

Anyway, for the first fenpdf version we'll leave this problem external to that.

> One more issue is the target platform: 3-button mouse is already proposed
> as a requirement, and I assume Linux and X with DRI are required as well.  
> What about JVM and 3D acceleration level?

JVM: Kaffe should work, 3D acceleration should be at least OpenGL 1.1
with 2 texture units (Quake 3 -capable ;).

However, as these do not vary between different fenfire subprojects, I see
no reason to include them in the 1.0 spec which is about ui and structure.

        Tuomas