Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » A question for Steve Terry, Miran, Spellcaster and other GUI people!

This thread is locked; no one can reply to it. rss feed Print
A question for Steve Terry, Miran, Spellcaster and other GUI people!
Richard Phipps
Member #1,632
November 2001
avatar

Unfortunately I think you are right Miran. It's just making a GUI from scratch when you've not made one before seems rather daunting..:-/

spellcaster
Member #1,493
September 2001
avatar

IronBob said:

not only is allegro's gui limiting. but its down-right ugly.

You're free to change the drawing routine to anything you like.

Quote:

Yeah, LexGUI is just an extension of the default Allegro GUI (as far as I can see all the widgets are "derived" from the default ones and they only "overload" the MSG_DRAW message)...

Yup. I tried to reuse most of the code. But some of the functionality is not changeable easily (without duplicating most of the code, and then changing small parts of it) so this project died ... more or less.

Quote:

I've used a lot of Java Swing and only a very brief peppering of Win32 code, but I do know that I love Java Swing.

AT my last job, my main job was designing Java widget sets. Some of them where close to Swing, some others were not that close to swing and employing some other (strange) libs like HAVI.
I also did a lot of work with swing.

And yes, I think the swing design is neat.

Quote:

Using plain C how would you do a GUI system? Or would you simply modify allegro's? (That question is for everyone else too..)

Allegro's main drawback is the missing container hierarchy. It's theone that will you bite sooner or later in the gluteus maximus.

So, I'd start from scratch.
And if I had to do it in C, I'd simulate C++ by giving each struct a VTABLE, and accessing functions only via that table.

But that's not very clever way (IMO), since you#re doing work others have done already for you (the g++ team) and chances are good that they did do a better job :)
So, I'd suggest that you use C++ instead.

While you can do everything C++ can do with C, doing it with C will normally be more easy :)
Also, if you know how to pull these kind of stunts in C, you can code C++ already... and if you don't know how to do these stunts, explaining it wil take longer than migrating from C to C++.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

IronBob
Member #3,248
February 2003
avatar

Quote:

You're free to change the drawing routine to anything you like.

if i plan to ever use the allegro gui i most likely will.

spellcaster
Member #1,493
September 2001
avatar

And the fun thing is: it's quite easy to do :)
With a few lines of code, the gui will really look nice (or let's say: way nicer)

In combination with DLG, the gui can cut your delevopment time (so use it for tools, but avoid it for games - or at least use it with care :))

--
There are no stupid questions, but there are a lot of inquisitive idiots.

Richard Phipps
Member #1,632
November 2001
avatar

It's frustrating when you know your skills can't match your vision for a program. :-/ Is a vtable a list of function pointers?

Too much I don't know.. Oh well, probably still going to try anyway! ;D

spellcaster
Member #1,493
September 2001
avatar

Learn C++.
Will look good in your CV, and it's always fun to learn something new ;)

--
There are no stupid questions, but there are a lot of inquisitive idiots.

Richard Phipps
Member #1,632
November 2001
avatar

Richard casts "BAH!" spell on Spellcaster for +4 damage.

Spellcaster casts "newbie" on Richard for +8 confusion.

Confused Richard says:
"Don't want to learn no yucking C++ ::)"

Richard goes to bed!

spellcaster
Member #1,493
September 2001
avatar

Um.. Pauls mailed me some pretty good texts on OO in C, I'm quite sure he can mail them to you as well.

But I still think it would be better to have a look at C++.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

miran
Member #2,407
June 2002

Go to [url http://www.bruceeckel.com/] and order/download some books. I especially recommend Thinking in C++ (both volumes)...

--
sig used to be here

Steve Terry
Member #1,989
March 2002
avatar

But Spellcaster's LexGUI is just an extension of the Allegro GUI, nothing more, mine was based off of LexGUI but took it a step further by adding DRS support, mouse extensions, font extensions, non-blocking procedures, etc. The Allegro GUI way of doing things isn't neccessarily bad, though it has bugs (i.e. Double clicking is horribly implimented and fails in most cases, try holding the mouse button down and quicky pressing again.. that should NOT be a double click :P)

[edit]
May I ask how it would be possible to allow for container functionality using my GUI, I never thought about containers or knew about them until this thread popped up. I could just call another proc from within a proc like teh allegro GUI does, but you'd have to have special handlign of overlapping portions, etc.
[/edit]

___________________________________
[ Facebook ]
Microsoft is not the Borg collective. The Borg collective has got proper networking. - planetspace.de
Bill Gates is in fact Shawn Hargreaves' ßî+çh. - Gideon Weems

spellcaster
Member #1,493
September 2001
avatar

At first, you'd have to implement something like a relative coordinate system.

Then you'll need functions to translate between the systems, and also functions to clip rects (imagine the case when a child is partly outside its parent container).

Then you need to ensure that no widget can draw outside it's visible area. If everything worked in step one and two, this should not be that problematic.

I had a look at the changes needed and decided that it's not worth the effort.

If I ever start something similar again, I would start from scratch.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

Steve Terry
Member #1,989
March 2002
avatar

Yeah I know what you mean, at least dialog boxes are separate containers in my GUI, nothing can draw outside of them because they are separate bitmaps. The relative system I have going though is kind of a hack, the structure takes absolute coordinates, i.e. dialog.x is 100, button1.x is 120, and teh button appears 20 pixels inside of teh dialog box, however when a proc goes to draw itself it must translate it's position relative to the dilaog box position since it's drawing to it's bitmap surface. This surface can be clipped to inside of it's borders as well so that when you resize the sides overlap it's contents. Maybe what we need is a simple base system to base GUI's off of, something that allows for flexibility than the allegro GUI, and to build off of that. Either way though, I've come too far with my GUI to back down... I'll see how far I can take this thing before I can absolutely go no further :D

___________________________________
[ Facebook ]
Microsoft is not the Borg collective. The Borg collective has got proper networking. - planetspace.de
Bill Gates is in fact Shawn Hargreaves' ßî+çh. - Gideon Weems

Richard Phipps
Member #1,632
November 2001
avatar

Sounds like everyone's pretty much agreed that rather than adapting the existing allegro GUI I should write a new one..

Curses!
You Fiends! Do you know how long that will take me ?! ;) hehe..

:P

spellcaster
Member #1,493
September 2001
avatar

depends what you want.
If you really want a full fledged gui, yep, writing a new one would be the way to go.

You should start by listing all widgets / features you want. Depending on this list it migh be possible to use allegro's GUI functions as a framework.

If you take a look at "Plastic Animation Paper" for example, or at some other programs like the old spaint from crack dot com... something like this could be done easily using allegro as backbone.

It's always a question of what you need :)

--
There are no stupid questions, but there are a lot of inquisitive idiots.

Steve Terry
Member #1,989
March 2002
avatar

Just for teh curious and for Richard, I copied and pasted much of my programs nas_do_dialog and nas_update_player from teh allegro source, but since it's already separated from Allegro it should be easier to customize to your own needs. Which means I need to start rewriting sections of it myself, but at least I have it set up so I can do so.

___________________________________
[ Facebook ]
Microsoft is not the Borg collective. The Borg collective has got proper networking. - planetspace.de
Bill Gates is in fact Shawn Hargreaves' ßî+çh. - Gideon Weems

axilmar
Member #1,204
April 2001

It's difficult to write a good GUI. Not that the main functionalities are difficult to implement, but there are a lot of things involved:

1) events should be queued. It's frustrating to click buttons but the GUI ignores them because it did something else than polling events at that time.

2) geometry management. A hot subject. If you look at commercial stuff, you will see lots of code for it. But, in a good gui, the programmer shall not position widgets at absolute positions.

3) skinning. Ok, that's fairly easy. But it involves careful planning of what resources each widget needs.

4) the Allegro does not have a paint origin: every coordinate passed in a drawing function is relative to 0, 0. But widgets need to draw into themselves, using their topleft corner as 0, 0.

5) drag-n-drop. Sooner or later, you will need widgets to talk between themselves and negotiate data transfers.

6) clipboard. Nuff-said. What GUI program is useful without a clipboard ?

7) Basic widgets like buttons are very easy to implement. But the most interesting widgets take big amounts of effort to get it right: trees, toolbars, grids, tables, etc. And you need to have toolbars in a modern gui. Have you ever wondered why Allegro carefully avoids more complex widgets ?

8) file associations. File dialogs need to know this as well as the icons for each registered file type.

9) text output. Allegro routines can't draw partial strings, and you need to make some hacking in order to properly display text.

10) a good GUI needs truetype fonts. Allegro does not have true type fonts. Although Alfont is an excellent library, it does not have routines for drawing underlined "&" characters. More hacking here.

11) the event model: how to raise windows when their controls are clicked. Windows knows when a window is toplevel, and it is raised automatically by the system when a child is clicked. But that is not valid in your gui, since you want to make a general purpose gui lib. So you have to come up with a system where events are bubbled up or propagated down...but its one has its own problems.

12) keyboard management: keyboard shortcuts, hot keys, etc. When pressing alt, Allegro gives you a number from 1 to 26 for each English letter. But that does not tell you what the character was, so good luck with implementing hot keys (not that it can't be done, though).

13) there is a long list of complementary classes that you need to code in order to make a gui. Take trees for example: widgets are trees, and tree items within a tree view are also trees. So, you need a template class that implements trees. You also need smart pointers and reference counting for managing resources (skin objects shared by widgets, for example). You also need to make your own string class that manages Allegro unicode strings. And don't forget those template classes for signals with 0, 1, 2 or more parameters.

14) how about an IDE ? it is really boring to write guis by hand. But then your classes would need reflection, i.e. to have the ability to manage widgets without knowing the class: just by using a predefined interface. IDEs are written that way. But good reflection can take ages to write, for each widget class.

15) you would also need a mouse cursor factory, since you can't have one bitmap for all video modes. That means routines for remapping bitmaps from one color depth to another, taking care of the mask pixel values (blit does not do that, does it ?). You should also code a routine that draws bitmaps disabled, i.e. with raised or sunken outline.

16) you need to make a smart architecture about the application's actions, since many elements will call the same action. For example, the save menu command shall be disabled when the document is already saved; but the toolbar save icon should also be disabled in such a case. These two must be linked somehow, otherwise the programmer will have to explicitely disable all related resources.

I've done more than 50 tries to write a good gui. I've written a Window system (Mx-Windows, if you are interested), but after finding how region clipping works, the rest was easy. But a gui toolkit..., that's a completely different thing. I've bitten myself too many times, thinking I've got a great design, then started adding virtual functions all over the place, only to come up with a mess, which I delete afterwards.

And since a GUI can be so large, either be prepared for a long development time, or get your friends to help you.

(Or we could just assemble a team of coders: I could write the basic functionality (from group feedback, of course), the most basic classes, then each one of the group, including me, we would implement one or two widgets. For example, if we had 10 programmers, we could easily have 50 widgets in two weeks time: each programmer would make 5 widgets in two weeks.)

I think a proper fully-fledged GUI is the most difficult thing to write. That's why so few toolkits got it right: Qt, Swing, Photon (maybe there are other good things out there, I don't know all). But the fact is that most gui libs are limited or flawed.

Richard Phipps
Member #1,632
November 2001
avatar

Thanks for that post. I'm going to give your comments added value since you wrote mx-windows. :)

If you've wrote many GUI attempts, then have you decided which design works best of all? Or is there no such thing?

I can see how a GUI is going to be a lot of work. It's unfortunate as the Allegro GUI just isn't good enough for me. I'm also not sure about adapting any existing GUI library after some of the earlier suggestions in this thread to start from scratch..

Hmmm...

Thomas Fjellstrom
Member #476
June 2000
avatar

mx-windows just plain rocks. I started writing a themeable widget set onto of (a slightly modified/extended) mx-windows, and since mx-windows can do shaped windows, you get shaped themed windows :D

really nice if you ask me.

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

axilmar
Member #1,204
April 2001

Quote:

If you've wrote many GUI attempts, then have you decided which design works best of all? Or is there no such thing?

I can't really say which approach works best. When writting a small library like MxWindows, it is quite easy to stay focused. But a full gui library, I don't know...If I knew, I would have made one, wouldn't I ? ;D

Quote:

I can see how a GUI is going to be a lot of work.

This is solvable: we need cooperation.

Quote:

It's unfortunate as the Allegro GUI just isn't good enough for me.

And for me, also. I imagine for many others, as well.

So, guys, Richard, Thomas, Steve Terry, Miran, Spellcaster, I have a question for you: why don't we join forces and produce the Allegro's ultimate GUI ? we can have a short period discussing the main issues, then each one of us can take the responsibility for producing a number of widgets. Since widgets are independent of each other, each one of us can take his/her own time and do as good as job as needed. I can make the framework classes for you to get started with!!!

Thomas Fjellstrom
Member #476
June 2000
avatar

This would be awesome. For tools and stuff. But Could it be usefull as a generic gui for in game stuff? Maybe config and what not.. Yo know? if the framework is good enough this could seriously rock.

also, Hopefully this'll work. But some widgets will take longer than others ;)

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

Steve Terry
Member #1,989
March 2002
avatar

I'm up for it though I think something like this has been attempted before without much success.. a lot of discussion but after that it just died. I know we need cooperation and determination with team effort to even get this thing off the ground and that's if everyone else you mentioned agrees with your statement. We need to decide on how the individual components will be divided up and who will take which tasks etc as well as the language we're going to base this on.. I'm for C since I'm adept with it and it's the language allegro is based on. If you go C++ that's fine but it will lose all possiblility of being integrated into allegro if it's good enough doing away with the hideous GUI forever :D

___________________________________
[ Facebook ]
Microsoft is not the Borg collective. The Borg collective has got proper networking. - planetspace.de
Bill Gates is in fact Shawn Hargreaves' ßî+çh. - Gideon Weems

spellcaster
Member #1,493
September 2001
avatar

I see a couple of problems. First one would be the C vs C++ discussion.

If you ask me, we should go for c++.
I doubt the allegro gui will still be part of allegro for v5, anyway.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

Thomas Fjellstrom
Member #476
June 2000
avatar

Even though, I prefer C, C++ probably is a better option. IMO.

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

spellcaster
Member #1,493
September 2001
avatar

If we use C, we have to implement all the OO stuff ourselfs, so why not use the OO mechanism C++ provides already?

Virtual functions and polymorphism is what makes GUI development easy. Without it, you'll run into problems sooner or later.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

axilmar
Member #1,204
April 2001

I think you are all positive to the idea of making a gui for Allegro. That's a good start. Of course, there is going to be a lot of disagreements, but we can solve them the democratic way: by voting. The minority would have to accept the majority's decision. Of course, any thesis should be backed up by the proper arguments, shouldn't it ?

So, let me present you with my opinion on the programming language: I think C++ is the way to go, for the following reasons:

1) Allegro 5 will not have an intergrated gui.

2) A proper gui lib would be twice as large as Allegro itself. I don't think the main library should be that fat.

3) C++ offers object oriented mechanisms, like encapsulation and polymorphism and inheritance. These features will have to be emulated in plain C, which is a tedious task.

So, for me, the proper language is C++.

Do we agree on C++ ?



Go to: