There are many cases that you need a shared pointer to a widget. For example, a container widget contains a list of widget pointers, but your container subclass contains pointers to specific widgets that are also on the parent's widget list.

A crap load of virtual method calls is a code smell. You can design GUIs without such a code smell.

I don't think so, but perhaps there is a case I have not thought about. Do you have an example? (aside from win32 which imposes Objective-C style OOP onto C objects).

If you design your gui properly, you will never ever reach a state where you need a thousand different onMySpecificCallbackForThisFunction methods.

All you need is a dispatch-allegro-event method on your widgets. You certainly don't need messages.

Allegro is the abstraction layer.

You don't need that, since Allegro provides the abstraction.

Not needed.

If you define different event ids for other engines, then your abstraction has failed.

If you map the events of other systems to your events that look like Allegro events, then Allegro does exactly that. There is no need for code duplication.

Anyway, there is no need for this to go on. You clearly do not wish to make an effort to understand anything beyond your own design decisions, and I am sure you will respond to this in the way you did before, i.e. not understanding what I am saying, so simply forget it. It's just a waste of time.

I understand that, although there is no reason to do so.

Do you understand that if you adopt the Allegro 5 semantics then your effort is redundant and you might just use Allegro 5 as the backend?

And the event ids for SDL would be these?

No, there would most likely be an EAGLE_EVENT_TYPE GetEagleEventType(SDL_EVENT_ID); function.

No, not at all. I can either support the union of the two libraries event abilities or the superset and have some functionality disabled for specific backends.

Not if I want to drive the system with SDL for example, then Eagle would still be the abstraction layer. If I want to say win->DrawLine(x,y,x2,y2,EagleColor(0,0,255,125), 2.0); in my widget then the graphics context can either call allegro's draw line routine, or sdl's draw routine. It is no longer bound to allegro. This is the whole reason I abandoned my earlier gui engine was because it relied on Allegro 4. Now I could support Allegro 4 or 5 if I wanted to. The flexibility is what I wanted.

Well clearly all you can do is criticize and if you don't want to hear my responses then why do you ask me questions? Merely to state your opinion and ignore mine? Were there even any features of my gui that you thought were worth keeping?

Abstraction makes sense. The similarities to Allegro 5 cause minor alarm. It suggests that you lack a higher-level knowledge of the problem domain and are copying what you know. Which sort of defeats the purpose of abstraction. If you just duplicate Allegro then you'll at best accomplish nothing new and at worst duplicate the Allegro developers' mistakes. Additionally, you may find that it's difficult to implement backends for other libraries if they aren't structured similarly to Allegro. It could be that the other backend implementations are such major hacks that performance is atrocious and the backend is unusable. Which sort of defeats the purpose. I haven't looked into your implementation so I'm just taking axilmar's comments at face value, but I would suggest you aim to strive away from Allegro. Perhaps learn SDL or whatever. Familiarizing yourself with other planned backends will help you to recognize the common elements between them. You basically have to prioritize. You either want to make something backend independent or you want to build an Allegro GUI. You can always add the abstractions after. It is software for a reason.

The arguing is more or less what I expected. It is probably a necessary stage to work through. Like I said, everybody thinks that their shit doesn't stink, but everybody thinks that everybody else' shit does. If you want to collaborate then you have to make sacrifices. Accept that what you build together won't be perfect, and figure out what will be good enough. Try to learn from one another instead of trying to prove superiority over one another. Protip: You're all wrong. Now you get to explore how each of you is wrong, but at the same time, sometimes, each of you is a little bit right.

Allegro is far from perfect. A GUI doesn't have to be perfect to be useful. Make yourself willing to fail and you just might make something useful. You'll surely learn along the way, which will increase your chances of getting it perfect next time.

I'd say that it's a reasonable point to make, especially since Allegro is C.

Exactly. Well said.

I am fully in favor of abstraction. Who wouldn't be? It would be nice to have a new gui library that can be used with any graphical subsystem.

But that is a tremendously difficult task. wxWidgets and Qt probably have millions of man days of work behind them, and they do not take into account games. We should not fool ourselves that we are capable of going that route.

I have no problem with that, although C++ makes things so much easier and safer to the point that it makes using Objective-C redundant.

People swap car engines all the time... It's easier with software because the frame is far more malleable. In any case, you admit that your abstraction layer will probably need to change to accommodate other backends so that pretty much makes the current abstraction layer not really an abstraction at all, but a redundant layer.

Don't worry Edgar, a backend abstraction layer is a good thing

GWEN and guichan both used the abstraction layer method. It's just a generally good idea not to tie down to a specific backend. It would be like if Allegro tied itself down to OpenGL or Windows.