Hello all.

Since Allegro 5 is almost upon us, and I'd like to learn it, and seeing that an A5 GUI library is often requested, I think it is a good opportunity to start a GUI library for it.

I'd like to do it in C++, but many here seem to be more comfortable with C. I wouldn't want to waste my time with something that doesn't cover people's needs, so, I'd like to ask you all:

Would you like a C or a C++ GUI library?

C. Allegro is a C library. I want a C GUI library !

Both. Reuse what you can, but provide an interface for both designed for the features of the language. Start with C because it's simpler and you'll be less likely to over-engineer it. Then you can come along after and see how C++ can improve it.

\o/

I FTFY.

C.

C for me, but don't listen to me or anyone else. For everyone who says C, there'll be someone else who says C++, and either way, that's not the point.
Make something that you find useful and release it for other people to use, and some people will use it. Some won't.
So draw your motivation from what works for you, not what works for "people". Otherwise you're setting yourself up to becoming demotivated by people not caring or not liking it.

This is absolutely true. Any project like this will only succeed if the developer(s) are doing it for themselves. As long as you open source it with a FLOSS-friendly license, people will take what they like from your project and fix it if it needs fixing.

Even if the only thing that your project does is motivate somebody to write a completely different library, it will have been worth it if it results in a good GUI library in the end.

People are buying EA games, although they're unplayable, literally. I highly doubt these guys don't know they're making shit, nor do I think they play it.

Yep, I'm trolling.

He's talking about Open Source, not commercial. Commercial software seems to work best when the developers hate their own product or something like that.

That's a little bit different: they do that for money, and it's most likely their day job. With FLOSS software, there's generally no monetary compensation for your effort, so you better be doing it because it provides value to you, or you won't get far.

This is axilmar we're talking about. The fact that this will happen is a foregone conclusion.

bambam, what's the point in encrypting a spoiler ? hmmmm ??

+1

Less likely that certain people that may take offense to it will stumble upon and read it.

Of course; don't hold your breath.

I see that most prefer C. For me, it's not that relevant; I am not gonna use any advanced C++ techniques anyway.

Doing so they do not get what they deserve for clicking on "reveal spoiler". That's defeating up the simple fact of having a spoiler button.

Go for the GUI !!

If you make yours work (and look) at least as good as the one Matthew showed in some youtube videos once, I vote for C as I might want to use it Otherwise i probably wouldn't use it anyway and then C++ would be fine.

Another vote for C... or at least for a C interface even if you code it in C++.

One vote for both! A4 had a brilliant GUI, definitely worth its price. I guess A5 won't have a GUI "of its own" like A4 had. So is there a need for a voting? Someone make a C GUI, someone make a C++ one.

Well, this is a Poll thread.

I'm sure we'll eventually have plenty of GUI addons/libs for Allegro 5 in both C and C++. Right now it seems there's already a few people working on GUIs given the number of GUI threads that have appeared recently.

They don't tend to get anywhere though. A good GUI is hard to do, especially one that fits in well with games.

I was going to suggest C++, but after some consideration I think it would be better to code it in C, because I think it may be easier to write a C++ wrapper for a C library than vice versa.

[EDIT]

Can someone point me to this video?

I prefer C++ as a language, but I vote for a C interface (whether or not it's written in C or C++).

The real question is Will we get a GUI library?

[edit]

So then what's wrong with that one?

Can you do a javascript port of it?

It's not ready yet.

Why don't you just help me port my C++ GUI library to Allegro 5? It's not quite ready yet, but give it a few(3-6?) months for the final touches / gui editor / documentation to be complete.

Note to axilmar : It all started here...

Anyway, I vote for C++.

The reason that allegro 4's GUI sucked was because they tried to cram every single different kind of gui object into one single struct. The result was that if your widget had any data then it had to be global, and this meant that if you wanted more than one of that widget then you had to write multiple gui functions. Also, it was really difficult to make the widgets interact with each other without any kind of a message system. Say you wanted slider2 to have the inverse value of slider1, that forces you to use a callback in slider1 that resets the value of slider2, which means they have to be global, which means more clutter and so on...

I honestly don't think you can write a good GUI for Allegro in C. I dare all you C zealots to prove me wrong.

Besides, C++ offers inheritance, function redefinition , function overloading , destructors , the STL , so on...

Is qt still around -- did they make much money? That might be a fun project for iOS.

Qt is indeed still around. Its the basis now for Nokia's products. Its the toolkit for Moblin, and has been ported to S70 after nokia bought out Trolltech.

Additionally Qt 4 has a Windows, OSX and X port.

I'm not a C zealot, so I guess I don't qualify. My GUI is (was?) an adventure in implementing OOP concepts in C, and actually works quite well.

The main annoyance was lack of function overloading. I played around with using variable argument lists as a replacement for that, but it only gets you so far.

Of course it would be much easier to use C++, but it's not a requirement in terms of writing a GUI that's easy to use and extend.

Define "good".
I mean, if I write in C, then a C++ GUI is almost by definition going to be rubbish, because I write in C. Also, compare

and

Clearly, not everyone has the same criterion for whether something is "good" or not. I could write a GUI addon for Allegro 5 that I would consider to be good and useful (but I'm not going to). I'm sure you'd hate it.

False. That's why you got data pointers to work with. Yeah, I know, it's a hassle. Could be done though.

It's a feature, not a hassle.

What features / structure does it have?

How is it extensible? A4 let you write you own dialog process, but that is faulty because you can only store so much data in a DIALOG. That makes you resort to global data and replication of code just to use a dialog process as an object.

Easy to use, easy to extend, and is interactive. A4 was easy to use if all you needed was a static data return, but extending it becomes problematic, and it is not easily interactive.

I don't hate C, but I don't see C having the proper features necessary for a truly useful GUI. Also, valid C is generally valid C++. There's no reason you can't rename your .c files to .cpp and use g++ instead of gcc.

Only because it would be lacking all the useful features that C++ has to offer. Nothing personal.

Well, I guess you're right about this. You can always use a void* to a custom struct, but if you want anything to be interactive, then your data has to be global so the callback functions can access it.

I like GTK a lot and it's all done in pure C as well. I just wouldn't want to use it in a game as it's hard to completely theme it for a game - and without theming looks out of place in things like KDE or Windows or OSX.

It uses struct inheritance and provides functions for easily extending and copying vtables. Anything that extends ALGUI_OBJECT can be used with algui_add(widget, x, y), etc.

Since Allegro 5 itself is in C, it seems clear to me that any Allegro 5 GUI should be C as well; regardless of any perceived advantages of C++.

Not if you're using C99, which any sane C coder is using these days.

That custom struct can contain any pointers to any data you want, globals are no more needed in C than they are in C++.

In my Allegro 5 GUI (written in C) I used event passing to implement inheritance. I thought it was pretty easy to extend. Here's an example of what would be involved into making a button with some custom fields of your own:

It's about as many lines as you'd use for a C++ extension too. And using events isn't the only option either (I did it because I wanted to map it to A5's event system naturally).

EDIT:

This too.

See, we're probably not going to agree on "good". I found A4's GUI very easy to extend to the things I needed. Not sure what you mean by "easily interactive", but that too is fairly easy. Especially given that you can use a custom do_dialog(), or call update_dialog() from within your update loop.

Didn't say you hated C, just said that if I write in C, a C++ addon isn't all that useful to me. I could have picked Pascal, FORTRAN or Perl as alternative examples.
And to be clear, I generally use C (for hobby projects anyway), but I use C++ occasionally.

Not always though.

Yeah there is: I don't want to. Certainly not if the only reason is to use some addon and I don't have any more "intrinsic" reason for wanting to use C++.

I know. Just saying that almost a-priori you won't find a C GUI addon "good", so setting anyone the challenge of writing a "good GUI addon in C" seems rather pointless.

A lot of C++'s features can be simulated with little effort using C alone. The automatic features, like RAII, obviously aren't supported, but there are various options.

For example, I personally just name "methods" type_method_name and pass type * as the first argument. I give "overloads" names with single character differences, similar to printf, sprintf, snprintf, etc. It's not quite as convenient, but it works well too, and I'm sure valid arguments could be made either way.

The pureness and simpleness of C can be refreshing now and then. I have no doubt that a powerful GUI library can be developed in pure C, but one would have to be careful to avoid bad practices that many C developers seem to take too lightly (i.e., global state).

Erm, ever saw a Java application not using lots of singletons? I think C programmers are no more or maybe even less likely to abuse global state than others.

Don't get me started on Java programmers. Java programmers are probably worse because they somehow think that a Singleton isn't global state, but that doesn't make C programmers' use of globals any more OK.

Let's say there is a button process that has a callback for when the button is pressed. That callback needs access to whatever data there is that you want it to affect, and that means it has to be global. Maybe globals aren't needed in C, but A4's gui forces you to use them.

No, it doesn't. See my earlier comment about using the data pointers in the dialog struct. Simply pass it on to the callback function.

As I said, it really doesn't.

The point is, using a callback sucks. Sure you can pass a pointer to a callback, but then the process using that callback is bound to that data type and if you ever want it to do something different you have to rewrite your process to fit a different callback.

Having a widget queue a message is immensely easier to respond to and hook up to a specific action. This is one of the major shortcomings of the allegro gui.

Someone should try hooking up A5 to libRocket or something similar.

Disclaimer: I've haven't even downloaded it yet.

Do it in si senior...I mean C, senior.

If there's anything worse than C++ it gotta be CSS

That's not your original argument for why you think it's bad, which as I pointed out isn't a valid argument.
See? You think its bad and make up the justification as you go along.

Debatable. Using a callback with the A4 GUI has never bothered me, for instance. It's all very subjective.
That said, I would use Allegro's message system if I were writing a GUI for Allegro 5 from scratch.

http://www.allegro.cc/forums/thread/606282/901627#target

No mention of how fast/slow the parser is though...

Let's take d_slider_proc for example. It has a void () (void* dp3 , int d2) callback that gets called when the slider value changes. You can use the dp3 void* as a pointer to your custom struct that holds all the information the callback function should use. Taking the time to bind all the necessary information to that struct takes more time and takes more work to access than using global data in the first place. So I stand by what I said. A4's gui encourages use of global data. Sure you can get around it, but it's easier not to.

Not really. Take a look at this old source file that uses A4's gui. It's ugly, uses lots of callbacks and global data. If I wanted to, I could update it not to use global data, but it would still be ugly.

All of that behaviour could have been easily prevented by making a slider widget that queues a value_changed message.

if (wmsg == WidgetMsg(&slider1 , TOPIC_SLIDER , SLIDER_VALUE_CHANGED)) {
   do_whatever_I_want_now();
}

If someone does decide to make a C GUI for Allegro 5, please don't base it off of A4's gui, for the sake of your users.

It's always "easier" to use a global in the sense that you don't need to worry about argument passing or casting or anything (if you want to be really evil you don't even need to worry about defining a data type). You just go right after the data. It's bad practice to though because it's error prone and limits code reuse. In C, accepting a void * is a very common way to pass any arbitrary data into an API. Not using it is your fault; not the API. Again, it's not easier, but it's more correct, less error prone, and overall cleaner than using a global. If you want easier then you shouldn't be using C (nor C++) in the first place. Any kind of messaging or event system will pretty much need to resort to the same thing to pass arbitrary data around; unless it doesn't pass any data around and just assumes the message or event loop already has that data, but then that could require globals for some applications.

An Allegro 5 GUI has the added complication of integrating multiple displays. It's a serious challenge.

BamBam... bambam... you need to try using more globals. All this void* cast with struct type identifier overhead workaround is more error prone than a single global.

A widget messaging system has no need to pass any data around at all. You get the message from the widget, decide what to do based on which widget and what message it is, and then you do it. It makes it far easier to deal with an action locally as opposed to globally or wasting your time binding a 1000 different sets of data into 1000 different structs and having a custom callback function for each of your 1000 different structs.

Fixed X 2.

What would probably make the most sense, is not having any fancyness in the api at all. You would be required to call the event pump function for the gui, as well as the drawing function, every loop, and pass in the display to draw to, etc.

Possibly. Depends on whether you intend to re-use that function or not. If you do, best not to touch global data!

That's again debatable, but it's not what you said earlier where you claimed you "have to use global data".

It's ok, you don't like the A4 GUI. You don't have to either, and you don't have to rationalise it as far as I'm concerned. If you do though, at least keep your arguments consistent.

That piece of code looks pretty obscure to me though!

Not even for the sake of those who like the A4 GUI? But don't worry, I'm sure that eventually different people will make different GUI addons since there's clearly room for different approaches here.
As I already said earlier, using A5's event system to interact with the GUI makes the most sense to me if you're designing the GUI from scratch. That's actually not orthogonal to basing the GUI on Allegro 4's GUI though.
Also, to get back to an earlier point in the discussion, it doesn't require C++ either (Allegro 5's event system is C, afterall).

My approach is very simple (already implemented): the GUI does not have a global state; all the state of the GUI is kept into the widgets, so one can run many widget trees at the same time and in parallel.

Fair enough.

Yeah well, consider me proven wrong. SiegeLord's and Matthew Leverton's designs seem reasonable enough to me. Still, using a this pointer seems rather archaic now that I use C++.

EDIT: seem to have somehow double posted with half an hour in between...

That's because you're travelling quicker than the light, Evert.

I've added a gui project to github, if anyone is interested.

The example program doesn't actually seem to show me any GUI widgets. I don't know if it's because my Makefile is doing something wrong or if I'm just not using the program properly. Should it be drawing something? What platform(s) have you tried it on? Or is it just an empty shell right now that needs to be filled in?

Try pressing keys 1, 2 or 3.

OK, now I see. Thanks.

For what it's worth, my GUI also uses the algui_ prefix. I don't really care at all if you use the same, but I won't be changing mine if I ever do release it.

I was wondering about that. I just wasn't going to be the one to say anything.

Matthew Leverton, release it. Set it free. Let it roam free and be with it's own kind... Let it go. Let it grow.

I'm making a C++ GUI lib with the following features.
Editor, save and load XML layouts.
Skinning, code your own rendering routines or customize data for existing routines.
Event queue, widgets put events in a queue and lets you handle them where you want.
Layout, container widgets that handle size and position of their children.
Clipboard, copy text between your application and the rest of your OS.

And possibly more coming. Of course, even this basic list of features are under rather slow development since I have a full time coding jorb and is very tired in the evenings.

I named the project SWAG.

For now, the example program is the testing ground for the new features. It currently tests drawing, widget tree management, focus and layout management.

I will change it then, but in the future.

A Finnish stand-up commedian pointed out that in Finland you're allowed to have sex at 16. And you're allowed to look at hard core porn at 18. So if a couple of 16 year olds are filming their act, they're allowed to look at the film only after two years.

<edit>
I nominate this thread for the derail category of Allegro '11 Awards.

It would be nice to have a few official A5 GUI libraries to choose from...
But I guess GUI libraries is just another 'touchy' topic.

It's not important that a GUI lib has a good set of gadgets. It's important that it's easy to write your own gadgets. If they are easy to create, then there will anyway automatically be a set of them in the first place, made by the creator of the GUI.

And a good C++ lib is better than a lousy C lib, whereas a good C lib is better than a lousy C++ lib.

Killed me.. So true, in Israel and many many other countries- it's the same.. However, I wonder how it goes if they film it, if they're allowed to and, or.. ? Kinda it's obvious that port would not be allowed to be sold cos' the actors have to be over 18 as well, but if they shot it(didn't look at it for 2 years), why the hell can't they sell it afterwards?!

P.S:
I add me "+1" to the nomination of this thread to Allegro '11 derail rewards..

So now we have four candidates working to create the best GUI for Allegro!

Which are:

axilmar: from Athens, Greece, 10 Years in the community. His web page has 50.000 visits per day.

Edgar Reynaldo: from Vermont, United States 4 Years in the community. Very well known by his game on the depot entitled: "This member has no projects listed".

Matthew Leverton: from Illinois, United States 12 years in the community. Many people say he was the original inventor of Tetris.

Trezker: from Sweden, 10 Years in the community. Very well known for selling his "Map and terrain generator" to Google to create, Google Earth.

So who you think is going to come up with the best GUI lib for this beautiful librarie? do your bets now!

Hey, just because I don't have anything in the Depot doesn't mean I don't have anything done with Allegro. See my ShadedShapes preview. The program that generated those images has been fully functional for several years, I just haven't released it yet.

Hey! if it isn't in the depot doesn't count!! and btw that Shaded Shapes looks like the computer was smoking weed!

I was just kidding man...

Nobody now that you've made it a competition. Thanks a fucking lot!

I bet the Americans will get there first.

That's a remake.

As for the award, it's only February.

No they're not. Production, possession and distribution of pornography depicting actors under 18 is illegal. Technically they're allowed to watch it (the law doesn't forbid watching nor acquiring) but they aren't allowed to store the film for the time in between filming and watching and need to destroy the material immediately afterwards.

derailment++;

Every adult website requires you to agree you're 18 years old or over. I agree they either shouldn't have the right to film it, and/or store and surely not redistribute, but they actually can't even watch it either.. o0

derailment--; //That's the new topic now!

Who said anything about adult websites? The EULA of pornotube.com != finnish law.

But I suppose it's the same thing anyways.

Guys, I've updated my gui lib to support events and drag and drop. You can find it here:

https://github.com/axilmar/algui

@aximilar:

Don't off-top in the off-topic forum!

My apologies!!!

And so, in the time honoured tradition of not getting a GUI done, this thread has now started talking about making porn movies. Oh well. At least it didn't end in a big argument like this attempt.

AE.

PS. I vote C

Perhaps you did not notice, but I started another thread about my gui library here:

http://www.allegro.cc/forums/thread/606344/

No, you're wrong, it did end in a big argument! How could you be so wrong about this fact!?

So wait, what's going on here? So do we have a GUI yet?

cause I need a gui for my programme its due in 24 hours or I'll fail the class I got in an accident and i need the gui cause i have to make crysis and it has to use variables...

... lots of them

Don't worry robots. I'll always be around to talk dirty in all these GUI threads...

i vote for C

Oh, sure, here you go.

int writeGame() {
  System* system = System::getInstance();
  User* user = system->getUser();
  user->goFsck(user);
  return 0;
}

See what happens when you program in C++?

Edit: Oh, and I vote C.