Is anyone interested in participating in an open source project for a GUI library? I am motivated by the lack of a simple GUI library, as it is mentioned in this thread. I've seen this request for a simple gui library before.

The desired features are:

1) native look and feel; it will use native Win32 widgets underneath and Qt or GTK on Linux.

2) cross-platform at source-code level.

3) simple; the APIs would be uniform and as less complicated as possible.

4) uses established C++ principles, i.e. the STL, boost::shared_ptr, boost::bind, boost::functional, virtual methods etc.; no message maps or macros

5) it will only be a GUI library; there would be no networking, threads, database, etc stuff.

6) uses unicode through out

First version will have a few widgets: label, image, button, check box, radio button, scroll bar, text box, combo box, list box, window, menu, menu item, file dialogs.

Future versions may have more complicated functionality, i.e. Multiple Document Interface, spin box, tree view, table view, drawing canvas, date and time picker, tabs, font and palette dialogs, printer and font support, open gl, drag and drop etc.

These things are difficult and time-consuming to code, but once a basic setup is there, I think it is enjoyable to code components.

So, is anyone interested?

Reading comprehension needs some work I think...

I've been thinking about dredging up my old brute-force assembler code for 486 which works just fine... I need it for my game. Never did have a drop-down list though, I'd want that for the available screen modes and saved games.

I've made a C GUI library that I use for my projects. It started off as a buttoned-menu manager but I decided to turn it into a full blown GUI. It's based on Allegro and uses no other APIs. But it currently lacks several important widgets (most notably text-entry widgets) and could do with being tidied up.

AE.

I think the decision to use threads or not is better left to the programmer. The point of my proposal is to only deal with GUI, nothing else.

It's not required for a GUI library to use threads. The basic execution flow of a GUI is: a) read events, b) dispatch events. If the user wants to use threads, that's fine.

Your comment would be valid 10 years ago, but nowadays it's not. All major compilers have a very nice STL implementation.

wstring is quite good. Win32 also has plenty of functions for unicode support.

Because not everyone needs X feature or Y feature. Someone may want to use pthreads, someone else win32 threads, etc. Why force anything on the programmers?

I've been gearing up to start on my own GUI and since you had mentioned earlier that you were working on one I thought about asking you about collaboration, however I can see that our overall desires for design would not work together at this time. Having a native look is not that important to me at this time, my GUI's idea of cross-platform is using Allegro while allowing customization by the user to the extent I am able to program in. I would like to achieve your 3rd goal of simplicity as well but I'll have to see how that goes. Regarding 4), boost seems like bloat to me, especially if it is just to manage memory. This can easily be taken care of with proper ownership. I agree with 5) but 6) seems like a feature I wouldn't have time for in the first version.

In any case, good luck and good coding.

Well, I'd like to keep it pure Allegro if possible to be useable as an add on package.
I plan on using C++ for inheritance, polymorphism, and possibly templates.
I'd like gui objects to be able to interact with user classes if possible, although I'm still working on figuring out a good way to do that. Perhaps user derived gui objects is the way to go although boost's signals and slots look interesting at a first glance.
I'd like gui objects to be able to interact with each other in at least a minimal way when chained behaviour is requested.

Really though, I'm still in the brainstorming phase. I started putting together some of the basic layout ideas but give me a few days to have a more concrete proposal of any kind.

Are you polling for interest because you want help designing it? Coding it? To know if it's worth your time?

You will be best off to just code the base and a few widgets yourself. Then build some sample applications and release it all. That's the only way you'll both get it working and get some help.

As soon as you introduce other people into the "brainstorming," you'll never come to a satisfactory design as everybody will want their own way because they are all programmers that could do it themselves if they had the ambition. But if you get something working, people will care less about the implementation details and more about getting more widgets done.

Hopefully that is your plan, because on the Internet it is unfortunately the only way things work.

a) I want help designing it.
b) I want to be motivated through the sharing of common goals.

The update method for a game GUI is different from the update method for an application GUI. For applications, the traditional method of putting paint events in a queue is adequate for most GUI cases. For games, it's not acceptable: the update method has to be mixed with the game graphics update method.

Hey, me too. I am fed up having to code a lot of lines of code just to do the most trivial tasks, i.e. change a variable etc.

What I've done in my latest project (using Qt 3.0.5) is to write connection objects between data models and widgets. Qt 3 does not support the Model-View-Controller paradigm, so I had to do this. It works exceptionally well.

Say, for example, that I want to edit an int variable. All I have to do is:

int var;
new LineEditConnection<int>(var, new QLineEdit(form));

The connection object connects the QLineEdit's signals with its own slots, knows how to convert a String to an int, and sets automatically the variable 'var' to the appropriate value.

I think this model of connecting things together with external classes is better than the Model-View-Controller paradigm, because it's much more flexible. With the MVC model, you are limited to what the author of the library thought is required. With this solution, you can connect anything to anything, provided that the necessary events/signals/callbacks/etc are provided.

Certainly not. All GUIs provide events; you have to create a good way of catching those events and connecting them to the appropriate handlers. The handlers themselves should contain all the necessary information to change the data as needed.

That's the best way to handle updates in a GUI. It also covers the case of a game GUI.

Ah, you are correct. My code example above shows how the widget changes the integer, but not how the integer changes the widget.

I intentionally omitted the part where the integer is not really an integer, but a Property<int> instance. The property has callbacks for when modified, and the connection object modifies the widget if the property's value is changed.

You only need a few primitives (model objects with 'change' callbacks, connection objects that connect the model objects with the widgets). You don't need callback types or anything else you mention.

You can do that sort of thing with boost::bind: you can bind any values to a function. It's very sophisticated, and a great deal of work to do on your own.

Talking with actual code is always easier:

In the above code:

1. when the variable 'data' is modified, the widget will change accordingly.

2. when the widget's content is modified, the data will change accordingly.

So now you have a perfect connection between the UI and the data, specified externally.

Because keeping the widgets independent from the model:

1. simplifies the development of the widget.

2. sometimes you don't want widgets to be connected to models.

Why re-invent the wheel? boost is there, it works out of the box.

Furthermore, I'd like to use:

1. shared pointers everywhere. No more memory management, even for widgets.

2. named arguments; it would be cool to be able to construct a widget with one line of code (e.g.: new Button(text="foo", click=bla bla, enabled=false))

From my experience, a GUI application is composed of 3 things:

1. the data model; the data of the app must be independent from the GUI, so as that multiple views of the data can be instantiated.

2. the UI; all the UI forms, windows, etc.

3. the controllers; the actual code that binds the other two together.

Good separation of concerns is the #1 quality of any good program.

I don't understand why you have the notification mechanism. Can you explain why you think it is more useful than signals and slots?

The data model should never tell anyone to redraw anything. That's the job of the connected views.

So, are you saying that, instead of connecting the widget to the model, the widget should be connected to something else, and this something else should actually modify the model?

Well, that's possible, as well, with signals and slots. In my example, the connection between the text box widget and the model is done externally: the text box does not know anything about the model, and vice versa. So, instead of connecting the model directly to the widget, you can connect something else to the widget.

I see no need for a messaging queue in either case.

Actually, adding boost to your project will simplify it: shared ptrs, bind, etc simply the development greatly.

Thank you very much for the discussion.

In case you have signals and slots, you don't need the local function. It's work can be done inside the slots.

That's why you use boost::bind for: to bind the required scope to the slots.

One problem with your mechanism is that you need a lot of event classes to represent all possible data changes, whereas with signals and slots you don't need those event classes, as the data are directly passed to the slots.

Nothing prevents you from not connecting a GUI to a model in the case of signals and slots. Suppose you have a modal dialog: you don't connect any widget to a model. The widgets change their contents, and when the user presses OK, then the data are transferred to the models.

There is one benefit from using a queue of events: the changes are there for anyone to see and process in their own pace.

There is also a drawback: the queue of events might contain multiple successive changes of the same widget, whereas only the last change is relevant.

The event queue can be simulated almost automatically by the signals and slots mechanism, if you connect widget signals to slots that put data in a queue.