vi like interface for rappid

================================================
vi like interface for rappid
================================================

:Author: jyf
:Date: 2013-10-10

.. contents:: index

links
=========

rappid
---------

http://www.jointjs.com/rappid


modes
=======

first of all, the new features shouldnt confused normal user and those who 
havnt used vi

so i think those new features should be actived when user press a shortkey
explicitly. these could corresponds with vi's mode concept

so maybe we should call the 3 modes as 

A. normal mode
B. expert mode
C. master mode

or

A. user mode
B. geek mode
C. nerd mode

so when user press some key that actived mode B, he could use some vi-like
key to move the selected object. like **hjkl**, or even **y** for copy object
and **p** for paste it.

and then he could use the classic key **:** for enter the final commandline mode
which would , just like vi does, show him an input(begin with : just like the vi
does again) at bottom, and he could put commands like **object1 100 200 move** 
so that that object1 could be move to (100,200)

BTW, emacs like could also works but many keybinding would conflict with browser

B mode keybindings
=====================

also we call it expert mode or geek mode

in this mode, user could do these jobs

object creating
-----------------

shapes has its type id, like 1-20, so people could press **1n** for creating a new
type 1 object in the current canvas. **n** is for **new**

object selecting
-------------------

press **f** and show all the object in the canvas with its own object-id, user could
then continue typing the object-id until it could lock to the target object, if you
guys ever used vimperator_, i think you might understand what effects it is

object moving
------------------
once the object be selected, user could press **hjkl** for moving object left,down,
up,right and i think the moving speed should increase by time

object modifying on size
------------------------------
user could press **HJKL** for increasing the object size on the 4 directions: left,
down,up,right. i think it would let vi user feel nature

object rotating
-----------------------------
i recommend **[** and **]** for rotating deasil and widdershins. 

object text modifying
-----------------------------
press **i** and you got the input focus on the selected object, if you have done
writting, press **esc**

object color modifying
-----------------------------
press **#** and follow the color expression, it could support #fff or #ffeecc, i think
a **<enter>** for commiting the color changing would be better

object deleting
---------------------------
press **do**, delete object

object arrow start point selecting
-------------------------------------
i recommend **A**, i notice that most shape type only have 1 arrow start point, so
this feature is not common. it shouldnt use **a**, and for A, it still means Arrow
,after you press the key, those arrow start point should show their number just like
object selecting. so the really key pressing might be **A2**, that mean user select
the number 2 arrow start point on the selected object

object arrow point to selecting
--------------------------------------
i recommend **a**, and when you press the key, we need the object selecting style
again, so user could easily choose the target object, and after that, user could use
 **hjkl** to choose the precise point on the target object

object arrow path deleting
------------------------------------
select any object, no matter is it the arrow start or point to, press **da**, if the 
object only have one path, delete it, done the job, if it has many path, shows an arrow
start point selecting style ui. so the really key pressing might be **da2**, which means
to delete the number 2 arrow path of the selected object

.. _vimperator: http://www.vimperator.org/vimperator

I'm more an Emacs user so please if I propose something that is not comfortable to a vi-user, correct me.

I propose two modes only:

A. normal mode = the default mode, the one it is currently on Rappid
B. vi mode (or command mode)

User can switch to the vi-mode by pressing Ctrl+v+i key-combo. I see the : mode as a variation
of the command mode.

object creating

Not convinced about the shape IDs. We would have to maintain a list of IDs mapping to shape types.
I propose something similar to the f (find) command. When the user presses n and keeps
typing, the stencil starts filtering objects based on the text type and the shape type. Example:
ncl makes the stencil show only "uml.Class" type.

object selecting & modifying on size & rotating

Agreeing, good stuff.

object moving

Agreeing. Only I'd add a command to modify the grid (e.g. g50 would change the grid size to 50px)
for improving the efficiency of moving objects.

object text modifying

Note that certain shapes may have more then one input field. Consider the uml.Class shape that has
three input fields: the class name, attributes and methods.

object color modifying

The key-binding (#) looks good to me. But again, objects have more sub-elements that can have
different colors. And also not sure if typing e.g. #f15ca7 would be convenient. Maybe we
can have something like themes? And have them named?

object deleting

Would just d do the job?

arrows

This would be the most challenging job I think. I have to think about it a little more. Just to align
with the JointJS terminology: Links have source and target. Source/target can either be a point OR
an object id OR an object id together with a selector pointing to a magnet. Magnets are sub-elements
that can be source/target of links. An example of magnets is the Model shape and its ports in Rappid.

OR (just thinking now)

Or we can have another mode (C) selection mode. When in this mode, the user walks through the
objects in the paper by hjkl keys, selecting them. This way the user can select two objects,
then switch back to command mode and press a to link them together (or perform other, mentioned, tasks
that operate on selections.

What do you guys think?

object creating

good, i agree with yours, a find like creating style would be better, for using name not number id, i just worry about people typed too much, of cause you know vi user dont like that. maybe you could build an Autocomplete support for that?

object text modifying

like what you propose on object creating, when you press i, it would try to let you select the target input from multi ones, and if there's only one input, the selecting job done at once

object color modifying

it could be done just like object text modifying, if you have sub-elements that need to modify the colors, the problem is how to show those selectable id or names for user, you might want to set the whole object's color or you just want to set the outter object's color and sub-element's color respectively

i think theme name could be approve, except we need to have a rule for them name , which should begin with a letter that not in [a-f]

object deleting

that's because arrows are belong to object, so when you have already selected an object, you need to use o or a to tell that delete command which should be deleted

arrows

selection mode is powerful, but i dont think it should perform first, because there're so many selectables in a whole canvas. if you perform the special command like f , i, a first, there only left those special selectables

for links build, since its a command that need two selectable(objects or just point), so user need to first select the source selectable and then target

you may say: how do we know what user choice on object or just point on object?

then again we should borrow the concept from object creating, first i think each selectable should have its own and unique identify, which is named automatically, for object, its just rect9, entity6, for those points belong to object, it should be rect9.point1, entity6.point5

the identify looks too long, but with Autocomplete support, user only need to input few keys , like a full link building demo: he should press

a this is for arrow link build
r this is the first letter of rect
this is for calling Autocomplete, which would return he rect in the input buffer
9 this is the object id
. this means we want to select the sub-elements on rect9
p this is the first letter of point type
this is for calling Autocomplete, which would return he rect9.point in the input buffer
1 this is the point id
, this tells the first selecting has been done
e this is the first letter of entity
this is for calling Autocomplete,which would return he rect9.point1,entity in the input buffer
6 this is the entity id
perform the building

you see, not that much key need to press

and i think this is also suitable for object color modifying, if you have plan to support link color, its has been support already!

and to help those typical vi users, we'd better support customized shortpath, so you can use
sEntity9.sub-entity11.point1,p1 to made a shortpath for Entity9.sub-entity11.point1
and next time when he press p1 and , it would return he Entity9.sub-entity11.point1 in the input buffer.

the shortpath name might override the object's identify. user should use it at their own risk