MaxGUI improvements

BlitzMax Forums/MaxGUI Module/MaxGUI improvements

degac(Posted 2009) [#1]
I wish to thank Sebholl for his hard work in bug-fixing and make MaxGUI better.

I've written this page to report the MaxGUI current situation on the supported platforms: it's not intended to show the 'leakness' or 'poorness' of MaxGUI...indeed I mean to show the completness (or quite completness) of MaxGUI module.

If anyone (BRL in primis) is not happy with this I will delete it immediately.

I would like to see implemented (in a future release...) some little changes:

* PIXMAP on button with user-defined layout (Left, Right, Top...): I've made some little hacks & tests and these works quite on every platform (of course if the platforms supports these features...)

* SQUARED buttons on MacOS/Cocoa: at the moment (I need to check if something is changed...) there is not a way to set the 'style' of a button: under Cocoa a button can be 'rounded' or 'squared'...and default button on MaxGUI are rounded (or squared if their dimensions is below some limits - not a great solution. I made some hacks to obtain squared button on Mac, so there is already a possible solution)

* some other gadgets should be made officially in proxygadgets module (as Leadwerks's spinner gadget & Property Editor-style gadget - now we have ScrollPanel, maybe is a double work...)

* ListBox with multicoloumns: I found an hack that works in Windows XP, it would be a great addition a common-platform solution.

* grid support

* standard requester for User notification (Text input, User+Password input, about window...)

* getVersion to check what MaxGUI-modules I run: not very important for final user, most important only for developers...to be honest I think EVERY BlitzMax module should have a GetVersion method implemented... Importance: 1/10


markcw(Posted 2009) [#2]
Hey degac, nice list but imo it's missing Gtkmaxgui, which btw supports Javascript through Gtkwebmozilla.


danielos(Posted 2009) [#3]
I also would love Listboxes with multicoloumns, would be great!


Ked(Posted 2009) [#4]
Mozilla HTML View. +1 :)


degac(Posted 2009) [#5]
After reading this thread I made some little changes to Seb code to manage different popup window (normal text, password text and login-window)

I need a separate PASS method to manage the results (user+password fields): the first approach was to use the USE method and returns a single string (user|password) and then 'split' the result...but this approch is more handy.
I know Ked made some 'about' & others things...


degac(Posted 2009) [#6]
I found this worklog on BlitzForum, I 'like' the images (I cant' read german sorry...:D) - but I understand d-bug is working on a 'CocoaMaxGUI' variation...
It should be interesting to see if some things can be 'glued' to the standard MaxGUI, or just create a new proxygadget (like the new toolbar Aqua-style NSToolbarItem, scroll down the page and you'll see what I mean...I think it is possible to create something 'similar' in MaxGUI for Win and Linux)
Some of the latest experiments on buttons (squared shape, images and text position) can be handled directly via MaxGUI with some little changes, while other 'button shapes' are platform specific (there is no 'help button' or 'quick search button' as standard button on the win or linux).

The question is: MaxGUI must represent a common level or can implement platform specific attributes?

I like the way MaxGUI is working, but I must admit that having the possibility to use 'platform specific' elements is a plus.


d-bug(Posted 2009) [#7]
Hi degac,

first of all, this is not meant as an offence to BRL or SebHoll in special. I understand, that most of Cocoas features couldn't be done because the other OS's simply doesn't have them.

I wouldn't call it a variation it's more some kind of a plugin, because you need cocoamaxgui.mod to get it running. I think there is no way for doing this as a proxy-gadget because most of the additions are made in Obj-C and must have their own functions-set in maxgui. NSToolbarItem is a good example for this. While the Toolbar itself uses maxgui-functions, like every proxy-gadget does, the items need there own functions because there identifiers aren't integer-values anymore.

All in all it's far away from perfection. I've managed to write all docs in english, but don't excpect to much, my english is as horrible as your german ;).

cheers


degac(Posted 2009) [#8]
Thanks for the answer, and I'm glad to hear your work is a 'plugin' for the current cocoamaxgui: this means (if BRL-Seb &/or whatelse really want to take it into consideration...) these changes (even if platform-specific) can be implemented.

We have already some kind of OS-limit: think to the Notify/Confirm/Proceed requesters under linux; you need MaxGUI to use these function (unless you like to press 'Y' or 'N' in the console...)


this is not meant as an offence to BRL or SebHoll in special


I dont' think an improvement can be considered an 'offence'.
Mark himself has 'opened' the development/beta-testing of BlitzMax to skilled-users...(there is a thread somewhere).

Thank again and go ahead!
(PS: thanks for the docs...)


CocoaExt is the attempt to get MaxGUI a bit closer to Apples GUI conventions. It provides different new ways of creating gadgets. It is strongly based on MaxGUI, so if you want to use it, you still have to purchase MaxGUI first. It will not overwrite any of the maxgui modules provided by BRL.




jsp(Posted 2009) [#9]
getVersion to check what MaxGUI-modules I run: not very important for final user, most important only for developers

Vote:+1


SebHoll(Posted 2009) [#10]
@ degac: Nice thread! I'll set some time aside to have a good read through it at some point. :-)

Two quick points though, while I'm here:

The question is: MaxGUI must represent a common level or can implement platform specific attributes?

First and foremost, *my* main aim with MaxGUI is that compiling a working app on one platform should mean you can compile the same app on another platform and expect it to work the same. Unfortunately, there is a lot of work still to be done here as you probably know. After that comes work on new features, but if they are platform specific I'd have to be reasonably happy that the other platforms aren't suffering because of it and that it isn't going to violate the first point before I add them.

The ProxyGadgets module came about because I wanted a way to expand and add new gadgets to MaxGUI without being hindered if complete equivalent component wasn't available in one of the libraries. There have been some awesome user proxy gadgets (esp. from both you and Leadwerks), but I don't want to add them to the official mods without checking them over thoroughly and making sure they behave reasonably well on all platforms, first. I'm also a bit warey about the ProxyGadget framework, particularly when it comes to things like freeing gadgets and awkward cyclic references. So I also want to look into this and make sure we get it right before we start adding lots of exciting (but complex) gadgets as if they are equivalent to driver created gadgets. But as you can imagine, this takes a lot of time, and at the moment I'm up to my eyes in bug fixes and documentation before the release so I'm probably not going to be able to get around to merging those in for you before the next release.

jsp:

getVersion to check what MaxGUI-modules I run: not very important for final user, most important only for developers

This would be quite useful but I'm hesitant to implement it as I'll have to keep on making sure the ModuleInfo version numbers are in sync with the value returned by each driver method that will be in separate source files. MaxGUI has enough version numbers as it is: one for each driver; one for proxygadgets; one for the core MaxGUI module; and then there's the release version numbers (that are somewhat similar to BlitzMax version numbers). And if I forget to update one of them, then we'll effectively have twice the number of version numbers floating around, and it's all gonna get very confusing. :-(

I believe the best was to go about this is if Mark was to add something to the compiler that automatically updates these values and functions with appropriate text when the modules are built. But I can't imagine these types of feature requests are particuarly easy to implement into a compiler. :-/


degac(Posted 2009) [#11]

First and foremost, *my* main aim with MaxGUI is that compiling a working app on one platform should mean you can compile the same app on another platform and expect it to work the same.



I completely understand the main goal of MaxGUI and the efforts to keep it 'on-the-route', and in general I agree with this vision: one source, three different application with the same layout.*

I posted the D-Bug's worklogs only to provide some hints/ideas...I must admit I'd like a 'standard Mac OS toolbar' (like the one of D-Bug): I'm working on a similar gadget (gadget strip/container?) for all the platform...

And about GetVersion...
1. I think it's should be implemented in ALL the modules (not only in MaxGUI)
2. I got the same worry and the same (final) solution (change the compiler...)

* Markcw pointed out one limit (due to FLTK): no Javascript support...
I dont' know if it's possible to implement a 'plugin system' to choose what Javascript/HTML render to use. But I think - at this point - MaxGUI needs to take in consideration a solution like this - for only the fact that the latest html-renders are far advanced (Firefox+Chrome now supports HTML5, I just tested the CreateHTMLView with this address http://html5demos.com/ - and it doesnt' work under Windows...)
I dont' know if a better solution is to move HTML from MaxGUI (and port it as an indipendent module) and make a bridge-wrapper-gadget to it.
(Just an idea, I have no clue how to make it...)