I have started work on an “unofficial” extension for A LOT of standard GUI controls for people to use.
So far, only Labels and some work on TextBoxes have had work, but throughout today, I will be working hard to lay the foundations for what could become a very large project. This project is intended to be rich in controls, including your simple drop-down menus and multiple selection options, to dialogs such as colour pickers, file and folder dialogs, and other advanced controls such as Tree and List views.
There isn’t much of a README yet, currently my main focus is getting the foundations done, that is at least the basic components before putting the first release onto haxelib.
Basic Controls
Label - Done
TextBox - Done
ComboBar
CheckBox - Done
RadioButton
ListBox
Slider
NumericUpDown
ProgressBar
Button - Done
If you’d like to help out, be my guest. Fork the project, make changes, test changes, and make pull request. Take a look at “Control.hx” for an idea of organisation, and include the license text at the top of the file if adding more files (don’t be excessive ;p).
Main aims:
Standardize GUI in OpenFL, keeping the APIs simple and easy-to-use
Provide customization through XML, JSON and Bitmap skins.
Have a close-to-native experience, hardware-accelerated and optimal UI controls for all platforms.
Automatic layout engine on a per-platform basis.
There’s a lot of work I’m putting onto my hands, but I’m up to the challenge. At least for now
Above is a video explaining the roadmap and the current progress. There is also a demo of the library that I show a bit later, in a separate video that I will also be uploading soon. I tried embedding the video, but for some reason it won’t show up.
The biggest difference would be implementation. I’ve used HaxeUI and tried to get used to it but to no avail, and consequently didn’t like it’s implementation. The idea behind mine is to be more reminiscent of WinForms, since that’s the background I come from, but simplify the APIs to suit OpenFL.
After looking at stablexUI, it looks interesting, but one things that it’s missing is a menu bar from what I can tell.
Ideally, a library I would want, for my own purposes, is a PropertyGrid containing the ability to modify properties of objects at runtime via Reflection, a Menu Bar with the ability to add separators (which HaxeUI does not have), icons (which HaxeUI does not have), and keyboard bindings (although not necessary, it’s still nice to know that one key combination sits on a given menu item.
Fully customisable Dialogs is literally a must for my purposes as well, so having a Colour Picker, Font Picker, Folder and File dialogs, and potentially even Print dialogs, would be very handy.
Basically, the GUI library would be as close to being as general-purpose as humanly possible, not designed with video games in mind, although some of the simpler controls could be.
Sounds great, but would it not make more sense to add to and extend waxe? There’s a lot there already, but it needs a couple more things, i.e. the last merge request from a while ago.
The problem is waiting for the original author to accept those requests. This is the same with HaxeUI and StablexUI, they are not updated as regularly as I would like them to be, and sometimes the original authors may not be active enough. OpenFL is actively developed, which is the only reason I am still here
The last time I heard, HaxeUI is still only compatible with OpenFL version 3.2.1 (mainly because it downloads that version along with an earlier version of Lime), quite frankly that’s not promising to me.
Trust me, I do share your concerns, but I’m also concerned about yet another GUI library supported by one author only. Maybe it would make sense to fork waxe? wxWidgets are at least a solid foundation.
Its worth noting that i agree with you about the HaxeUI implementation, its overly complex. Im currently working on v2, which is a total rewite and it has a greatly simplified implemenation and a load of extra stuff also (like no more Roots! Just add directly to stage or whereever), plus it will work with openfl, flambe, nme and probably Kha, snowkit and pixi. Small demo here: https://dl.dropboxusercontent.com/u/26678671/haxeui-openfl.swf. I will also be planning adding some of the things you mentioned for sure. Im not sure what you mean about not being active enough, i answer issues when i can, and merge pulls when i think they are decent / work.
You’ll see what i mean when you lib takes off, it can be a bit of a pain to manage - every one and thier dog has a different idea of what a UI is, how it should work and what it should look like.
Also, not sure what you mean about being only compatible with 3.2.1 of openfl, that might be because i fixed it at the tested version on my system, but thats easy to remove. I added that because it means the haxelib version has the right dependencies of openfl and lime, esp while the OpenFL next migration is on going i figured this made sense. Its certainly not a requirement to be on those versions, its just the latest ive tested against - ie a working dependancy. What cutting feature of openfl is it missing? (Im running current openfl on my system btw, i just havent packaged that and sent it up to haxelib but can do so now if it would help in someway)
Anyways, thought i would just chime in and let you know i try to be as active as time and sense allows, plus working on HaxeUIv2 at the same time. I certainly wish you well on the lib, defo looks nice (just browsing the code), is there a demo we can have a play with somewhere? How is it skinned?
Ah, yeah, that makes sense. Didn’t really think about it like that.
There is no demo at the moment, it is very early stages and currently I’ve just finished up with TextBox’s, although trying to test it on Flash and having trouble with Flash Player not loading SWF files properly >.<
Obviously TextBox’s aren’t going to work on native right now, but sooner or later, it will
Also, sorry if I made it sound like it was not being actively developed. Of course, I’d be more than happy to work on HaxeUI than do everything from scratch, adding things like customisable dialogs, and particularly File/Folder dialogs, which we could all benefit greatly from, I think.
The way I’m currently implementing skins is by applying them to graphics handling, such as:
You’ll see once I’ve got my TextBox done and pushed.
Other than that, I will get a demo done at some point. One of my problems is actually sticking to projects, regardless of how much I love it (I suffer from anxiety issues).
But they dont include folder selectors and i would like the ability to make the native using SysTools if wanted / needed. Might help in someway anyway.
Native “action” dialogs seem like a win to me, I wrote the haxeui file dialogs as a test (ish), but actually using them felt unatural, the flash open/save dialogs on the other hand (that haxeui file dialogs switches to if flash / air) felt much more normal, hence the desire to move to SysTools (or the link you provided). So i agree totally, that native is the way to go when you interact with the OS.
Im not sure about menus. Not only is it not as “atomic”, ie “open/save” is a very specific action that can probably be translated to most OS’s, menus (in my view) should be able to appear everywhere. So not sure native rendered menus make any more sense than native rendered buttons/lists.
And if its native “the lot” then (a) openfl isnt a help and (b) its really quite impossible to do, i had a play the other month and just between wxWidgets, native html5 and native android i got into a whole spagetti of mess. The excludes, of course, iOS, OSX and the myriad of systems i know nothing about.
(small subtext, but they do also work - non flash - on android, haxepad - https://github.com/ianharrigan/haxe-pad - can open and edit text files on andriod)
