Re: [zzdev] Clasm keybinders, 0.8

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> I've been working on a Clasm implementation of the 0.8 keybinder routines.
> The current 0.8 keybinder is 99% Java-code/1% Clasm-code, and when my work
> is done, those numbers have changed places.

The 99 keybinder is 1% Java-code / 0.8% Clasm-code? ;)

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

> 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"}
>                      .     
>                      .     
>                      .        
> 
> 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.

Also, Japanese is going to be interesting...

> The algorithm(call it X) for the inner keybinder loop would roughly be like
> this:
> 
> 1. Get next cell on d2 => A.
> 2. If there is something on step(A, d3, -1):
> 	- get endcell of that cell on d1 => B
> 	- do algorithm X on step(B, d3, -1)  

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

> 3. If A is not an empty cell:
> 	- check if pressed key matches the string on this cell
> 	- if it does, eval the code on step(A, d2, 1) 

Also, probably we should have these as

	d.binding-list, d.binding, d.binding-inherit

or something like that?

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

	Tuomas