Test Suite

BlitzMax Forums/MaxGUI Module/Test Suite

Brucey(Posted 2012) [#1]
Hello :-)

Is there like a test suite or something that can be run to check that everything works as it should?

Well, you know… that something on platform X is working the same on platform Y, etc…

Rather than writing code snippets for every conceivable combination/interaction…


I know the answer, but I thought I'd ask anyway ;-)


matibee(Posted 2012) [#2]
Not that I've seen or heard of. And what a time to think about it when I don't have the time to submit tonnes of snippets - I'd love to help.

I can give you the source to this application if it helps:
https://www.youtube.com/watch?v=ZrjJUTRw3Vo

there's a fair bit going off in there and it doesn't require any 3rd party mods IIRC: 2d & 3d OpenGL, many custom controls etc.


skidracer(Posted 2012) [#3]
When I was developing original drivers I had the 27 examples from the MaxGUI docs folder which I would mutate manually and MaxIDE as my main test app.

Oops, nearly forgot, birdies glcube:



Last edited 2012


Brucey(Posted 2012) [#4]
Cool. I completely forgot about the examples there! Thanks.

Oh… a canvas, great. :-/
Heh, it's taken me long enough to work out how to propagate timer ticks into my event loop!! It seems I can poll the native driver and it picks up my gui events too. (well, on OS X it is, who knows what it will do elsewhere!)


Derron(Posted 2012) [#5]
Same for things like "Application menus" which paint over a canvas...
Without special timer handling it just looks ugly (not repainted). So your own classes need to use custom eventhook-methods to reach the desired output.

I cannot imagine that behaviour being wanted as default.


bye
Ron


Brucey(Posted 2012) [#6]
The examples are very useful indeed, it turns out.

I can switch from one gui-driver to the other to see that I'm getting the "expected" behaviour from mine. So far, it's frighteningly similar..

I've found myself adding a call to LockLayout() on the base CreateGadget() of all the gadgets, as it's setting stuff for the layout engine, apparently. Not sure if I need to set it for everything, but it doesn't seem to be hurting it so far.

I think the "Okay" button is going to be a whole load of hurt - by default there's no default mechanism to have Return/Enter activating a button. Probably just requires some deep understanding of the API, I suppose.

Hopefully the examples will cover enough to test most things reasonably well to get the core stuff up and running.


Derron(Posted 2012) [#7]
By default an application should "focus" the default button on an notification box - and the "window" should handle "ESCAPE" as decline.

With the focus set, the "Enter"-Key should be handled by the OS (same for Space-Keys) (untested).

It is the OS fault to handle non-mouse-actions and therefor "Enter" and "Ecape" get some usefulness.


bye
Ron

Last edited 2012


Brucey(Posted 2012) [#8]
Except MaxGUI doesn't appear to see a difference between a standard window and a dialog window, so you can, in theory, add these buttons (Ok/Cancel) to all windows.

But we'll see… small things like this don't concern me too much at the moment. Better to get the core functionality working and worry about details later ;-)


Henri(Posted 2012) [#9]
As someone pointed out somewhere Windows specification requires OK button to be wired to return key and Cancel button to ESC key. In Maxgui creating button with BUTTON_OK flag does this.


Brucey(Posted 2012) [#10]
Well, I may be able to hack something together with a QDialogButtonBox rather than craft my own key handling code which is what the box appears to do already.

This morning I am learning about toolbars, icons and icon strips. Cool.


Derron(Posted 2012) [#11]
we talk about maxgui and brucey notes a qt-box... hmmmmm - that smells like "wrapping a framework into a wrapper"...

Did not know that maxgui simulates dialogs (notifications, alerts, file choosers ...) if only simulation with windows takes place - the behaviour could be different to standard applications (stay in front aka "modal dialogs" etc.).


bye
Ron


Brucey(Posted 2012) [#12]
Well, toolbars were a lot of fun :-(

But at least the bad behaviour is consistent across platforms, so I assume it's the MaxGUI code that's being the problem somewhere.

However, on a brighter note, I've managed to integrate BlitzMax's Linux event handler with the main event loop. I just needed to add a listener to some file handle somewhere, and both GUI and Max events fire off as they should now.
Well, now I've sussed that out, I know where the GTK module needs to be fixed ! (which is certainly a step forward, I suppose)


Brucey(Posted 2012) [#13]
Experimenting with the examples is helping a lot. I can switch back and forth between one GUI driver and another, click, etc, note what events are generated, then to the other, and do the same.

… ah, mine is missing event Blah… hack hack… yay, now it is generating that event… onto the next.

Chooser dialogs (font, file, colour) are native (to the driver), although there appears to be some code in FLTK that allows one to choose between native/FLTK (depending on the platform?).

Modality has always been an issue with MaxGUI.


Brucey(Posted 2012) [#14]
Three Birds! !



Here you can see the birdy demo running in parallel (i.e. at the same time) on the three different platforms.

The rear window is native OS X.
The left window is native Linux running headless over the LAN. (headless - code runs on the Linux box, but is displayed via an X11 session on my Mac)
The right window is a Parallels virtual instance of XP.

Mac and Linux worked out of the box, but it took a few hours to work out how to disable double-buffering on the Windows side. (Finding the *exact* settings to apply is not documented anywhere!!)

Seems I didn't need to implement the QGLWidget after all, as I can simply pass the widget handle to the BlitzMax graphics driver and it takes care of the rest. Cool :-)


GaryV(Posted 2012) [#15]
One day they will sing songs about the legend of Brucey.


Derron(Posted 2013) [#16]
Thought there is a movie about him (brucey almighty) :D.

Nice to see progress but up to now my linux boxes are qtfree - dunno how they "integrate" into my desktops theme.

bye
Ron


Brucey(Posted 2013) [#17]
. . . and MaxIDE as my main test app.


And so began my first attempt at starting up MaxIDE with QtMaxGUI. . .



. . . of course, I was afraid to actually do anything with it at that point, so I just killed the process ;-)

But I think it kind of almost looks like MaxIDE.

Not sure what's going on with the icons… and as you can tell by the vast amount of TODOs on the left, there is a lot it is trying to do but cannot yet.

First steps :-)


shinkiro1(Posted 2013) [#18]
impressive :)
Will you wrap the canvas too?


Brucey(Posted 2013) [#19]
The canvas is already working. See the "three birds" post.

Just got the syntax highlighter in MaxIDE working. Seems to work seamlessly as you type (well, which is probably what you want and expect!).


matibee(Posted 2013) [#20]
You know you are probably, single handedly, as always, doing more for BMax than anyone else in the whole wide world :) I just hope it's worth it.

Anyway, if/when you get 5 minutes, I'd be really bicurious to see how this looks with qtMaxGui...

http://www.blitzbasic.com/codearcs/codearcs.php?code=2924


Brucey(Posted 2013) [#21]
I'd be really bicurious to see how this looks

Bicurious, hey?

Well, it happens to look exactly like the CocoaMaxGUI version, even down to the over-written labels!



Which is something, I suppose - in that it performs exactly the same, so I must be on the right track as far as my implementation is concerned.
When you click on a tab, it sorts itself out, and the labels look correct. Not sure what the darker grey bit is doing there tho.


matibee(Posted 2013) [#22]
Bicurious, hey?


Damn! That'll be the freudian spell checker :D

That's a lot closer than I had with native linux maxgui (it was shockingly bad and unusable.) This gives me a glimmer of faith.


Brucey(Posted 2013) [#23]
Well, just for comparison, this is what it looks like on Fedora 17. . .





Struggling somewhat with maxide at the moment. It does a lot of initial layout stuff on hidden windows, which is a problem with Qt as it is not really designed for manual layout, and doesn't always report the correct client widget dimensions (because hidden stuff doesn't lay-out until it is visible)… ho hum.