Hi Vitalije,
I'm following your work in the sqlite-leo branch with great interest.
Congratulations for this great idea and endeavour! Some of your ideas
are being quite inspiring for me.
Regarding your recent comment about simplifying Leo's init code:
However, as I have stated in README of that branch, I am striving to
make a prototype of Leo that can have much simpler init code, Leo
which would allow user to change any setting and see its effect
immediately, and in which user won't have to imagine what color or
font would look like while entering text value for those settings.
... it takes me to what could be a naive question from my part but, is
it really impossible to simplify the init code without requiring the
switch to sqlite-based settings? It seems strange to me that the access
to those settings cannot be made *independent of the underlying source*
by the use of an intermediate abstraction layer or proxy or whatever you
call it... I mean that it should be possible to have also a real-time
settings edition experience by editing Leo outlines, shouldn't it?
Let me be clear in that *I'm not implying nor considering *to throw out
the idea and the work (present and future) on the .leo.db format, but it
seems to be possible an ample separation of the settings handling from
the underlying backend.
Xavier
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
