Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    4
  • comments
    8
  • views
    5140

Fix: Event Handling & UI

Sign in to follow this  
m.r.e.

772 views

As the title suggests, I've been working on the event handling and user interface. They are tied together so they are updates/upgraded together. This has added a lot of complexity to the project but I believe it will be worth its troubles.

Originally, I had processed all the user input with the main window's event procedure using global variables. This worked pretty good as I could define the "actions" as variables. The variable, representing the action, would be either "true" or "false". This was pretty basic and old-school. So I rewrote, or wrote an entire event-engine.

I narrowed my choices down between two patterns: Observer and Visitor. Eventually, I choose the observer pattern. I figured it's features in abstraction would do nicely. I made the "Event" the subject that "EventHandlers" would subscribe to. I've not added a priority system yet, so all subscribers are currently handled in a FIFO manner. While each subscriber(EventHandler) is notified about the subject(Event) via Event::Notify(). In this method, each subscriber's event handling procedure is called. The procedure can return "true" for processed or "false" for pass.

It seams kind of redundant to subscribe to events, but it makes for cleaner code. I have two major events currently implemented: KeyedEvent and MouseEvent. Each define their own values and provide access to them via get/set accessory. Events are never queued. This may become a problem later, so I've been considering adding that feature when I add priorities.

I rewrote the user interface(UI). The base of all operation is the Widget. The widget defines most of what a UI component would be. From Widget, I have wrote several sub-classes that I felt I would use most often and leave the ones I would not use that often, only implementing them on a "as needed" basis. So far I have: Button, CheckButton, RadioButton, Slider and TextField. The first three are grouped together. CheckButton and RadioButton both derive from Button. Slider, is just that, a sliding control. It's something you would use to display volume. It's similar to a scroll bar, but doesn't have the end buttons.

All Widgets subscribe to events when enabled and render them selves with a global Theme. I felt using a global theme was a nice way of abstracting the rendering part from the components. In a way, they are all like builders, rendering custom images using themed parts provided by a global theme. They also use some of the image attributes, so if I change images they should adapt. I don't have a container Widget yet, nor have I implemented any layout scheme. I figured I would utilize the state machine I already use to act as a container for UI widgets. That only leaves a layout of some kind to manage how and where widgets would be and what might their tab-order be.

[media='800x600']

[/media]

Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!