Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » GWEN UI Allegro5 port

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
GWEN UI Allegro5 port
Edgar Reynaldo
Major Reynaldo
May 2007
avatar

I think a widget container and a widget layout manager should still be separate. In my GUI, the container manages updates, input, and display, along with things like focus, hover, and z-order. If I used layout managers, the widget handler (container) would have a pointer to a layout manager. I think the two responsibilities should be kept separate. The container class does enough as it is already.

axilmar
Member #1,204
April 2001

That does not sound like an ideal solution. Maybe if each widget owned a layout manager, maybe, but that is still making the widget base class a container class, which IMO should be separate.

Actually, making the widget class a container class is the right thing to do. It simplifies the design tremendously.

Very few resources are actually saved by not making the base widget class a container. Suppose the average desktop application contains 1000 different widgets (overestimated by a large amount), and a container class has 16 bytes more than the non-container class, then the resources saved are 16000 bytes. 16K for a modern desktop computer is nothing. It's even nothing for the lamest of phone devices.

I may have misunderstood what you meant. Did you mean make a set of widgets that are also layout managers? Or did you mean make every widget a layout manager? The first option I can understand, but I thought you were talking about the second option, which seems wrong.

What I mean is this:

  • each widget has the necessary virtual methods to support layout management.

  • specific widget subclasses actually implement those virtual methods.


    I think a widget container and a widget layout manager should still be separate. In my GUI, the container manages updates, input, and display, along with things like focus, hover, and z-order. If I used layout managers, the widget handler (container) would have a pointer to a layout manager. I think the two responsibilities should be kept separate. The container class does enough as it is already.

    But adding a layout management interface to a widget is a very small thing to add to a class. By making layout managers separately, you complicate the API without needing it to be so.

For example, in Qt, you should not only put a widget inside another widget, but also add it to the layout manager of the parent widget.

Compare Qt's approach with mine: all you have to do is to add one widget in another.

Managing layouts on top of widgets adds a lot more complication that shouldn't be there. You have to carefully manage pointers from widgets to widgets, from widgets to layouts, from layouts to widgets and from widgets to layouts. The user of your API will have to make double the effort in constructing a GUI: he will have to put one widget inside the other, then instantiate layouts, put those layouts in widgets, then add the children widgets to those layouts. Having no separate layouts is a win-win both for the library designer and the library user.

If you want to see how I do layout, you can browse my gui's code in github. I'll be glad to answer any question you might have.

Oscar Giner
Member #2,207
April 2002
avatar

axilmar said:

each widget has the necessary virtual methods to support layout management.

specific widget subclasses actually implement those virtual methods.

Do you mean that each kind of container must fully implement layout management? How is that better than having layout classes that work with any container? If I, as a user, want to implement my own container, this means I must also implement layout management? And for containers already implemented, how can I add a different kind of layout?

CAn you show us a small example of your API, because I think I don't really understand what you mean? Just a main window, with a box layout and 6 buttons organized in a 3x2 grid, for example.

axilmar
Member #1,204
April 2001

Do you mean that each kind of container must fully implement layout management?

No. The base container class may implement no layout management, it can only provide the interface for derived classes.

Quote:

If I, as a user, want to implement my own container, this means I must also implement layout management?

No. You just create a derived class from the container widget of your choice.

Quote:

And for containers already implemented, how can I add a different kind of layout?

Create a derived class and override the appropriate methods.

Quote:

CAn you show us a small example of your API, because I think I don't really understand what you mean? Just a main window, with a box layout and 6 buttons organized in a 3x2 grid, for example.

Sure. I do not have an implementation yet in my current effort, but I did various GUI libraries in the past that did this:

Window *mainWindow = new Window();

//the grid widget is a child of main window
Grid *grid = new Grid(mainWindow, 3, 2);

//the buttons are children of the grid window
Button *button1 = new Button(grid, "button 1");
Button *button2 = new Button(grid, "button 2");
Button *button3 = new Button(grid, "button 3");
Button *button4 = new Button(grid, "button 4");
Button *button5 = new Button(grid, "button 5");
Button *button6 = new Button(grid, "button 6");

jmasterx
Member #11,410
October 2009

That's basically how my GUI works too:

agui::FlowLayout* layout = getGuiFactory().createFlowLayout();
getGui().add(layout);
agui::Button* button = getGuiFactory().createButton();
layout.add(button);
button->setMargins(5,5,5,5);
button->setSize(200,50);
button->setText("Hello");

The gui factory manages the memory, this makes it much easier to skin and deal with everything.

The FlowLayout inherits from Layout and Layout inherits from Widget. For my needs, this is perfect.

Oscar Giner
Member #2,207
April 2002
avatar

Ah, I see. So you have two different objects, first the mainWindow itself, and then the layout manager (Grid in this case). I first understood that the container (mainWindow) would also implement the layout management. So the only difference between this and Qt's way, is that in your case the layout classes also inherit from Widget.

This effectively makes everything easier to implement. The only drawback I see is that layouts now also get messages and must ignore and pass them up in the chain. Layout managers should not know about that.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

axilmar said:

Actually, making the widget class a container class is the right thing to do. It simplifies the design tremendously.

I would have to disagree. I would say that making widgets that are also containers is okay, but making every widget a container seems wrong. It doesn't lead to good separation of code, and it doesn't sound very OOP to me. It sounds like a messy monolithic class. I know that a lot of code goes into both the widget base and the container base, and I wouldn't want to combine the two.

It's not about saving resources in this case, but it is about separation of duties and code, and keeping code organized and logical.

Matthew Leverton
Supreme Loser
January 1999
avatar

Come to think of it, I think my hierarchy may go like: Object > Widget > Composite > Container. The composite class introduces children and a layout manager, while the container class exposes a public API to add children.

axilmar
Member #1,204
April 2001

It's not about saving resources in this case, but it is about separation of duties and code, and keeping code organized and logical.

Believe me, I've been there, I've created libraries and coded in libraries that have a separate container class from a widget class. The separation between container and widget complicates things ten times more than it need be, and you don't gain anything in reality, since the basic Widget class will need to have a Layout management interface anyway.

You don't even get more logical and organized code by this separation, because the base class Widget will have to have virtual methods that are about the container.

 1   2   3 


Go to: