gutopia-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rgui-dev] RE: Backend


From: Kero van Gelder
Subject: Re: [rgui-dev] RE: Backend
Date: Fri, 6 Sep 2002 21:38:58 +0200
User-agent: Mutt/1.4i

> so lets take Button from components.rb as an example:
[snip]
> take a look at the definitions of attribute() and event() in the
> Component class, which is very important b/c all the components inherit
> from this master class.

Yeah, all of them do. More on that later.

[snip]
> the most significant thing about the Component Class is that it has an
> instance varaible that holds a reference to the native backend
> component. that's how a GUtopIa widget is linked to the "real" widget.
> see the #create method in the Component class. that's where the backend
> widget is created.

except create() is never called...

  Gutopia::Window.new(:title=>"My First Window")

should construct a window, right? Preferably do some layouting
automatically and put it on-screen (no reason to call special methods
for that, by default).

So the Component comes from the abstract Gutopia class, right?

and who puts Component.body in there? when?

I think code examples that show how to use the ideas can make it much
more alive. At least for me. It also helps to answer the question
"What would be the ultimate GUI code for you?" 'coz writing it shows
what is still wrong.

> of course much of this is likely to change if we drop support for
> multiple backends and just support our own (i.e. ruby-wise)

Don't be too fast to drop it.
Part of the exercise is to find out some abstraction layer that fits
more than one toolkit. As soon as we use more than one, it's useful.

In my opinion (and therefore in Ruby-Wise), a Button is a Label that
can be clicked. Thus, it need not take care of displaying a String,
fonts and other things.

For a native binding, a Button would be a Gtk::Button, but that still
allows the Gutopia::Button to take its attribute(:event) from
Gutopia::Label

This OO exercise should keep the footprint of Ruby-Wise small.

> > What I'm missing is a picture like the Rouge alpha/beta/gamma.
> > Ruby-Wise was intended as the pure Ruby gamma implementation,
> > i.e. old-fashioned toolkit (but with all great features from
> > tk/gtk/andmore combined). Anything like XML, IDE, functional
> > reactivity, who-knows-what (maybe even layout managers?) is in layers
> > above.
> 
> not perfect or super detailed, but look at the picture here:
> 
>   http://www.rubygui.org/cgi-bin/wiki.pl?GUtopIa_Common_Meta-API
> 
> wise.rb is one of these backend wrappers.

Sorry, that's only obvious stuff...

The Markup halfway the page is not in the picture on top.

> > So, I've done a bit of setup for the runtime choice of native toolkit,
> > attached toolkit.rb
> 
> i looked at this but didn't quite follow. could you explain a little?

1) take a set of toolkits, sorted on Gutopia priority (whatever that is)
2) check whether there is a Ruby binding for each toolkit, (and that
   it can run, i.e. the toolkit itself exists)
3) check whether there is a running environment for each toolkit, 'coz
   a running environment means a user preference; Wise should be on
   this list as often as possible.
4) include the top-of-the-list in Gutopia, so the implementation of
   widgets is available, users can now call Gutopia::Window.new()

> also, the question as to whether we should even bother with other
> backends is up in the air. i really am leaning toward just supporting
> ruby-wise and developing it into the versitle "Chameleon".
> 
> i'm not sure what Leon'a stance on ParaGUI with GUtopIa is at this
> point. i know his goal for ParaGUI was to create a game, and perhaps
> he's already started into that with his bindings. of course my first
> thought was that ParaGUI would be able to serve as this chameleon tk,
> but Leon suggested that ParaGUI might not be up to the task. haven't
> heard anything about that since, only his suggestion that ruby-wise
> would probably the better route.
> 
> > After which I did a bit of hacking in Wise, where I got lost in
> >   "Some String".instance_of? String   => false
> > which is wrong, of course. But it doesn't help for productivity :(
> 
> how about kind_of?

Confused ::String and Wise::String :)


The hacking make steps towards constructors like:

  Button.new("Press here") { p "Pressed here!" }

instead of

  Button.new(nil, :text=>"Press here") { p "Pressed here!" }

and also allows Window.new(:modal) for Window.new(:modal=>true)
so this would allow for shorter code for the user.

I am still interested in making the Ruby-Wise API as convenient as
possible, and consequently what Gutopia provides directly above the
toolkit should not be "worse". In higher layers, many interesting
things can be done.

Tell you what, I'll think about components that are in X or otherwise
below Ruby-Wise. Some of those pop up within or above Ruby-Wise, like
the WM. If I work a bit on the docs of the API that is below
Ruby-Wise, I might just form a better opinion of the blocks
surrounding it in Gutopia.

+--- Kero ------------------------------ address@hidden ---+
|  Don't split your mentality without thinking twice       |
|                          Proud like a God -- Guano Apes  |
+--- M38c ---------- http://httpd.chello.nl/k.vangelder ---+





reply via email to

[Prev in Thread] Current Thread [Next in Thread]