Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Poll: Allegro 5 GUI in C or C++?

Credits go to AMCerasoli, Andrei Ellman, bamccaig, Dizzy Egg, Dustin Dettmer, Edgar Reynaldo, Elias, Evert, GullRaDriel, jhuuskon, Johan Halmén, Karadoc ~~, kenmasters1976, Mark Oates, Matthew Leverton, Michael Faerber, Neil Walker, Peter Wang, Ron Novy, SiegeLord, Thomas Fjellstrom, Tobias Dammers, Trezker, and type568 for helping out!
This thread is locked; no one can reply to it. rss feed Print
 1   2   3   4 
Poll: Allegro 5 GUI in C or C++?
Edgar Reynaldo
Member #8,592
May 2007
avatar

axilmar said:

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

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...

Dustin Dettmer
Member #3,935
October 2003
avatar

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

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

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.

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.

Evert
Member #794
November 2000
avatar

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.

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

A4 had a brilliant GUI

and

allegro 4's GUI sucked

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.

Quote:

The result was that if your widget had any data then it had to be global

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

GullRaDriel
Member #3,861
September 2003
avatar

Evert said:

Yeah, I know, it's a hassle

It's a feature, not a hassle.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Edgar Reynaldo
Member #8,592
May 2007
avatar

My GUI is (was?) an adventure in implementing OOP concepts in C, and actually works quite well.

What features / structure does it have?

Matthew Leverton said:

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.

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.

Evert said:

Define "good".

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.

Evert said:

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

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.

Evert said:

I'm sure you'd hate it.

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

Evert said:

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

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.

Elias
Member #358
May 2000

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.

--
"Either help out or stop whining" - Evert

Matthew Leverton
Supreme Loser
January 1999
avatar

How is it extensible?

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.

Karadoc ~~
Member #2,749
September 2002
avatar

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++.

-----------

SiegeLord
Member #7,827
October 2006
avatar

Also, valid C is generally valid C++.

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

Quote:

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.

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:

#SelectExpand
1int my_button_proc(WZ_WIDGET* wgt, ALLEGRO_EVENT* event) 2{ 3 return wz_button_proc(wgt, event); 4} 5 6typedef struct 7{ 8 WZ_BUTTON button; 9 int my_data; 10} MY_BUTTON; 11 12BUTTON* create_my_button(WZ_WIDGET* parent, float x, float y, float w, float h, ALLEGRO_USTR* text, int own, int id) 13{ 14 MY_BUTTON* button = malloc(sizeof(MY_BUTTON)); 15 wz_init_button(button, parent, x, y, w, h, text, own, id); 16 button->my_data = 0; 17 ((WZ_WIDGET*)button)->proc = &my_button_proc; 18 return button; 19}

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:

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++.

This too.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Evert
Member #794
November 2000
avatar

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.

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.

Quote:

I don't hate C, but I don't see C having the proper features necessary for a truly useful GUI.

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.

Quote:

Also, valid C is generally valid C++.

Not always though.

Quote:

There's no reason you can't rename your .c files to .cpp and use g++ instead of gcc.

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++.

Quote:

Nothing personal.

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.

bamccaig
Member #7,536
July 2006
avatar

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).

Elias
Member #358
May 2000

bamccaig said:

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.

--
"Either help out or stop whining" - Evert

bamccaig
Member #7,536
July 2006
avatar

Elias said:

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. :P

Edgar Reynaldo
Member #8,592
May 2007
avatar

SiegeLord said:

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

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.

Evert
Member #794
November 2000
avatar

That callback needs access to whatever data there is that you want it to affect, and that means it has to be global.

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.

Quote:

Maybe globals aren't needed in C, but A4's gui forces you to use them.

As I said, it really doesn't.

Edgar Reynaldo
Member #8,592
May 2007
avatar

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.

Peter Wang
Member #23
April 2000

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

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

Dizzy Egg
Member #10,824
March 2009
avatar

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

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

Elias
Member #358
May 2000

libRocket

Quote:

libRocket is the C++ user interface middleware package based on the HTML and CSS standards.

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

--
"Either help out or stop whining" - Evert

Evert
Member #794
November 2000
avatar

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.

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. :P

Quote:

Having a widget queue a message is immensely easier to respond to and hook up to a specific action.

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.

Neil Walker
Member #210
April 2000
avatar

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

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

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

Edgar Reynaldo
Member #8,592
May 2007
avatar

Evert said:

That's not your original argument for why you think it's bad, which as I pointed out isn't a valid argument.

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.

Evert said:

See? You think its bad and make up the justification as you go along.

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.

bamccaig
Member #7,536
July 2006
avatar

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.

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. :P 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. :P 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. :P

#SelectExpand
1#include <stdio.h> 2#include <stdlib.h> 3 4struct Foo 5{ 6 int x; 7 int y; 8}; 9 10struct Bar 11{ 12 int x; 13 int y; 14 int z; 15}; 16 17void * teh_callback(void * arg) 18{ 19 struct Foo * foo = (struct Foo *)arg; 20 21 // Do whatever I want now with my Foo. 22 23 struct Bar * bar = malloc(sizeof(struct Bar)); 24 25 if(!bar) 26 return 0; 27 28 bar->x = foo->x; 29 bar->y = foo->y; 30 bar->z = 15; 31 32 return bar; 33} 34 35int main(int argc, char * argv[]) 36{ 37 struct Foo foo = {5, 10}; 38 struct Bar * bar = 0; 39 40 bar = teh_callback(&foo); 41 42 if(bar) 43 { 44 printf("{x:%d, y:%d, z:%d}\n", bar->x, bar->y, bar->z); 45 46 free(bar); 47 } 48 49 return 0; 50}

 1   2   3   4 


Go to: