qt plugin: status
Edward K. Ream
plugin.
I've just pushed the beginnings of the non-QtDesigner stuff.
QQQ
revno: 1216 branch nick: qt-plugin
Reorged the code to allow programmatic control of the main window.
1. Removed the File menu.
2. Removed dead code.
3. Added comments.
In particular, c.frame.top is a Window object, and all the leoQtX
classes
use ivars of the Windows class to provide services to Leo's core.
4. Added @auto nodes for qt_main.py and qt_main.ul.
5. Revised and simplified imports so that they don't drag in
unnecessary parts of Qt.
QQQ
The @auto nodes are a nice touch. If you, Ville, change the qt_main
files, please remove the File menu and its actions. That way I won't
have to disable it by hand again.
Other than that, I don't see the need for any changes to the
QtDesigner stuff for now. The adapter classes (leoQtX classes) have
easy access to the main window: c.frame.top is a Window object.
That's just about all that is needed for the adapter classes to drive
any part of the Qt gui.
Now it is time for me to read, read, read the Qt docs.
Edward
Ville M. Vainio
> The @auto nodes are a nice touch. If you, Ville, change the qt_main
> files, please remove the File menu and its actions. That way I won't
> have to disable it by hand again.
Done.
> Now it is time for me to read, read, read the Qt docs.
If you want something to print, you can download "C++ GUI Programming
with Qt 3" at:
http://www.informit.com/content/images/0131240722/downloads/blanchette_book.pdf
It's largely valid for Qt4 as well.
--
Ville M. Vainio
http://tinyurl.com/vainio
Ville M. Vainio
outright harmful low-level tk-isms (and I don't mean just the current
tk implementation, but the fact that such functions would exist at
all):
- All the creation & destruction stuff
- Splitter and scrollbar stuff
- All the low level stuff leoQtTree
- etc etc
I suppose they will be removed or replaced with no-ops?
Ville M. Vainio
a bit (I'm talking about the responsiveness). You can see this when
you compare it agains qleolite, using the same leo document (e.g.
test.leo) and moving around the tree with cursor keys.
zpcspm
>
> > The @auto nodes are a nice touch. If you, Ville, change the qt_main
> > files, please remove the File menu and its actions. That way I won't
> > have to disable it by hand again.
>
> Done.
>
> > Now it is time for me to read, read, read the Qt docs.
>
> If you want something to print, you can download "C++ GUI Programming
> with Qt 3" at:
>
> It's largely valid for Qt4 as well.
about using Qt.
For example:
http://www.qtrac.eu/pyqtbook.html
Ville M. Vainio
> A bit of googling reveals that there are even Python-oriented books
> about using Qt.
> For example:
>
> http://www.qtrac.eu/pyqtbook.html
Yeah, for money. Luckily, the C++ books/docs are perfectly applicable
to PyQt as well, since it's the same API (just convert -> to . and
remove type declarations, and you are pretty much there).
Ville M. Vainio
commands. Unsurprisingly, they don't really work (e.g. insert-node
fails).
Ville M. Vainio
This happened because the icon paths were broken. Fixing.
Edward K. Ream
> It seems much of the code currently in qtGui.py is redundant or
> outright harmful low-level tk-isms (and I don't mean just the current
> tk implementation, but the fact that such functions would exist at
> all):
rough guide, but now that we are thinking of the leoQtX classes as
adapter classes there is not need for most gui-related stuff.
The "tk-isms" are merely placeholders for the essential interface
between Leo's core and the qtGui plugin. The names don't matter, but
the qtGui must implement all the classes defined in the gui base
classes.
For example, I have just finished generating all menus from the "tk-
isms" in the leoQtMenu class. This must be done programmatically, as
you know.
It would be convenient if you would allow me to revert your changes to
qt_main. My code wants to have a menu bar already allocated, and
there is no longer any reason to have "by hand" menu items. When my
code is pushed you can insert whatever menu items you like in
leoSettings.leo!
It this ok with you?
Edward
Ville M. Vainio
> It would be convenient if you would allow me to revert your changes to
> qt_main. My code wants to have a menu bar already allocated, and
> there is no longer any reason to have "by hand" menu items. When my
> code is pushed you can insert whatever menu items you like in
> leoSettings.leo!
>
> It this ok with you?
It's ok. Once I pull, I can re-generate the ui stuff so that I just
allocate the menu, but don't leave any menu items.
Edward K. Ream
On Oct 6, 2:06 pm, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> It's ok. Once I pull, I can re-generate the ui stuff so that I just
> allocate the menu, but don't leave any menu items.
Edward
Edward K. Ream
On Oct 6, 2:02 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
> On Oct 6, 12:13 pm, "Ville M. Vainio" <vivai...@gmail.com> wrote:
>
> > It seems much of the code currently in qtGui.py is redundant or
> > outright harmful low-level tk-isms (and I don't mean just the current
> > tk implementation, but the fact that such functions would exist at
> > all):
>
> The stuff that creates most widgets will be removed.
improvement to separate the gui-creation stuff from the adapter
classes. For example, leoQtMenu needs only to set
self.menuBar = c.frame.top.menubar
in order to gain access to the part of the Qt gui it needs. Similarly
for the tree and body stuff.
So yes, you could consider the old mix of code to be harmful: it is so
sweet to have most of the gui complications in the Ui_MainWindow
class. In the new order of things, the adapter classes are, with the
exception of the leoQtMenu class, dealing with already-created
objects.
As you can see, very little code is needed in the leoQtMenu class to
generate menus and menu items (actions). The only ugly part was that
Leo's core thinks that the menus returned by the adapter class are
real gui menus, so I had to hack a wrapper class which is both a QMenu
and a leoQtMenu. Very ugly, but it works.
Edward
Ville M. Vainio
>> The stuff that creates most widgets will be removed.
>
> I should say a few more happy words about this. It is a *huge*
> improvement to separate the gui-creation stuff from the adapter
> classes. For example, leoQtMenu needs only to set
I'm happy to hear that you share my thoughts on this. I was coming up
with a mild rash from the thought that model/engine would be
instantiating and configuring concrete GUI objects...
Ville M. Vainio
kinds of cool stuff to log as html (images, rich formatting,
hyperlinks etc):
Ville M. Vainio
> I just added QTextBrowser to log panel. It will allow users to put all
> kinds of cool stuff to log as html (images, rich formatting,
> hyperlinks etc):
Additional rationale: we can dump clickable links to log that select a
leo node specified as url. This is particularly cool e.g. for search
results, error messages etc.
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> > I just added QTextBrowser to log panel. It will allow users to put
> > all kinds of cool stuff to log as html (images, rich formatting,
> > hyperlinks etc):
>
> Additional rationale: we can dump clickable links to log that select a
> leo node specified as url. This is particularly cool e.g. for search
> results, error messages etc.
Will you be back porting to the Tk interface? ;-) Just kidding.
Although, come to think of it, someone demoed a tk-html pane a while
back.
Cheers -Terry
Edward K. Ream
I don't see this at present. There were some problem with launchpad
yesterday. Did you ever actually up this. Or maybe there was a
reversion?
The present leoQtLog class creates tabs programmatically. It would be
easy to use a QTextBrowser instead of the QTextEdit object. The
selectTab method creates the tabs. Feel free to make this change if
you like: you would also have to modify the put and putnl methods of
the leoQtLog class.
Edward
Edward K. Ream
> Will you be back porting to the Tk interface? ;-) Just kidding.
I guess I don't understand the joke. The gui plugin interface is what
I'm porting to. There are some hooks in various places that work
around, for example, the weird Tk text indices. These hooks are do
nothings for wx and qt text widgets.
> Although, come to think of it, someone demoed a tk-html pane a while
> back.
The qt gui plugin, or any other gui plugin, is free to do *anything*
provided that it implements the interface in the gui base classes in
leoPy.leo. You'll see this in action in the next few days.
Let's step back and see the big picture. In essence, the gui plugin
does three main tasks:
1. Creates Leo's window.
2. Handles events, and calls methods of Leo's core.
3. Handles calls from Leo's core to manage gui elements.
There has been considerable discussion of task 1. Yes, it's nice that
QtDesigner does some of the work cleanly, but by no means can it
possibly do all the work. For example, tabs can be created
dynamically, as can body pane editors.
As I write this, however, it see that it would be helpful if Ville
could create the 'Log','Find' and 'Spell' tabs in QtDesigner.
Anyway, the bulk of the problems typically arise in tasks 2 and 3.
That's where we'll see how capable the body and tree widgets are.
Edward
Edward K. Ream
> I'm happy to hear that you share my thoughts on this. I was coming up
> with a mild rash from the thought that model/engine would be
> instantiating and configuring concrete GUI objects...
matter. The gui must create tabs and body editors programmatically.
Perhaps QtDesigner can help, but no static tool can do all the work.
There is no substitute for substantial code in the various leoQtX
classes. There is no free lunch.
Edward
Ville M. Vainio
> As I said in another comment, this doesn't get to the heart of the
> matter. The gui must create tabs and body editors programmatically.
> Perhaps QtDesigner can help, but no static tool can do all the work.
> There is no substitute for substantial code in the various leoQtX
> classes. There is no free lunch.
As I said, dynamic creation of tabs is easy, so no worries about that.
Regarding free lunch, I feel that Python and Qt are all about free
lunch ;-)
Ville M. Vainio
> On Tue, Oct 7, 2008 at 12:01 AM, Ville M. Vainio <viva...@gmail.com> wrote:
>> I just added QTextBrowser to log panel. It will allow users to put all
>> kinds of cool stuff to log as html (images, rich formatting,
>> hyperlinks etc):
>
> Additional rationale: we can dump clickable links to log that select a
> leo node specified as url. This is particularly cool e.g. for search
> results, error messages etc.
Screenshot attached ;-)
Kent Tenney
Drool.
Edward K. Ream
>>> I just added QTextBrowser to log panel.
Very cool.
I'd like to be able to switch between QTextBrowser and QScintilla in
the body pane. The leoQtBody interface to the core makes this easy:
just implement the interface for QTextBrowser instead of QScintilla.
Of course, the body then has to be created in program rather than just
in QDesigner. But in fact, we have to do that anyway to support the
two orientations for Leo windows.
Edward
Ville M. Vainio
> I'd like to be able to switch between QTextBrowser and QScintilla in
> the body pane. The leoQtBody interface to the core makes this easy:
> just implement the interface for QTextBrowser instead of QScintilla.
>
> Of course, the body then has to be created in program rather than just
> in QDesigner. But in fact, we have to do that anyway to support the
> two orientations for Leo windows.
It can be done with QStackedLayout. It's something I wanted to do as
well - people may sometimes want to edit rich text in leo, for
example. However, we really want QTextEdit, since that's editable.
Peter Bienstman
> It can be done with QStackedLayout. It's something I wanted to do as
> well - people may sometimes want to edit rich text in leo, for
> example. However, we really want QTextEdit, since that's editable.
keep track of notes, then some extra formatting or the ability to
insert pictures would be nice.
What would be even nicer is that each node had an attribute to specify
which widget is used to edit/display it. That opens all sorts of
extremely interesting possibilities, like having a special widget for
contact data or appointment data or anything else the user could come
up with.
Peter