🔒 Locked

Question on my interface setup for my UI classes.

Started by SolarChronus Dec 2, 2013 at 2:26 AM 2 replies 1.6k views

Original Post

Dec 2, 2013 at 2:26 AM

So I'm onto rolling my own classes for UI use for fun and learning. I've create a bunch of interfaces to manage the UI widgets but I'm at a fork in the road on the more complex widgets I want to create.

Right now my UI code consists of the following:


// Interfaces
IGUIWidget {}
IReactsToClick {}
IReactsToHover {}
IProgressBar : IUIWidget {}
IImage : IUIWidget {}
IButton : IUIWidget, IReactsToClick, IReactsToHover {}
ILabel : IUIWidget {}

// Concrete
Label : ILabel {}
Image : IImage {}
ProgressBar : IProgressBar {}
Button : IButton {}
ImageButton : IImage, IButton {}
LabelButton : ILabel, IButton {}

Now for the 'complex' widget.

I have an object that has the following properties:

- Acts like a button

- Has a background image

- Has a content specific image

- Has multiple smaller images that change (can be any number).

- Has a label

- Has a progress bar

Here is the interface and concrete class I've come up with:


public interface IComplexWidget : IGUIWidget
{
    IButton button { get; }
    IImage background { get; }
    IImage contextImage { get; }
    IList<IImage> multiImages { get; }
    ILabel label { get; }
    IProgressBar progressBar { get; }
}

public class ComplexWidget : IComplexWidget
{
    public ComplexWidget()
    { }
   
    public Button button { get; protected set; }
    public Image background { get; protected set; }
    public Image contextImage { get; protected set; }
    public IList<Image> multiImages { get; protected set; }
    public Label label { get; protected set; }
    public ProgressBar progressBar { get; protected set; }
}

Would this be the correct path for creating more complex widgets?

NightCreature83

Dec 2, 2013 at 8:25 AM

Looking from a very abstract point of view here you could say that a screen is nothing more then a container of items, where each item on the screen is a container of behaviours. Now this property of UI corresponds with a component-entity approach, where each item on the screen is an entity and the role it needs to achieve is done through the components attached to it.

From your description that approach is easiest with a component-entity structure because if you have another widget that doesn't need the button you can just leave that behaviour out. UI's in general are highly changeable and as such really don't fit inheritance hierarchies that well. You will also want to data drive most of this so that you can construct your screens and items outside of the code, for faster iteration.

ferrous

Dec 4, 2013 at 1:56 AM

Yeah, for example it seems like your ComplexWidget could be boiled down to just having a IList<IUIWidget>(), or possibly broken into a list of all UIWidgets, a list of all IReactsToClick, IReactToHover.

When the mouse moves over the complex widget, you iterate over every IReactToHover and see if the mouse is over it and then call it's react function or whatever it needs to do. The Screen/complex widget doesn't need to know whether it's hovering over a button or a progress bar or whatever this way.

Kimmi

Dec 5, 2013 at 3:36 PM

And keep in mind to separate the UI-View-Logic like Clicked-State-Rendering from the game-logic like fireing an event into your game-application. You can declare a bundle of trigegrs to start an action like starting a new game from the view-state-handling in your ui-code and this make it much more mantable if you want to rework your ui-elements.

Kim

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.