"Kero van Gelder" <kero@chello.nl> wrote in message news:<pan.2003.03.20.21.35.31.1956@chello.nl>...
> Both GUtopIa and Rouge aim for higher level abstractions. correct.
> Both also tend to be low on activity (while the ideas are pretty good).
Hi,
I've been working on this, off and on, for a while. I posted some
code a while back, but was waiting until it was actually usable in
small projects before I did a major release. I've been struggling
with some usage issues, and the good news is that I think I've got a
coherent solution.
The project started out proving the layered concept: there are
high-level APIs that programmers use, mid-level APIs that generate the
GUI code, and low-level APIs that actually draw the widgets. I used
FOX as the low-level API, but was hoping to get enough low-level
layers to make the toolkit able to run on any desktop, with the
assumption that most people will have *some* Ruby GUI toolkit
installed.
What I have so far is a really basic XUL interpreter, so you can write
the GUI in XUL and run the parser on it, and you get a FOX/Ruby GUI.
There is also a programmatic high-level API that's fairly uninspiring,
but doesn't require XUL knowledge.
The thing that bothered me most was the binding/callback mechanism.
One thing I'd like to do is be able to use GUI servers. These are
services that run as part of the Desktop system, and answer RPC calls
to generate GUI elements. There are a number of these projects, and I
feel as if there's some real potential there, especially for scripting
languages. Currently, the bindings are specified in the XUL code, or
in the Ruby code as callbacks. I've decided that I don't particularly
like this, so I'm trying a new approach.
My current fancy is to use the signal/slot metaphor, in the hopes that
this will further detach the View from the Control. The GUI will be
created however it is created, and the application will attach methods
to GUI elements in the publish/subscribe method.
So, what this will all look like is something like this:
--- 1 ---
require 'rouge/zool'
tk = Rouge::Zool::parse( File.new( "ui.xul" ) )
tk.listen( "submit_button", "onClick", proc { puts "Hello World" } )
# Proc or Method
tk.start
--- 2 ---
require 'rouge/builder'
tk = Rouge::Builder.new
tk.window( "Rouge Demo" ) {
tk.button( "Submit", "submit_button" ) { puts "Hello World" }
}
tk.listen( "submit_button", "onClick", proc { puts "And goodbye,
too!" })
# Two listeners
tk.start
Now, that's just the front end. The back ends can be just about
anything that you can code a middle layer for; middle layers are a
single class that implements a bunch of methods, like:
# Creates a button with some text
def button( title )
and so on.
I'll post a link to a project page pretty soon. There is no
documentation, and I have *very* little time right now to answer
questions, so I've been sort of hesitant to do so.
Notice that this is all high-level stuff, which is a far cry from the
original topic of "native Ruby widget sets". There are two kinds of
"native": the kind that means "pure Ruby", and the kind that means
"using the user's native environment". As a user, I prefer the latter
to the former. As a programmer, I don't care, as long as the API I'm
using to create the GUI is really, really easy to use, and the end
result doesn't suck. The interesting problem, for me, therefore is
creating a really nice programmer's API that can use any number of
back-ends, thereby empowering people to use the GUI widget set that
they prefer.
Sorry for the spelling errors; this was posted through Google Groups.