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!
miran
Member #2,407
June 2002

First of all, sorry for being late in this discussion. A project like this is a good idea and I would love to work on it. I've been working on my lib for a long long time now and I put a lot of hours in it so it will be kind of hard to just drop it. But then again after reading axilmar's post I realized what a crappy piece of shit it really is so I guess it wouldn't be that hard after all...

About the language: C++ is the way to go. Personally I don't see any reason why we should try to make a pure C library that could be integrated in Allegro or something. And doing a standalone GUI lib in C makes no sense to me...

About the features: Allegro is a game programming library. Making an add-on library for Allegro that is not focused on making games is pointless and we should take that into consideration. But making a GUI for a game is quite different than making a GUI for a tool. First of all the library must be completely skinnable which is not as easy as it may seem at first. Secondly the lib must support things like animated widgets and mouse cursors, transparency, non-rectangular widgets, etc. Also the GUI must work with various different screen update methods. Most GUIs (mine included) use a dirty rectangle system based on memory double buffering while most games will want to use page flipping or triple buffering. Also OpenGL for 3D games must be supported natively...

About the last little argument on widgets: There are two extreme positions one can take in making a widget set. Either you can make just a few very general widgets each with countless flags and properties or you can make a separate widget for every little difference in functionallity. Naturally when using OOP one should lean more to the second aproach although in some cases this could be open to discussion...

--
sig used to be here

X-G
Member #856
December 2000
avatar

One has to be pragmatical though ... having one class for InsetBevelFrame and one for OutsetBevelFrame is ridiculous - it's unnecessary, counter-intuitive, and blocks fast switching between styles if it ever becomes actual.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

Richard Phipps
Member #1,632
November 2001
avatar

Umm.. if people do want to make this library then they better agree now to use C or C++ and whether it's going to be a general GUI library or designed for games.

It may be that people won't be able to agree on these issues. Maybe we will have two different GUI libraries?

:o

23yrold3yrold
Member #1,134
March 2001
avatar

I don't think a C library would be impossible. Maybe make one first, then port to the other? Starting with C++ would probably be good then ...

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

spellcaster
Member #1,493
September 2001
avatar

Quote:

I feel no distinction should be made between togglebuttons and regular buttons - "togglable" should be a flag. They both share the same behaviour, and I don't feel such a small change warrants a widget of its own.

That's fine for me. I just thought that using the toggle button as the base for radio buttons and checkboxes might be a good idea.

Quote:

I'm not sure what you mean with "formatted input field" - if you mean richtext, then yes, it should be its own. If you just mean "format masked", then it should probably be a part of the textbox.

Not sure here. A formated input field allows you to pass an input mask, say "###.###.###.###" for an IP address, and similar things. The non-special chars (the dots in this example" will not be part of entered text, but will be displayed statically within it.
I could agree on that a single-line-text-input (phew) and the formated text input should be the same, but since you also said already that you want multi-line text and single line text to be the same widget...

Also, using different widgets doesn't require you to duplicate code. Good class hierarchy and / or using utility classes allows you to reuse the code.

Quote:

What would the different between a Panel and a Frame be?

A panel is mainly a rectangular area. It's more or less the most primitive widget there is.

A frame would have all the nice things title bars, resizing controls, etc.

Quote:

And, as mentioned, the dialogs might as well not be widgets of their own ...

While they might be no widgets, common dialogs are still something we're going to need.

Quote:

About the features: Allegro is a game programming library. Making an add-on library for Allegro that is not focused on making games is pointless and we should take that into consideration.

I disagree here. Allegro is more than just a game coding lib. It's a multimedia lib. The main reasons there are not many tools using it, is the lack of a gui :)

Quote:

First of all the library must be completely skinnable which is not as easy as it may seem at first.

True.

This is another part of the list we should start:
General requirements.

One problem I have with your list is transparency (as long as it refers to more than the magic-pink trans), since it's not well supported by allegro.

Regarding the screen update: I assume it will render to any context you provide, and use dirty rect system internally as well.

So, you could tell all your base widgets (say a list of buttons, on the bottom, a map in the center right and a floating window) to update itself.
They will redraw them self (according to input they got, and a list of dirty rects you may have passed to them) and add the changed areas to a dirty rect list.
You can then simply blit the context, or use the list to blit only the dirty areas.

Again, this is just my view of it, once again pretty close to the way java is doing this stuff.

Quote:

Also OpenGL for 3D games must be supported natively...

In this case, I'd say you should team-up with Korval, who should have something like this ready already :) (sorry, couldn't resist)

Regarding the upcoming lang discussion again:
I think we can do the general planning now without thinking too much about the lang.
Once we know what we want, it will be more easy to find the best way to do it :)

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

Steve Terry
Member #1,989
March 2002
avatar

I agree with spellcaster here as well, we should just generalize out what we need and get some simple structured outlines going, after that we'll get a better idea on what language we should do the GUI in. Unfortunately for me though I'm moving in a month and do not know how much free time I may have after that, let alone the amount of free time I have at the moment since I'm busy transfering jobs, traveling, filling out apps, etc. I like the slots and sockets approach, callbacks have issues and cause extra code that could be done with a simple pointer from one widget to another. It's a brilliant concept (I read up on it a bit :D), and doesn't look like it'll be that hard to do in either language, though most of what I've read about explicity mentioned OOP as the requirement. This is an excellent discussion and I think we've all learned much from it, now if we can all band together with our differences aside and actually make something that works and looks promising. I know it'll definately take longer than a year to complete this, but it'll take determination and team effort.

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

Spellcaster, I agree with you. Although my widget list was a bit long, it was just a list of requirements. I disagree with you about the Window though: you need resizable widgets with a caption that can be moved around with the mouse. When I talked about Windows, I meant 'window frames': caption, icon, close button, minimize button, maximize button, etc. If that's what you meant, then we are on the same track.

The following quote is the most important one heard in this discussion:

Quote:

Allegro is more than just a game coding lib. It's a multimedia lib. The main reasons there are not many tools using it, is the lack of a gui.

If Allegro is to take off, it needs a decent GUI library. Every game development environment is accompanied with a suite of tools that ease game development. Without the tools, a developer has to go through the path of making the tools first. That's a big 'no' for most of us, because what we want is to make games, not tools. We get easily bored, and that's why there are so many abandoned projects. The usual counter-argument is that 'there is no one size-fits-all', and that's true. But, if every developer has to develop his/her own tools, why should he/she create a gui lib first ? at least the gui should be 'standard', in the sense that it is available right from the start.

As for the game gui, I disagree: how many games need a combo box, for example ? most games need a simple menu-driven with input boxes and buttons gui, not a gui toolkit. If one plans to make gui-driven games, like a strategy game, that means that most probably he/she does not need 60 FPS and the game can hapilly live within the space of gui toolkit.

X-G
Member #856
December 2000
avatar

There's another issue, though: Should such a GUI library really use Allegro, or is it better to write tools in GUI systems intended for more general use, such as Qt, GTK+ or wxWindows? Is an Allegro GUI as we know it now just a weak "emulation" of a proper GUI that can never be as good as a "proper" system?

As for game GUI's: Netcrux requires a fairly complex GUI system, including combo boxes and lists (for the configuration menus), and it needs a fairly high FPS - not necessarily at the time one uses the GUI, but still. Also, have a look at games like Neverwinter Nights - fairly sophisticated GUI, high frame rates.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

spellcaster
Member #1,493
September 2001
avatar

Quote:

I disagree with you about the Window though: you need resizable widgets with a caption that can be moved around with the mouse.

Um, yep. But a window has neither a border nor a title. At least not in the common GUI terminolgy.
Think win32, motif, xlib: every widget is a "window".
In X, you need a window manager to provide the frame (caption and resizing) for top-level windows, in win32 you can specify that you want to add a frame, and in Swing Windows and Frames are different classes.

If speaking in patterns, the frame "decorates" the window, allowing to resize, move, etc. whatever is in it's content area.

Quote:

Should such a GUI library really use Allegro, or is it better to write tools in GUI systems intended for more general use, such as Qt, GTK+ or wxWindows?

Should one really code games with allegro, or is it better to use OpenGL / DirectX or SLD / ClanLib?

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

axilmar
Member #1,204
April 2001

Quote:

Um, yep. But a window has neither a border nor a title. At least not in the common GUI terminolgy.

Well, anyway, I meant a frame. The essence is not in nitpicking, is it ? Let's make a gui library, guys!!!

Quote:

or is it better to write tools in GUI systems intended for more general use, such as Qt, GTK+ or wxWindows?

WxWindows is not very C++ style because it uses message maps to map methods to messages. That's the primary reason I dislike it.

I don't know GTK.

Qt is fine, but on Windows you need a commercial licence to use anything beyond version 2.1. So either the tool must be limited to 2.1 capabilities or someone must have a Qt 3.1 licence.

Furthermore, there is a need for an intergration layer with Allegro. I don't remember by heart, but Qt widgets don't give access to the window handle. Even if they did, the intergration layer would be specific to each window system: different code for win32 ,for X, etc. I am assuming here that the tool would use Allegro somehow to draw stuff within a window, manage bitmaps, etc.

One of the advantages of Allegro is that it is multiplatform: the same code compiles under Windows, Linux, Mac, BeOS and a lot of other platforms. Having a thin gui library which exploits this multiplatform capability would be a great asset. Writing Allegro tools using allegro would be great, since there would be no intergration problems.

Quote:

not necessarily at the time one uses the GUI, but still. Also, have a look at games like Neverwinter Nights - fairly sophisticated GUI, high frame rates.

Sorry, I haven't played Neverwinter Nights. Would you care to explain what complex GUI interaction it has while the game is running ?

Anyway, the problem of the update method can be easily solved: each widget should have one or more flags that tell how the widget is changed. Is it resized ? is it dirty ? etc. Now, when it is time to update the screen, the widget tree is updated using the above-mentioned flags, and then drawn onto the game buffer bitmap. In applications, widgets are drawn only when they need to directly to the screen. In games, the programmer shall have the capability to install a back buffer, i.e. a bitmap to use while drawing the widgets.

X-G
Member #856
December 2000
avatar

I see spellcaster missed my point. I was just asking if I was the only one who felt a bit uncomfortable at the thought of a GUI running inside a graphical window, which does not support normal interaction with outside windows (think drag and drop) and generally has a completely different look and feel than the rest (and in some cases, reacts much more slowly - Allegro's mouse is, for instance, much slower than the Windows one on my computer)?

Quote:

Could you care to explain what complex GUI interaction it has while the game is running ?

Lists, text input, drag-n-drop, IIRC there were checkboxes and combo boxes, popup menus.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

Steve Terry
Member #1,989
March 2002
avatar

I'm kinda confused about the slots and sockets approach though, wouldn't you still need callbacks for specific function calls, whereas slots and sockets are excellent for tieing two or more widgets together?

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

X-G
Member #856
December 2000
avatar

Yes, you would. Signals and slots are just for connecting widget actions togther - such as what should happen when something is clicked, etc. The alternative is overriding a function - things like onPaint() fall into this category, because they're not really something signals and slots are supposed to be used for.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

spellcaster
Member #1,493
September 2001
avatar

Quote:

I see spellcaster missed my point.

I'm quite good in point missing :)

Quote:

I was just asking if I was the only one who felt a bit uncomfortable at the thought of a GUI running inside a graphical window, which does not support normal interaction with outside windows (think drag and drop)

You can support d&d nicely while running within an allegro window. All you ahve to do is to add some win32 calls.

Quote:

and generally has a completely different look and feel than the rest (and in some cases, reacts much more slowly - Allegro's mouse is, for instance, much slower than the Windows one on my computer)?

The mouse problem should not be there in windowed modes, and I've reported the problem with the mouse almost one year ago.

Regarding the look: "hip" applications (video/audio apps in particular) seem to use a pretty non standard gui anyway.

And still, Music Maker, Bryce, Poser, Painter, eJay, etc. sell well.
It all depends on the market. And if you're going to use the allegro gui for a project, chances are good that you'll target gamers, or "geeks" of some kind or another.

Regarding Signals and Slots: Um, they are nice, but I must admit that I'd prefer regiserable callbacks and function overloading.
(Um, yes, once again I try to milk my java knowledge :))

I just think calling a registering function is pretty simple.
You want to get notified as soon as a window is moved? Register your function at the eventSource, and wait until you get called.

Implementation could be either function pointers in C++, interface pointers or functors in c++.

The main reason I don't like Signal/Slot is that it requires you to do some extra parsing.
I'm not that fond of MessageMaps, because it's pretty hard to alter them dynamically.

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

X-G
Member #856
December 2000
avatar

Quote:

Regarding the look: "hip" applications (video/audio apps in particular) seem to use a pretty non standard gui anyway.

Yes, and I'm equally annoyed at them. >:E

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

spellcaster
Member #1,493
September 2001
avatar

Then you should not partake in this discussion here :)

If you want a native GUI interface, use the native API of your platform. You don't have much choice there.

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

X-G
Member #856
December 2000
avatar

It all depends, really. I'm all for having a GUI - some games need it - but I'm just wondering whether its feasible to have one to use for tools in these days, when we have more "standardized" GUI systems - such that didn't really exist in the days of the Atari ST and DOS.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

axilmar
Member #1,204
April 2001

Quote:

I was just asking if I was the only one who felt a bit uncomfortable at the thought of a GUI running inside a graphical window, which does not support normal interaction with outside windows (think drag and drop)

Drag-n-drop from other windows is different for any window system anyway. In this case, we would need custom code for each O/S.

Quote:

and generally has a completely different look and feel than the rest

Well, on my Windows box alone I have various apps with completely different look and feel:
1) normal Win32 apps from Microsoft which are the original look and feel.
2) Qt based apps that have a slightly different look and feel. I can tell which apps are written with Qt anyway.
3) GTK based apps with an entirely different look and feel; for example DevC++.
4) Java apps with with an entirely different look and feel; for example PVCS, JDeveloper, PowerDesigner (at work).
5) All the media player programs that are skinnable. Way different interface.

So, the unified look and feel is kind of a myth. But this is no problem, as long as an app has menus, scroll bars, list boxes, text boxes and other things that are similar ideas. So, I don't think anyone would complain that our lib would look slightly different.

Don't forget that we can make it skinnable. The MASkinG library has done a pretty good job in skinning.

Richard Phipps
Member #1,632
November 2001
avatar

I agree with Axilmar on the last point. If everyone loved the look of windows then everyone would use it. With skinnable themes you can at least cater for different personal tastes.

I hope people here follow up on their intention to start a GUI library!

It would certainly benefit most Allegro users anyway.. :)

Steve Terry
Member #1,989
March 2002
avatar

I'm well on my way with my own library though it's limited due to using the same allegro dialog constructs as with most of the other GUI's. This most has excited me into realizing I need to ditch the underlying allegro structures and go with something a little bit different. Miran, Spellcaster, and I have had a great deal of experience with skinning so that won't be a problem there. So far I've managed to mimic the look anyway of MacOS, Windows, XWindows, and BeOS with a single dialog procedure, it's based on what is there and what is not there in the skin. For example BeOS has header text background (the thing behind the text that conforms to it's width), and no minimize icon. In the skin config file you tell it to draw the close icon to the left of the text, and the maximize icon to the right of the text, not the dialog header. Because the minimize icon doesn't exist (loaded as NULL) then a double click to the header will minimize the dialog. It requires one heck of a lot of code, but it's doable. In fact a lot of stuff for the headers is completely optional:

Main header bitmap (goes behind text, fits entire doalog top) Required
Text background bitmap (goes behind text, conforms to text) Optional
Minimize Icon: Optional
Minimize Disabled Icon: (these are for when the dialog is not selected (greyed out)) Optional
Maximize Icon: Required
Maximize Disabled: Optional
Exit Icon: Required
Exit Disabled: Optional
Rollup Icon: Optional (as well as disabled icon)
UnRollup Icon: Optional (as well as disabled icon)
Sticky Icon: Optional (ditto)
UnSticky Icon: Optional (ditto)
Help Icon: Optional
Help Disabled Icon: Optional
Header Panel: Optional (used to go in front of text, single bitmap)
Application Icon: Optional

That's 20 separate elements to draw just a skinned header, but rarely will every element exist in one datafile, and you have to keep in mind that most of these elements can be left, right, or center aligned. I also have plans for a mask element as well to poke through the header and show the background.

To do something like winamp with our GUI we could also have a procedure that acts like the dialog but is one single bitmap, dragging can be done anywhere another widget doesn't exist, and buttons, etc, can be replaced my icons instead giving the look and feel of a winamp-type application.

I think Axilmar gave a pretty decent framework example go off of, but I really haven't had the time to look over it in detail. But I think we have enough to get started with. As well any of my subprocedures i.e. mouse and text can be ported to this new library easily... very easily. I use nothing GUI specific in them and are in fact separate libs already. The text routines need some help though, I'm just not satisfied with how I handle them yet...

Here's what we've agreed on so far:
Skins
Slots and Sockets
C/C++ (I don't think it matters anymore as long as it works under both API's)
I would like to see different update methods as Miran pointed out but it's gonna be tricky to pull off. We may either have a set_gui_update_method or a way to pass a backbuffer and screenbuffer into our routines, maybe a combination of both...

I would hate to see my GUI die as well which is why I would hate to give up working on it even if my efforts are kind of vain, but I'll also give my best effots towards this lib as well if it gets off the ground. Again lots of discussion which is good, but little in teh ways of everyone getting together on this and making a working framework or teaming off to work on separate components. I think that's something we should do anyway, break off and work on base components (i.e. mouse, text, main routine runner, and anything else that's needed) once we get a decent idea on where to go with this GUI.

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

Hey Steve, I already have my Widget class ready that provides the following:

1) buffered and non-buffered drawing
2) focus management
3) geometry management
4) opaque and non-opaque widgets
5) misc widget properties like enabled, visible, etc.
6) accelerator table support
7) Widget trees (of course).

It's quite a clean interface. I have already made all the big decisions about the design, but I am always open to suggestions.

Tomorrow I am gonna do the Event class which reads mouse, keyboard and timer events from an internal queue.

It's C++ of course. Are you interested ?

X-G
Member #856
December 2000
avatar

Can we get to see this code? I'd be very interested in having a look at it.

I'm all for a new GUI, by the way - and I much prefer C++ over anything else for it.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

Steve Terry
Member #1,989
March 2002
avatar

I'd love to give some support for this lib, my C++ skills are a bit rusty though, but I understand class concepts, etc. Maybe after this week I can begin to do some work, I think I'll have most of my moving issues sorted out by then :-/

1)Drawing straight to screen, or buffered? not sure here what you mean. Fast GUI's use a DRS system, which is a form of buffered drawing.
2)Ok, gotcha there
3)Not sure what geometry management is.. like non-rectangular widgets?
4)I think that's up to the skin for opaqueness
5)Like the allegro GUI you need some flags like D_SELECTED, D_HIDDEN, etc.
6)What does this do?
7)Trees are good, I'm assuming you mean child widgets where the child widget is relative to the parent widget at location 0 0. I pondered this as well, like nested widgets.

But yeah, I'm interested and would look over it.

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

X-G
Member #856
December 2000
avatar

6) Keyboard shortcuts.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

axilmar
Member #1,204
April 2001

Ok, here is the source code (attached to the message). The suppied zip also has html help starting from the 'index.html' file in the docs directory, as well as a Test class derived from Widget for testing purposes.

Steve, here are your answers:

1) widgets use the 'screen' pointer to draw themselves, but in bufferred mode the screen pointer points to the buffer.

2) Geometry management: Each parent widget is responsible for maintaining the layout of its children, or resize itself according to its children. My Widget class has lots of methods to support this mechanism and to minimize redrawing for avoiding flickering.

4)It is not enough for the skin to define such a property. The widget redraw mechanism must support redrawing of overlapped widgets before drawing a non-opaque widget. Non-opaqueness is also useful in labels, check boxes, radio buttons and other non-rectangular widgets that use their parent as background.

6) Each widget can register itself to be called when the relevant accelerator key is called.

7) Of course. Child widgets have a x, y relative to the parent. This parent-relative x, y is translated to the screen-relative x, y once widgets are on the screen. All other operations are done using the widget's screen coordinates, though. For example, the Test class draws the widget by using its x1(), y1(), x2(), y2() coordinate methods.



Go to: