It’s not until just now, when I’ve been sitting here for a couple days wanting to work on Tako but not actually doing it, that I’ve realized that I’m having a ‘low’ with Tako.  Any project I’ve worked on at home has typically gone through cycles of highs and lows — times when I work diligently all day and night, and times when things are so daunting that I think about them all the time but don’t actually do any work.  My experience has been that if I push through the lows, I get quickly back into things.  It’s just pushing through the lows that I’m not terribly good at.

With that in mind, I’m going to switch tracks from doing mocks to doing something I typically totally dig: GUI!

User Interface Solution?

I’m sure there’s a custom library out there I can use as a UI solution.  I’m also sure that it would be a pain to implement, and it would be bloated with features that I don’t want.  Seeing as how I traditionally really like writing UI solutions, I figure the best bet for Tako is to do just that.  I should have enough mocks at the moment to at least start planning the UI solution.

Things I want for the Tako UI solution:

  • Normal/Disabled/Hover/Active states for PNG-sourced graphical buttons.
  • Simplicity of authoring the system, and UI elements within the system.
  • ‘NinePatch’-style non-interactive panels.
  • Tooltips.
  • Complex formatted text rendering.  Word wrap, color tags, tooltip/link embedding.  I plan on potentially using this UI system for other projects, so having robust text rendering would be great.
  • UI state stack.  Will need something of this sort, since you can theoretically click through a bunch of Mantle links.
  • Simple toolbox of widgets.
    • Image.
    • Button.
    • Scroll bar.
  • Resolution independence.  Not by scaling everything up, mind you…  Must be able to anchor panels to other panels or to the edges/center of the screen.

Things I do not want for the Tako UI solution:

  • Draggable/resizable windows.  The temptation is always to make really beefy windows as the base class for everything else, but I really don’t want that.  Simplicity.
  • Complex data file parsing.  I’m perfectly fine with all widgets being hardcoded, if it means that it’s faster to develop.  A proper data file loading system can always be added later.
  • Text entry fields.  I don’t think there’s anywhere in the design at the moment that calls for custom text entry.  Even avatar names are supposed to be randomly generated.
  • Complex widget interactions.  Only one widget is going to support dragging natively (the scrollbar).  There shouldn’t be lots of weird parent-child “yes I handled this event, no I didn’t handle that event” stuff, because there really shouldn’t be overlapping UI elements, thanks to there not being ‘windows’.

Well, that’s enough of a starting point, I guess.  Maybe I’ll take the time to do a more fully fleshed-out feature list on the UI system…  including a task breakdown, outside of the current breakdown for Tako-Gimel.  Jolly good!