[wxPython-users] Pallavi 0.5: Text editor utilizing wxPython

[Dusty Phillips]

> You might think about signing up for the pyxides group
> (http://groups.google.com/group/pyxides) -- it's a low traffic list
> dealing with python based editors and trying to promote collaboration
> among us clan of wxPython-based editor writers.   (I'm the author of
> Peppy.)

> So, I recommend joining the pyxides list.

Excellent! Requesting membership immediately. Thanks for the pointer.

Perhaps I should be replying there. I wouldn't want to impose on Sir
Robin's hospitality for too long. We may have to eat every one of his
minstrels.

> > I came across Peppy about a month ago when I started adding
> > wx.aui. I considered joining development at the time, but it seems a
> > bit "overengineered" for my taste).
>
> Probably an indictment of my documentation. :)  I can understand why
> you might think that, especially when the website focuses on the
> software development process from the project management point of
> view.  I need to rewrite the focus from a development point of view.
> Developer-level docs haven't been a priority for me as my framework is
> still evolving, but perhaps that was a bad choice on my part.
>
> And, also, I'm trying to write XEmacs in python. :)

Whereas, when it comes down to it, I'm trying to write JEdit in
python, but with only one language instead of three.

>  It is designed to
> be much more flexible than a normal text editor, with major modes that
> don't necessarily have to be STC instances.  For example, you can edit
> a file using the STC, switch a hex edit view of the same file and edit
> a few bytes in hex, and switch back.  Or, view a png file and in
> another view look at the hex bytes.

I've been considering whether or not it will be necessary to replace
STC with a more generic buffer. STC is super-powerful, but its hard to
extend in Python since its C at heart.

> So, my goals for peppy's framework were different than yours, but that
> doesn't mean there won't be collaboration among all of us.  Check out
> PyPE and SPE for more code ideas.  I've borrowed a bunch of code from
> them.

Done a little of that, although I rewrite everything. Both those
editors crashed a lot when I tested them. Plus, I chose an MIT license
because I can comprehed it (compare GPL), so I'm not sure how legal it
is to borrow code from GPL'd editors.

> I like your EventBus idea.

I can't take credit for that; its directly inspired by JEdit, although
it seems that most jEdit plugin developers don't use it. I've tried to
make it clear that plugins should pass all messages on the bus. That's
why, for example, there is no way for one plugin to get direct access
to another. The idea is that if one plugin sends and receives the
exact same set of events and actions as another plugin, it can behave
as a drop-in replacement (perhaps with much different functionality)
for that plugin without other plugins having to be any the wiser.

> My current work in peppy has been with
> wx.lib.pubsub and message passing, and the idea of trying to get
> messages to particular frames and STC components without keeping track
> of a list of listeners myself.

Yet another aspect of the mammoth that wxPython is that I wasn't aware
of. :-) I have (rather unsuccessfully) been trying to keep the STC and
wx components as isolated from the rest of the code and plugins as
possible. I was hoping it might be possible to create a variety of
interface plugins that might allow, for example, ncurses-based, gtk or
qt-based, tk-based, cocoa-based, etc interfaces for the same core
editor. But I've ended up relying too much on wx because its... so
easy.

> From pain of experience, I'd recommend thinking about multiple
> top-level windows and multiple views now, if that support is of any
> interest to you somewhere down the road.  I spent a lot of time
> working with other editors before deciding to write my own framework
> because I couldn't get around global variables or other assumptions
> that made hacking multiple frames into other editors too difficult.
> For example, view in your code seems to be tied to one wx.Frame
> instance, so that means that a plugin can only be tied to a single
> top-level window?  Maybe I'm not reading your code correctly...

That's correct. Once I had thought of sending views as a (globally
maintained) list of wx.Frames to plugins. Right now, the view is the
main parent when it comes to communication. But I don't think it will
be that hard to refactor it into some kind of "view manager". The one
thing I've been worried about is the wx.aui code. If aRandomPlugin
creates a docking window, which view (wx.Frame) does it attach it t
to? As far as I know, its not possible to replicate aui dock windows
to multiple AUIManagers. I also don't think its possible to drag them
from one AUIManager managed frame onto a second one.

At any rate, as a result of Chris' request and your advice, I think
I'll put multiple views on the todo list for 0.6.

> Also, you might be interested in the setuptools plugin system for
> user-written plugins.  It is becoming the de-facto standard in plugins
> by defining a hooks for plugin entry points.

I'll look into it, thanks. I'm not sure I can leverage the dependency
resolution aspect of it because my intention of allowing multiple
plugins to replace each other means that no one plugin can depend on
another.

Distribution has been a major pain for me -- installers, OS-dependent
paths, dependencies... and so far I haven't done anything for
distributing plugins. One thing I hate about JEdit is the
plugin-manager. I figure there's no sense in writing a distribution
system when most OS's provide one already (be it linux package
management, Windows installers, etc). Utilizing setuptools may meet
the happy medium nicely.

Dusty