Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Other than HTML/CSS, any other standards?

This thread is locked; no one can reply to it. rss feed Print
Other than HTML/CSS, any other standards?
Chris Katko
Member #1,881
January 2002
avatar

Other than HTML/CSS, any other standards for separation of function from presentation for a program?

For example, if I wanted to either make a custom interface API for my program, or, use them from a scripting engine in a game to make customized popups, is there a standardized alternative to HTML/CSS?

Because as far as I know, HTML and CSS are bloated, full of security issues, and never the same from one computer to the next. Hence the joke:

{"name":"css-is-awesome-700x375.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/8\/385657d30b646fbee509303ed67decbf.jpg","w":700,"h":375,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/8\/385657d30b646fbee509303ed67decbf"}css-is-awesome-700x375.jpg

I believe Windows Presentation Foundation uses a form of XML but it can also be disgusting and hard to debug.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Crazy Photon
Member #2,588
July 2002
avatar

Do you mean for the web or in general?

-----
Resistance is NEVER futile...

furinkan
Member #10,271
October 2008
avatar

Chris Katko
Member #1,881
January 2002
avatar

Do you mean for the web or in general?

For custom interfaces. Here's an example of a game using (ugly) HTML/CSS menu systems:

{"name":"2utothw.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/d\/fd10b4c4167f8d3bbb143d26cb412af7.png","w":1600,"h":900,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/d\/fd10b4c4167f8d3bbb143d26cb412af7"}2utothw.png

furinkan said:

KDE uses an HTML/CSS JSON based format: http://en.wikipedia.org/wiki/QML

Neat! I was hoping to see something JSON related. It's so much more human readable.

[edit] Though I definitely don't want to use the Javascript run-time if I don't need it.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

furinkan
Member #10,271
October 2008
avatar

@Chris: I've been meaning to ask - I remember somebody using HTML/CSS with Allegro. Was that you? Do you know what libraries are used? It is a very cool concept!

beoran
Member #12,636
March 2011

why not use a full blown scripting language like lua or mruby to do the GUI formatting? It's the most flexible and legible approach, and you'll probably end up needing a scripting language anyway.

Chris Katko
Member #1,881
January 2002
avatar

I've got two distinct ideas but they both can benefit from learning about this topic.

First:

furinkan said:

I remember somebody using HTML/CSS with Allegro.

I mentioned intending to try an XML-like system for Linux so that programs could have a variety of "stylesheets" for small/large monitors, phones/tablets, etc. But I have not pursued that yet.

Basically, you expose a list of controls/forms and the visual side is completely separate. The GUI is as encapsulated as possible from the functionality, so you can pick and place controls from unrelated forms and change their size, position, and type (slider bar verses knob). This also allows multiple user custom stylesheets that can be for specific DPI/resolution/etc or more general and scaling.

But I'm not actively pursuing that as I have too much on my plate right now and I have no idea how to get anybody else's software to use that. Being able to reinvent other people's programs would be insanely powerful to propagating my tool and allowing everyone to use their same programs in a more custom way. It would also allow less common programs to do advanced niche things like having a "terminal only" GUI for any and every program.

The other huge problem would be dealing with programs that depend on focus. Button focus, text box focus, and so on.

Basically, in the age of the internet, I see zero reason GUI's should be static, un-customizable, and not scaling to fit different DPI screens.

Secondly,

beoran said:

and you'll probably end up needing a scripting language anyway.

This one is for a game that would be modder-friendly and likely use a combination of JSON and Python, as Python will already be running the scripting language for the objects.

I'm just kind of wondering if people have already done most of the work for me in more standardized ways. But I'll still likely have to do most of the grunt work it seems for this unless I go straight for HTML/CSS and include a renderer.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Erin Maus
Member #7,537
July 2006
avatar

librocket could be useful. I would have used it in my current project if I could have used my own allocator, but alas...

---
ItsyRealm, a quirky 2D/3D RPG where you fight, skill, and explore in a medieval world with horrors unimaginable.
they / she

StevenVI
Member #562
July 2000
avatar

Apache Flex uses MXML and CSS to define UIs. MXML, as the name implies, is an XML format for marking up the components. It worked very well for me way back when I was doing client-side development.

It sounds like this is exactly what you're looking for.

__________________________________________________
Skoobalon Software
[ Lander! v2.5 ] [ Zonic the Hog v1.1 ] [ Raid 2 v1.0 ]

Thomas Fjellstrom
Member #476
June 2000
avatar

Interesting, I didn't know apache took over most Adobe Flex development.

How easy would it be to tied Flex to allegro? Can you just hand it a GL context and tell it to "fire away"? Or maybe it needs a custom Renderer class defined?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Chris Katko
Member #1,881
January 2002
avatar

librocket looks great at first glance!

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Kibiz0r
Member #6,203
September 2005
avatar

HTML isn't bad. I mean, it's just a description of a document with some standard types of nodes. With polymer and the emerging custom element standards, you can even make your HTML match the terminology of your content more closely. (And you can sandbox CSS to a subset of the tree, so it's not as much of a pain!)

CSS... is bad. The principle is great, but the implementation is too focused on manipulating browser details rather than expressing your design.

As far as bloated and vulnerable, those aren't really defects of the formats themselves but of browsers.

I would say, if you're going to use HTML and CSS, use a shorthand preprocessor like Haml and Sass, and use a templating language (not sure what is out there for C/C++, but something like Erb from Ruby or Handlebars from JS, specifically Ember's implementation with auto-updating bindings) rather than trying to roll your own way of inserting dynamic content.

Flex/Flash is great for GUIs, but you will probably have a marshaling problem to deal with since your UI content is locked into a VM. I don't have a lot of experience with Flex, specifically, so I can't speak to how much you get right out of the box. Also, check out Scaleform.

Edit: librocket looks really handy, but you'll have a long way to go to get what you were really asking for: "Here's my HTML, hand me some data and I'll shove it into the right placeholders and render it with my CSS." That needs to be a self-contained package you can create just with HTML and CSS, and integrate with some code that doesn't know anything about HTML and CSS. librocket's examples show a lot of blurring between those two concerns.

e.g.

<div id="high-score">{{highScore}}</div>
...
DataBag data;
data.set("highScore", 500);
highScoreView.render(data);

Chris Katko
Member #1,881
January 2002
avatar

I like that idea as well. It probably wouldn't be too hard to "roll my own" in that sense. Things are a little up in the air, though because I don't know the complete picture of my own needs. Where are the boundaries? How much work am I willing to do for X amount of complexity and Y amount of simplicity to create them.

I need a markup language for doing button interface stuff, right-click context menus, dialog with lots of text and a scroll bar. Everything that's in that second picture I posted plus more and better looking. Animations tied to finite-state machines. Also DPI customization. So I guess rolling my own will make that a lot easier.

The biggest two things are simplicity of customization, and it has to really look like a game UI and not some cheap knockoff of one from the early internet days.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Kibiz0r
Member #6,203
September 2005
avatar

For rich UI with a lot of dynamism, you need a programming language attached to it. And I'm assuming that you don't want to reinvent the wheel when it comes to right-click menus and such. But, for HTML/CSS, 99.9999999% of the existing code you'll find to fill those needs is going to be JS or something that compiles to JS.

If you're really crazy, you could probably use LLVM to compile JS to machine code and somehow have it target librocket's DOM. (I'd love to see that, btw, that sounds insane!)

Other than the obvious desktop UI frameworks, then, I think your options are Scaleform+Flash/Flex or the million one-offs out there that just give you the absolute basics.

Flash does give you the really cool benefit of being able to use Flash Pro to design the UI, which is a pretty nice application.

Chris Katko
Member #1,881
January 2002
avatar

It should be noted I'm already planning on using Python for the object's scripting language. I don't really want to reinvent a grid alignment solver, so maybe extending HTML/CSS with function callbacks is a good route.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Kibiz0r
Member #6,203
September 2005
avatar

There's also Awesomium. Seems like it gets you a little farther than librocket.

If you want to leverage existing JS code for UI -- which I would highly suggest doing since you seem to want a powerful UI toolkit -- you'll need to tackle the JS integration problem.

The way I see it, you have three options there:

1. Strive to eliminate JS at compile time.

Write a DOM binding (against librocket or Awesomium) that can be consumed by C++ or Python.

Compile third-party JS to essentially C++, with a virtual JS runtime that is provided by your DOM API.

Awesomium gives you a leg up with already having a richer DOM closer to browser DOM, but you'll still ultimately depend on a JS runtime beneath your virtual runtime that supports C++ and Python without direct JS marshaling.

Librocket is probably a cleaner choice, but you would spend more time building a virtual JS runtime since you can't lean on V8, and I would worry about bugs emerging from failure to support corner cases that third-party JS libraries depend on.

This option seems crazy, and would require very careful design to bring all JS semantics out into a pure C++/Python world, but if you can get to that point then, as a consumer, you can integrate any JS libraries you want and work with them without worrying about JS.

2. Encapsulate runtime JS interaction.

Write a wrapper on top of Awesomium that has convenient semantics for C++ and Python, and ties into the rest of your application's architecture.

There are probably libraries out there already that hide Awesomium's JS marshaling from a C++ consumer, and maybe also from a Python consumer. You'd just to have to integrate the two and sprinkle in some of your domain-specific concerns.

This option is only possible with Awesomium, (or by integrating a JS runtime with librocket, at which point you've made Awesomium yourself...) and lets you skip out on most of the tech integration and focus on providing a nice Python interface.

Any improvements to your C++ interface are gravy, since you can always fall back to direct JS runtime marshaling in C++, or even in Python for that matter if you need to cut some architectural corners.

3. Embrace JS as the fundamental language of your UI.

Translate alternative languages (like Python) into JS, using any of these source-to-source compilers.

Again, this is mostly for Awesomium unless you want to re-create it with librocket.

This is probably the easiest option, but it does require that you write your "Python" interface instead as a JS interface, and you're at the mercy of JS semantics when writing Python, since you're really writing JS. However, third-party libraries should work with minimal effort, and you have tremendous flexibility in language choice as a consumer.

A central trade-off here is that your C++-vs-Python interaction is mediated by a JS runtime. If you have use for Python as a scripting language beyond UI, you'll have to be aware that you're using two different "dialects" in UI and non-UI use cases, and references to JS data will be inaccessible from a non-UI context.

---

I'm very comfortable with marshaling/FFI, so I'd probably go with option 2, especially since having C++ as the "single source of truth" appeals to me when it comes to crossing the line between engine scripting and UI scripting from Python.

I'd only recommend option 1 only if you're very comfortable with compilers and runtimes, and don't mind a significant effort as long as it results in a DOM that really and truly uses Python as its scripting language.

Option 3 is very interesting, though, because it doesn't require much effort to get going, and could be an excellent prototype to start off with and see what your needs really are. You'd still have the door open to pivot into option 2, or to build a "good enough" bridge between the C-Python and JS-Python worlds.

---

All in all, this is an interesting problem. Game UI kinda gets the shaft when it comes to framework support, because all the standardized efforts out there focus on desktop or web, neither of which are great fits, and the one-off solutions out there for games are often extremely limited in scope and leave you holding the bag when it comes to tailoring them to your specific needs.

I've been thinking about what I would do, given that I've basically made the transition to full-on Ruby acolyte at this point, so Ruby would be my "single source of truth" and also my preferred scripting language. I'm also really comfortable using JS (through CoffeeScript, usually), so I think I would just roll as vanilla as possible and accept that I'll be calling back and forth between Ruby and JS a lot. I'd probably end up making some common abstractions that are shared across Ruby and JS, with similar interfaces but context-specific syntax and semantics.

Anyway, hope that rambling helps. :P

Go to: