You might remember that I wrote a program for laying out comic strips. I stopped using it when I stopped working on Stolen Pixels to become an author. I think about Comic Press now and again, feeling vaguely guilty that I’ve got this useful chunk of software sitting on my hard drive, basically going to waste. I should clean it up and release it to the public. Or do some tipjar-based development on it. Or something.

And then I remember that Comic Press is in this oddball limbo state. It was written in Visual Studio 6, which came out in 1998. It uses a ton of non-portable Windows code. I can’t even compile it now that I’ve migrated to Microsoft Visual C++ 2010 Express. I need to update all of the dialog and menu code to get it running. But if I’m going to do that, I should fix this interface to make it a little more portable. But if I’m going to do that…

A GUI system is what enables you to add standard controls to your program. Buttons, menus, checkboxes, file open dialogs, scrollbars, edit windows, and so on. See, in Windows (or Linux, MacOS, etc.) the operating system can do all of that for you. With a few lines of code I can make a button…

I can tell the system, “stick a button right here”. Then Windows (the operating system) will handle everything else. It will draw the button, making sure it matches the theme used by this particular computer. It will make the button look “pressed” or “disabled” at the proper times. It handles hotkey interactions. It tracks mouse movements and clicks to see where the user is clicking, and it will send me a little message if the user ever gets around to activating the button so I can take the appropriate action. I do not hold up the Windows API as some great work of technological engineering. It’s old and awkward and clunky and not terribly efficient. But it’s there, and it saves all of us Windows programmers from needing to write our interface code from scratch.

The problem is that we lose all of those features once we’re talking about a window that renders 3D stuff. For example, if I’m rendering a 3D scene in OpenGL:

Basically, you can’t do this:

I could make a Windows-style window to sit in front of the 3D window, but that’s not the same thing. It’s the difference between using the chat window in the corner of your World of Warcraft screen and just having (say) a Notepad window positioned over that same area of the screen. It doesn’t work.

So once you’re doing the 3D graphics thing, you’re stuck making interfaces yourself. This is a lot of really fiddly work. Most people don’t even realize how crazy complicated a scrollbar really is. There’s buttons at the top and bottom for moving up and down a “line” at a time. There’s the scroll area, which should let the user jump to the given point in whatever thing they’re viewing. Then there’s the shuttle control itself, which changes size based on the ratio of the total document and the potion that is immediately visible. There’s interactions between the document and the scrollbar as the document changes size. Using the mousewheel on the document should move the scrollbar, and using the arrow keys on the scrollbar should move the document. This adds up to days of work, just for a scrollbar. Add in the time you’ll need for text windows, button bars, progress bars, sliders, spinner controls, and all the other things we take for granted, and you have months of work.

Months!

For an interface!

A lot of this probably explains why game interfaces are so primitive.

I don’t imagine we’ll be seeing a text box with a scroll bar in Minecraft anytime soon. I’m betting Notch had to program his interface from scratch. If I made an interface by hand, this is exactly what it would look like: Buttons and sliders. Those are far easier to implement than other types of controls. Note how the difficulty selector is a button with four states: Peaceful, Easy, Normal, Hard. In a full-featured windowed environment, usability standards would normally call for a drop-down box in this context.

Over the years, a lot of enterprising developers have taken a stab at solving this problem. They do this by making a library, which is a big ol’ lump of code that you can add to your project. Some of the notable ones are:

Some of these were abandoned before they were finished. Some are poorly documented. A lot of them are just hard to use. Some are stuck looking like Windows 95. Some are difficult to compile, or have challenging dependencies.

Ideally, a library should be as simple as possible. If you make a library to handle the physics in a game environment, you shouldn’t include a bunch of crap for generating sound effects. Yes, the programmer using your library will probably need sound effects, but they might already have a sound system. That extra sound code stuff will be all the more stuff that they have to compile. It will create more dependencies and make the library that much harder to learn, integrate, and debug.

OpenGL is a perfectly focused library. It does rendering, and only rendering. It doesn’t know how to load images. It doesn’t talk to your file system for saving and loading data. It has no physics, no particle engine, no support for 3D models. No sound, no joystick support, no special effects. It’s concerned with the low-level, nitty-gritty details of drawing polygons. If you want to load in a texture map, you load in the image (JPG, PNG, BMP, TIFF, etc) yourself (you’ll need another library for doing that) and just feed OpenGL the raw image data. It doesn’t concern itself with where images come from, where they reside on disk, or what they’re named.

I said it’s a perfectly focused library. I did not say it was a perfect library. It concentrates on doing one thing, and doing it well. If you need more you can get other libraries to do other things. If you want a lot more help you can use one of the many game engines built on top of OpenGL. But the core is there, uncluttered, if that’s what you need.

It’s fine for me to sit here and make broad statements about keeping libraries simple, but in the real world this kind of platonic ideal is actually really hard to achieve. The problem here is that you need a lot of stuff to make a proper GUI. You need fonts. (You can’t have an interface without fonts!) You need to be able to load images. (Because those interface buttons have to be made of something.) You need to process keyboard and mouse input. (Otherwise, what’s the point?) It needs access to the rendering systems. (So that it can draw its controls.) This means your “interface” library needs hooks into the filesystem, rendering, an image loader, peripheral I/O, and a font loader.

This is a nightmare. A lot of those things are messy, non-portable systems, which means they will vary from one operating system to the next. It means the library will need to include lots of other libraries, which will lead back to my original rant.

Awesomium is about the most promising development so far. It’s a library that lets you stick a fully functional web window into OpenGL. So you could put your interface into web page form, stick it on a polygon, and render it that way. The downside is that HTML doesn’t have native support for all types of interface controls. (Progress bars and sliders are two important ones.) You can create these manually using Javascript, but then you’re back to hand-coding your own interface elements.

It’s a tough problem, which is why I keep walking away from it every time I revisit Comic Press.

121 thoughts on “The GUI Problem”

Actually, progress bars and sliders have both been added in HTML5. They’re not universally supported yet, but my current project at least uses sliders copiously. (That said, I have the advantage of knowing what browsers I use and that no one else is going to be using those particular bits of the program anytime soon.)

With that said, something just feels wrong about the fact that the best way to do UI in an OpenGL game is to throw three more languages, an interpreter, an XML parser and a layout engine into the mix.

QGLWidget can be used with Qt’s “overpainting” technique to render regular widgets right on top of the GL scene. Disclaimer: While I am a huge rabid Qt fanboy, I haven’t used this particular technique myself yet.

You can even transform the widgets and really go nuts like they do in their WolfenQt demo.

It does, yes. It is a complete “kitchen sink” library – and I don’t see that as a bad thing. QString does Unicode out of the box. QMap, QList use the pImpl idiom and implicit sharing and (IMHO) a pleasure to work with. there’s a foreach macro for all of their containers but if you want you can use STL-style iterators too. The documentation is fantastic.

I dunno, I found C++11 to make C++ fun – not even having to *bother* about pImpl when you have move semantics (in other cases: sharing is bad, m’kay?), and ‘auto’, lambdas with std::for_each, and range-for all make for-each easier by far than a macro. I’m not sure what you mean by “QString does Unicode out of the box” – I’m not sure I *want* a string type to be much more than a character list (with lexicographical sorting and substring match for find(), of course), and you always had std::wstring. If you really want, eg. UTF-16 on all platforms, or just to be clear that you’re using UTF, C++11 added explicit types for all of them, BTW.

Every C++ library re-invents strings. Because the standard guys thought they didn’t want to force people to use a certain format, and that results in my writing code with the following types: CString (CStringW / CStringA / LPCSTR), std::string, char* and BSTR. And I’m not actually using QT or Boost, which saves me another two variants. Speaking of which, there’s also VARIANT (can contain a string) and then there are database types such as VARCHAR, CHAR, Text or Longtext. Thanks guys. This is not overly complicated at all…

Some of these can do unicode, some can’t all need specific conversions, and it’s a huge hassle.

If you ever design a programming language: Include the basic types into your ISO-standard.

I’ve had to learn to work with Qt (4) from scratch over the past year, designing an interface (also from scratch). I found that Qt handles a lot of things more or less exactly the way you want it to, but getting the stylesheets to stick takes some practice. I can’t comment on Qt’s personal code versus the C++ code our back-end programmers used, but I never had a lot of issues sticking QStrings everywhere.

If you’re looking for advice on your comic program in particular, I’d say:
1) Port any actually necessary code to C#
2) Write a new GUI in WinForms (yes, yes, I know, but it gets the job done better than almost anything else)

For a game, there are (some, fewer every year) compelling reasons to write in C++. For a non-game application? It’s just asking for pain. Don’t ask for pain, use a better language.

Interestingly our C++ game at work can be run with a -editor command which, within a couple of hundred lines of code, loads up some DLLs then runs the game inside a C# window with all sorts of extra controls (all inside C# projects).

Our game uses D3D not OpenGL though so maybe that’s what makes it work.

Okaaaaay. I don’t even know how to respond to these C# suggestions. I mean:

1) Acquire new IDE
2) Learn new language
3) Port entire project – thousands and thousands of lines of code – to new language
4) Get some third-party toolkits (like OpenTK) to replace the functionality I’m losing by moving away from my current setup.
5) I don’t see how this solves the original problem?

I’m sure C# is a fine language, but given that you’ve just proposed many weeks of work, I’m curious what I would get in return?

Let’s put it this way. There is an order of magnitude of GUI API usability between C++ and all .NET languages. Personally, I have been doing some stuff in F# (though C# is far easier to learn for someone proficient in C++), for example, and the very week I started learning it already could, with the help of the API documentation, of course, do things I would not dare to do with the native Windows API in C++ and otherwise have to use some external GUI library (with all the hassle you mentioned).

And I did not even have a real WYSIWYG GUI editor, I was making a window and buttons and controls from scratch, in code. I could do even fancy stuff like react to mouse wheel scrolling with a whopping three lines of code (and that included calling one of my own alrady existing functions with a value derived from the scroll direction and distance!).

Though I would not recommend porting an existing program to C#, I highly suggest learning it for new projects or when you might decide to re-write a particular tool from scratch.

WinForms is a simple layer over Win32 windows and controls, so nothing. An argument could possibly be made for a transition to WPF, which has ridiculously themeable and customizable DirectX-backed controls which you could layer over a DirectX 3D scene, but that means you have to:
1) lose portability (WPF is one of the few libraries that Mono doesn’t support)
2) learn Direct3D (not *that* big of a deal, “#include ” solves pretty much all the COM tax, and it’s nearly 1:1 for features with OpenGL at this point)
3) learn WPF (I was not kidding about the ridiculousness of this API – it’s astonishingly flexible, but means you have little best-practice and defaults to fall back on)
4) Rewrite all your OpenGL to DirectX.

Note that I *didn’t* include learn C# in there – WPF and all the rest of .NET is perfectly usable from C++; though certainly getting native types to play well with the managed types can be a pain at points. On the other hand, C# has a lot more tooling, and is pretty easy to learn anyway: I’d recommend you do just for the experience – I’d love to see your ranting about all the things you didn’t like about it for one thing :P.

But in the end, it’s buying you little, for a high cost. My inner performance nut freaks out at loading a whole goddamn HTML layout engine and scripting runtime for just putting scrollbars on screen, but commercial games do a pretty close thing: ScaleForm is a heavily-optimized Flash renderer and ActionScript runtime used for pretty much anything even close to 2D graphics (Menus, HUDs, even in-world billboards and screens). And it costs a *bunch*. And you *still* have to implement your controls.

One of my longer-term dream projects is a fully factored, easy to use, fully featured but low impact GUI library: give it a skin, font metrics, layout and input data and it spits back vertex/index buffers and text-layout (roughly). There’s a bunch of problems to figure out still, in that skins might need both GL and DirectX shaders, getting text metrics can be tough, input fields are goddamn bastards that will ruin just about every requirement up top, etc…. I would just about have to provide a text-rendering implementation too, dealing with fonts cross-platform is too high a burden for just about everyone. And of course, someone will beat me to it half-way through! So I don’t have much incentive :P

I think you vastly, vastly, vastly underestimate the efficiently of a well-designed memory-managed language like C# with a large, well organized, runtime enviroment like .net. And for what it’s worth, the Unity game engine uses C# and has a pretty good track record of completed games. And XNA, natch.

But I was talking about your comic captioning program, not your game engine. Sorry if that was confusing.

I think you vastly, vastly underestimate the time required to learn a new language and translate a project over to it. :) I mean, think about how long that would take. I’ve got all kinds of stuff allocating blocks of memory, drawing into a Windows bitmap image, then blitting from there to memory, then from memory to OpenGL. All of that would need to work in a completely different way. And that’s just one of a dozen systems that operates on a really low level. I wouldn’t need to just “familiarize” myself with C#, I’d need to learn enough to be a C# badass. How long does that take?

And it’s not that I “underestimate” the benefits, it’s that I really don’t know what the benefit would be at all! This is not an improperly estimated value, this is an unknown value. Your suggestion that it’s “better” is pretty hard to quantify.

This is the pound key: Â£. I bring this up as something that always confuses me when on dialing into an American conference call and I get told to press the “Pound key”. For me, this “#” is the hash key ;)

Wellllllllll, most of what you mentioned can be handled by the .NET runtime.

If all fails, C#/C++ interop is really cheap. Both in terms of performance and actual development cost.
Y’see, for a student project, we needed to create an application that used a lexer/parser made with lex and yacc. That meant native C++.
On the other hand, the previous year I’d made an equation derivator in C# that consumed premade ASTs, but I never bothered to deal with the lexing/parsing part.
So for this project, I grabbed both parts, added some C++/CLI glue (mostly wrapping the native C++ objects in CLI objects) and it was good to go. Took me about two evenings, including the time to learn C++/CLI, P/Invoke and interop.
It really is that easy.

Fair point, but learning a language really isn’t as hard as Shamus implies. Consider my uni had us, for a single course, pick up C++, Java, Scheme and Python.

If anything, the fundamental differences in programming paradigms might trip one up, but C++ is procedural with OOP tacked on, while C# (and Java for that matter) are OOP with procedural options. In fact, there’s less of a mental burden when switching from native to managed because you no longer have to consider memory management. Just new it up and let it go. RAII, the darling of many C++-ists, is still there in the form of the using() {} clause. So you don’t really lose much.

Oooooooooooooooor, now that I think about it, you could just skip it all and use C++/CLI. All the benefits of the .NET class library, only a bit of the new language burden. Copy paste the native code, add your managed bits and you’re good to go. You don’t even need to keep them apart.

I agree that learning the basics of a language is fairly easy. But as Shamus said, this wouldn’t require learning basics, but becoming a “C# Badass” (as he so eloquently put it).

While I bet you’re decently proficient in all four of those languages, I’d bet you aren’t a “Badass” in any, unless you dedicated further time to them afterwards.

Additionally, you learned those in uni, where you are expected to dedicate a fair amount of your time and mental processes to such things, with the goal of using them to further your career ambitions. And it still took you 8 months of schooling, so let’s call that 2 months per language to get to a reasonable proficiency.

Now imagine doing this while attempting to pursue a completely unrelated career with no potential for financial (or really even personal) gain from learning said language.

Suddenly, it becomes much more difficult to do, and much more time-consuming. I’d multiply that time frame by at least 2, maybe 4, given these conditions.

So that’s 4-8 months of fairly dedicated work, around his other responsibilities, that Shamus would need to put in, for little to no benefit.

So not to be rude, but no, “Learn a new language” is not a valid suggestion.

On top of that, the real problem isn’t just learning the language. Even if you were a baddass in both C++ and C#, you still have a ton of badly portable code to look forward t. Especially thanks to the nature of Shamus’ program where a lot of the code will be dealing with rendering stuff, rendering it using OpenGL. With that in mind, your port would probably turn into something resembling more of a complete rewrite than anything else pretty soon.

That’s assuming that Shamus isn’t mistaken about needing to be a C# badass – he seems to be talking about porting his memory management code over; isn’t that actually massively redundant? Like writing assembly-style in C?

C++/CLI has RAII enabled for the managed part, which proves that .NET could handle it, but currently, C# is not powerful enough to handle RAII unless it is very manually (not forgetting “using”, and knowing how to write a correct Dispose method)

His previous experience was VB6 and VBA, from 10 years ago, and he is a lawyer, not a software engineer (I’m NOT kidding).

For your Comic software, a C#/WPF application would be quite easy to write, I guess, and in the end, coming from C++, it would make you at least on par with experienced C# programmers (an interesting thought for your curriculum vitae).

If you have good programming experience, even if its in a completely different environment for you, I feel confident in saying that you can complete a WinForms app that will shuttle images around, mash them up, add text to them, and save the result as a single completed image in a few afternoons. (This may only be a small subset of what your Comics Maker does, I’m not sure)

Writing desktop apps with OpenGL and C++ is like starting the process of building an airplane with a few thousand rolls of steel, 300,000 billets of aluminium, a CNC machine, a laser cutter, and a welder. Sure, those tools are amazingly useful, and you CAN build just about anything with that combination… but C# in Visual Studio is like starting with pre-built wings, engines, wiring harnesses, fuselages and such. You can just bolt them together and start flying. Carrying this example entirely too far, the OpenGL/C++ combo makes building a completely custom engine design for that plane way easier – you were going to do that anyway. C# WinForms makes designing that custom engine really difficult, because it is designed to build whole planes quickly. You could still do it, but it would just be a huge pain. Use the right tools for the job is all we’re trying to say.

I’m skeptical that it would be worth porting your code, but you might want to at least poke your head in and investigate for future reference so that you don’t mash your forehead against the wall next time you need to build a desktop app. (As mentioned, with Mono you should be able to get it running just about anywhere)

If you’d like to take a look at a language which is similar to C#, but isn’t tied to Microsoft and doesn’t run in a VM, I recently converted from C/++ to D(www.dlang.org), which seems to take a lot of its syntactic cues from C#(and pretty much the rest of them from C++). Total time to pass up my C/++ skill level: about a month.(granted, that’s not much of a baseline, I’m paid to program in Java)

D is also able to interact natively with C libraries(C++ not so much sadly) and you won’t even have to throw out all your OpenGL code, because there’s a very good bridging library called Derelict which has links to SDL, OpenGL, OpenAL, ODE, and several other libraries I haven’t even heard of.

There are also ports for the GTK and WxWidgets UI libraries, so that’s that problem taken care of, and D has all sorts of memory management features which will make a blog entry you made around the time you started Project Frontier entirely obsolete: to concatenate two strings, you would use…

string str1 = “Twilight is a great series”;
string str2 = ” for starting arguments”;
string str3 = str1~str2;//str3 now reads “Twilight is a great series for starting arguments”

and to print it out, you could use either

writeln(str3);//print str3

or save yourself the time and just use

writeln(str1~str2);//print the concatenation of str1 and str2

or the way I would do it

writlen(str1, str2);//multiple input parameters are converted to strings and concatenated.

I’ve been waiting for another programming-related blog entry, because I’ve been wanting to pitch D since I read that one, and I sadly only started reading Twenty-Sided a few weeks ago.

> I'd need to learn enough to be a C# badass. How long does that take?

Not as much as one would think. C# is very easy once you know C++.

At first, it seems like C++, but with a cleaner syntax. It is very pleasant to write. The syntax comes naturally. Almost zero learning curve. In fact, most or your time will be spend instead discovering the huge standard library that comes with .NET.

After a time (a few weeks, for me), if you were advanced enough in C++ (are STL, Boost, RAII, exception safety, etc., familiar concepts?), C# feels like a beautiful but castrated C++.

> And it's not that I “underestimate” the benefits, it's that I really don't know what the benefit would be at all!

The real benefit is that you write code faster in C# than in C++. Also, you have a very large standard library, meaning that you probably won’t need much (or at all) external libs.

For the performance, this is still hotly debated (see the discussion between Herb Sutter and Miguel de Icaza). Unity is supposed to enable game programming on C#, but could Skyrim be written on C# ? I seriously doubt it. Most performance intensive apps (including games?) are still faster on native code.

Perhaps you should take a look at Unity, and how it is received. Are users complaining about its performance issues? Are the games developed with it on par with the kind of games you want to write?

What you really get in C# is JIT (Just in time compiling). Not sure if it’s in visual C++, but being able to place a breakpoint, check the values, write new code, then have the program continue running from where it left off immediately is very appealing, especially when porting over code, or working on someone else’s code. Now, this isn’t enough for me to say switching all the code over, but it’s definitely the one thing that sold me on switching languages.

C# isn’t just “superior” to C++. It’s different. It forces you to use a garbage collector and Windows. Managed code is also oodles slower than highly optimized C++ code. I’ll give you an example:

Managed languages are built on the premise that all functions are virtual.
C++ is built on the premise that all functions can be inlined.

I would certainly say that the software Shamus described is a better fit for C#. C# also has WPF which is hugely superior to MFC (or COM or ATL), and generally the libraries are far more sophisticated. But C# is far worse if you want to do CAD (such as CSG), physics simulation, Algebra or program a robot with very limited memory and cpu (assuming you can get .NET to run on that bare-bones Linux in the first place). I would also say that suggesting to port the thing from one language to the other is beyond foolish.

So please, instead of stupid language wars: There is (nearly) always a reason why a certain language can be superior for a certain task than (most) other languages. I would not want to use C++ for webpages, and I would not want to use PHP for robots.

Our biggest product (a few dozen developers) works like that. I would not consider it “easy” at all, though it is of course possible that we messed up somehow. On the other hand, we use WPF on top of a Direct3D-layer, and I can’t imagine that this works well in any case.

It also adds a huge issue to your project: You now need to know two languages and two sets of libraries instead of one. Most of our developers are not good at both sides (me included, my C# knowledge is largely theoretical). For a single-person project, having to deal with the interfacing overhead is probably more work than just dealing with a less-than-stellar GUI API.

Actually the JIT is decent enough at detecting and inlining that raw execution speed is fairly close between native and managed. What’ll bite you a little is that managed has more internal sanity checks that can’t be disabled (which is good for program robustness, less so for performance), but the biggest kicker is the garbage collector. While it’s fast, it’s also something that you can’t control that randomly injects latency into your code by periodically suspending all threads briefly. This is completely invisible for a normal desktop app but if you’re doing something high-performance (eg. realtime rendering) it can cause noticeable hitches.

I do not hold up the Windows API as some great work of technological engineering. It's old and awkward and clunky and not terribly efficient. But it's there, and it saves all of us Windows programmers from needing to write our interface code from scratch.

I disagree. The stuff might save us from an even larger lot of hassle, but generally I find the Windows C/C++* API nowhere near the level of usable. It’s better than nothing, but whenever I have to do anything directly with it, the first thing I do is write a wrapper of sometimes dozens of lines for what would otherwise seem like a trivial one-liner, but needs setting up proper input and output objects, conversion from standard types to Windows API types, handle buffers (because C++ standard types like std::string could just do it automatically, but the Windows API is also meant for C so we get to do this the old school way, too), and generally keep eat-or-die #defines out of the rest of my code (and btw who found it clever to invent a ERROR_SUCCESS constant that indeed meant success, but lets the readers eye always stick to that big ERROR in caps whenever one tries to quickly browse through some code?).

*.NET has a far more practical and programmer-efficient interface. It’s a shame there is no identical native C++ interface (it’s usable in C++/CLI, but when you are going down that route you could just better do it in C# anyway).

ERROR_SUCCESS is 0, so you can always just do “if (error) …” or “if (!error) …” instead….

Anyway, you may get your wish: Windows 8 is bringing in the “Windows Runtime” or WinRT, which is basically bringing .NET’s metadata and type system to the native API (unlike the .NET libraries, however, it’s not garbage collected or JITted, nor does it have the .NET security model, so it’s blazing fast). Now for the bad news, *at least for now*, it’s only available for Metro style apps, so effectively only Windows Store apps, with all the API restrictions, code signing and submission process burden. I pray for the day that, like it’s predecessor COM (an astonishingly broadly used design), WinRT is stolen and used as the binary interface of new systems, langages, OSs, etc…. It’s pretty great technically, is what I’m saying.

it's only available for Metro style apps, so effectively only Windows Store apps, with all the API restrictions, code signing and submission process burden

And that means for a lot of people it will effectively not exist at all. Just like the .NET libraries are not directly available in native C++, the new WinRT produces yet another encapsulated world that might be better than the outside but entirely closed-off.

Unless there are real technical hurdles for the given limitation (one I could imagine – that there might be things you cannot do in WinRT and are also not meant to be done in Metro and so just left out), I highly suspect that the goal of the restriction is to produce incentive to build Metro UIs by providing a shiny new library to make this (possibly) more efficient.

This is why I had the “*at least for now*” qualifier in there. I don’t know if Microsoft has said anything one way or the other (but they would be crazy to do so) but I expect “Metro style” to become a less and less meaningfull description as contrasting “Desktop” with future versions of Windows. Firstly the *requirement* of Windows Store for Metro should be dropped (or at least relaxed) in later versions once they’re happy they’ve figured out the experience and security issues with that (they’re trying to solve the “XXXHotNakedGurlsXXX.jpg.exe” style problems), since MS gains nothing by encouraging development for Desktop. Secondly, the feature set of Metro style apps (God I hate that name, “Metro” is a set of graphic design rules: a “design language”, not a runtime!) will obviously expand, and the obvious direction for them to expand is to cover the needs of current Desktop apps.
In short, *eventually* WinRT will not be nothing, but until then it’s shiny design and ease of use mock me, from just over that fence :(.

According to official Microsoft sources (I directly asked them at a training session), the Store is *not* required for a Metro-style app. It’s totally permitted to install WinRT apps from a regular desktop application installer — but that way you have to take care of user permissions, ads (if applicable), and updates yourself.

And you also have to bear in mind that WinRT apps don’t have access to the “regular” Win32 API. Which means that the ten billion existing libraries for Win32 are completely useless to you if you go that route.

Careful with the generalisation. I spend a lot of my time writing low-level WinAPI code, and I came to the conclusion that not all of it is utterly horrible. Yes, most of it is insanely clunky, especially when you go below MFC/WPF, and dive into COM and ATL. That shit is painful to use. But on the other hand, a lot of MFC is actually quite practical, and there are a few redeeming things about it:

1. It’s incredibly bug-free. If something doesn’t work, you can be sure it’s at your end. This makes debugging a lot easier, because you never run into absurd errors due to bugs in the libraries (I’m looking at you, JavaSwing!)
2. You very rarely lack a required feature. You *can* change every behaviour, and though that sometimes isn’t so easy, at least you can do it without rewriting the whole thing from scratch.
3. Well documented, and well-written code. Sure, you sometimes have to search through msdn to find the correct piece of documentation, but at least it exists. Every parameter, every return value, all is explained in detail. And if you need to step through its code during debugging, it’s very easy to understand what stuff does, because the code is very cleanly written (few side-effects, early error testing).
Go look at CMFC (which is an extension MS acquired by way of buying a company) in comparison: The documentation is just outright horrible, the interfaces lack crucial basic functionality and the code is a pain to debug.

Do I curse daily about all the things that WinAPI sucks at? Of course!!

With QtQuick you probably could implement about 90% in QML / Javascript with a simple C++ layer for serialization. I have now written two commercially available products with it and I never want to use any other Framework again :)

Search for QtQuick or QML on youtube, there are quite a lot examples. Also the documentation has become quite good over the years ( qt.nokia.com )

You had to do it. Threw down the challenge to the C# dweebs. If they are proposing C# then they cannot use ANYTHING ELSE. They cannot code in a real environment and they have no concept of portable code. The only good that has come from C# is these self same folks have quit using VB.

Windows (including all their proprietary crap) is THE problem. Embracing their products mean you cannot have things that work, there are always security holes (with trucks driving through daily) and it will solve 90% of your problems. Of course it is the 90% that is mostly solved anyway but you just have to restart.

Then they will be happy. And goodness will cover the land in Balmer inspired rages.

Me, I can barely tolerate C++, C# is like nails on a Visual Basic blackboard. Reminds me that all of this comes from the genius of Billy The Boy Gates and his OS Interprettier. Oh, it interprets and it is prettier. NT is still soiling the landscape.

I don’t really like it when people go around promoting their chosen language/IDE/whatever like it’s the best deal in town and will magically make everything better without ever getting into details, but you’re being a bit hostile there.

On the other hand, C# (or VB) is a lot more friendly to beginning programmers than C++. Should they learn OOP in a simple (but less useful) language or a dense, complex language that takes them 3 times as long to grok?

For what it’s worth, I wish I had learned Python first instead of a dialect of Basic. It’s very friendly to newbies without sacrificing power. I can’t comment on C# because it showed up after I stopped using Microsoft products, but I hear it’s a good language. Java’s model (bytecode and a VM) is the right one for high level portable languages. Of course, there’s the JVM for people who don’t want to play the Mono game. I should really get around to learning Scala.

It’s actually in pretty wide use in gaming, including, notably, the recent indie release Fez. Microsoft has released some tools for writing games in C# – XNA – and a lot of games use it, including everything in Xbox Live’s Indie Games store. I have no personal experience with it so I can’t comment on its quality, but it has a very good reputation.

That’s good to know. I learned VB.NET several years ago and I’ve yet to find anyone who uses it professionally. It’s nice to hear that C# sees some use. I don’t have enough personal experience to comment on its quality either, but I will say that it made a good impression on me.

More notably, The Sims 3 used it (running on Mono so they didn’t have an external dependency) for all their scripting. Of course, since they were using Mono before they had implemented a generational compacting GC there were cases where all the scripting just hung for up to 15 seconds at a time as it collected… :(.

For most of what I do these days (since retirement) is it C, some assembly and some small languages I write myself.

I was one of the first subscribers to MS developers license. Cost several hundred dollars a year and they shipped lots of CDs every quarter (or month??). The reason I am so down of them now is large percentages of what they shipped did not work. The MFC libraries had entire sections that just returned 0. Did no work, just indicated success. Some coding required. MS and their products have not gotten better in the time since, but they have gotten better at their marketing of mediocre material.

I hate language wars. And word processor wars and browser wars. Just code and STFU. If you are worthwhile then I can read your posts. Like this web site!

And there is a massive contradiction between the “Me, I can barely tolerate C++, C# is like nails on a Visual Basic blackboard.” kind of gratuitous (and insulting) assertions you write in one post, and the “My preferred language is the tool that fits the job” you wrote in the other.

This an issue for mobile as well. I’ve got plans to work on an OpenGL game on Android/iOS once the PhD thesis is finally submitted. I’ve noticed that you’ve got a choice of setting up a view with the controls that come with the OS, or writing your own. The former breaks immersion in the game in that you switch out to a completely different style of graphics, where as for doing your own in OpenGL..you have to make a lot of effort to get anything fairly simplistic in a user interface. Each game needs its own controls as well, so it’s far from a simple problem. And as OSes are updated then the chance of something you’ve written breaks. If you’re using the standard OS functions, then you’ve more chance they will carry on working.

There is additional problems on mobile devices is that the screen sizes will change, so you have to design the user interface so that it can adapt. The OS UI does this semi-automatically with the standard controls.

I’ve noticed that a lot of the PC games I have tends to put the controls into the corners, so as the resolution increases the controls merely get smaller and further apart. System Shock II is a good example of this. It must have been hell trying to support something like X-Wing or Tie-Fighter in multiple resolutions given the cockpit graphics and intrinsic displays, which is why they never bothered.

It would be better if there was a standard OpenGL standard library for these things like there are for the graphics shaders and the STL..but my hopes aren’t high…

No,but on mobiles you can change the size of the screen practically instantly.Just by rotating your phone,you change the screen significantly.Thats not something you encounter on computers and stationary consoles,where once you launch the game,the screen resolution remains constant practically until you exit.

Why do you need to write an OpenGL interface for ComicPress? It’s already got an interface, and as far as I can see in the screenshots.

I am not quite sure how other portable software handles the business of not having the Windows UI manager on other operating systems, but I’m pretty sure most software that isn’t a game is still using the OS’ own UI libraries, whichever theat may be. And while a custom OpenGL interface could potentially look flashier and be faster and better fitted for the purpose than the OS one, it would also look quite different from what the user of said OS already knows, so it might not be the perfect thing to do. See also the controversy about Blender’s UI not using standard OS dialogues and putting some people off with it.

The interface is tied to Windows, making it very very not portable. That’s not a deal-breaker. I mean, it works fine for ME.

Worse, some of the interface uses resource files. (The files that describe the layout of a dialog box.) I made these resource files in DevStudio 6, which I no longer have. Visual Studio 2010 express can’t edit or use these files, so the project can’t even compile unless I remove those dialogs and recreate them in some other way.

I was thinking that since I need to rebuild half the interface anyway just to get it to compile, I might as well move to something less Windows-centric. Maybe.

Isn’t there some kind of way to convert from DevStudio 6 to something more … open (in the sense that there’s more than one software that will be able to work with the format)? I’m almost sure you’re not the first person trying to take a project from an older windows version to a newer one.
I’ve actually no idea how other projects to this, but I always assumed that the OS-specific part of most user interfaces of portable software must be relatively thin. Then again, I might be very naive…

By the way: Do you remember the radial menus from Neverwinternights (or Realsoft 3D, if you know that)? I loved those. Think it’s easily the best way of implementing a context menu. If (in case!) you’re doing the interface yourself anyway, you could do that to your software! I’d love it*.
Ahh, the possibilities!**

*Not that I’ll ever use it, because I’m not making comics… :(
** ohh, the constraints…

Ugly: Well, that is a matter of taste, I’d say, and a matter of implementation. The ones in Realsoft 3D don’t look very great, the ones in Neverwinternights … well they look like thy typical slightly overdone game interface. Within the context of that game, I’m completely fine. Also, I wouldn’t call regular context menus “good-looking”, would you?

scale badly: One could argue that having context menus with 30 options is also not a nice thing. Also, there are ways of dealing with this: Group the options and have either sub-menus or a layered one, i.e. an outer circle with more options. Realsoft 3D does this, and it works.

no advantage: Wrong. If you click somewhere and the options are wherever your mouse pointer is, right around it, you have a shorter way to wherever you want to go. If the same options are alyways in the same place, you don’t even need to look anymore, the whole thing becomes a mouse gesture. This is impossible with traditional context menus. In a square menu you need to hit a spot with the mouse pointer, while in a radial menu you just need to go into the right direction, which is a lot faster.
I do not see how that is “no advantage”

“the devil incarnated”: Hmm… you’d need to prove the devil’s existence before you can defend that statement. Good luck. Also, they were always very nice to me. What have they done to you to make you say this?

Hard to implement: You have to take care that the menu works with any number of entries from one to a few dozens. Submenus will pop up where? on the outside of the first ring? Create a new ring? How do you navigate back? Sure, these issues can be solved, but they are far less trivial than in a rectangular menu.

Hard to implement part two: You must design icons. Our left-to-right writing works *very* poorly for radial menus. Can you remember thirty icons? Can you remember three hundred, when Photoshop and Office want to use it? Icons are quite expensive from a programmer’s point of view, because you either need to buy them, or spend way too much time painting them yourself.

Scale badly: You can’t just “add a line”, you have to completely redesign the whole thing. All your mouse-gestures are gone as soon as a few entries change, because all directions are now different. Anything past a dozen entries is impossible to do, and big submenus are hard to navigate (because you have to close the main menu while you browse it).

Adding an extra line to a normal menu is easy as pie. It requires no complex layout code, it always works, it can contain as many letters as you want, and it doesn’t need an icon.

Radial menus are good for demos, but complex to design, and nowhere easier to use.

You seem to assume that I want to replace every UI element ever with a radial menu. That’s of course a bad idea.
If you design a context menu with 300 entries, you’ve done something horribly wrong. So don’t complain if you can’t fit those in a radial menu. If whatever list of stuff you have doesn not fit into a radial menu, then maybe you shouldn’t use one. If you have 300 entries, then maybe you shouldn’t put them on a regular context menu either but try and organize them somehow…
This is of course a question of using the right tool for the right job, and not a “radial conquers all” thing. Be reasonable.

So far: I agree they’re hard to implement, but most of that is just because it’s not a standard element. Of course the designer needs to think about where to put things in order to be consistent, which is not as important if you have a list of items.

On the other hand: It’s wonderful to use if it’s done well.
Submenus may again require brain activity on the side of the developer, but I’m sure there are several standard solutions available for the standard problems in this regard. I think for example that NWN does the submenu thing very well. Navigating the same tree with regular item lists would take longer and require much more attention and time from the user.

Of course you do not need to design an icon for everything, who told you that? Aside the fact that many regular menu items these days do have icons, including the usual copy/cut/paste items in today’s context menus, but why would I not be able to read text in a radial menu?

In general, a regular menu structure (like your OS’s application menu, or any larger menu within an application) is easier to navigate if no level has more than 12 entries. For example, many applications will just create an entry on the base level of the windows start menu, which reults in a list that won’t even fit onto the screen in one piece — do you like finding anything in this type of menu? This becomes a big lot easier if they’re grouped into categories (graphics, games, office, bla…). Of course there are instances where it’s reasonable to have more than 12 items on one level, but as mentioned before, Radial is not for every menu in the world, I just see it as a very cool usability improvement, for context menus, from a user perspective.

I thought it was just “me” capitalized, but then I googled it and discovered that there’s some kind of programming keyword or something called “me,” and it has to do with C++, so I’m now completely unsure.

Open up the compiled .exe or .res file in Visual Studio’s Resource Editor mode. You now have the .rc source code for that dialog as well. (You’ll have to reconnect the numeric ids to their symbolic names, but this is relatively painless.)

(Related tip, since I keep being surprised by the number of people who haven’t noticed: go to File -> Open, and select a file but don’t double-click it. Now instead of clicking Open, notice that there’s a dropdown in there, and select Open With from that menu instead. Particularly handy for .exe files.)

I have to agree, as you say, GUI tends to be hard to make portable as it ends up being designed on top of the existing engine/project, it is usually integrated into, and relies upon, the existing code/libraries.

Your OpenGL reference is probably the epitome of library design, a bunch of loosely linked libraries utilising each either but allowing someone to plug in a new library to change, or extend, the functionality. But it has taken a long time, and continuous development, to get OpenGL to it’s current state.

To rebuild it bottom up to be a portable library would be a lot of work considering that you built it for an existing project to suit you own needs without thinking of re-portability. Only you can decide if that is worth your time, and the inevitable support that you will need to supply.

Considering your recent post about Kickstarter, and your loyal following, you might be better off doing a poll for how much people would like to pay for a version of your software and what language they would like it in, or usable with. Decide from that what you are willing to undertake, over how long a period, and then give people the option to pay for you to do it after you lay out the options?

It would at least help in the decision making about whether or not to spend time on it, and if enough people are seriously interested it could give you the incentive (and financial encouragement) to get on and do it.

Personally, it wouldn’t be of use to me, but I might still donate money. I’m sure you have a lot of followers that feel the same from the enjoyment that you have given us over the years :)

You know, it might even become a full-on software that people buy, if it’s good enough and solves a problem well that is really hard to do without having ten years of Adobe Photoshop experience. There are an astonishing number of pieces of software around which sell decently well for a small team to live off. Bingo Creator comes to mind.

I say it’s certainly worth investing a week or two into it and trying to get it into a presentable state. Kickstarter might be a decent plan. You’re also quite good at video stuff, and you’ve got more than just an idea, but a (theoretically) working prototype. Just be really careful about how you would word “It’s not in a state to be released”, or else people will understand “It’s finished, but I want money or else I’m not giving it to you guys, hahaha, I’m a blackmailer!” instead, and spend the rest of their days insulting you.

People who don’t write code for a living don’t realize how much work separates “academic example” from “a program that you can give to a customer”. There’s a huge 80/20 gap in between, where you need to account for people having no clue that you “just need to shift+control+rightclick to continue”, fix problems when the program is not running from your dev envinronment, but rather from “Program Files (X86)” and without admin rights, incompatibilities to Vista or drivers, and so on and so forth.

Well, manga studio does all that comic press does and much, much more, including drawing and effects. The non-professional version costs 50$, so comic press has to sell at a much lower price because of the vast difference in features.

There’s not really a comparison, having used Manga Studio – that program is *terrifying*! There’s a big difference between “can do” and “can do easily and consistently” – if ComicPress was easy to use and guided people towards consistent and high-quality results it would *absolutely* have a spot on the market, even at $50 (though you would probably get more bites at a lower price anyway, see iTunes/App Store)

RE: HTML: I’ve noticed a few games that use HTML formatted pages for menus. It seems like a good way to get the exact style and formatting to me. I mean, that’s what HTML is for right?

Something else I’ve wondered about: I see a lot of games that use linked PDFs for help pages (e.g. Total War: Shogun 2). PDFs can do forms too, can they not? How hard would it be to build a menu interface in Acrobat? That seems like it would be more scalable and more powerful than HTML.

The more I think about this the more it seems this is a pretty frequent problem for private coding projects:
I’ve done something, and it works for me, but it’s so messed up it’d be an offence giving it to anyone, but I can’t get around to cleaning it up / giving it a UI deserving of the name / remove some of the ugly tweaks that are fine for exactly my use case but will annoy everyone else …

If there was one relatively easy way to brush up just a small percentage of those abandoned hobby projects and make them do something useful, that’d be soo cool!

In Shamus’ case, I’d say that opensourcing it and putting it on Sourceforge or similar, as well as organizing two or three people here on the blog to help sort a few things out would likely give the world a really nice cartoon editor. But Shamus’ would have to part with the idea of making money on it. But then there’s open source companies making money alright, but that requires a little bit more thinking things over, making up business models… and back to the “I’ve no time for this” line :(
Sadly, leaving a piece of code to lie around somewhere doesn’t increase its chances of success either.

Have you ever heard of Immediate-Mode GUI, or IMGUI? It removes almost all the boiler plate code from the GUI: no need to setup the GUI first and then keep it up to date, no need to react to events to synchronize the UI state with the game step and vice-versa; you get hover and drag-and-drop almost for free; and the code is tiny. One drawback: you need to render the whole GUI each frame, which we usually have to do in a game anyway since the entire screen changes all the time.

Seems like he is describing how pretty much every game did input-handling for since the very beginning? You know, people did it that way for Pong and Pacman, and you do it differently for non-game GUIs for a reason: This becomes absolutely impossible to maintain when your GUI contains hundreds or thousands of context-specific buttons and elements. It only works when your input is tightly defined (e.g. “W is forward”).

If you do with for photoshop, you will have long times where the GUI freezes because it needs to wait for the computations, and that code-piece where the GUI happens will be tens of thousands of lines in a single function. Splitting stuff into dialogs and doing everything via event handling is better, not worse!

I faced this problem a couple of years ago, and *nearly* used PLib (http://plib.sourceforge.net/), which is great. Try and look past the dated web page! You can link it into your app and it is very unobtrusive: no need to change lots of other GL code to accommodate.

In my case, I had a pure C app, and I opted to try and implement a small OpenGL toolkit in C, rather than move to C++ (Actually I did experiment with moving to C++ but hated it. Mind you my toolchain was all GNU, no IDEs or anything, and the average compiler error was 5 terminals high).

If I ever returned to my game (a UFO clone) I’d either suck it up and move back to C++ or… well, that’s pretty much it I suppose. Or C# maybe. And either PLib or QT in the former case.

I read Shamus because of what he writes about and how he presents his views. Variously he rants, raves, decries and describes. I enjoy his work.

Personally I want him to write. Books and posts mostly. I want him to make enough money doing that so he can take a break now and then and present some new Project Frontier for our enjoyment and enlightenment.

I don’t want him to write in C, C++ or C#. English is what I like to read from Shamus. The rest is just icing on the cake.

I bought his books. My wife liked them as well. Okay, that is one more. Let’s keep them coming.

I can’t speak for low level C++ programming(haven’t had to try that since college), but my latest job required me to learn C# and Silverlight. Before that, I was using primarily VB6(supporting an old software package) with a few tools in VB.NET.

For me, the learning curve was not too bad, but I was working on Windows GUI, not OpenGL(and didn’t have to create anything from scratch for a few months). The majority of syntax and structure is somewhere between Java and C++(erring primarily on the side of C++ thank goodness). If nothing else, Lambda expressions are fascinating.

My understanding is also that Silverlight/WPF is Microsoft’s preferred interface tool going forward; they planned it to ease internationalization of programs (instead of fixed coordinates and hard coded values, screen objects are placed in containers relative to each other and can shift as the window is resized, the resolution changes, or the text changes; and data binding simplifies connecting your code to the interface(when it works right).

It’s amazing, but I’m trying to find a simple comic-making program that does much of what you seem to be showcasing in your screenshots, and such a thing just doesn’t exist. Everything is either high-end artist-oriented suites, or free junk that doesn’t allow for any customization whatsoever. Even the plug-ins for the major free/low-cost art programs are difficult to use and still rather limited.

If you ever got wanted to go ahead and re-implement this program so that it would compile- even if you left it tied to Windows- I’m pretty sure you would find a good market for a medium cost comic-maker with decent tools. (Seriously, nothing out there lets you change the angle and position of the dialogue-bubble tail.)