Note: I subscribe to the lyx users list but not the
developer list so any responces should be mailed or
copied to me directly.
I have a feature I very much would like lyx to have.
It is similar to a feature I implemented a long time
ago for a company that is now defunct.
This feature would be changed much now anyway.
The basic idea is to give the user much more control over how
(s)he maps maps key input sequences to lyx input functions
(more about this below).
I would be prepared to implement this feature once my thesis
is completed (I hope). This should be around X-mas.
In the meantime I would perhaps need a modification to Lyx
that could be done in the meantime.
I assume that Lyx has a list of mappings of user command names to
user command numbers. I would need all of these mappings to be in a
single file (perhaps this is already the case). For example
the file could be called userCommands.h and look like this
#define enterMathMode 3
#define exitMathMode 4
#define findCommand 5
#define copyCommand 6
#define stdParagraph 7
...
This list should include every command that lyx has available for
the user to input including all commands evoked by Menus or key
sequences.
I would also need for there to be a routine that gets the user
input from the keyboard (the input could also come from a menu
but lets avoid this issue for now.)
For example there might be a routine that
reads data from the keyboard and maps the keyboard input data
to the input command numbers. This routine
should be the only way that lyx can get keyboard input.
Perhaps this routine also already exists.
If this routine and the above file already exists then
perhaps no changes to lyx need to be made.
Now here is what I propose to do (eventually).
1) I would create some initial files for a number of systems/terminals
lyx can support. Let's call these files keyMap files.
These keyMap files would look something like this:
enterMathMode Meta m
Meta M
exitMathMode Esc
copyCommand Copy
findCommand Find
stdParagraph Alt p s
F12
...
These files describe the mappings of key sequences to user command
names. The idea is that a basic set of these files be provided
and that users be allowed to create new ones or mofify the ones
available. (Thus the user needs access to the file userCommands.h
so perhaps this shouldn't be a .h file.)
There would also need to be a file for
every system/terminal lyx supports
providing the user with the list of names that lyx uses for the keys
on the keyboard. In the original version of this program this file
maped the key names to the sequences of characters generated when
they were pressed. I think things will work differently now.
This allows the user to specify any (sensible)
sequence of key inputs to be
mapped to any user command names he wishes.
Lets say the user is using a Sun and edits a keyMap file
Sun-Lyx-KeyCommands so that he can use his favorite keys from
his sun keyboard.
The user then has to run a command buildKeyboard on his
Sun-Lyx-KeyCommands keyMap file
before running lyx in order for any changes he made to the KeyMap
file to take affect.
Perhaps there should be a lyx command to reload the mappings
that the user can invoke so that he need not exit lyx to
change his key mappings.
This gives the user a lot of flexibility. Of course he can
hang himself with it.
When the command buildKeyboard is invoked by the user or
alternatively by lyx it takes the data in the keymap file
(in this case file Sun-Lyx-KeyCommands)
and the data in the useCommands.h file and combines them into
a file say, Sun-Lyx-KeyMaps. While the command buildKeys is
at it it can organize and compress the file
Sun-Lyx-KeyMaps so that it
uses as few resources as possible.
Now the data in the file Sun-Lyx-KeyMaps
is accessed by lyx through a routine.
Lets call this routine getKeyCommand(). getKeyCommand() would
replace the routine in lyx that currently provides the function
of processing the keyboard input.
There are five advantages of doing what I propose:
1) Much more flexibility given to the user.
This is the main reason for this change.
2) Lyx runs more efficiently since, at run time, it only needs to
load the file Sun-Lyx-KeyMaps
and from then on it can call the routine getKeyCommand()
when it wants user keyboard input.
3) If the routine is put into a separate library
that lyx includes then this feature could be made to be
independant of lyx altogeher and thus be available
for many other applications.
4) When I implemented a program similar to this it was able to
keep track of the input and store it into a file for recall.
This worked well for generating test scripts to test our
code. In particular these files were keyboard independant.
Alas now users can also input mouse commands and motions and
menu selections so providing such a feature now is more difficult
and unclear.
I have obviously left out a lot of details but I think that I
have provided enough information for a discussion to occur.
I can probably siphon off enough time from my thesis to participate
in these discussions.
Once my thesis is complete I should be able to implement the
command buildKeys entirely on my own. I would need a specification
to be decided as how it is expected to work and in particular
as to how it is to interface with Lyx. The design should be
such that buildKeys can be used in conjunction with a mulitude of
applications.
Note that I do not know C++ and don't want to. But I know C and
am prepared to implement the command buildKeys in C. Afterwards
if anyone wants to convert it to C++ thats fine with me.
I wish Lyx were written in Eiffel or Smalltalk but that's life.
Appologies for this post being so long.
I hope you found it worth reading.
Hopefully you will agree that it is worth adding to Lyx.
The work needed, outside of the work that I do, should be
minimal, mostly involving some reorganizing (good to do anyway)
and removing chunks of code to be replaced by small pieces of code.
If you have further questions fell free to mail me.
Thanks
Ralph Boland
