Archives for posts with tag: aui

Another very short update.

Implemented tooltips!  (Imagine there’s a cursor in there — screen captures don’t capture the cursor.)

You may notice that the style tags from Label work just fine in tooltips.

A bit of technical detail on what I’m doing here…  The Widget class has a few static members and methods relating to tooltips.  Some members include:

  • A generic tooltip label-based widget.  This generic label is used for displaying tooltips such as the above, where all you want is some formatted text.  It’s up to the client to instantiate this widget, since there’s no way that aui will know things like what style to use, how wide to make it (to best suit the UI of the client) and stuff like that.  I could theoretically have that information passed in to some initialization method, but I like this for now.
  • A reference to the currently active tooltip widget.  This may or may not point at the generic label mentioned above.  A widget can provide its own custom widget as a tooltip, which will be handy for things like WoW-style equipment comparison tooltips, which are made up of a bunch of other widgets.
  • A reference to the control that called the tooltip.  During the tooltip updating process, this caller widget is polled to find out whether it still needs to be displaying a tooltip.  As long as this poll continues to return true, the tooltip will never be hidden.  (Note to future self: the fact that you have a memory leak due to controls sticking around forever is probably due to controls being deleted while they still have a tooltip active.)

It’s up to the client to call Widget.updateTooltip() and Widget.renderTooltip() in their main widget’s onUpdate() and onRender(), respectively.  This ensures that the tooltip exists within the input area — and renders in the same scale as — the main widget.

On a side note, I added a PanelLabel widget, which is effectively just a Label, but it will render a panel in the specified style behind the text.  Did this because it trivialized making the generic tooltip.  🙂

Next step: scrollbars!  After that, I should be able to dig into some Tako-specific screens.  Scrollbars are the first major compound widget I’ll be making, so here’s hoping that aui’s structure works out!

Short update!  Got buttons working.  What I ended up doing was creating a Button class, and instead of putting all the graphics stuff in there, I put only the behaviour, and put the graphics in a derived PanelButton class (so-called because it renders its frame using a panel).  This means I’ll be able to hook into Label regions and make them function exactly like buttons if I want to!  Very handy for things like hyperlinks!  🙂

I am likely going to rename what are currently called “listeners” into “parents”, because that’s functionally how I’m using them.  I’m even using them for determining absolute widget positioning.  Put that on the todo list!  Anywho, the way the parent knows that a button was clicked is because its onEvent(source, event) method gets called.  Source will be the widget that triggered the event (potentially overridden on its travel up the hierarchy), and event is more information.  If you click a region in a Label, you might get something like onEvent(Label@reference , “regionName”).

Heck, I suppose in this manner, you could construct a full menu system using only a single label…

“[:createCampaign|Create Campaign]\n[:quit|Quit Game]”

Hmm, most interesting.  🙂

To anyone interested, the basic algorithm I’ve used to format aui’s labels is visible here, under the July 29, 2011 section.

The results are that the string:

"This is an example of a [white|label] which makes use of a few things:\n\n-[special:newlineLink|Newlines]\n-[special:tagLink|Tags]\n-[special|Regions] (though you can't see them)\n-Generally a bunch of text!"

Renders like this:

The basic premise is that you add global ‘styles’, which are associated with tags (like “white” and “special” above).  You specify a ‘region’ when putting in one of these tags, which associates all the words in that region.  Later, this will be useful for adding things like hyperlinks and tooltips.  If you want to insert a region without using a style, you can do something “[:like|this]” (where “this” is in the “like” region, but uses the default style for the label).

Since the heights and widths of all the chunks of text are dynamically positioned, it should be pretty straightforward later to add things like embedded icons, if I were so inclined.  Neat!

This is extremely not how you’re supposed to make AngelCode fonts.

Step 1: Make font PNG.

Step 2: Hand-author ‘exported’ AngelCode .fnt file.

Step 3: Import into game using pre-existing Slick functionality.

EDIT: *an hour or two later*

Also ill-advised is getting preoccupied with getting through one’s task list.

…that said, both word wrap and horizontal/vertical alignment options work!

It may not look like much at a glance, but the hex-button-thinger that’s rendering on top of the hex grid is a NinePatch-style panel.  It’s non-interactive, but I’ve added a few styles that will essentially be used to implement all the panels and buttons in Tako’s current mocks.  The actual source graphics look like this:


I’m developing an extremely simple UI system, as I mentioned in my previous post, which I’m calling “aui”, for “Apocriva’s UI”.  I sometimes forget how much I enjoy writing UI systems.  I could likely share aui if there was any appetite for it later.