Need feature suggestions: GUI Authoring Tool and API
Author
Hi All,
I'm in the process of building a GUI Tool and API for indies/hobbyists. So it's not just an API (literally a dime a dozen), but a full-blown authoring tool to go along with it. Purpose is to allow you guys to build and iterate upon a GUI very quickly with (hopefully) little hassle.
Since my needs are very simple, I have built out the following so far:
- Keyframed animation
- Font loading
- Texture loading
- Sprites
- Buttons
- Labels
It's coming along really nicely, but I'd like to flesh it out a bit more before I open it up to people to poke around in. So what I'd like to know from you guys is: what would you like to see in such an UI API and Tool? What would make this usable to you?
Remember, I'm building this for you guys to use, so it's your needs I'm interested in.
Thanks :)
Graf
Sorry, I'm a noob about APIs. (I don't know what it has to do)
Some widget callbacks:
Just some things from top of my head (I'm in the middle of windowed GUI making myself)
Some widget callbacks:
SelectionFunc // when does an item become selected (mouse-on-item)?LeftClickFunc // probably double/triple click handling insideLeftUpFuncLeftDragFuncRightClickFuncRightUpFunc // not so necessaryRightDragFunc // not so necessaryMiddleClickFunc // not so necessaryMiddleUpFunc // not so necessaryMiddleDragFunc // not so necessaryMouseRollFunc // should work on not active items tooMouseHoverOnFunc // if mouse moves, item becomes mouse-on-item, for mouse cursor change, or delayed pop-up stringMouseHoverOffFunc // if mouse moves, item becomes non mouse-on-itemMouseHoverFunc // called every time if mouse moves: I'm not sure it's necessaryDeActivateFunc // if item becomes non active, for example roll back text in editboxKeyFunc // key input, for edit box cursor movement, and maybe for change mouse-on-item, to enable full keyboard useCharFunc // character inputDrawFunc
Hi Grafalgar,
I think an opensource GUI editor would be really great!
What I would like to see:
- a front end / back end architecture so we can easily plug an OpenGL, OpenGL ES or DirectX renderer
- ability to write plugins for export and import of design files (XML would be cool as a default file format)
- ability to add a custom component with custom events
- containers that automatically scale components or align them at different screen resolutions
- multitouch friendly API (with support for easy gestures)
- support for localization for all texts and images
I would like to see it written in plain C++ with no dependencies to ease porting.
I can help porting to OpenGL ES and iPhone, if needed.
I think an opensource GUI editor would be really great!
What I would like to see:
- a front end / back end architecture so we can easily plug an OpenGL, OpenGL ES or DirectX renderer
- ability to write plugins for export and import of design files (XML would be cool as a default file format)
- ability to add a custom component with custom events
- containers that automatically scale components or align them at different screen resolutions
- multitouch friendly API (with support for easy gestures)
- support for localization for all texts and images
I would like to see it written in plain C++ with no dependencies to ease porting.
I can help porting to OpenGL ES and iPhone, if needed.
Author
Thanks for the suggestions so far :)
The API is written is plain ol' vanilla C++, so porting should be pretty straightforward. In fact, porting should be as easy as compiling the code to your platform and adding your own renderer/file io/input implementations.
I do have plans to add plugins; for custom controls as well as for import/export. I'll bump that up in 'priority.' Same goes for localization.
What about scripting? Do you guys prefer using a scripting language of sorts or like to write all the ui logic in C++?
The API is written is plain ol' vanilla C++, so porting should be pretty straightforward. In fact, porting should be as easy as compiling the code to your platform and adding your own renderer/file io/input implementations.
I do have plans to add plugins; for custom controls as well as for import/export. I'll bump that up in 'priority.' Same goes for localization.
What about scripting? Do you guys prefer using a scripting language of sorts or like to write all the ui logic in C++?
Personally, I don't like the idea of scripting being part of the API.
I think that to develop a nice and slim scripting system it's not easy and that it should not be the focus of a GUI library.
Moreover big games usually already have a script engine running and could need the same interface, and for small games (for example on iPhone) I think we really don't need a so powerful feature.
That's just IMHO anyway.
I think that to develop a nice and slim scripting system it's not easy and that it should not be the focus of a GUI library.
Moreover big games usually already have a script engine running and could need the same interface, and for small games (for example on iPhone) I think we really don't need a so powerful feature.
That's just IMHO anyway.
Strongly agree with Txkun with regards to the scripting.
I feel that a GUI tool should primarily be focused on layout - logic and special effects should live in (or be handled by) game code - I think it's much easier to code logic on a game-by-game basis, than to make a tool which can be diverse enough to handle any kind of scripting requirements that will ever come up.
Wrt feature suggestions - the only one I can think of is ability to layout menus - horizontal, vertical, and grid layout. And consider making the menu elements generic - so they can be text, graphic, sprite, model, or whatever.
Good luck with the project!
I feel that a GUI tool should primarily be focused on layout - logic and special effects should live in (or be handled by) game code - I think it's much easier to code logic on a game-by-game basis, than to make a tool which can be diverse enough to handle any kind of scripting requirements that will ever come up.
Wrt feature suggestions - the only one I can think of is ability to layout menus - horizontal, vertical, and grid layout. And consider making the menu elements generic - so they can be text, graphic, sprite, model, or whatever.
Good luck with the project!
I agree with the poster above.
You can make some general "engine" functions, but let the user have freedom to make his own. If he wants immediate mode GUI or whatever else, then let hit do the job.
Provide him/her with general creation/functions/renders/windowing, but let him have his own stuff too. So I suggest that I suggested in my first post, let every functions of a widget/window be just function pointers.
You can make some general "engine" functions, but let the user have freedom to make his own. If he wants immediate mode GUI or whatever else, then let hit do the job.
Provide him/her with general creation/functions/renders/windowing, but let him have his own stuff too. So I suggest that I suggested in my first post, let every functions of a widget/window be just function pointers.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
