Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Extending Gosu / Fidgit: A GUI framework for Gosu/Chingu
- - By Spooner Date 2010-11-04 21:06
Fidgit

As part of my big project, I am creating a GUI toolkit. Although there are alternatives that work with Gosu, for one reason or another I didn't like them too much and didn't want to use them. In any case, I would have had to massively extend them in order to get the functionality I required, so I thought I would start from scratch (famous last words?).

* Extends Chingu, so you can use all the Chingu niceness.
* API based, roughly, on Shoes (i.e. extremely terse DSL), though not nearly as restrictive or limited.

The readme has some example code and a list of components which you might like to peek at. There isn't a usable gem yet, but there are quite a few examples in the repository for you to chew on (or run, if you are keen).

Any early feedback would be appreciated. Thanks!

WARNING: This is hugely PRE-ALPHA code. Don't even consider using it yet, since the API is changing on a daily basis and a lot of really important things just aren't implemented or are very broken! I'm just letting people know what is being worked on and to let people give feedback on the API and things they _need_ from a GUI tool-kit. Also note that I am developing the things I directly need for my own project; anything other requests will be put at the back of the queue.
Parent - - By jlnr (dev) Date 2010-11-04 22:47 Edited 2010-11-04 22:52
Looks very professional already. What is the connection to FXRuby (mentioned in the README)? Is it just that it has more features to offer than Shoes? FXRuby looks *completely* different from what I remember :)

Also, here goes my usual vote for skinning via overriding ComboBox#draw etc., instead of having ":border_width=>…, :border_color=>…, :background_image=>…" etc. etc. etc. But that sounds a bit opposed to the simplistic combo_box creation, so I'd have to write MyGame::combo_box(options) too?
Parent - - By Spooner Date 2010-11-05 11:25
Yes, the Shoes reference refers to the method-based API (which is the standard), but you can just use the object-based API if you'd prefer, which is actually modelled on FXRuby (I originally copied the FXRuby stuff that seemed to make sense and the class names are the same as FXRuby for the most part). Of course, there should be no reason to actually use the objects directly, so maybe I should forget about that (yes, the intention is to give Shoes API (terse and makes assumptions) along with FXRuby complexity if you need it (lots of complex controls and options))

  # shoesish
  pack :vertical do
    button text: "hello" do
       # handle event
    end
  end

  # FXRubyish
  VerticalPacker.new(container) do |packer|
    button = Button.new(packer, text: "hello")
    button.subscribe :clicked_left_mouse_button do
       # handle event
    end
  end

Well, the idea is that generally you want to just mess with the options (I haven't implemented :border_width or :background_image yet, since I don't personally need them, but they do fit in with my plan). If you want to override, there is nothing stopping you and you have the option of completely overriding #draw OR overriding #draw_background, #draw_border and/or #draw_foreground to have more fine control (#draw just calls those three protected methods).

Yes, you'd have to monkey-patch the original Fidgit class, but since Container#combo_box(options, &block) just calls ComboBox.new(parent, options, &block) you could also either monkey-patch ComboBox#initialize or the Container#combo_box methods. Three options, then, but all monkey-patch based, so I can see they aren't ideal...

What I had considered, however, was that you could have an Element.container_method(type) that you'd call in your overriding class so that it would automatically add (or replace) the Shoesie methods. Avoids the requirement of monkey-patching, which is a good thing, though not sure it is the best way:

  # Overriding the defaults.
  class MyComboBox < Fidgit::ComboBox  
    container_method :combo_box # Replaces the default Container#combo_box.
  end

  # Creating new methods.
  class MyComboBox < Fidgit::ComboBox
    container_method :my_combo_box # Adds Container#my_combo_box, so you can still have access to the original type.
  end

Thoughts on that?
Parent - - By jlnr (dev) Date 2010-11-05 17:32
I don't mind the monkey patching so much. In C++, I'd have given Button an abstract/missing draw() so that the user has to supply their look. In your lib, I also implement draw, except that I happen to delete the original implementation on my way. Not too horrible. :)

What bugs me is that I carry around lots of hashy things that I don't need. Usually my GUI is pre-rendered images all the way, not even using Font to label the buttons. (Yes, my game has a folder with lots of pre-rendered buttons. :)) But that is just me, and the Ruby ecosystem is full of stuff I ignore anyway. So that's not a very pragmatic argument from my side.
Parent - - By Spooner Date 2010-11-05 17:41
Ha, well, the defaults for Fidgit are actually just the settings I want for Sidney :) That might explain it! People can use those defaults, modify them a little bit with the hash arguments (or use a schema.yaml file, which I haven't implemented yet and maybe won't bother with) or override, which is their choice.

You aren't really needing to use the hashes if you don't need them (you can just completely ignore them in your initialization code and they will just default to {} anyway).

My reasoning for having lots of defaults is to ensure that you can come to Fidgit and make a simple GUI in about 37 seconds. You can worry about the presentation after you've got it working (and in LD, you just leave it as it is).
Parent - By jlnr (dev) Date 2010-11-05 18:11
Hmm, I think that is an awesome thing about the hashes. Unlike having accessor methods for everything, they are a completely transparent channel from widget creation to #draw. Not only do they not bother me after I monkey-patch #draw, they actually can transport my own stuff.

The LD argument is definitely true.
Parent - By Spooner Date 2010-11-13 10:50
I've been working quite a lot on this over the last week. Still some things I need to pull together or fix before I can take it to beta stage and a public gem (I'll say, conservatively, a week or two, so I can get one or two fix patches out before LD ;) ). I am planning to add a schema file (a bit like a CSS file) to make customisation easier and fixing the packing system (which is a bit flakey :P), tweaking the method interface and cleaning up the code and docs. I'm not adding any brand new controls or functionality, unless anything pops up (which it probably will).

I also think I need to change the current license (GPL) to a more library-friendly one, like MIT or LGPL, if I'm going to see anyone but me use it (My end products are GPLed, so a GPL library is fine for me, but I know that is a bit restrictive for anyone else).

Looking at the API and/or the examples, are there any fundamental things that are conspicuously absent before I make the v0.1.0 release? Any requests for functionality for a later version? I expect I'll end up breaking everything for 0.2.0 when I realise what I've done wrong, but that is something to worry about at a later date :)
- By Spooner Date 2011-03-20 01:22 Edited 2011-03-20 01:32
I'm really sorry about abandoning this project, especially since so many people seemed interested in it. Just got to be too much work and I ended up taking a few months completely away from coding.

After quite a long break, then, I've been working on Wrath for a few weeks and kept wanting to have a decent GUI for it. Ironically, when Wrath got a bit much, I thought I'd pop back and do some Fidgit (how much I get done, is yet to be seen; making no promises this time). I've pushed a 0.0.2alpha gem, which is essentially where I left it, but which is fixed to work with Chingu 0.9pre4 and a couple of other tiny fixes. Still some serious bugs and great likelihood of changing API, but something to play with!

Also, thanks to Robert Rouse for making a few improvements back in January, which I've pulled in now. Nothing like getting someone submitting code (even if not a huge amount) to warm the cockles :P

EDIT: Pushed 0.0.3alpha, which just adds proper gem dependencies for installation.
Up Topic Gosu / Extending Gosu / Fidgit: A GUI framework for Gosu/Chingu

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill