I made this with Eagle and Allegro 5.
EDIT
Updated demo. Now you can resize and move everything thanks to my WidgetMover class. Wrote it yesterday, ironed the bugs out today.
Download here : Demo2.7z
Everything is done with the mouse. LMB selects. MMB drag scrolls (only the inner window). Hover over different areas to see which widget is in focus, and to see the layering effects. Hover over the border to see the icon change to a grabby hand to move the widget on LMB press, and hover over the margin to see the resize icons.
{"name":"611953","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/1\/117cf8015c51eb6108ba16240442bd18.png","w":1202,"h":941,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/1\/117cf8015c51eb6108ba16240442bd18"}
{"name":"611956","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/a\/8ad6c44d2aff28ab0c43292981e7ac0f.png","w":1202,"h":941,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/a\/8ad6c44d2aff28ab0c43292981e7ac0f"}
Cleaned up the example code.
Widgets follow the CSS Box model, with a margin, border, and padding surrounding the inner client area. In the left picture, the margin is blue, the border is green, and the padding is red, so you can see it more easily. The right picture looks much better without the coloring though.
Support for attributes is built in.
Eventually I think styling with CSS and scripting with XML will be implemented. That seems to be the direction I'm heading anyway.
...scripting with XML...
{"name":"tenor.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/3\/6392f3acb985a4c0d29c37ba48ad2eed.gif","w":418,"h":234,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/3\/6392f3acb985a4c0d29c37ba48ad2eed"}
I assume you mean layout/content in XML. Scripting in XML, like as in programming in XML, would just be silly. 
Thank you for the correction but don't you have any thing to say about the rest of it?
All that I can really say is that you've done a lot of work on this, and that's great. You should keep it up. I have no immediate need for it, and I think that the learning curve would be quite steep for somebody that did. Also, I think that like most non-trivial software it has some design flaws, but that's to be expected. You should be proud of it and you should continue working on it. I think that a video demo would have been much more informative than still screenshots. My intention is not at all to diminish the work that you have done, and that is why my previous post was so narrow in its scope. I don't have a lot more to say on the rest of it.
The only other thing that I can add is that this sort of redundancy drives me crazy:
if (!bg || (bg && !bg->Valid())) {
If !bg failed then bg is implied. When I see this sort of construct I am left to wonder if the author made a mistake because they're repeating themselves, and it's pointless. Of course, we all make mistakes. It's just a pet-peeve because colleagues do this regularly. This can be simplified to:
if (!bg || !bg->Valid()) {
Or, depending on style, though it doesn't aid in keystrokes and generally I don't find that it aides in readability either, you could transform it into this...
if (!(bg && bg->Valid())) {
Perhaps in this case it helps, but it's highly subjective. I appreciate languages that have an unless statement, or at least a more visual/readable not keyword so the operation isn't as easy to overlook. Particularly as our eyes age.
The only other thing that I can add is that this sort of redundancy drives me crazy:
if (!bg || (bg && !bg->Valid())) {
Ah, yes, you're correct.
I like your second version the best :
if (!(bg && bg->Valid())) {
All that I can really say is that you've done a lot of work on this, and that's great. You should keep it up. I have no immediate need for it, and I think that the learning curve would be quite steep for somebody that did. Also, I think that like most non-trivial software it has some design flaws, but that's to be expected. You should be proud of it and you should continue working on it. I think that a video demo would have been much more informative than still screenshots. My intention is not at all to diminish the work that you have done, and that is why my previous post was so narrow in its scope. I don't have a lot more to say on the rest of it.
Steep learning curve? Perhaps, but there will be full documentation by the time I release it, as well as small tutorials, and a widget creation guide.
Design flaws? What would you change? Or what would you support that I'm not?
I will take your advice about a video demo. I've never recorded video on my laptop before, so that will be an adventure. It's much easier to demonstrate it if you run the example program though, which is why I linked to it.
Design flaws? What would you change? Or what would you support that I'm not?
I can't say there necessarily are any. I certainly am not familiar enough with it to know them. I think that the flaws will reveal themselves when you try to develop a separate backend for it.
I can't say there necessarily are any. I certainly am not familiar enough with it to know them. I think that the flaws will reveal themselves when you try to develop a separate backend for it.
Quite right, again. I originally developed Eagle for Allegro 4, and then decided I no longer wanted to be tied down to a single library, as well as reach a larger audience. So I made the abstraction layer, and implemented a driver for Allegro 5. Most of the system and everything is just modeled around Allegro 5 anyway, so when I write the SDL2 driver, I will probably need to refactor everything once more. But for that I would need someone versed in SDL, as I have zero experience with it. I could help them write the driver, but wouldn't know how specific code would have to be implemented.
Anyway, it's growing, and evolving. I'm in a feature freeze right now, for the most part unless there's something really important I'm missing. So that means writing docs and test programs and debugging.
Thank you bambams, for the helpful insight. Appreciated. 
