Re: Clasm keybinders, 0.8

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Hiya!

Tuomas Lukka wrote:
> > The goal is high flexibility, which will be realized by separation of code
> > from the data. The keybinder clasm-routine essentially traverses through a
> > list of cells that contain strings that match with keys that the Java JVM
> > feeds it. Those cells have their correspondent actions (clasm code
> > implementing that certain key) connected on a dimension. (Probable problem:
> > we bind ourselves to Java by doing this)
> 
> Why? Because of the key strings?
> 
> We should standardize those ourselves so that we don't need Java, since
> also different Java versions handle some events differently so we should
> have a common reference case.

Yes, we should, but I don't think it's an immediate problem. The
immediate problem IMHO is: Make the 0.6 keybindings work! When we
standardize the key strings then, we can easily change the strings in
the space.

> > This can be found also at
> > http://vegai.cjb.net/projects/gzigzag/keybinder.txt and a drawed/scanned
> > version at .../keybinder.jpeg as soon as I get myself near a scanner.
> >
> >
> > Shared
> > keybindings
> >                    PP Specific
> >  |---|
> >  | a |-{clasm for  |--|
> >  |---|\ "a}        |PP|
> >    |   \           |--|
> >  |---|  \            |
> >  | b |-..\|-| |-| |-||
> >  |---|    | |-| |-| ||     Client specific
> >    |      |-| |-| |-|\
> >  |---|           \   |\    |------|
> >  | c |-..         \  | \   |Client|
> >  |---|             \ |  \  |------|
> >    |                \|   \    |
> >    .                |-|   \   |
> >    .                | |    \  |
> >    .                |-|     \ |
> >                      |       |-|
> >                      |       | |
> >                      |       |-|
> >                      |        |
> >                      |    |------|
> >                      |    |Ctrl-H|--{clasm code for
> >                      |    |------|   Client-specific
> >                      |        |      "go home"}
> >                      |        .
> >                  |------|     .
> >                  |Ctrl-H|--{clasm code for
> >                  |------|   PP-specific
> >                      |      "go home"}
> >                      .
> >                      .
> >                      .

One important thing from 0.6 is modes. We need these, because we have to
have a movement and an edit mode right from the start.

> > Here, we use the third dimension for "common" or "shared" keybind lists,
> > since different views and clients probably will share most bindings (a-z,
> > A-Z to name not-so-few).
> 
> Um, I don't like the "a", "b", "c" ... approach. There should be exactly *one*
> code that covers all "insertible" characters. This is because different
> encodings have different characters available; it wouldn't be nice if
> gzz didn't work straight out of the box with czech etc.

Same opinion here. There were two special key strings in 0.6, INSERT and
DEFAULT: INSERT matched all insert characters, DEFAULT all characters.
What we did was calling the code that's going through all the bindings
three times: first, for the key string; then, if we don't have a match
and it's an insertable character, for INSERT; then, if we still don't
have a match, for DEFAULT. (At least it was like this IIRC.)

I would like to use the same conventions in 0.8, if possible.

> Also, Japanese is going to be interesting...

Yes. For the moment, we probably want to stick with AWT for inputting Japanese?

> The 0.6 version did
> 
>  2. If there is something on step(A, d3, -1):
>         - do algorithm X on headcell(A, d3, -1)
> 
> I don't see the use of the additional complication.

Agreed.

Also note that the headcell itself should probably be ignored, as it
will likely contain a label for the list of bindings, and maybe be
connected in some other structure itself.

> Also, probably we should have these as
> 
>         d.binding-list, d.binding, d.binding-inherit
> 
> or something like that?

d.menu, d.submenu, d.binding-inherit (or d.menu-list, d.menu,
d.binding-inherit or so) in my opinion. Maybe even d.user-1, d.user-2, d.binding-inherit.

The point here is to have a design in which the key bindings list and
the user menu are next to each other. Like in PUI menus, you can then
see the key binding right next to the menu item it invokes; unlike PUI
menus, you can edit them, and you can browse through the list of key
bindings as well as through the menus. (This does not mean every key
binding is on some menu, or every menu item has a key binding assigned;
but if it has, it will be right there.)

This is one of the places where we can use ZZ nicely to make our lives
easier. I asked Marlene to ask Ted about this quite a long time ago, and
he said it would be ok.

> > I'm not sure how the choice of the keylist (in the example, PP/Client) will
> > be made runtime. From Java or Clasm? Would a clasm-solution there be
> > unnecessarily complex when compared to a java-solution?
> 
> Window and view-specific. Clasm shouldn't be too complicated.

Could we then also do the PP/client keybindings as different modes?
(Maybe the Java code could change the mode on startup if necessary and desired?)

- Benja