http://gamadu.com/artemis/

I find the project structure used in freetype-rs less confusing.

I suggest we separate the example and use a path = "../../" in the Cargo.toml to build with the local library.

This way we can add more examples.

https://github.com/ocornut/imgui

Should be implemented by all the slider widgets.

One idea I would love to see in a user interface framework is the integration with full Boolean algebra search to quickly filter and display subset of the data.

This can be extreme powerful and there is almost no end to what clever things you can do.

This requires a ton of planning and this issue is just a starting point for that direction.

A Theme could define default widget attributes (i.e. Color, Frame/Margin, etc), and would allow us to add a FromTheme(Theme) variant to enums like Coloring, Framing, etc.

• Remembers history and support auto completion.
• Can provide suggestions when protocol is not specific (https, http etc.)

https://mollyrocket.com/861

• Similar to interface in Unity 3D
• Fits nicely with a render loop

http://www.polymer-project.org/

The font in the 'all_widget' example "Dense-Regular" which looks modern and minimalistic.

The first thing that shocked me when seeing it the first time was "where are the bounds of the widgets"? This is because it starts with black background color. Then I started to like it, and was disappointed that by changing the back-ground, there was this black area around the widgets.

The text could flip between white/black if it is hard to read with the background.
This way we would only show bounds when the widget is focused, but not otherwise.

A "tag" could be used to connect nodes instead of tagging nodes themselves.

The idea is that a "tag" has a local meaning for a group of objects. All objects connected with a tag can be "grabbed", "filtered" etc.

This would make it easier to find relevant information that is non-verbal expressed, such as images.

Creates a panel from JSON data.

Can also be used to copy settings between panels or use it with a widget that controls saved/predefined settings.

• Allows for creation and editing of text

Would this be in the scope of conrod?

For discussion, see #49

This can not be derived automatically because the color structure uses [f32, ..4].

See discussion #47 (comment)

pub struct Color(pub [f32, ..4])

At the moment, a unique UI_ID (User Interface ID) must be passed into each unique <widget_name>::draw call. This UI_ID is used by the UIContext to store the state for the associated widget and retrieve that state each time the draw function is called.

Currently, it is up to the user to make sure that they pass in a unique UI_ID for each widget that they draw (see the "all_widgets" example). This can be annoying for the user to keep track of, and makes it difficult to build parent widgets out of several child widgets, as each child may also require their own UI_ID.

An ideal solution would be to somehow automatically statically assign a unique UI_ID for every <widget_name>::draw call. Perhaps this is possible with a macro of some sort? Maybe one that generates a unique number every time it is called within code (I don't know if this is possible)?

This isn't an issue for retained-mode UI as the state is stored within unique widget structs meaning a UIContext is unnecessary. However, I'd much prefer we managed to solve the UI_ID issue, as in most cases retaining widget structs for every widget's state seems to be overkill, especially when almost all of their state can be procedurally derived from the data and context they are associated with anyway.

This should be implemented by all the button widgets.

The nodes are extensible with any Rust type, using the AnyMap.

This allows one to attach data to the graph.

The panels could be a Rust type that is attached to the graph.

Here is a space to collect Widget Type ideas.

This list is taken directly from the ofxUI readme as a basis for ideas. Any more ideas are welcome!

• Buttons (push, state, toggle, image, label)
• Button Matrices
• Dropdown Menus
• Labels
• Sliders (rotary, range, vertical, horizontal)
• Number Dials (aka Spinners)
• 2D Pads
• Text Input Areas
• Image Sliders
• Image Buttons
• Image Color Sampler
• Value Plotters
• Moving Graphs
• Waveform & Spectrum Graphs
• Radio Toggles
• Text Areas
• Sortable List

A 3D, graph-like navigation option for UI layout. Each Node would contain a canvas, on which the widgets would go. Using screen-picking, the 2D canvases would track the 3D nodes. Here's an example of my own 3D node system https://github.com/mitchmindtree/ofxNUI which we could take inspiration from / port across.

NOTE: it would be necessary to get both #6 and #7 done before moving onto this.

This could be a nice way to entice users / show them directly what they're getting when they use Conrod.

Perhaps, it could be good to wait till we have some more widgets etc though first!

Perhaps we could harness the beauty of rust's module namespacing for the enum widget state naming?

i.e. instead of NumberDialerState we could just call it State which will make usage easier within the number_dialer module while still remaining easily accessible outside of the module as number_dialer::State.

Started a new project to specify a flexible user input structure:

https://github.com/pistondevelopers/ui

Contains the Boolean algebraic functions for indexing.

https://github.com/bvssvni/rust-index

Perhaps this should be updated to latest Rust and moved to a PistonDevelopers repo.

When doing

cargo build
make examples

I get the following error:

error: macro undefined: 'impl_get_widget_data!'
examples/canvas.rs:55     impl_get_widget_data!(widget_data)

http://vimeo.com/18423305

https://www.youtube.com/watch?v=DPIA2g8T6Hw&feature=kp

When I adjust the padding slider in the 'all_widgets' example, the control looses focus when I move the cursor outside the bounds of the control.

I think the slider should keep focus while the mouse is pressed.

Perhaps there is a state which the widget can set that tells the ui context that the widget is capturing the focus.

For discussion, see #49

This can not be derived automatically because the color structure uses [f32, ..4].

It is very useful to have a command in Conrod that opens up an URL in the default browser. This could work cross platform.

For example, when the user clicks on a "Website" button.

From the reddit post http://www.reddit.com/r/rust/comments/2d8h2d/inspiration_for_graphical_user_interface/

graph based, immediate mode, user interface with some fancy search capabilities.

That looks like a better description to me.

@TyOverby is working on https://github.com/TyOverby/Rust-IUI/

I suggest that we move the widget goals over to its own project and make Conrod focus on the 3D navigation part. The widgets will use immediate user interface.

Since we use symlinks, we can create a fork under PistonDevelopers.

https://github.com/chris-morgan/anymap

extern crate anymap;

https://github.com/bjz/cgmath-rs

This has lot of features that are useful for 3D.

I've been working on a syntax for search that encapsulates Boolean predicates, but feeling more lightweight and without binary operators. It is a small language consisting of (), - and [].

(x y) means search for x or y.

(x -y) means "search for x but not for y.

[x y] means search for both x and y.

(x -y z) is the same as (x z -y).

The operator - is can only appear within () which must contain at least one positive item.

For discussion, see #49

This can not be derived automatically because the color structure uses [f32, ..4].

It would be nice to have a widget that could be used to control playback of audio/video streams.

Copy the latest Makefile from https://github.com/bvssvni/rust-empty and use the commands make lib and make git-ignore. Set the variable DEFAULT = lib.

@mitchmindtree Added simple sliders, buttons and checkbox:

Currently there's some boilerplate functions that need to be written when designing a new or unique widget module. These include default, get_widget, get_state and set_state which are implemented almost identically for each widget module, with only the types differing. It would be trivial to write a macro that took a couple type arguments and expanded to all four of these functions. I'll do this in the next day or two.

Collect some information about existing graph based scripting languages, perhaps we can use some of it to build in a "command line" in the interface.

Nodes can have predefined "actions" which are exposed to a command line functionality in the search bar. This would allow automated tasks as well.

To make this possible we need a nice syntax, possibly using an existing scripting language.

I've started experimenting with a working Widget trait over here:

https://github.com/mitchmindtree/nui

There's a basic button and slider that are both functioning aesthetically though don't yet have any event system. I'd love to start a discussion on how to best approach setting up an event system for a UI framework like this! @bvssvni maybe you have some ideas after working on rust-event? Maybe we could use rust-event?

Also, there could probably be a more efficient way of passing GameEvents to the Widgets rather than plugging them straight into the Game trait like in the example. Would love to hear ideas on this also!

Performance now hugely fluctuates when drawing labels or widgets with labels (at the moment only the slider supports an optional label).

I've tried to follow the usage example within the font_with_piston freetype-rs project as close as I can, but I haven't yet been able to fix it. I'm unsure if this is an issue with my implementation or if the problem stems from within freetype-rs itself?

On some occasions the example runs blazingly fast without issues, however most of the time the example will start fine but progressively slow down to an unusable state.

If someone gets a chance to run the example and has some ideas, that'd be great! Otherwise i'll revisit tomorrow and have another stab :-)

(This bug has been introduced with #37.)

Summary:
A "Canvas" will be a rectangular face on which we can place "Widgets", where a "Widget" is the core trait for each UI element (such as sliders, dialers, buttons, etc).

Inspiration:

• A "Canvas" reference class https://github.com/rezaali/ofxUI/blob/master/src/ofxUICanvas.h
• A "Widget" reference class
  https://github.com/rezaali/ofxUI/blob/master/src/ofxUIWidget.h

Thoughts:

• Widgets get placed upon Canvases.
• A Canvas holds pointers to all of its widgets in a vector.
• All of the Widget positioning is relative to the Canvas position.
• The Canvas position is relative to screen width/height.
• The Canvas has an "add_widget(w: &Widget)" method (or something similar)

This can be cancelled with backspace and confirmed with Enter.

http://en.wikipedia.org/wiki/Entity_component_system

http://www.reddit.com/r/rust/comments/27y4zt/anymap_a_safe_and_convenient_store_for_one_value/

We can declare a type for each "property" or "component" a control can have and then build all objects as compositions of these properties.

I think we should decide what goals we want to accomplish with the project early so we got a direction to work toward.

• Piston integration
• Basic widgets

As discussed here PistonDevelopers/piston#320