Leo uses a mono-spaced font for body text. No doubt this comes from Leo's background as a programming editor/IDE. But many people don't use it like that, or not only like that. They use it for creating documents, notes, or other non-programming uses. For these uses, non-monospaced fonts can be easier to read, and also more compact. What would be involved in making Leo use other fonts for certain nodes?
If it were for all nodes a font change would be easy: just change the font-family setting in the theme outline. But this would make all nodes of all outlines use the same font, which is not what we want. There is an obvious way to prevent this: subclass the body widget , which is a *LeoQTextBrowser*. In the theme, add a new logical font family, and in the Qt CSS stylesheet, specify this font family for the subclassed objects. Use this subclassed body editor for the non-mono-spaced nodes. Easy. The next questions are how to change the editor widget on any body node you want, and how to have Leo remember which one to use for which node when the outline is reloaded. Changing the editor widget will probably not be hard. A commander could contain two of them rather than one. All existing body editor code would still work since the subclassed widget would have the same interface as the current one. Persisting the map between nodes and editor class - I'm not clear about the best way to do that. It could be included when other properties are written to the sqllite database, such as the record of which nodes were expanded when an outline is saved. Alternatively, perhaps a new directive would be the best way to handle it. When a page is scanned for directives, if this new one is found the editor is swapped out if necessary. To sum up, to introduce the new capability to Leo, we would need to: 1. Subclass the current body editor class; 2. Add new commands to change or restore the body editor type on a per node basis; 3. Add new commands to make the change to a subtree or the entire outline; 4. Create a way to persist the type of editor to use for nodes across save/restore actions; 5. Enhance some of the theme outlines. 6. Decide whether child nodes should inherit their parent's body editor. Except for 4) and 6) none of this seems like it would need much effort to implement. I'm not sure how much effort would be needed for the persistence aspect. If child nodes should inherit their parent's editor type, that would take some careful work to make sure that all related commands pick up the alternate editor properly. Please post here with ideas and suggestions! Is this something that people would be interested in? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/a6660655-8c19-4a7d-966f-5e85edb1322bn%40googlegroups.com.
