gzz-dev
[Top][All Lists]
Advanced

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

Re: [Gzz] SCUMM, PUI and FenPDF


From: Tuomas Lukka
Subject: Re: [Gzz] SCUMM, PUI and FenPDF
Date: Wed, 23 Apr 2003 14:52:21 +0300
User-agent: Mutt/1.4.1i

On Wed, Apr 23, 2003 at 12:18:56AM +0300, Matti Katila wrote:

> Ok, I was writing a peg about these bindings but I can do it later since I 
> think we need first discuss about bindings. Everybody should be able to 
> say his ideas now.

Oh, certainly. PEGs are good for ideas that are already pretty firmly
shaped but if you're not quite sure, a discussion here is very good.

> Today we were talking with Asko about these issues and he talked a lot 
> about mouse cursor shape changing while actions and after our discussion 
> I really think we do need it.

I agree, and have agreed for a long time.  The question is: when can 
we schedule this for whom.

The problem is that there is a small number of people doing lots
of jobs.

Saying "X" would be nice usually stresses me because it's
difficult to allocate jobs as it is. It would be really nice
if we could start discussing priorities so that it wouldn't
be only my job to keep in mind all these "wouldbenice"ties
and try to think what's so important that it should be done
now by someone.

> Well, currently we use button3(right) dragging:
>    -up/down for zoom factor.
>    -left/right for fisheye factor (not yet implemented in pp).
> 
> This is quite normal feeling. It's cool.
> 
> Secondly we use button1(left) click:
>    -move around canvas by animating the pointed position to center.
> 
> and dragging:
>    -move canvas fast without animating. This is like taking a normal paper 
>     in hand and moving it freely. I really like this.
> 
> Some of these are currently implemented in prue java pp so if you don't 
> know what I'm talking about you should try 'ant clean compile pp' in 
> fenfire module. 

Only the pure java version?? Why not also GL version?

> Next waypoint:
> 
>    - How we do area/thing selecting?
> 
> Issues:
>    -We cannot paste, since we don't know are we using left or right 
>     linking and this is *important*.

Well, that can be done by Ctrl-V creating a special flashing object
and mouse motions take it to right or left, or something?

> I propouse 'adventure games' like mouse handling because I don't want for
> example push modifier keys at the same time (in macosX and one button 
> mouse we still need to use modifiers or such (at first time I saw mac 
> mouse (I was ten years...) I though mac users were more handicap than pc 
> users because they cannot handle more than one button *sigh* :)

It cuts both ways: for any extra button or feature, 50%-80% of people
will *never* touch it.

> So there's some free actions:
>    -button3(right) click is free. This is good for changing 'mode', i.e.:
>        -normal: mouse1 drag - moves paper freely.
>        -select: mouse1 drag - selects an area.
>        (-move/resize: mouse1 drag - move or resize annotation/note)
> 
> Mouse pointer shape must be changed between these modes.

I have to say that I dislike this idea. Modes are usually bad, especially
at such a central thing.

Imagine someone who doesn't know a thing about us trying to use it.
"What happened now"? ...

A modifier key has the advantage that you always *know* whether you're
pressing it or not.

A changed mouse cursor shape just makes people feel weird, unless
it's directly associated with something they do.

I'd propose shift-drag for selection... Or mouse button 2.

> Other idea:
> 
> How linking is done?
> I like to propouse this:
> 
> Hmm.. after selecting an area animate two buoys to left and right bottom 
> corners where the selected area is seen. 

Sorry, you lost me there.

> Now go to place were you want to 
> 'paste' and select the other area. Once you have selected the area the 
> buoys in corners need some 'hey me in here' - animating and just click to 
> one buoy in bottom corner to make a link in specific direction.
> 
> And better version: ;)
> so the algorithm would be:
>     -select area
>     -select another area (probably from another pdf/paper (I like to call 
>      these as canvases))
>     -after this, first area is seen with two buoys, left and right side of 
>      the selected area and link can be made by clicking one of these 
>      floating buoys.
>     -or abandon by clicking in other place than the link making buoys.

A different idea: the selection floats at a "clipboard".
When you select a new area you then drag a line out of it, left or right,
and then leave the line and drag the thing from the clipboard to the line?

        Tuomas




reply via email to

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