WidgetUI - Components for UGUI

The game I'm developing is somewhat UI intense. After a while I found myself in the situation where my UI logic was scattered everywhere around the project and the UI components were hardly reusable. So I decided to take one step back and design my UI components in a more generic way.

To make things easier for people suffering the same problems, I'm releasing the result here.

For now there's only Lists and Selectboxes. Lists come in two variants. The first one uses custom layout classes, which allow for more elements inside the list without a performance regression (tested with one million elements) and the second one uses Unity's native LayoutGroups.



I would like this to become a more complete solution, but I cannot do it all by myself. So I hope the community will contribute to this project. If you nailed down a bug or added a feature, please issue a pull request.


You can find the source code and an example project on GitHub. Notice there's a tutorial in the README.md file.

► Source
► Example Project


Let me know what you think.

 

Changelog

1.1

• Added Tooltip Widget
• List: Added SelectedItem property
• List: Highlight selected item
• Fix: SelectBox now uses the correct camera when displayed in world space (thanks @DoomSamurai)

1.0

• Initial release

 

Nice one
How can I retrieve the current selected element in the list?
Also are you considering implementing a version with toggles instead of buttons?

 

Thanks!

I'm afraid there is no property like myList.SelectedItem. I had concerns about performance and decided against it. When an item is added to the list, a delegate is registered to the button's onClick event. The only way to reference an item in a list uniquely, is to remember its ID. That means the element's ID has to be stored inside the delegate. Now, if you delete the first element, all following delegates become invalid because the ID points to the wrong index. To correct that, you'd have to recreate all delegates, which can be performance critical on large lists.

I'd recommend to listen to the list's OnSelectItem event handler and store the variable which is passed to the handler. Another possibility is to extend a List class of your choice, overwrite the OnWidgetClicked method and save the parameter to a public property (like SelectedItem).

I'm not sure if I understand your second question correctly. Do you mean a button that remains in the pushed-state after a click or radioboxes?

 

Hi knowbuddy, are you familiar with EZ GUI. I am really missing the scroll list, listitem and listitemcontainer functionality with the new uGUI system.

 

For what I need now a pushed-state could do the trick
Thanks for the answer and explanation

 

You can create such a list fairly easy. Extend a list class and override OnWidgetClicked. You can use IndexOf to find the index of the clicked element and use it to get the Widget / GameObject from ListWidgetBase::m_widgets. The problem I see, is to maintain the pushed or hover state of Unity's button component.

I know the name but I never actually used it.

 

And yet another ComboBox, and this one supports selection retrieving and setting too. fell free to add it to your package:
Forum.

 

Thanks for sharing this knowbuddy. I still have to do some more lurking in your code but it looks very nice. What kind of Widgets do you feel could be added to this project ? I may be able to contribute at some point.

 

Hi DoomSamurai, there are a lot of things that could be added. But it's hard to tell what people need for their projects and it would be a shame if you spend a lot of time developing something that is never actually used by anyone. I think it's best to create a new widget because you need it. For me that would be Tooltips (currently working on), TabViews and Windows.

 

knowbuddy, took a look at your samples. Thanks!

Have you considered a border option around the selected item as an alternative to coloring the background?

A built-in way way to track the selected item as discussed above would be good for lists of reasonable size.

Thanks again for sharing

 

Hey,

I will most likely be taking a look at this to see if I can add anything. I spend a lot of my free time extending Unity GUI and I would rather it not just end up dying on my desktop.

 

Hi knowbuddy, what controls the spacing between items in the list and if I want a border how can I achieve that when the items are anchored to the top left?

My question is related to FixedLayout. I see experimenting with Unity layout I may control those things.

Also in the sample onSelectItem is passed a string. I created a version that will be passed a Sprite from an Image. In that method how does one get the related GameObject that contains the string or the Sprite?

 

Worked on a generalized version of a ListBox last week

My Screenshots: http://forum.unity3d.com/posts/1886572/

The Essentials
- Took approach found in general asp.net controls; basically does bare bones with 2 calls; set the DataSource and call DataBind()
- Created ListBox control with script/object that holds reference to prefeb button to copy/instantiate (doesn't have to be prefeb)
- Added ItemBound event to ListBox that allows you to modify any properties of button after initial creation of each item (set name, pictures, data, etc.)
- Button has additional script/object with property that holds reference to data object you want to reference. That way you can retrieve any data for that OnClick method you define.
- Button prefeb has method defined for OnClick event (simply associated in inspector)

That just gets you started... then you have to think about panel resizing, navigation, etc.

After I'm done with this project this week, I'll probably work on releasing the ListBox control code and some examples in the asset store

 

The background coloring is done by the button component of the list element. I've been looking for ways to keep a button in the pushed state and I think it's possible by repeatedly injecting mouse events to the Selectable class, which the Button class inherits from. But I have yet to test it. Given it works, borders could be created using the Sprite-Swap transition.

FixedLayouts implement the IFixedLayout.GetWidgetPosition method to calculate the position. To add additional space between the list elements you could write the method as follows:

Code (CSharp):

1.  
2. // vertical layout with spacing
3. public Vector2 GetWidgetPosition(int p_index)
4. {
5.     return new Vector2(0, p_index * (m_widgetSize.height + 5 /* margin*/ );
6. }
7.  

Another way is to add the margin directly to the list element prefab.

At the moment the only way is to access ListWidgetBase.m_widgets (take a look at post #7). I know that is not an optimal solution. I'll try to make things a bit easier / accessible after the holidays.

I know the feeling . Feel free to add a pull request.

Looks good!

 

You know, I've been thinking -- a list with prefab header and footer areas that are just plug-and-play, with a third generic listing prefab element (with anchors/layouts/elements properly positioned so that whether or not they're 'used' in a particular listing index, it would still allow their parent/containing element to store a reference to them so that each one can be activated/deactivated and/or replaced through code later on or as they're populated.) could serve a ton more applications than another combobox, dropdown list, or listbox ever could.

For example, it'd look a lot like what marchere has done up there, but with plug-and-play prefabs for the header and footer, with programmatically replaceable buttontext, images, and normaltext on a third prefab inside a scrollRect which auto-expands (along with its mask) to the size of its parent minus the height of the header and footer, with buttons that can be setup to execute either a global function/method/etc. (by default) or individual function/methods per each list item's button (if set via code) upon being clicked, and scrollbars (if any) would be optional (or something the user himself can setup.) Finally -- the header and footer prefabs generally are set to stretch to the size of the parent container horizontally (but not vertically), although that should be something the user himself would decide as long as the widget (and all its prefab components) are stored inside a resizeable empty gameobject w/ a scrollRect which acts as the container holding it while the widget would be set to expand to its parent container.

This sort of thing would benefit a lot of people struggling with the new GUI if someone would make it and release it for free here or on the asset store. I wouldn't imagine there to be much to it, but the paltry documentation on how to use the new GUI programmatically seems to be limiting the support we devs can give each other without many practical and working examples of the GUI to learn from.

Without us giving what we can to one another, the community's progress as a whole will remain stifled (as it has been since even before the beta was final), and because of this, there will be less cool stuff developed with the GUI system without each other's support.

Just my two cents.

You can bet, just as soon as I make something useful with the new uGUI system, I'll be the first to share it freely. I only hope others will follow suit until more examples and standards are more readily made available to us.

So props to you, knowbuddy, for being so kind to help out your fellow devs! -- I hope that we all come to share that same spirit! Thanks dude!

 

Released version 1.1 which includes a Tooltip widget and list improvements. Check out the changelog!


@awesomedata: Thank you for your thoughts. I agree that the programming documentation is very sparse. There are several utility methods that really help, but they are scattered and not mentioned in the right places in the docs. I found most of them by accident when I was looking through the source code of uGUI. However, I think that more user made examples will find their way to the forums or to the asset store. Especially after Unity 5 has been released.

 

knowbuddy Thanks for the update!!