mint: details, part 1

sign up sign in

I've mentioned mint before now, in the 2015 intro, and on the community chat - but I figured I could mention a little more about it as we go along toward it being available. I also mentioned I dislike announcing libraries that aren't available, but people were excited, so I wanted to expand a little on where mint is at, and where it's headed.

mint logo

what is it?

mint is a game focused, renderer agnostic, minimal UI library.

Those sound like marketing terms, but they are the core focus of what I need from a UI library. When I first decided to make it (yet another UI...) I wanted the following:

  • Not a 100% solution. I don't and never will believe in the "100% solution" type of development chase. It is not worth it, and you won't be able to cater for every need. mint solves specific things in specific ways and it will aim to do those really well. It will not be a silver bullet, just like every thing else in snõwkit and everything I write it has a place, it has an audience.

  • To the point. 1000 controls might sound impressive for a UI library, but I see that for what it is - 1000+ source code files and a nightmare to work with/maintain/build upon. That obscure control that < 0.00001% apps ever use is a liability.

  • Flexibility. When I make games, I want to prototype them quickly. I want to be able to express an idea fast, and often this requires quick work up of a user interface that can polished later. Also, late into a project, I might need a very unique but oh-so-worth it control type that would drastically improve the experience - this is the type of flexibility I needed in mint. I need to be able to extend and kneed the controls to fit my game/application/interaction.

  • Framework independence. I think people write a lot of UI code, and I wanted to further explore my previous attempts at writing a logic-only system with agnostic renderer adapters, allowing OpenGL based (like luxe) or Flash based (like NME,OpenFL) or others (like Flambe) to share the same code for the controls, and only implement the display portions. So far this has proved quite effective and should allow mint to be used in any haxe framework, with a little effort.

  • Multiple resolutions. Whenever I make things they also tend to span many resolutions, from mobile to web to desktop. How I normally handle this is by percentages, and constraining things to the edges of the screen or to each other. After I had worked with a constraint based auto layout the one in OSX/iOS from Apple engine for UI specifically, I was sold that this is the approach I want in my UI tools. And so, mint uses the same constraint solver to do the work.

  • Game focused. This is a vague term but it just means the same as the above three points, plus some extra focus on game requirements (like intrinsically handling non-mouse input paradigms). It also means to me that the rendering of the controls can be in line with what my game demands. What this doesn't mean is that you can't make apps with it, in fact, mint was originally created for tools/apps.

.mint files

I am not a big fan of UI from file formats (like xml, wpf, flex etc), they always felt like they got me 90% of the way to what I wanted but I would end up programming the rest anyway.

I wanted to see if I could tackle this for my own preference, because file based layouts can be generated from tools, and can be shared across frameworks, they can be validated for mistakes, they can be diffed in version control, and more.

One type of UI I enjoy (yea, I love UI, I am weird that way) is CSS/HTML. Aside from the crazy stigma and browser vendor stupidity over the years, it does have a lot of great stuff going for it. In a previous engine, I even embedded chrome just to use html/css as the UI because it was so much easier to work with.

With that, I took a step back and decided to deduce the things I liked about the combo, and see if I could spec something up that would give me the same feelings for mint.

This is what the current WIP format is looking like, it has two parts - the control markup (i.e defining the controls themselves) and then the layout markup. The layout markup is constraint based, more on that below. I won't go into too much detail, but just note that > defines a new control, and : is a layout block. Controls can obviously be nested, and the syntax is >control_type name { options }. I opted for strict formatting (i.e key:value;) to allow better error checking and validating while writing them.

Code side

The file format is not THE way to make layouts and UI, I often actually prefer coding UI directly, and of course, the file loader simply uses the existing API to do it's bidding, so you can fetch and manipulate controls once loaded. It doesn't compromise the code side, it leverages it.

Constraints

Constraints are quite fun to play with, here's an example of some constraints from the demo below.

constraints

In the demo, the pink box is canvas and the orangey box is screen. The screen is bound to the mouse, so that the automatic layout can be demonstrated. When you add a constraint like constrain(canvas.w, screen.w) it creates a simple equation, and the other form that exists is an inequality, like constrain(canvas.h, '>= 128'). These will take some getting used to (luckily there are places where this is already in use, to learn from) but the key idea is that instead of describing how the controls are laid out, you describe what you want from them, and the solver handles the rest.


demo

The above demo comes from the constraints listed above.
Moving the mouse changes the size of the screen bounds.

Click to run demo

Finally

I'll be posting more in depth details about the solver (Cassowary), it's a standalone haxe library in itself, and other experiments with it, but for now this is where I am going with it.

mint isn't going to solve every UI issue, it isn't going to be the best thing ever. But it certainly will solve my needs for a UI, and it will hopefully be a pleasure to use.

I'll show more along the way, as it's not quite ready for users right now, but feedback/ideas is appreciated, and I hope you'll enjoy looking at the processes I take when writing libraries like these.

Tags
snowkituimint