Last active
December 25, 2015 03:59
-
-
Save yunfan/6913572 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
================================================ | |
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 berect9.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