That's not the point. The point is if my ideas are implemented anywhere, and yes, they are implemented.

Actually I am not refusing to see merit on your design, I am simply rejecting it in favor of a better design. My design has more advantages than yours, plainly and simply, in this area (in another area your design might have more advantages than mine, and so I'd choose your design over mine).

I've already done it for my job, I am too tired and bored to go ahead and write another gui toolkit on my own.

Nope. Only some widgets have those features, not all widgets.

EDIT:

Your problem is your ego, actually: you think that your choices are the best, without sitting down and thinking about if they are truly the best.

And no, I do not have the same problem, because what I do is present a list of arguments that support my design, compare them to the list of arguments for your design and find my design better.

And I am admitting that this concerns only specific parts of a GUI library that I have experience on.

If you come up with a better design, then I'd gladly adopt it, something you will not do.

And thus 10 different gui libraries for allegro are born.

Your system is nearly complete? You don't even have a single widget yet.

If you don't want to cooperate, that's just fine with me. But don't you ever again say why do we have so many different guis.

There's valuable discussion going on here, let's not get derailed.
Finish the design doc and everybody can implement what parts they want and/or keep their own projects.

I don't think either of you guys has explained in enough in detail why your layout management system is
(better, easier, more flexible) than the other guys.
I'd be amazed if this hasn't been discussed ad-nauseum somewhere else.
How about a link to some other gui layout system that works similarly to what you want to implement.

Meanwhile discuss an interface for the layout system and come back to the details later:
widget->setOrientation(int type);
anything else

Meanwhile let's move on.

Returning to the design doc:
============================
Question about this:
“proper clipping; ignore widgets that do not intersect with the clipping rectangle defined by the hierarchy of widgets.”
-you mean ignore rendering of widgets outside parent clip boundary or input also?
-to be clear you're talking about view-clipping and not tracking changes/damage to gui.

widget-rendering:
============================
Requested Features:
-ability to override/disable rendering for a widget (without sub-classing?), without affecting child widgets. Children will be rendered normally.

-separate processing gui layout from the actual rendering.
I should be able to let the GUI do everything (layout+input management) for me and
I can still draw all the widgets myself if I so choose.

-widget->RenderOver : eg: over-hanging tabs

-widget->RenderUnder: eg: drop-shadows

Let's discuss render-backend:
============================
Support multiple render methods:
Eg:
1. SimpleRender – painter's algorithm (Render widgets back to front).
CONS: Slow
PROS: easy to implement when:
a) adding a new back-end (this is phase #1)
b) performance doesn't matter
c) no support for buffering (legacy / embedded / low-memory / )
2. CacheRender -
TODO: We haven't discussed tracking damages/changes for redrawing widgets
How to handle transparency/translucency?

-do you need to query what features are available?
-allow switching between render methods?

Should this be a class/interface?

Oh, ok, I didn't see any widget code in the svn repository.

Well, if your system is nearly complete, then you don't need any help, do you? the discussion is pointless then, when it comes to a unified Allegro gui system.

Well, ok. I work full time anyway, so if you complete your library, kudos to you. As I said earlier, I am too bored to do it alone.

I didn't speak for a complete rewrite, of course, if we were to start over we'd bring the good parts of Eagle5 onto this library.

Edit: by the way, there are lots of other libraries we could use. For example:

http://sourceforge.net/projects/my-gui/?source=directory

Another nicer one:

http://static.cegui.org.uk/docs/current/

Edit2: wow, CEGUI is complex!!! why do they make such software...a gui library is a simple concept, it need not be so complex!!!

A GUI is complex. You can certainly limit the scope of it, but you will be limiting its functionality. That will make it more suitable for some purposes, and less suitable for others. You need to fully define what purposes it should be suitable for to do that. "Games" is not defined.

This reminds me a lot of an open source game called Wesnoth I contribute to. They started replacing their GUI system about 5 years ago because their original GUI code was just hacked together.

However despite a lot of continuous work on it the new GUI (called GUI2) still is nowhere near done and they are not using it yet. The source looks like this: ^[1]

I sometimes wonder if they will ever get to use it. I'm pretty sure they originally thought it would at most take a year or so to implement a simple GUI. And theirs also is designed specifically for one single game with no intention to ever use it for something else, so something much easier than a general one...

My goal with my library is to provide the ease of gui programming with Java inside a C++ environment. And to make better built in layout managers than what Java provides, because they lack a lot of features. The one feature that they totally needed was a pin layout, where you specify coordinates from 0 to 1 and widths from 0 to 1. All relative to the container they are in. Or how FlowLayout needs a vertical alignment component, and how you need to be able to have empty places in a GridLayout without using invisible widgets. That sucks.

What is a good compiler to aim to support now? mingw32-gcc 4.7 and 4.8 support -std=c++11 and -std=gnu++11 and the latest version of mingw binaries for allegro is 4.7. To be honest I never really learned all the new features of C++ 11.

I think I would find it handy at least. And it is simple enough to provide it anyway. And my GridLayout is going to support per cell horizontal and vertical alignment. As well as allowing cells to span multiple columns or rows like Java's GridBagLayout.

Why not use CSS for layout?

Complicated or not: wouldn't a CSS layout manager just be another layout container widget?

What? Managing an invisible widget for the sake of alignment? That sounds like having to use invisible widgets as placeholders in Java's GridLayout. That sounds like a bad idea.

Why not just give it a cell x,y,w, and h?

It's a great idea. You can create very complex guis very easily, even with one liners.

Actually, it's not an idea, it's the way DFUW's J2F framework works. It has an existing implementation.

Because a cell is redundant in this case.

Imagine having a grid of 10000x10 items, for example: if you have one cell object per cell, then you'll have 100,000 objects.

And if you think that 10000x10 is a rare case, it is not. Many games need that, to present long lists of items (market, leaderboards, achievements, etc).

That's exactly what I am talking about.

In DFUW's new GUI system, the position and sizes of widgets is never specified. It's always computed automatically from the layouts.

For example, the chat window of DFUW is made entirely out of layouts:

http://www.youtube.com/watch?v=jU4ulaqYZfA

Take a minute to watch the video, it's pretty interesting: the chat window contains several popups, one of them being the chat options, which is quite complex: it has radio buttons, check boxes, labels, text boxes with custom backgrounds, accept and reject buttons, a dynamic list box, a scroll bar etc.

It's all made with layouts.

And if you play Darkfall and you switch languages, the chat window and its popups all automatically adjust themselves to the size of the fonts used in other languages.