EventListenerId addEventListener(EventType eventType, const std::function<void(const EventPtr &)>);

Don't you need to use mem_function? I never could get the hang of that.

It looks like an interesting idea. Maybe there is some redundancy in my design then, because right now I have both widget messages and listeners.

edit this is what I have right now

void WidgetBase::RaiseEvent(WidgetMsg msg) {
   // signal your slots
   PrivateRaiseEvent(msg);
   
   // send event to listeners
   EagleEvent e = MakeEagleEvent(msg);
   EmitEvent(e);
   
   // tell our parent
   if (wparent) {
      wparent->QueueUserMessage(msg);
   }
}

No, and you're not doing anything all that original anyway. What you're doing is standard SWING design from java anyway. And yes I might like to reduce my messaging system to perhaps just listeners, and that would be completely within my rights to choose to do so. Stop implying that I just copy peoples work and ideas. It's pissing me off.

Why would he want to? You've been behaving like complete asshole for some time now.

Also you do not own ideas. You said yourself those ideas aren't original anyway. It is entirely his choice to "credit" you with helping him. Just as it's entirely your choice to be helpful or not. I'd say your general attitude robs you of any due credit though. It's clear you aren't helping to be helpful, but doing so in hopes of exploiting him for personal gain. Which is a really shitty attitude. You should just try to help to be helpful or GTFO. If he ends up developing a better library as a result of your discussion then great! Especially if he releases it open source so you can use it to. Nothing stops you from doing the same! Put your egos aside already. Jesus. You both suck or you'd have done this already.

I thought the whole point of collaboration was for both parties to benefit. :/

I do like your idea though. I think it would work well.

As far as me using it in my library goes, not likely. My QueueUserMessage system works just fine for now, and I see no point to refactor that too just yet. I need to just sit down and work on my layout managers and then start porting widgets. What should the default layout of a container be? An expander? Ie., it takes up the full space of the panel it is on?

I don't think a container should have a default layout. When building a hierarchy of containers, it is seldom that a default layout can be useful. In most instantiations of a container, a different layout is instantiated.

Making layouts be widgets makes the reuse of layout algorithms more difficult than they can be.

For example, a window frame does not have a specific layout. Forcing it to have a specific layout makes changing layouts of the frame more difficult thab it can be: you either have to subclass the window frame to change its layout or add a container to it with the desired layout, which means one more widget consuming resources unneccesserily (the window frame could have the layout the container has).

Plus ot hardcoding the layout on a widget makes the whole thing a lot more flexible, for example the orientation of a scroll bar could change by simply altering the layout of its root widget, whereas with hardcoded layout the scrollbar needs a different base class for each orientation.

Many many times. In the current game I work, I had to implement the layout system in that way, because the same problem kept coming up over and over.

Not really. It has increased the code reuse and simplified the code.

In the game I work, the scroll bar class I have created has an orientation property. If I set the orientation to horizontal, I also change the layout to horizontal, if I set the orientation to vertical, I change the layout to vertical.

Then subclasses of the scroll bar that implement the actual components can choose the actual graphics from the 'orientationChanged' event.

By having separate layouts, you can do that too. In my GUI library for the current game I work at, each widget has a pointer to a layout object, and layout objects can be shared with widgets. I have a set of functions that create horizontal boxes, vertical boxes, grid boxes, etc, and all these share the same layout instances. I also have layout instances that need parameters, and for these each widget has its own layout instance.

The advantages of separating layouts from widgets are:

• less widget instances. If a container has a hardcoded layout, then in order to change that layout you may add another widget to it with the appropriate layout.

  
  

• less subclassing. If a container has a hardcoded layout, then in order to change that layout you may subclass it.

  
  

• less resources. If layout instances can be shared across objects, then that means fewer application resources.

For example, suppose you have a button with a horizontal orientation, which puts a text and an image side by side.

Suppose the button's layout is hardcoded because it inherits from class HBox.

In order to reuse the button code with a vertical layout that puts the image above the text, you have the following options:

1) create a new instance of VBox, put it inside the button, then add the image and the text in the vbox.

2) subclass the button to modify its layout algorithm internally. Then you break the contract that the button inherits from HBox.

If the layout is not hardcoded in the button, then all you have to do is change its layout.

Furthermore, if layouts are separated from widgets, writing new layout classes is easier: in the new layout class you don't have to deal with all the details of widgets. If layouts are hardcoded in widgets, creating a new layout means creating a new widget instance, providing constructors (if needed) for the base class that have to deal with widget properties that are unrelated to the actual layout, etc.

Additionally, debugging code in which layouts are separated from widgets is easier: if you have a problem with layouts, then you simply look at the layout code. You don't have to deal with all the rest of the widget code.

If I may, one of the things that I find really helpful with design is putting implementation details aside and coming up with a stateless API. Which is to say, your base classes have no defined state (i.e., data). What methods must they have to get the job done, and what pieces of data and code (more interfaces, which is essentially also "data") need to be fed into them for them to accomplish their intended purpose?

Inheritance is a tricky tool to wield, but it will help a lot if you figure out the purely virtual interfaces for your objects. Your implementation classes (base classes and derived classes) won't inherit any state or code from your interface classes. The only thing the interface classes do is provide a defined way of interacting with an object whose state is completely abstract.

It is best if you can use your objects through these interfaces instead of directly through base or derived classes with known implementation details. Just a thought... I know that coming up with "interfaces" before implementations results in much better designs for me.

And in my case I have the advantage that a layout has all the background features of a widget, such as its outer and inner area as well as its background, margins and 9 patch area. You can give your layouts a border just as if they were a separate panel as well as a background, which are all drawn automatically when WidgetBase::Display is called which is auto called by the gui.

I think the main difference here is that I have something mostly working and all you have right now are design ideas. Last time I looked at algui all you had was component and container, and all they did was hold components.

Which is proprietary, and very unuseful to anyone like us. Do they ever plan on making it open source? Probably not, it's their moneymaker.

Obviously you have your own ideas and you don't care for anyone elses. Fine. That's why we have 10 different guis. I don't see myself abandoning what is already mostly working for something totally unwritten to work on a project with someone who refuses to see merit in any design other than his own. You want to be a project leader? Go ahead. But don't expect me to donate any of my time to your project.

And you have your design now, so why don't you go code it then. If it is so much simpler and easier to do it your way then you should be done in no time at all.

edit
And those are features common to almost every widget. A widget should be able to have a border or margins and a 9 patch background that resizes automatically as they do. And you can leave any or all of it blank and it will not be drawn. It's a feature, not bloat.