Rev 1201 contains a the new qtGui plugin, a repackaging of Ville's
recent qleolite code.  I tested this with test.leo.  To enable the
plugin, uncomment the line # qtGui.py in the @enabled-plugins node in
test.leo.

Here are some technical notes while they are still fresh in my mind:

No substantive changes were made to Leo's core to support the plugin.
I added two or three missing do-nothing methods to base classes and
improved the oops messages that are printed when a subclass should
override a method but doesn't.

The qtGui plugin now works pretty much as did the qtGui plugin.  I
temporarily disabled the interaction with ipython, but it probably
could be added back...

The qtGui plugin does not use the leoBridge, or use any other major
hacks.  It is much more fully integrated into Leo than the qleolite
code.  In particular, it provides the classes that Leo's core expects
to see: subclasses of leoFrame, leoMenu, leoTree, etc.  In some cases,
such as the log classes, I simply used the base class.

Leo now goes through its very complex init code without major
problems.  As you will see, there are a few oops messages about
missing overrides, but nothing real bad happens.

c.frame.tree.redraw_now calls  c.frame.top.populate_tree, i.e.,
Window.populate_tree and all pretty much works as before.  The Window
class must eventually migrate to the other gui classes.

I actually have not looked closely at class Ui_MainWindow.  Apparently
it comes from the gui designer.  Eventually I will probably have to
shuffle the code to other classes, or at the very least assign
"official" ivars like c.frame, c.frame.tree, c.frame.body to entities
created in the Ui_MainWindow class.

Most of the code in the leoQtFrame, leoQtTree and leoQtMenu classes
does nothing.  It certainly does not add anything to the actual Qt
code at present.  Instead, these classes are the interface with the
rest of Leo's core.  As you can see, the interfaces are fairly
"capable": they allow Leo's core to get information from the gui
widgets, to control the text widget, and to set user-defined
characteristics of the various gui widgets.

There is a lot of fairly tedious work involved in fully hooking up the
connections between the widgets and Leo's core, but this work is
extremely worthwhile: it means that Leo's core should not have to
change *at all*.  That's the whole point of these classes.

Opening another leo file works, but an exception is thrown.  In spite
of this, the other Leo file appears as it should.

The next steps will be to clean up the gui classes and to add Qt
widgets to the main window.

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to