Re: QtDesigner/Glade

[Richard Dale]

On Wednesday 16 January 2002 10:20 am, Helge Hess wrote:
> Richard Dale wrote:
> > I think the Qt Designer format is too specific to the Qt toolkit to use
> > as a AppKit format. For instance, here is a sample extract:
> >
> >         <widget class="QPushButton" row="3" column="2">
>
> ...
>
> >             <property name="enabled">
> >                 <bool>false</bool>
>
> ...
>
> > It has the name of a Qt widget 'QPushButton', and expects it to have
> > properties compatible with other Qt widgets.
>
> Why can't we map that to an NSButton ? I would expect that the
> functionality of Qt and AppKit is pretty much the same.
Yes, you could write Qt compatibility categories for NSButton and other AppKit 
widgets.

> The only tricky thing is the box system, but even this should be pretty
> similiar between Qt, Gtk+ and GS-Appkit for most stuff ?
Qt has various layout classes such as QBoxLayout, QHBoxLayout and QVBoxLayout 
etc. They assume that the widgets they are laying out will have certain C++ 
methods that they can call to resize the widgets, so you couldn't do that 
with Qt compatibility categories. There would need to be a C++ peer instance 
associated with each AppKit Objective-C widget to interface with the layout 
managers - a pain without Objective-C++..

> > On the other hand, it would be possible to generate Objective-C/Qt code
> > via the Qt Designer uic utility for the KDE Qt/Objective-C bindings
> > project,
>
> ...
>
> Well, I'm not so interested in using Qt ObjC (only a bit ;-). I would
> love to have a common XML based format for generating UI for any of Qt,
> gtk+, AppKit, Aqua, ... - like XUL. Of course choosing an XML format
> which already has UI builder support is best ;-)
I still think that you have to make the other toolkit widgets look like Qt 
ones before you could use Qt designer. So I don't think you would have 
created a common XML format, but more a 'Qt widget behaviour protocol' to map 
'foreign' widgets onto the Qt runtime. 

Qt Designer assumes event handling would be done in the Qt style, which is 
much the same as the AppKit - ie you subclass a widget to do event handling 
rather than add event listeners like Java. So perhaps a 'compatibility 
category' could manage the translation between AppKit events/methods and Qt 
ones.

> > The .ui file format isn't language independent as it can contain embedded
> > snippets of code (always C++ at the moment), which makes it specific to
> > whichever language you were using with Qt Designer.
>
> Who forces me to use the code features ? If I use Qt Designer just for
> layout, I would expect that the .ui file doesn't contain code. Even if
> it does contain C++, we might soon have ObjC++ in gcc 4.x ;-), so this
> could be a cool feature in any case.
Yes, slots are just void methods - only the way you call them via emitting 
signals is specific to Qt.

> > And it assumes widgets
> > are connected via the Qt slots/signals mechanism, rather than
> > outlets/actions.
>
> Yes, this would need to be mapped too, but I'm pretty sure it is
> wouldn't be too complicated, as the concept is always the same (UI sends
> some message to some object ;-)
Yes, the AppKit itself doesn't have any runtime support for outlets and 
actions, that is only done in InterfaceBuilder I think. So they are just 
instance variables and methods which could be connected nearly as easily via 
signals/slots using the Qt Objc bindings runtime, as with IBConnectors (is 
that the class InterfaceBuilder uses, I've forgotten..).

-- Richard