Yes, Dusty, welcome to the Text Editor Writers support group! I'm hopeful that we can all continue to share ideas and code. In writing peppy, I started off as a pet project where I was writing most of my own stuff, but as it got bigger, there was more to debug. I started thinking that it would be a good idea to let the time spent by others not go to waste. So, I started shamelessly borrowing code.
What I'd love to see with pyxides is a lot of code that we could mix and match among applications. Stani's Fold Explorer comes to mind, if I'd ever get back to working on the text editing part of peppy rather than the framework. I know we all have different goals with our editors, but were we to have a big set of code with few external dependencies (i.e. low coupling), we could all borrow stuff at will. For example, the overarching goal of peppy is to have multiple top level windows with multiple ways to view the same file. That may be too much overhead for some people to consider using peppy for a framework, and that's cool. But, if I can make some of my stuff independent enough, maybe it will be useful for others. I've been trying to pull stuff out of classes where I can and putting them into mixins or standalone files in the peppy.lib module. To kick off some discussion, I was wondering if you'd talk about (or point to a good description of) the jedit plugin system that you were emulating. Do you have to define all the messages that get passed around in advance, i.e. do all plugins have to implement the same interface? For peppy, I rolled my own plugins for a while until I ran across the Trac component architecture (http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture). Basically a Trac component (aka plugin) is a singleton that registers entry points that other Trac plugins can add themselves to. You define interfaces, and one plugin can implement one or many of the interfaces. I have found that useful. The implication of this architecture is that you can't have multiple instances of the same Trac plugin -- you've got to treat the Trac plugin as a factory to generate other objects. That's its drawback, I suppose, and though I've found that limiting at times there were always ways to work around it. As a bonus, they integrate well with the setuptools plugins. The thing that intrigues me about what I think I understand about the jedit plugins is the message passing. I wonder if a Trac component could be a factory for jedit plugins? I'm still struggling with message passing (wx.lib.pubsub), because with my multiple views I might want a message to be sent to only one of the views, but there's no way to do that with vanilla pubsub. I was trying to get away from the message *passer* having to know the target view: it just sends its message and the message passing facility would knows where to direct it. Don't have a good solution -- I could have each message receiver check if it is the intended target, but it seemed like there should be a better solution. Rob
