Not logged inGosu Forums
Forum back to Help Search Register Login
Up Topic Gosu / Extending Gosu / GGLib: A Gosu GUI Library
- By psadda Date 2009-01-28 21:05 Edited 2009-01-28 21:08
I can see that someone has already made a GUI library for Gosu. That just shows how long I have taken in packaging my library.
I started work on a Gosu project just over a year ago. As part of the project, I wrote a simple Ruby GUI Framework and decided that I would release it independently. (Which, once again, took an entire year...)

If you want to opt out before these copious amount of text, check out the download before you go:

Unlike Rubygoo, GGLib does not provide a full fledged GUI library, but aims to make it very easy to write one's own widgets. And it is unbelievably easy to write widgets with GGLib. It's almost like using C# or VB with .NET to write Windows GUI apps. That said, GGLib does still provide a small assortment of predefined widgets. It has some interesting widgets, such as the DebugConsole and TracePanel which Rubygoo does not have. It also had the ability to fade in and out of menus, which Rubygoo does not have, and has an extensible window state mechanism. As of now, GGLib lacks a full set of widgets, but I will continue to add new widgets such as check boxes, radio buttons, and labels in the near future.

Unfortunately, many of the widgets which were previously part of this library have been removed because they are two heavily intertwined with the project I was previously working on. I will try to extract these widgets from the rest of the project so that they can be neatly distributed with the library. One of these widgets, the TextBar deserves a special mention. The TextBar is not a text editor like the TextBox, but a medium for conversation with in game characters. It is similar to the textbar in Gameboy games and many console games: that strip with text and response options that appears at the bottom of the screen. But the really cool thing about the TextBar is that it is fully scriptable: not from Ruby, but from a special custom language which the application parses passively rather than actively. (That is, the application pauses parsing the script to obtain a human response, rather than the other way around.)

Since this library is so old, some of it is a bit outdated. For example, before Gosu's text input was updated in 0.7.9, GGLib had it's own text input interface. With Gosu 0.7.9, GGLib's Widget#feedText and associated routines became redundant. This, and other legacy code, will be scrapped as soon as possible.

Currently supported widgets:

Finished widgets which must be cleaned up before release

Planned widget additions:

Other planned additions:
Remove legacy code
Add audio hooks
Reintroduce serialization/deserialization
Reintroduce debugging/logging
Add layout mechanism
Add theme mechanism
Add support for drawn widgets as well as image-widgets.

- By wh1pl4sh Date 2009-01-29 00:30
First post on the forum =)

Let me say I really appreciated your lib. I'm creating a game here (actually my first game with Gosu) and it helped me alot to create great GUI so far. Just let me ask you (and, of course, all the other members) a kind of rethorical question, wouldn't be better if Gosu handle panels, instead of creating new windows? I mean, I created some games using Pygame, and  I  could use the pygame.sprite.Sprite class to create the panels for my GUI. Maybe because I'm newbie to Gosu I'm not considering problems that could arise from this idea.

psadda, keep up the nice work! if you need any help on further development, let me know =). Although my Ruby experience is kind of limited, I'm really enjoying Ruby and Gosu =P.
Cya, happy hacking
- By psadda Date 2009-01-29 21:37
If all you need is the ability to display a background image for your panel, you could use the GUIWindow#newImage function. If you need some slightly more advanced functionality, such as the ability to recieve input such as mouse clicks, you could implement a simple subclass of widget. (Actually, you could use widget itself, as it would provide all the necessary functionality, but it would be bad style to use something which should be considered an abstract base class.) If you need more advanced functionality such as panel based content layout, it isn't available yet, but I am working on it. I hope that answers your question.

Thanks for the input.

By the way, do you mind sharing your app, or screenshots of your GUI? I'm interested in seeing what kind of stuff people are doing with the library.
- By philomory Date 2009-01-30 08:27
Ok, I haven't had a chance to download this and play with it yet, but from readings your description I'm quite excited. I've been wishing for something like this for a while now.
- By ? Date 2009-01-30 15:00
Is there any gui library for guso c++? If not, any plans to extend gosu a little bit more to handle gui? (The text input abstract class is a great start, but not quite enough for a full gui some games would need).

- By wh1pl4sh Date 2009-01-30 19:15
Not at all, I've being away from my pc for a couple of days, but I guess by Sunday I'll have the game finished (anyway, is a just a simple Space Invaders clone, but I'm working on to, who knows, do some great game in few weeks with Ruby =P).
I've actually extended some of your code, and modified some part of it too, but just some lines, not much.
I've gotta tell you, the fade effect is awesome! I really liked that. To simulate the kind-of panel behaviour I'm using this effect, it seems pretty nice actually (of course, fading too much just feels a bit awkward lol).
So, as soon as I'm done with the game, I can happily share it =).

Cya, happy hacking.
- By psadda Date 2009-02-01 03:35 Edited 2009-02-01 03:38
wh1pl4sh, I'm glad to hear that the library is working well for you. The FadeScreen was a short bit of inspiration. I was trying to figure out how to stop the transitions between menus from looking so choppy, and then I realized that most fullscreen apps/video games actually have a very quick fade in/fade out between screens. So, I felt it was pretty important to add the fade in class. Right know, I'm trying to see if I can use the new clip_to method to limit the fading to a single widget. What kind of modifications did you make? Maybe I should add them to the main library. ;)

About C++ libraries, there is no C++ GUI library specifically targeted at Gosu that I know of, but in C++, it is possible to directly access the components of the window, such as the Graphics class, use them with existing C++ or C toolkits such as wxWidgets, FLTK, GTK, ,etc.

philomory, I hope you like the library.

I've made some updates to the library. I'll post them along with more complete documentation on the Google Code site sometime tomorrow. I added support for themes to the library. Now, the same widgets can reused with different graphics. Themes can also be loaded from textfiles. The only problem is, there aren't any themes yet! There are two types of themes right now: drawn themes, drawn themes, which are drawn from code, and image based themes. Drawn themes can be easily reshaped and resized, but they don't look as good as image themes can. I've also added two new widgets: Label and CheckBox.
- By psadda Date 2009-02-13 19:25 Edited 2009-02-13 21:16
I've finished version 1.1. It is up on the Google Code site:

* Bugs with the DebugConsole widget fixed.
* Label widget added.
* DeltaCursor class added. This cursor does not more around the screen, but instead calculates delta x and delta y values each frame. It can be used as would the cursor in an FPS (although that would be 3D), or a top down RTS.
* Themes added. To apply a theme to a widget, you simply pass the theme as a parameter on construction, or change the widget's theme property later on.

Here are some screenshots of BasicExample.rb with different themes.

From left to right: BlueSteel, Rubygoo, Shade, and Windows.
- By psadda Date 2009-03-31 02:35
Version 1.2 is up at GGLib's new RubyForge page:
Version 1.2 has CheckBox widgets and RadioGroup widgets, along with a number of minor improvements, including support for mouse down states.

A perk of GGLib's new RubyForge page is that now it is possible to install GGLib simply with a "gem install gglib" command.
- By jlnr (dev) Date 2009-04-04 21:56
After a fresh gem installation, none of the examples really worked :( Are they somehow outdated?
- By psadda Date 2009-04-05 20:53
Fixed in 1.2.1. Thanks for pointing out the error. ;)
I added label functionality to CheckBox and RadioGroup without first testing it - very stupid of me. The error was simply using x instead of @x.
- By jlnr (dev) Date 2009-04-05 23:25
Now I get:

> gglib requires gosu (>= 7.12, runtime)

The joys of Rubygems deployment ;)
- By psadda Date 2009-04-06 00:25
Fixed. I've got to be more rigorous with my testing. :p
- By big_love Date 2009-05-07 20:06
Hey psadda!

I just took a look at both Rubygoo and GGLib. I'll be doing a pretty text-heavy game here soon, but will be sort of emulating a fictitious operating system, so windowing systems with buttons and text areas and the like are sorely needed for me. I actually started to write my own library, until I noticed everyone else's work.

First, let me say, I love the approach you've taken, with theming, with widgets, etc. That being said, I question the approach of hooking into Gosu's core Window library for a couple of reasons.
1. If we can only display one window at a time with Gosu, would it not be a pretty jarring experience for someone who needs to write/play a full screen game? Which begs the question...
2. How do I write a game using your library like the game I'm planning on, mentioned above? Specifically, how do I emulate say, a great many windows being opened and closed using this?

While I think what you're doing is fantastic for games where a single interface is needed at a time, I don't think it's quite right for my needs per se... Which is totally ok :P We can still be friends of course, haha. And I still have great respect for your library, I just wonder how useful it would be to people who are say, needing huds overlayed on top of their 2D game, since a "window" in your library is an actual physical window, and from a very cursory look, the widgets can't be used outside of GGLib's implementation of the physical window :(

I say all that to say this, though... that I don't think we should all be banging out GUI libraries constantly, haha. I'd much rather begin working with someone on a single, bad-ass GUI project that everyone would find desirable. Of course, there's always the "can't please everyone" and there's also great versatility in having multiple projects to choose from (open source environments ftw!)... So I don't know. I'd be interested in your thoughts on perhaps changing the shape of your library, working on a new one with me, or taking the completely valid opinion of "Screw you big_love, I love my lib!" :P

In short, my points are this:
1. Overriding the base functionality of a Gosu Window is, imho, inherently wrong, since we can't really have multiple windows.
2. This sort of library wouldn't work in a full screen game, or in a game that should desirably only run in one window
3. Not being able to use your GGLib::Buttons or widgets in a vanilla Gosu project is a bummer :/
4. Though I think your way of handling events and state is intriguing... personally I'd prefer a get-out-of-my-way approach and let the game author decide how eventing should take place.

If I were/am to write my own lib, I'd envision it as being as close to the bare Gosu metal as possible. Handle the annoying, crappy parts about creating huds and whatnot, like nesting and moving and clipping and clicking... but everything else, simply give the author a way to access the methods and properties of the interface, and let him/her do with it however he/she sees fit...

All that being said, I like Rubygoo's single window approach, but I hate it's interface (sorry Rubygoo :/). And finally, I hope it won't be misinterpreted as if I'm attacking. I sincerely would like to get your opinions/interpretations on this, and I'm *hoping* I'm just not seeing something obvious or perhaps not-so-obvious with your framework. Quite honestly, I'd rather not write my own :P You're obviously further into this game than all of the Gosu GUI programmers that I've looked at so far, so you've most definitely got the deepest resources to tap :)

Oh, also, I have the current, rudimentary state of my library here:
You can see the current state of consuming it here (not much going on just yet):
And finally a video of it in action here:

At the moment, I'm using a base class called Container to be able draw border, background color, position, and nest children containers. The interface is, to me, pretty straight forward and handles most of the tediousness of positioning and movement, and saves the programmer time by being able to use ruby-like syntax for drawing and nesting children containers (which will eventually be children buttons, textboxes, windows, etc). The important point, though, is that it only requires that you draw the parent containers... not the children containers (same with move).

My hope is to basically be able to give the consumer a framework that they can just say, "Hm, I've got my gosu game, and I want a hud. Well... I'll need a window." And then give them an object that they can treat just like any other Gosu object (sprites, images, quads, etc). This, imo, would feel natural to anyone who is familiar with Gosu...

But bah. I'm rambling. I'm very interested in your thoughts :D
- By psadda Date 2009-05-08 02:19
Hi, big_love.

First off, you do raise some interesting points, but you also seem to have a few misconceptions about GGLib. Let me first address these before talking about anything else. This is the basic structure of GGLib:

* GUIWindow (extends Gosu::Window) has one or more Widgets and StateObjects
* StateObjects break up program logic and behavior for different states (Different menus, the actual game, etc.)
* Widgets have behavioral components (event handlers) and visual components (Themes)
* Themes control the visual aspect of the library

There are a lot of other helper classes in there, but this is the gist of GGLib.

Now, for your points:

1. Overriding the base functionality of a Gosu Window is, imho, inherently wrong, since we can't really have multiple windows.
  I am not sure exactly what you mean here. GGLib::GUIWindow derives from Gosu::Window. You simply create a GGLib::GuiWindow instead of a Gosu::Window to use GGLib. There is no need for multiple windows. (In GGLib, Widgets are not types of windows, as in most GUI libraries, because Gosu doesn't support multiple windows - see the brief GGLib system I outlined above.)
2. This sort of library wouldn't work in a full screen game, or in a game that should desirably only run in one window
  Once again, GGLib is tailored to Gosu, which can *only* run in one window and can run either in fullscreen or windowed mode. GGLib does not interfere with this.
3. Not being able to use your GGLib::Buttons or widgets in a vanilla Gosu project is a bummer :/
  I'm still not 100% sure what you mean. Do you mean that you want to be able to use Widgets without a GUIWindow? That's just impossible. GUIWindow redirects input to Widgets while Gosu::Window does not. But GUIWindow is derived from Gosu::Window, so all of the raw API is still exposed. In fact, is is still exposed in most places, so there should be no need to use a Gosu::Window.
4. Though I think your way of handling events and state is intriguing... personally I'd prefer a get-out-of-my-way approach and let the game author decide how eventing should take place.
  StateObjects *are* meant for a get-out-of-my-way approach! StateObjects basically simulate the multiple windows that so many people keep asking for - not graphically, but behaviorally. You can completely change the look and behavior of the window simply by changing its state object. Once you have multiple states (menus, the actual game, the credits/highscore screen, etc.) in your application, trust me, you will fall in love with state objects. But if for some reason you really do not like state objects, you can override the update, draw, button_down, and other methods directly in GUIWindow, just as you would do in Gosu::Window.

Just to clarify, here is the GGLib philosophy:
* GGLib is meant to be close to be close to Gosu and 100% reverse compatible with Gosu, unlike Rubygoo, for example, which completely rids of the Gosu interface.
* GGLib is meant to be easy to use. The program that would take thirty-forty lines in Rubygoo would only take 10-15 lines max in GGLib. Look at the examples for both libraries if you don't believe me.
* At the same time, GGLib supports low level (if you can call it that in a dynamic scripting language :P ) access to the Gosu API because it is 100% reverse compatible with Gosu, meaning that you can use a Gosu::Image and a GGLib::Widget in the same application, at the same time.
* GGLib aims to abstract and seperate behavior and appearance as much as possible, through interchangeable Themes and StateObjects. Now, as you mentioned when talking about StateObjects, this abstraction can like seem tedious and unnecessary work in small programs. However, in larger programs, the small amount of extra work will save programmers' necks. Simply overriding Gosu::Windows methods does not scale. StateObjects and Themes do. Mess around with the library a bit more, and you'll see what I mean.
* GGLib aims to be easily extensible. As you may have noticed, GGLib does not contain a large amount of different Widgets. You may have also noticed that Widgets are stored in a folder called "ext", short for extension - because they are not part of the main library. Surprise! While I did provide some utility classes in the ext folder, this is not what I think of as the core of GGLIb. The core of GGLib is a framework rather than a library. It was originally meant as a tool to make it much easier for programmers to write their own, application specific libraries rather than as a library itself. The subject of coding widgets is too complicated to cover here, but I am working on updating the Widget Programmer's Handbook, an old document left over from what I will call proto-GGLib, and it should be up on GGLib's site within a week or so.
* GGLib aims to give the Gosu programmers what they want - so far it has mostly been guesswork. Thanks for your input!

Those are not only GGLib's aims, but also its strengths.

Here are GGLib's weaknesses:
* It is bound to Gosu. Cannot be used with any other graphics engine.
* It is only usable from Ruby, not C. (Unless you call the Ruby functions from C, but IMO, this would be a silly thing to do.)
* GGLib does not have a large set of pre-defined widgets, like Rubygoo, for example.
* GGLib does not have any good container system. At one point, I hope to launch a major overhaul of the GGLib core (a 2.x branch) that supports container widgets and psuedo-windows.

Could you use GGLib for your project? Yes.
Is it the best option? Maybe - there is not enough information for me to make good call.

So, in summary, from what I gathered, your main complaints were
1. GGLib does not allow the programmer enough control; the programmer should be able to interact with Gosu directly
2. This library wont work in a fullscreen window, or in only window.
3. GGLib does not have adequate container classes. (GGLib's windows are physical Gosu windows, not containers.)

My responses are:
1. This is possible. In fact, GGLib was designed with this in mind. If you want something even *more* barebones, go download GGLib 1.0 from - but be warned, the code is so ugly it may blind you for life.
2. Again, this is possible. In fact, GGLib was designed with this in mind.
3. This is very true. I want to fix this problem as quickly as possible. It is possible to emulate containers to a limited extent with the current framework. Again, this is detailed in the Widget Programmer's Handbook.

I hope this list-based response answered your questions. I would be very interested in working with you on the next release of GGLib, or on some new fusion library, especially if you have any ideas on implementing container classes.
- By big_love Date 2009-05-08 02:59

I'll take some to post a bit more later, but after reading your philosophy for GGLib, as well as your other explanations on my (now) obvious misunderstandings, I'm really excited to try and really dive deep into this. It sounds like I had a pretty fundamental misunderstanding of the way the core library was meant to be used. Admittedly, I only looked at the examples, so I don't think I got the full breadth of what your library can do.

*runs off to tinker some more*

Thanks for taking the time out to explain!
- By psadda Date 2009-05-18 00:25
Version 1.3.0 is finished and available for download at GGLib's RubyForge page:
1.3.0 is mostly a maintenance release. Many small bugs and ugly interfaces that developed in the changes introduced during the last few releases have been fixed. Documentation has also been expanded a bit, and there are a few new example files. There should be some full-fledged tutorials available from within the next week.
- By psadda Date 2009-06-19 17:52 Edited 2009-06-19 17:57
It's been a while since I posted an update, so hear is some information about the upcoming GGLib release, 2.0:

The main feature of 2.0 will be containers. GGLib's container system will be similar to the box model used by XUL: all containers will be derived from HBox and VBox. (In my experience, the box model is the simplest way to procedurally build a container based GUI.) In addition to having a theme, each widget will now also have a wide number of formatting properties that control how its container displays it and how it displays its children. Also, all Widgets can now be moved after construction without side effects. (I don;t know why I didn't implement this feature earlier.)

I'm still ironing out some bugs, but I should have a release done shortly, probably within the week.

Here is some sample code (that currently works - I may post a screenshot later):

  # In case you use Gosu via RubyGems.
  require 'rubygems'
rescue LoadError
  # In case you don't.

require 'gosu'

require '../gglib'
require '../ext/widgets'
require '../ext/themes'

class ContainerDemoWindow < GGLib::GUIWindow
  def initialize
    super(640, 480, false, 20)
    self.caption = "GGLib Containers Tutorial"
    self.state =

class ContainerDemoStateObj < GGLib::StateObject
  def onStart
    # The GGLib container model is similar to the box model used in XUL.
    # There are two main types of container: HBox and VBox.
    # HBox aligns all of its contents on a single horizontal line and VBox aligns its contents vertically.
    # You can create tables with multiple rows and columns by nesting HBoxes and VBoxes.
    $t1 =, 0, 0, 200, 40, 12, GGLib::Themes::BlueSteel)
    b1 =, "Click Me", 0, 0,{ |widget| $t1.text = "Thank you" }, GGLib::Themes::BlueSteel)
    b2 =, "Exit", 0, 0,{ |widget| $window.close; exit }, GGLib::Themes::BlueSteel)
    container =,0,0,640,480)
    container.valign = GGLib::Format::VAlign::Center
    container.align = GGLib::Format::Align::Left
    container.margin.left = 40 = 40
    container.spacing.size = 2 = GGLib::Format::Spacing::Flexible
    container.add(b1, $t1, b2)
- By Shinobi Chef Date 2009-06-20 11:13
Great work psadda
- By psadda Date 2009-08-20 18:00
After months of squashing a colossal collection of bugs, I'm proud to announce that GGLib v2.0 is finally done! (And bugfree - at least to the best of my knowledge.) I am currently working on writing up the documentation, since GGLib's documentation to date has been lacking. In 1-2 days, I'll have a public release.
- By aimjiel Date 2009-08-24 17:57
I don't know about you, but the splash demo is a bit wonky on ubuntu jack, two windows pop up, one blank, and then the second one loads and the system nearly goes down. Albeit, I am on a lappy that's a bit dated... Oh well, a splash woulda been nice.
- - By psadda Date 2009-09-01 22:05
I'm not sure why the splash demo would lag so long. It doesn't even use that much GGLib specific code. It's a pretty simple wrapper around Gosu code.

The first window should pop up with an image of a banana in the background (a bit random, I know) and the text "Loading". You should see the console in the back counting down time. The splash window should then close. After it closes, a second window should pop up, the same as that from BasicExample.rb.

GGLib code only really runs when you reach BasicExample. Which version are you using? 1.3?

The only possible problem I could see is the countdown. The procedure calls sleep(1). Maybe sleep is implemented on poorly on Ubuntu. (Probably not.)

I updated the splash in 1.4 (I decided not to call it 2.0). It was incompatible with some changes I made. Maybe the new version will work for you. But 1.4 will not be up for a while. I really want to take this time to work on some real documentation beyond the RDoc. At first, I though about writing a simple reference, like that of Gosu's. But then I realized that I should cover some more advanced topics such as extending GGLib since GGLib isn't much use unless you extend it. I don't want to release before I finish the documentation and it might be a while until I do. I've already written pages and pages of docs, but I am only about half way done.

In the meantime, it shouldn't be that hard for you to roll your own implementation. Take a look at the example code. All it does is create one window, run some calculations, close the first window, and open a second. You could try using a Gosu::Window instead of a GGLib::GUIWindow for the first window and see if that helps.
Parent - - By RunnerPack Date 2011-02-21 05:50
So, it's been over a year (537 days, according to the forum engine) and still no 1.4… I'm anxious to try out the container system, and I'm also curious about possible new widgets (so I don't have to make as many of my own when I start my next project ;)

If you'd like some help on writing the docs, I'd be glad to pitch in. Although, truth be told, I would rather have a release with half-finished docs than no release at all :D
Parent - - By psadda Date 2011-03-13 19:36
I'm currently finishing up midterms at college. When I return home for spring break on the 19th, I will release version 1.4 sans documentation. If you could help write the documentation, that would be extrememly helpful.

I really should have done this a long time ago. I'm sorry about the wait.
Parent - - By RunnerPack Date 2011-03-16 10:08
Hey, don't worry about it. We all have things that have to take priority over hobbies. Also, I promise not to eat into your spring break with too many annoying questions as I work on the docs ;)
Parent - - By jlnr (dev) Date 2011-03-16 10:57
Hobbies? Folks, we are all on a big mission together! *glowing eyes* ;)
Parent - - By RunnerPack Date 2011-03-16 20:39
haha, yes, I knew someone would say something about my use of the word "hobbies." I do look forward to the day when the majority of (2D) games are libgosu-based, but I also think that the more smart folks like you, psadda, banisterfiend, et al. we have contributing to the project, the sooner that day will arrive.

¡Viva la misión grandé! ;)
Parent - - By psadda Date 2011-03-20 23:10
I have good news and bad news.

Bad news: It looks like I lost the files for GGLib 1.4. I suppose that is what happens when you are slow about commiting to version control.
Good news: I've started work on GGLib 2.0. I plan to release it sometime early in April.

GGLib 2.0 will be reworked to have an easier to use, more Ruby-ish API. It will also have a much more flexible style system, new themes, and containers. It will also have the ability to use multiple rendering backends. (The main option being, Gosu, of course.)
I'll post some more information and screenshots of the new themes later this week.
Parent - By banister Date 2011-03-21 08:14
would you be able to make a text input box widget with a scroll bar ? :D i'd love that
- By Scyllinice Date 2009-09-30 00:47

Is it possible to use GGLib without using GGLib::GuiWindow? If so, what's the process?

I'm playing with Chingu, so I inherit from Chingu::Window.
- - By psadda Date 2009-09-30 04:14
Yes, it is possible to use GGLib without the GUIWindow class.
I think I briefly mentioned how to do this earlier in the thread, but I'll expand on this now:

There are three different ways you can use GGLib without GUIWindow:
1.) Write your own implementation for forwarding input to widgets. This would probably take a long time.
2.) Copy the appropriate routines from GGLib::GUIWindow into your own window class. This is a bit easier, but requires knowledge of GGLib internals.
3.) The easiest solution: modify the declaration of GGLib::GUIWindow in window.rb to inherit from your own window class.

I think an even better solution would be for me to create a GUIWindow module that can be embedded into an existing window class using Ruby Mixins. I'll see if I can post an implementation tomorrow.
Parent - By banister Date 2011-01-19 02:48
Just wanna say this library is the bomb. cheers.

Oh and your examples dont work out of the box, i looked in BasicExample.rb and it has:

require "../gglib"

but i replaced it with:

require "../lib/gglib"

and now it appears to work :)
- - By psadda Date 2011-03-28 20:53
I'm still working on GGLib 2.0, and I thought it would be good to post an update on my progress. I am currently about one-third done. GGLib 2.0 runs on the Gosu backend, but theming and input/event handling are still unfinished. Most of the work that remains involves finishing the theming engine, testing the library, and creating the new themes.

I have decided that I will release a 1.9 version of GGLib. Version 1.9 will serve as a sort of beta for the 2.0 release. It will have almost all of the functionality of the 2.0 release, but will only have one or two themes and will be mostly untested. Expect to see a 1.9 release in the second or third week of April and a 2.0 release by the first week of May (but hopefully by the last week of April).

Here is a sample of what 2.0 will look like (and I promise it won't turn into vaporware like 1.4):

require 'gglib'
require 'ext/backends/gosu'

window = do

  self.layout =

  hello_button = do

    self.theme = GGLib::Themes::Titanium

    #Take a look at this cool new syntax for event handling.
    #There is no more need to subclass a widget just to handle an event!
    self.on :press do |this, args|
      label =
      label.text = "Hello, world!"
      this.parent.add label


  self.add hello_button

Parent - - By jlnr (dev) Date 2011-03-28 21:39
Can you eliminate the 'this' argument by instance_eval'ing the block, or would that hide other stuff?
Parent - - By Spooner Date 2011-03-28 23:45
The problem with a Ruby's instance_eval is that you gain access to private/public methods and ivars on the object and lose access to them on the outer context; this was really irritating in Shoes, for example (even though the terse API it enabled was nice). Fidgit uses a hand-rolled instance_eval (sort of framework) for object creation, which, while avoiding this particular issue (it only exposes public methods of the object, while simultaneously preserving access to outer context ivars), it is much too slow to use in event handlers (And it has other issues, so it is a bit of a two-edged sword for me even in the limited way I use it).
Parent - By banister Date 2011-03-29 01:29
spooner! where are you! i need help with regex! ;)
Parent - By jlnr (dev) Date 2011-03-29 11:59
Ah, as I feared. I think I also remember you discussing the various eval flavors with banister. Mmh... :/
Parent - By RunnerPack Date 2011-03-30 10:08
Sounds great! Can't wait to try it out.
- By psadda Date 2011-04-18 20:05 Edited 2011-04-18 20:27
I have fallen a little bit behind schedule, but not too far. I should still have a 1.9 release by the end of this week. (Or, in the worst case, at the very beginning of next week.) So far, the widget model and the rendering code are mostly complete. The remaining tasks are coding event dispatching, creating new themes, and creating new widgets. Event dispatching should be fairly quick, since I should be able to reuse most of the code from GGLib 1.3. Creating new widgets and new themes will take much more work. I will probably release GGLib 1.9 with only one theme and four or five widgets. 2.0 will have six themes and about a dozen widgets.

Here is a screenshot of what GGLib looks like right now:

This is the code for the above screenshot:

require 'gglib'
require 'gglib-ext/themes'

window =, 480, false)

container =
container.resize 300, 400
container.theme = GGLib::Themes::AquaBou

window.add container

window.renderer ='/media/gosu.png')

Some notes about the above code: Every widget is drawn by a renderer. If you do not assign a renderer to a widget, it will be invisible. (Its children will still be drawn if they have been assigned renderers.) Typically, you will not assign a renderer directly as I did with the window in the previous example. Instead, you will assign a theme. A theme is essentially an intelligent collection of renderers. It will delegate drawing to the renderer that is most appropriate for the given widget. I applied a theme to the container in the previous example.

GGLib 1.9/2.0 is still a work in progress. The API and graphical appearance will probably change significantly by the release.
Up Topic Gosu / Extending Gosu / GGLib: A Gosu GUI Library

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill