On Wed, Sep 8, 2010 at 2:41 AM, Ville M. Vainio <[email protected]> wrote:
Important: please read the *entire* post before hastening to reply to individual comments here. As you will see, toward the middle I change my mind once, and toward the end I change my mind *again*. > At present, yes. After the release, not so much - as I see it, "core" > is not really the place to add features. It's the place to add features that everyone should have. > It should be something that just sits there, changing as little as possible > through the evolution of software (that is, only when needed). And that's what will happen after the present work is done. > There has never been a > software project that aimed for lower modularity - the trend is always > away from the monolith, towards a more modular solution. Putting more code in leoRst.py does not affect Leo's modularity in any significant way. > Let's consider the situation after the screenshot saga has been played > through and people don't pay attention to inkscape support anymore - > then we'll have effectively dead code in core, eating up (small > amounts, I agree) memory for everybody forever. But bloat is not just > about memory, it's about conceptual complexity as well. Conceptual complexity will be unchanged. > Lean core => better survivability, always. This is a new point. The question is, will Inkscape go away or change it's command line? I doubt it. Even if did, the worst that could happen is that a script would crash :-) Let me summarize my position. I would be perfectly willing to put the inkscape code in a plugin. I might do so just to end this conversation :-) However, I see no real advantage in doing so, and a real disadvantage, namely that some features that I want to use regularly (*core* features, in my estimation) now depend on a plugin. Ok. I'm going to change my mind right now. Something just shifted as I reread you replies and my responses. There are other "core" features implemented in plugins. The inkscape plugin will be no different in this regard from the unl, scripting and plugins_menu plugins. This is an important enough issue that I'm going to repeat your comments, with my new replies: > At present, yes. After the release, not so much - as I see it, "core" > is not really the place to add features. So in the new viewpoint, the core is the *minimal* code required to support Leo's operation. Clearly, some modules are indeed required. We can't do without leoNodes.py, the file code and the code that draws the screen. The question arises, should leoEditCommands.py and leoRst.py be in Leo's core? In my mind, this is *still* a difficult issue. I prefer to leave things alone. > It should be something that just sits there, changing as little as possible > through the evolution of software (that is, only when needed). Hmm. This still does not seem to capture the essence of core vs. plugin. > There has never been a > software project that aimed for lower modularity - the trend is always > away from the monolith, towards a more modular solution. I still think this is irrelevant. All properly designed Python modules are modular, wherever they are. > Let's consider the situation after the screenshot saga has been played > through and people don't pay attention to inkscape support anymore - > then we'll have effectively dead code in core, eating up (small > amounts, I agree) memory for everybody forever. But bloat is not just > about memory, it's about conceptual complexity as well. Again, I still think this is irrelevant. > Lean core => better survivability, always. This sounds good, but again it's a non-issue. Leo's core is going to be "survivable" whatever happens to c.inkscapeCommands. Drat. In the process of trying to agree with you I have convinced myself that leaving the inkscape code in leoRst.py is ok :-) Something is still not quite right. None of the discussion has captured why Leo's design is successful, which is that Leo's modules are well-defined. Each module contains *all* code related to a particular "subject". The only exception that comes instantly to mind is that commands are defined in two main files: leoCommands.py and leoEditCommands.py. This is no big deal. And of course any file can define new commands with @g.command(command-name) So in my mind, the *essential* question is this: can the Inkscape code stand on its own feet, or is it merely a helper for the rst code? Again, this is a close call. Too close to make a big difference, imo. So I'm going to change my mind *again*. I'm going to leave the present code as it is. This is almost entirely a matter of *convenience*: - One module instead of two. - No need to enable another plugin. - No need to document dependence of scripts on plugins. This is a *provisional* decision. I'll be happy to reverse it if it becomes clear later on that it would be more *convenient* to put the code in a plugin. Edward -- 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.
