gutopia-dev
[Top][All Lists]
Advanced

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

Re: [rgui-dev] Idea for binding to the low level api


From: Massimiliano Mirra
Subject: Re: [rgui-dev] Idea for binding to the low level api
Date: Fri, 30 Aug 2002 12:16:02 +0200
User-agent: Mutt/1.3.28i

On Thu, Aug 29, 2002 at 09:52:54PM -0400, Rich Kilmer wrote:
> Tom,
> 
> Had a thought tonight on the way home.  I was using VRuby today and as I
> was coding it I looked at this code and thought...man I wish I could
> just generate this stuff.  So here is the idea.  Instead of building a
> binding library for a low-level toolkit...creating Classes to wrap each
> widget, etc, build a generator class that accepts the metadata
> (application/model), and builds a String that represents the Toolkit
> code; 

LOL!  Same environment, same stimuli...  I was about to (re)propose
this (I had months ago in the first rush of GUI topics on ruby-talk),
but you beat me to it.

My take is this: have you ever written DocBook/SGML?  It is a markup
language that looks like XML or HTML (both are children of SGML,
actually).  You write stuff like this:

<book>
  <part>
    <title>First part</title>
    <chapter>
      <title>GUIs</title>

      <section>
        <para>blah blah blah</para>

        <para>blah blah blah</para>
      </section>
    </chapter>
  </part>
</book>

Then you feed it to a processor together with a DSSSL (or XSL in the
case of DocBook/XML) stylesheet, and it spits out HTML, plain text,
TeX, DVI, PostScript...

One could write things like:

<gui>
  <window>
    <title>Blah</title>

    <checkbutton id="chkSomething">Something</button>
  </window>
</gui>

...and the processor would spit out GTK code, Tk code, etc.

Now DocBook/SGML output is static (except maybe for HTML output, which
could be said to answer the `click' event and `switch windows').  The
bridge to build for a GUI would be event handling.

NOTE: my gui example is not faithful to the DocBook one.  DB only
deals with structure and meaning, i.e. has no knowledge of how the
chapter, the section etc. are going to look.  My example is plain
wrong in this sense.  A more true example could be:

<interface>
  <section level="1">
    <title>Blah</title>

    <switch id="SomethingOnOff" title="Something"></switch>
  </section>
</interface>

The <switch> element would represent a widget that returns a boolean
value.  This can be the classic check button as well as the graphic,
animated depiction of a real switch, depending maybe on a style sheet.
By the same token, sections of level 1 can be a tabs in a tabbed
window as well as windows in a MDI application.


> then evals the code into the interpreter.  Maybe the code could be
> encapsulted in a Proc that accepts parameters like:
> 
> 
> class GTKGenerator
>   def GTKGenerator.generate(myApp, myModel)
>     code = "Proc.new do |application, model|\n"
>     
>     ...lots of stuff generated here which
>     represents all the widget creation that
>     the toolkit needs, setting up bindings
>     to events, etc...
> 
>     code << "end"
>     proc = eval(code)
>     proc.call(myApp, myModel)
>   end
> end

Take another small step and you can just generate ui_gtk.rb or
ui_tk.rb and require it from your program.  (The point of my initial
suggestion was to avoid runtime layers, because you don't really need
them once the application is up.  I added the stylesheet madness
later. ;->)


Massimiliano




reply via email to

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