gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] Revised PEG: fenpdf 1.0


From: Tuukka Hastrup
Subject: Re: [Gzz] Revised PEG: fenpdf 1.0
Date: Mon, 4 Aug 2003 18:07:55 +0300 (EEST)

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.


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

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


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

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


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


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?

-- 
-- Trying to catch me? Just follow up my Electric Fingerprints
-- To help you: address@hidden
                http://www.iki.fi/Tuukka.Hastrup/
                IRCNet: Stugge/tuukkah @#pii,#fenfire,#ynna
                Jabber ID: address@hidden, ICQ #11321669





reply via email to

[Prev in Thread] Current Thread [Next in Thread]