Recently, I was working mostly on a leo.external.sax2db script (*part of 
sqlite-leo branch). Idea was to make stand-alone script that can parse xml 
leo document and produce sqlite db version of it. The first part of it was 
to transfer outline with all vnodes and their ivars including v.u. This 
part went smoothly and it is capable of turning any Leo document from XML 
file to its db version.

The second part was supposed to collect all the settings from the outline 
and store them in separate table. I wished to implement it in such way that 
it uses from Leo code base only those objects that are easy to instantiate, 
that don't require special init code. And I almost made it. It searches 
tree and collects all settings creating table of tuples:

(gnx, kind, name, value, conditions)

conditions is a list of conditions that affect this particular setting. A 
condition may have any of the following forms:

   - ifhost: hostnames,...
   - ifenv: env values,...
   - ifplatform: platform,...

In tuple this list of conditions is joined with some special separator 
'|#|' which is unlikely to be part of hostname, environment vars or 
platform names.

The idea was to store all those tuples in database table and on opening Leo 
document to calculate conditions and select only those settings whose 
condition list is True. Empty list of conditions is considered to be True.

I have been implementing one by one all needed functions for dealing with 
different kinds of settings and everything went smoothly until I came to 
at-commands, at-buttons and at-outlinedata kinds. Those kinds require 
g.getScript, and it requires operational commander. Now I had two choices:

   1. to re-implement g.getScript without commander and that means 
   re-implement write file logic with all possible at-directives, or 
   2. to raise white flag and admit that it was a bad idea in the first 
   place

This get me to think again about the reasons that lead me to this. I wanted 
an easy way to change shortcut, or color or font and see the effect without 
delay. I wasn't feeling very comfortable with the idea of using PyQt to 
implement those features and I wished to implement gui for those parts in a 
web page where I feel more like being at home. For creating such web page I 
needed access to settings and some way to persist the changes in settings. 
Now, after swallowing large amounts of Leo's code, I feel confident enough 
to access all settings data directly in Leo. As far as persistence is 
concerned, I am confident that I can write command to open relevant 
settings file, make change there and save it again. So that part of the 
problem is solvable. The only thing that remains to be done (apart from web 
page) is reloading settings and Edward has created branch for it and 
presumably it will be done in foreseeable future.

Now as I am becoming more and more familiar with Leo's code, implementing 
something in PyQt doesn't seem so frightful anymore. I need to experiment a 
bit.

I wish to implement as a start three very simple dialogs. One for entering 
shortcut, one for entering color and one for entering font. As I write this 
I have just remember that commands `show-fonts` and `show-color-wheel` 
already exists. So it will be just shortcut dialog. It will have just one 
input control which will register any KeyEvent in format that Leo would 
accept for at-shortcuts setting line. When user edits at-color settings 
node, opening color dialog should start with the present color value 
selected and after clicking OK it should change the value in headline. When 
user edits at-font settings node, clicking OK should adjust body of node to 
selected font. When editing line in at-shortcuts node opening shortcut 
dialog should change the relevant line with pressed key combination. In 
more advanced version of shortcut dialog it may present user a list of all 
commands, filter field for filtering commands list and user would be able 
to select command from list and press key combination to be bound to 
selected command.

Vitalije

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to