Almost There...

So, it's a bit less than 1 month since I started working on QtMaxGUI, and it's fair to say that it is mostly functional at this point, and depending on what parts you need you could even say that it is capable of performing those functions completely.
MaxIDE is running fine apart from some outstanding issues :

• Menu shortcuts do not currently override built-in keyboard shortcuts. I think I will need to implement a filter on the parent window to accomplish this, which will filter all the relevant key presses and create a Gui Event for them.
• In/out-denting does not work as expected. This is due to issues with the position of the text cursor/anchor. Also programmed cursor movement may be raising events when they shouldn't be - confusing things somewhat.
• Popup/Context menus are not yet working. There were problems creating an action with no parent (as MaxIDE does for pre-building the context menu), so I'm not sure what will happen when I plug this into a context menu creation event.
• The HtmlView does not seem to work on Win32. I think on that platform there are issues with overriding the event handler functions, as I already had to comment out the paintEvent() override to stop it crashing. Which is funny, because all it does it how I explained it previously - by calling into BlitzMax which then calls the original super-class function. It almost seems as if there is some kind of corruption occurring during the C++ -> BlitzMax -> C++ path. The other platforms are fine. I may just end up removing all the event overrides for QWebView and see if it solves the problem.

That's all that come to mind at the moment. Everything else appears to be fine. "Dialogs" all seem to work. Find, finds stuff, etc.

I say "Dialogs" because they are not QDialogs (which are designed for the role of a small, in-program window). They are QMainWindows, which are really meant for a different job, but unfortunately MaxGUI assumes it can do all kinds of things to a window which a QDialog doesn't do without more work, and which a QMainWindow is designed for. But, I think I've managed to work around it and get things appearing to function as expected.

I had a few more issues recently with my item model. It turned out that the root node/item would often return an index of -1, -1, rather than an invalid index. This confused some views more than others, to the point that most TreeViews in MaxIDE were fine, but the Debug view didn't show any content, and the comboboxes were completely broken!

However, after a whole day of debugging, I found I only had to add a single check in the right place and it all started working. Black Magic :-p

It's certainly been an interesting project, which has advanced QtMax in leaps and bounds, and helped me to better understand more of the lower-level functionality of Qt.

Much of the QtMaxGUI glue is a dumbing down of the Qt API though, since we are having to throw away a lot of the "cool" stuff in order to make it work in a certain way. I would still recommend that you are better off using the Qt API as it was intended as your program will be much, much easier to write, and much much more object-oriented ;-)

Untouchable Views

So there I was, having a look at implementing QListView and realising that, as a control/widget, it didn't have any direct item interaction methods whatsoever!

Oh, bugger...

Fortunately, as noted in my last post, I've been creating a BlitzMax version of a type of a item model which subclasses QAbstractItemModel. And for QComboBox it is working really well. Changes to items on the combo eek down into the BlitzMax item objects. Whenever you change data in these item objects, they emit events that the rest of the model/view framework can handle appropriately. It's all rather cool and groovy!

Anyway, back to QListView. It doesn't do very much, on the face of it, apart from display a list. Any (and all) interaction with the items is done via the model and the "selection model". Changes to the model filter up to the view automagically, and stuff appears (or disappears) in the visual list before your very eyes.
As a framework, it appears to work very well indeed. Of course, if you are used to doing stuff directly with controls/widgets it is a bit of a leap to start playing with the model instead, and simply ignoring the view altogether!

As an example, if we want to change the text for an item in QComboBox, we simply call :

setItemText(index:Int, text:String)

and all the real work of processing that information and is handled by QComboBox.
On the otherhand, if we want to change the text for an item in QListView, we need to :

model.setData(index:QModelIndex, text:String)

where index is a reference to the location of the item in the model (row, column, parent item).
Notice that we need the model, and a way to map our row/index to the model's index reference.

Once we set/update the data, the view will update the text accordingly.

So, when we are working with Views, look, but don't touch!

:o)

Not so QStandardItem...

So there I was trying to work out how I might integrate a model/view design into QtMax for handling all of the list/tree widgets, and I got to reading the QStandardItem/Model documentation.

"Hey, that sounds like just the thing I need!" I thought to myself, and hacked away at creating the wrapper code for QStandardItem and QStandardItemModel, using a custom QStandardItem object which handled user Object data on-the-fly.

Everything was looking shiny and new, so I decided I should test it out, and knocked together a quick QComboBox test app, which used my model and added a couple of items via the comboBox API.

Ta da! … oh, wait… nothing is actually happening!?

Further investigations revealed that QComboBox wasn't designed to expect a subclassed QStandardItem and went happily off to create base QStandardItems itself without using the "factory" that the documentation said I should implement (::clone()).

Which, as one would imagine, was somewhat of a let down after writing a whole bunch of code that I couldn't use ;-)

… time passes …

I pondered and pondered for a while, and went through a couple of mis-starts, but then came upon the idea that the best thing to do would be to code most of what I needed in BlitzMax, and interface that directly with the backend C++ classes, which would mostly act as a pass-through.

Okay, so the thought of implementing my own item/model for plugging into a QAbstractItemModel was a tad on the daunting side, considering that I wasn't only writing a couple of C++ classes, but a bunch of helper types, object transformations  and the main BlitzMax types to hold everything together.

I ended up keeping the names, QStandardItem and QStandardItemModel, and rewrote what I already had. I decided that all the item info needed to be kept in the Type, so I came up with a way to store everything in a TMap based on the "roles" that the model/view framework uses. I also built a custom children item holder which is based on an array, rather than a TList. I thought that it would be quicker doing lookups on an array index than trawling through a TList, and I am happy to take a hit on the resize of the array when it is required.

Because the underlying system passes data via QVariant, we need to do a lot of conversion between that and Objects. but it's simple casting so it shouldn't be too slow.

It took a whole day to get to a point where I was ready to try the QComboBox test app again, and after a couple of minor tweaks, I was very pleased with the results.
A simple call to :

combo.addItem("item 1", data)

iterates through the entire model framework, creating a new QStandardItem and populating it appropriately with all the role data, and even the user "data" object, which you can then retrieve by calling itemData(index) !

Of course, there's still much to do, like implementing cleanup and so forth, but with the basic engine running I feel much better about using this as a core for all of the Item-based widgets - lists and trees.

:o)

Event Handling (or Round and Round in Circles)

Today we are going to discuss how to wrap a Qt event handler function in BlitzMax.

Meet our friend, an event function :

void QLineEdit::changeEvent ( QEvent * ev )

This is called in Qt whenever the contents of a QLineEdit changes. Details of the event can be found in the QEvent object passed into the function.

In BlitzMax, our QLineEdit type has a matching method :

Method changeEvent(event:QEvent)

You can subclass QLineEdit with your own BlitzMax type, and whenever the text changes, your overriding method will be called :


Type MyQLineEdit Extends QLineEdit

Method changeEvent(event:QEvent)
Print "It Changed!"
End Method

End Type

Well, that's just great, says you, but how does the magic really happen!?

Ah, I'm glad you asked, because it's really rather interesting.

If we were writing in C++, it would simply be a case of creating our subclass and implementing the overridden function in our new class. For any events we don't care about, we don't override them. Job Done.
However, with a wrapper, because BlitzMax code sits so high above the C++ glue you need to override ALL of the event functions so that you can push them back into BlitzMax and either perform the default function, or call into the overridden method in the new Type.

So, the first step is to override, the event function :


void MaxQLineEdit::changeEvent(QEvent * ev) {
_qt_qwidget_QWidget__OnChangeEvent(maxHandle, ev);
}

In our QWidget BlitzMax type we already have a callback function set up for this event (since changeEvent() is a QWidget event that QLineEdit overrides itself), so we can call this. maxHandle is a handle to our BlitzMax object (the one with the method).

In the QWidget type, our callback function simply constructs BlitzMax objects and calls the real method :


Function _OnChangeEvent(obj:QWidget, event:Byte Ptr)
obj.changeEvent(QEvent._create(event))
End Function

Because BlitzMax is clever, if the "obj" object happens to be a subclass of QWidget, the changeEvent() method of that subclass will actually be called instead, and therefore, your overridden method will be called.

But what of those methods you haven't overridden? Shouldn't they perform their original functionality? Well, yes, of course, and therefore we must also supply this default functionality by calling back into Qt and handling the original event.

Our QWidget type has this default method call :


Method changeEvent(event:QEvent)
bmx_qt_qwidget_default_changeevent(qObjectPtr, event.qObjectPtr)
End Method

Subsequently calling this function in our C++ glue :


void MaxQWidget::defaultChangeEvent(QEvent * event) {
QWidget::changeEvent(event);
}

Which, as you can see is allowing Qt to handle the event as it would normally if we hadn't overridden it ourselves!

Ideally, in our original example, any events that your override yourself, you should really add a call to your superclass method so that Qt might have a chance of processing the event too. Otherwise you might your application acting strangely.
So, doing something like this is a good idea, unless you have a reason not to :


Method changeEvent(event:QEvent)
Print "It Changed!"
Super.changeEvent(event)
End Method

If you like going around in circles, writing wrappers may be for you!

Happy coding!

:o)

Wouldn't it be interesting..

.. if MaxIDE was actually stable on Linux, and didn't want to crash/hang/annoy at every given opportunity?

That would probably require creating a MaxGUI wrapper for QtMax (itself being a BlitzMax wrapper for Qt).
There are many advantages to doing this. The main one I see is that I get to test QtMax and check that I'm implementing all the things for all the widgets that I need to be. So, for example, any widget subclasses really need to implement all of the inherited event handlers and so forth. For example, a QLabel should implement inherited events from QObject, QWidget and QFrame, as well as its own.
It's not a difficult job, there's just a lot of it!

Having a rummage through the GtkMaxGUI source, it is incredibly messy down there. I think the main reason is that raw Gtk is harder to use generically.
As an example to show how easy it is to create a CheckBox for use in MaxGUI, here's some basic code :

Type MaxGuiQCheckBoxButton Extends QCheckBox

Field gadget:TQtGadget

Method MCreate:MaxGuiQCheckBoxButton(text:String, parent:QWidget, owner:TQtGadget)

gadget = owner

Super.Create(text, parent)

Return Self

End Method

Method OnInit()

connect(Self, "toggled", Self, "onToggled")

End Method

Method onToggled()

PostGuiEvent EVENT_GADGETACTION, gadget, ButtonState(gadget)

End Method

End Type

We extend off the QCheckBox, and simply connect to the "toggled" signal, posting the subsequent event back into the MaxGUI event queue.

Notice too that we are only using pure BlitzMax code here. All the nitty-gritty interaction with low-level Qt is handled by QtMax. No externs, or glue code to be found!

Resurrection

Some might call it the End of the World ™, but I like to think of it more as a resurrection, having recently sat down and got QtMax up and running with (the latest) Qt 4.8.4.

Funnily enough, it ran straight out of the box on Linux, and the apps happily ran headless across the network here at Brucey Central. For the other two platforms, I'm having to rebuild the shared objects/dlls and sort out the headers.

Once everything is running on the three platforms, it's time to start filling in the blanks...

Qt did MaxGUI

I forgot to mention, last time, that in the beginning of 2007 I knocked together a basic MaxGUI module using Qt as a backend. It was mostly done as some C++ practise, as I was essentially picking it up (C++) as I went along learning the API itself.

Interestingly, it mostly worked, but at the time, being GPL only on Windows, I wasn't overly keen on supporting it - and it's not like there aren't already enough MaxGUI modules floating around as it is!

One advantage to the "MaxGUI wrap" thing, is of course that one only needs to wrap a very small portion of the API, rather than every single method and class. The disadvantage is obvious - in that you only get a nibble of the whole Qt cake.

But you know me... experiment, tinker, kludge...

.. perhaps I'll resurrect it enough to have MaxIDE working in Qt...

In the beginning...

...there was BlitzMax + MaxGUI.

Nice as MaxGUI is, it's not really designed for big applications, and is a bugger to get everything looking good across platforms - which is the whole point of a write-once-compile-for-three-platforms application.

...then came BlitzMax + wxWidgets, otherwise known as wxMax. wxMax is a BlitzMax language-binding of the wxWidgets API, written by someone who should probably know better!
As a cross-platform applicaiton framework, it is very good indeed. It covers more than simply the GUI, with tools such as PDF generation.

Qt, is very similar to wxWidgets, but for a couple of facts.
The first, is that it renders its own UI, rather than trying to use the native gadgets (which wxWidgets does). As long as it looks the same, then how things are rendered isn't too important.
The second, is that Qt already has Cocoa support (in Qt 4.5), and has cross-platform support for WebKit (the engine that Safari uses to render web pages).
Otherwise, the two are very similar in functionality.

So why Qt, if wxWidgets is already good enough?

Well, why not?
There's no harm in having more choice :-)

Now that Qt is LGPL, it's also easier to develop applications for it that are intended to run on all three platforms (Linux, Mac and Win32). Previously, Win32 was GPL or Commercial only.

Anyway, I'll hopefully be writing about my adventures here...

Stay tuned ;-)