I was thinking about what Terry said in a recent thread related to plugins: "Maybe it would be cleaner to have just one file, i.e. have cleo import todo if it senses qt."
This makes me think about a general problem with plugins. At present, plugins are managed by an @enabled-plugins node in an outline. The plugins are present in the body of this node. Commented lines are ignored and those plugins are not enabled. I do see a little problem here. The body of a node is *flat*, like a text file. Plugins can have dependencies (other plugins). This is already a hierarchy, and this is something that leo is very good at! What do you think, would it be possible in the future to manage plugins as them being a subtree of the outline? Leo can keep the @enabled-plugins node (as root of this subtree), but have one node per plugin (dependencies as nested nodes). The body of the @plugin nodes can be used to store plugin-specific configuration options. This post would not be complete if I won't explain what made me think about this. Consider it a story. I know Edward is fond of them :-) So, I am an user of Slackware Linux for some time. Slackware Linux has something specific. It's package manager doesn't track dependencies between packages. This task is left for the sysadmin, who is supposed to know what to do. This was a reason for countless holy wars and attacks against this distribution. I was using a flat text file for a couple of years to track dependencies between packages. This was before I found out leo. With leo this become easier. No, it become *much easier*! All that I'm doing now is to create a node for any package. If another package depends on it, I just paste its node as clone and make it a child of the first package. So when I have to install a package, I walk deeper into its subtree and install its dependencies first. I'm not very good at algorithms (and I'm not proud of it at all!), but I believe this is similar to backtracking. The moral of this story is simple. Data stored in some hierarchy is much easier to manage than flat data. Every leo user knows this axiom. So I wonder if the plugin architecture of leo can benefit from it, because leo already provides an usable backend. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
