What do you want in a GUI library?

[Guard13007]

I've been working on a GUI library for my own use, since I don't really like any of the current libraries available, but I'd like it to be something others use and enjoy too.

Which brings me to the question: What do you want in a GUI library?

More specifically, I'm curious how you'd prefer to manage what elements appear, what kinds of elements you want, how much you want automated, what types of elements, what features, etc etc.

(And if you're curious about the project, it's called Pop.Box, and is theoretically capable of being used, but lacking enough element types for me to verify/promote/use it.)

[alibix]

I just started using and I guess it would need to be easy to understand and capable of having many applications but I think that is what everyone would want

[alibix]

Oh and gifs in the documentation

[Inny]

I'm a little crazy so just take this reply as what I do out on the fringe, but what probably isn't good advice at all.

I heart the hell out of lua's coroutines. Mostly because they're unlike generators from other languages in that they have their own function call stack. Which in terms of keeping some overall gamestate just involves resuming the thread and not having to keep some global state machine and a well-formed hierarchy of state subclasses. In my testing, this leads to the ugliest code but benefits from being hyper-localized. I haven't taken these ideas much further than simple displays and menus and what not, but it would be amazing to see the idea of an Immediate Mode GUI like Quickie and SUIT extended to work well and take advantage of coroutine threads.

[airstruck]

• Data-driven UI design. I want to be able to describe an entire UI without calling any functions or requiring any libraries.
• An API that dovetails with the data-driven format, such that changing data fields after the UI has been constructed triggers any appropriate behavior. In other words, an API primarily based on function-bound properties.
• Cascading properties where applicable. If I set the font size on an element with children, the children should inherit that font size, for example.
• User-defined elements should be reasonably easy to create, and should be able to be composed of built-in elements when appropriate.
• Theme support. A third-party author should be able to supply a module that defines the look of all standard UI elements, and possibly user-defined elements as well.
• Style support. The application developer should be able to customize the look of groups of specific elements in a straightforward way.
• Responsive layout manager. I don't want to specify any positions at all, and very few dimensions. Most dimensions will come from the theme, from the contents of an element (shrink to fit) or from the parent and sibling elements (expand to fit).
• Rich events that bubble through the hierarchy, can be hooked up to multiple handlers, can be trapped or allowed to propagate.
• Support for multiple layers of UI, with appropriate event handling. For example a modal dialog can appear above another UI, any mouse events outside the dialog are trapped to prevent interaction with underlying UI, and no keyboard events are allowed to propagate to underlying UI.
• Baked-in support for common functionality like tab navigation, keyboard shortcuts, scrollable areas, and so on.
• I don't want to screw around with wiring up a bunch of Love events (love.mousemoved and so on).

[Guard13007]

Some of these ideas I've thought about, some of them I haven't. Either way, you've all given me a lot to consider, so thank you.

I do have a new question though. Could you give me some pseudo code examples of you using your ideal library? Just make up how you'd like to approach it and give an example of that use?

[kikito]

No global state. No assumptions. Multi-resolution.

[Guard13007]

No global state. No assumptions. Multi-resolution.

By no global state, do you mean not setting globals, or no "one single system" (so you can create multiple instances of the GUI system)?

No assumptions, what kind of assumptions have you seen that are bad? I think it's literally impossible to not have any assumptions, but if you give me some good examples that may not be obvious to me?

Multi-resolution? Do you mean like supports everything being scaled/rotated/transformed? Or something else?

[bobbyjones]

Make a GUI program to create GUIs using your GUI. Lol. Kinda like airstruck said. Design a way that your library can be represented in just data. That way you could make a GUI application to make GUIs.

[kikito]

By no global state, do you mean not setting globals, or no "one single system"

I explain that here: http://kiki.to/blog/2014/04/11/rule-4-m ... s-modules/

give me some good examples (of assumptions)that may not be obvious to me?

Don't assume that "esc", or the joypad "b", are for "going back". Give me a hook for setting up the "go back" action. Same with "enter/a/activate", "up/up/previous", "down/down/next", etc. Don't assume that the mouse is in love.mouse.getposition. Give me a hook function in case I want to apply transformations to the gui in a way which changes the mouse, or I want to move the cursor with the pad.

Do you mean like supports everything being scaled/rotated/transformed? Or something else?

I mean that instead of saying "this button is 30px width and 50 px high", I want a gui were I can say "in this group of buttons, each one is as wide as the container, and 25% its height". The only place I should have to specify pixel dimensions would be the root "window"; this way, the Gui would work in any resolution.