On Wed, Nov 19, 2008 at 11:02 AM, Jesse Aldridge <[EMAIL PROTECTED]> wrote:
> I have a program that uses wxPython and I want to port it to Qt due to > a bug in wx. I know the feeling. > So I'm thinking I might as well abstract my gui > functionality and allow for easy switching between wx and qt. Since > Leo has recently done something similar, I was wondering if there is > some sort of gui wrapping functionality I could pull out of Leo to use > here. I'm looking for, like, a general explanation of how it works > and what files I should look at. The big picture is this: - Leo interfaces with each gui through a subclass of the base leoGui class. The subclasses init the gui, run the main loop, etc. In particular, the subclasses create the Leo window by calling methods of leoFrame.py, which are actually implemented in gui-dependent subclasses of the classes in leoFrame.py. - Leo's core interfaces with the body pane and other panes via subclasses of the base baseTextWidget class in leoFrame.py. For example, all of the commands in leoEditCommands.py assume the 'w' variable is a (subclass of) baseTextWidget. This is the essence of what makes Leo's core gui-independent. You can see all this in action in the qtGui.py plugin. As you can see, must of the details involve supporting Leo's tree. Supporting the baseTextWidget interface (by creating a subclass) is quite straightforward. The qtGui.py plugin uses subclassing to minimize the amount of code that is written. Please feel free to ask more questions. But before doing that, I would study the following: 1. The base classes in the tree: 'Code-->Gui Base classes' in leoPy.leo, especially the documentation in the node 'Code-->Gui Base classes--><< about gui classes and gui plugins >>' 2. The corresponding tkinter sublcasses in the node 'Code-->Gui Tkinter classes'. You will see that the subclasses are usually much simpler than the base classes, with the notable exception of leoTkinterTree.py which implements a tree widget "by hand". 3. qtGui.py, which contains all the Qt-specific code. 4. The two flavors of the wx gui plugins in LeoPluginsRef.py, in the tree: 'Plugins-->Experimental' Neither of these plugins is functional. In particular, the interface with Leo's core (the gui base classes) have changed since these were written. Still, they will give you an idea of the scale of the work involved in doing Leo in wxWidgets. Your porting job will likely be easier. HTH. > I don't know, maybe this is more trouble than it's worth. Writing my > own wrapper wouldn't be too hard (I don't think). But it's not good > to reinvent wheels, so I thought I'd give this a shot. It's your call. One of my favorite sayings is that reusing designs makes sense; reusing code often does not. 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 -~----------~----~----~----~------~----~------~--~---
