GUI's and the Rouge, Part II

[Tom Sawyer]

in part one of this message i mention the problem of non-POLS and
ugliness when it came to hand coding a GUI interface. follow this link.
it is example code of the Rouge's utopia:

http://www.rubyide.org/cgi-bin/wiki.pl?RougeArchitecture/Alpha

i can honestly say this code is probably better than any i have ever
seen, but i'm sorry, it's still just dosen't look like my idea of gui
utopia. it is still a traditional approach, albiet very innovative in
its use of ruby's OO and iterators, it nonetheless follows the same
overall design characteristics of other tools: defining each and every
widget, designating *content* and style, their coorelation, and binding
procedures before passing off execution control (app.controller.start)
to the gui engine. but, i hear you thinking, "what other way is there?
that's just how it's done!" well, i emphisized content above because its
the key to a better approach. we can get a taste of this by looking
amrita:

http://kari.to/amrita/sources/docs/QuickStart

the beauty of amrita lies in the fact that the data which is to appear
in the end result contributes to its design. thus, in part, the layout
does not have to be specified because the data itself designates it. the
end result is cleaner leaner code. in effect amrita has done what OO
design is intended to do, it has given precedence to the data model.

although amrita is a unidirection html/xhtml templating system, her
principles just as easily carry over to guis. arbitrarily, as
programmers, we can think of it like this: instead of widget.displays(x)
we get x.widgetized. let me provide a mock code fragment to help
clearify. we'll call our imaginary gui toolkit, RougeDuex.

require 'rougeduex'

class MyClass
attr_accessor avar
def initialize
@avar = ""
end
end

myobj = MyClass.new
myobj.avar.extend RougeDeux::WidgetFactory(:Label)

mywin = RougeDuex::WidgetFactory(:Window).show
mywin.embody {
pack myobj.avar, RougeDuex::TOP
}

myobj.avar = "Hello, World!"

and just like that we have a window with a label in it greeting us.

you might notice something a bit odd about this very simple example: the
window was displayed prior to the label being added. this is a key
point. by retaining execution, such that the gui is a spawned processes,
we retain the ability to modify it "on-the-fly". just think of all the
neat tricks we can do with that! no longer are we limited to just the
event model of the gui's engine. morever, notice that the class
definition is completly clean. there's no mention of RougeDuex anywhere
in it, nonetheless it is direclty linked to our gui. should avar change
for any reason, so will our label. and if avar were a text entry field
or any other input widget, instead of a label, avar would automagically
reflect that input.

you may wonder how other aspects of avar as a label get designated. well
since avar was extended to be a label it gained a few things that allow
us to do that: myobj.avar.style={:color=>'red'}, for example. no
problem!

also one might be concerned about performance with such dynamic
rendering, since anytime one changes a variable the gui requires
refreshing. well, a transaction model can help with that were it is
essential.

so there's the ideal, my friends. i am sure certain elements of the
current Rouge project could be carried over into this, and i think the
end result would be the easiest, most intuitive and fun (like ruby!) gui
to ever have the priviledge of being coded by you ;-)

in the last part of my series (don't ask me what posessed me to do this,
i don't know!) i'll go into the possabilities of implementation.

~transami

_(")_ v man
\v/
^ ^

[Ned Konz]

On Saturday 20 July 2002 10:00 am, Tom Sawyer wrote:
> we can think of it like this: instead of widget.displays(x)
> we get x.widgetized.

The main problem with this is that the data shouldn't have to know
about how it's going to be presented.

When you want to display something on (say) a PDA, you might choose to
have different representations (shorter strings, no colors, etc.).

Maybe the best strategy would be to have an intervening policy object
between the data and the widgets that determines how a given piece of
data would be presented in a particular kind of UI.

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

[Albert Wagner]

I'm sorry, Tom, but I don't see a really new direction in your comments. It
appears that you have simply repackaged/renamed the current solutions to
writing a GUI program. Perhaps I am just slow-witted or perhaps my opinion
is premature and I should wait on more details. Let me specify the sources
of my confusion:
1) GUI design is more of an art form than a technology. I don't believe that
good design of a user interface can be automated.
2) How is replacing a GUI specification with a template an improvement? The
same design decisions that go into a GUI specification will have to go into
template design.
3) It seems that you are unhappy with the concept of a mainloop and
callbacks. Yet, the whole purpose of a GUI is not to just display data but
to monitor the user's actions and carry out his intent. The user's
keyboard/mouse actions are an event that triggers a cascade of internal
events. How would you handle this?

What am I missing?

[Tom Sawyer]

On Sat, 2002-07-20 at 12:25, Ned Konz wrote:
> The main problem with this is that the data shouldn't have to know
> about how it's going to be presented.
>
> When you want to display something on (say) a PDA, you might choose to
> have different representations (shorter strings, no colors, etc.).
>
> Maybe the best strategy would be to have an intervening policy object
> between the data and the widgets that determines how a given piece of
> data would be presented in a particular kind of UI.

thanks Ned,
a good point. but thanks to ruby we can deal with this farily easily w/o
having to resort to intervening objects by seperating parts of a class
definition. just as one extends a class now one can create conditional
extenstions dependent, say, on the platform. for exmaple:

pda.rb:
class MyClass
def initialize
super
avar.extend RougeDeux::WidgetFactory(:Label)
avar.style={:width=>10}
end
end

pc.rb:
class MyClass
def initialize
super
avar.extend RougeDeux::WidgetFactory(:Label)
avar.style={:width=>100}
end
end

myapp.rb:

class MyClass
attr_accessor avar
def initialize
@avar = ""
end
end

require pda.rb if $interface='PDA'
require pc.rb if $interface='PC'

so this is one approach. in a sense it is like an intervening object,
only it's an intervening definition. (note: this does "confuscate" the
object, but it does it in a clean, well seperated manner) i'm sure there
are others ways. one thing i hadn't taken into account, that your post
made me consider is the idea of stylesheets --convenient ways to set the
properties of a large number of widgets at once. but i'm sure that would
not be too difficult to factor in.

~transami

--
~transami

_(")_ dobee dobee do...
\v/
^ ^

[Rich Kilmer]

Apologize in advance...this is a LONG response...

> -----Original Message-----
> From: Tom Sawyer [mailto:tran...@transami.net]
> Sent: Saturday, July 20, 2002 1:01 PM
> To: ruby-talk ML
> Subject: GUI's and the Rouge, Part II
>
> in part one of this message i mention the problem of non-POLS and
> ugliness when it came to hand coding a GUI interface. follow this
link.
> it is example code of the Rouge's utopia:
>
> http://www.rubyide.org/cgi-bin/wiki.pl?RougeArchitecture/Alpha

Well I have not looked at this in a bit. I wrote this in an evening as
more of a proof of concept than anything else. Sean Russell had ideas
that appear to follow yours more closely than mine. BTW: I have
uploaded the source that enabled this to:
http://www.infoether.com/ruby/utopia.zip

It does not show it in the example, but the attributes and available
widget definitions are completely extensible in the model (see
utopia.rb). Again, it was more of an experiment than a "real solution"
to the problem of GUI abstraction.

>
> i can honestly say this code is probably better than any i have ever
> seen, but i'm sorry, it's still just dosen't look like my idea of gui
> utopia. it is still a traditional approach, albiet very innovative in
> its use of ruby's OO and iterators, it nonetheless follows the same
> overall design characteristics of other tools: defining each and every
> widget, designating *content* and style, their coorelation, and
binding
> procedures before passing off execution control (app.controller.start)

First, execution control is not necessarily passed off by starting the
controller. It does not have to be, but since Ruby's threading is
non-native, most UI toolkits kind of take over. This could be addressed
(without adding native threads to Ruby)...such as having another process
that presents and controls the UI and communicates to the Ruby process
via a socket...like X.

Second, I have no problem with binding an object-attribute in as a
binding to a widget. Like:

class MyClass
attr_accessor :avar
def initialize
@avar = ""
end
end
myobj = MyClass.new

myLabel(:label).text(bind_object(myobj, :avar))

and when the method bind_object is called it aliases the original avar=
method with one that updates the Label's 'text' attribute (and vice
versa).

Or to more align with your example below:

myobj.extend Utopia::WidgetBinder
myobj.bind_widget(mainWindow.myLabel, :avar)

> to the gui engine. but, i hear you thinking, "what other way is there?
> that's just how it's done!" well, i emphisized content above because
its
> the key to a better approach. we can get a taste of this by looking
> amrita:
>
> http://kari.to/amrita/sources/docs/QuickStart
>
> the beauty of amrita lies in the fact that the data which is to appear
> in the end result contributes to its design. thus, in part, the layout
> does not have to be specified because the data itself designates it.
the
> end result is cleaner leaner code. in effect amrita has done what OO
> design is intended to do, it has given precedence to the data model.

Well, in amrita, the hierarchy of the data has to match the hierarchy of
the (HTML) UI. As can be shown in this example from the QuickStart doc
above:

<table border="1">
<tr><th>name</th><th>author</th></tr>
<tr id="table1">
<td id="name"><td id="author">
</tr>
</table>

data = {
:table1=>[
{ :name=>"Ruby", :author=>"matz" },
{ :name=>"perl", :author=>"Larry Wall" },
{ :name=>"python", :author=>"Guido van Rossum" },
]
}

You see, the minimum you need is a hierarchy in your design of the UI
because UIs are built using a "container/component" model. My example
from utopia presented a simple hierarchy, but one that needs to be
specified somewhere. That I fully specified all of the attributes of
the elements in the UI...up front...does not mean it needs to be so.
You could do:

require 'utopia'

app = Utopia.new_application("My Application")

mainWindow = app.modeller.build(:window).body {
icon(:icon)
menu(:menubar).items {
file(:menu)
help(:menu)
}
fruit_panel(:panel).body {
firstName(:textfield)
lastName(:textfield)
favoriteFruit(:textarea)
submit(:button)
clear(:button)
}
}

Then do:

mainWindow.fruit_panel.body.firstName.text.bind_object(obj, :foo);

>
> although amrita is a unidirection html/xhtml templating system, her
> principles just as easily carry over to guis. arbitrarily, as
> programmers, we can think of it like this: instead of
widget.displays(x)
> we get x.widgetized. let me provide a mock code fragment to help
> clearify. we'll call our imaginary gui toolkit, RougeDuex.
>
> require 'rougeduex'
>
> class MyClass
> attr_accessor avar
> def initialize
> @avar = ""
> end
> end
>
> myobj = MyClass.new
> myobj.avar.extend RougeDeux::WidgetFactory(:Label)
>
> mywin = RougeDuex::WidgetFactory(:Window).show
> mywin.embody {
> pack myobj.avar, RougeDuex::TOP
> }
>
> myobj.avar = "Hello, World!"
>
> and just like that we have a window with a label in it greeting us.

OK, now give me syntax for the example I presented on the the rubyide
site. Your idea of mixing the widget capability into the object is
cool, but how the widgets get organized on the screen needs to be
defined somewhere.

>
> you might notice something a bit odd about this very simple example:
the
> window was displayed prior to the label being added. this is a key
> point. by retaining execution, such that the gui is a spawned
processes,
> we retain the ability to modify it "on-the-fly". just think of all the
> neat tricks we can do with that! no longer are we limited to just the
> event model of the gui's engine. morever, notice that the class

Again, I absolutely agree with you, and I don't think we should be
limited to the event model of the GUI (OS'es aren't).

> definition is completly clean. there's no mention of RougeDuex
anywhere
> in it, nonetheless it is direclty linked to our gui. should avar
change
> for any reason, so will our label. and if avar were a text entry field
> or any other input widget, instead of a label, avar would
automagically
> reflect that input.

Again, having the UI widgets bind to non-UI objects is cool, as I showed
above.

>
> you may wonder how other aspects of avar as a label get designated.
well
> since avar was extended to be a label it gained a few things that
allow
> us to do that: myobj.avar.style={:color=>'red'}, for example. no
> problem!
>
> also one might be concerned about performance with such dynamic
> rendering, since anytime one changes a variable the gui requires
> refreshing. well, a transaction model can help with that were it is
> essential.
>
> so there's the ideal, my friends. i am sure certain elements of the
> current Rouge project could be carried over into this, and i think the
> end result would be the easiest, most intuitive and fun (like ruby!)
gui
> to ever have the priviledge of being coded by you ;-)

I am not hung up on anything done so far (it was a quick hack), but we
need to see semi-realistic examples with windows, menus, events, etc.

>
> in the last part of my series (don't ask me what posessed me to do
this,
> i don't know!) i'll go into the possabilities of implementation.
>

I will look forward to it.

[Tom Sawyer]

On Sat, 2002-07-20 at 12:49, Albert Wagner wrote:
> 1) GUI design is more of an art form than a technology. I don't believe that
> good design of a user interface can be automated.

quite right! it can't be. but we certainly can make the tools for its
PRODUCTION easier.

> 2) How is replacing a GUI specification with a template an improvement? The
> same design decisions that go into a GUI specification will have to go into
> template design.

why do people use template systems at all? but actually i'm not saying a
template is neccessary. in fact my code example had no mention of a
template. so i'm not replacing a GUi spec with a template. yet i think
template systems are very powerful tools and Rouge or whatever should
have one.

> 3) It seems that you are unhappy with the concept of a mainloop and
> callbacks. Yet, the whole purpose of a GUI is not to just display data but
> to monitor the user's actions and carry out his intent. The user's
> keyboard/mouse actions are an event that triggers a cascade of internal
> events. How would you handle this?

this would work much like the gui's we use today. the gui engine still
processes events, and we still provide a means for action when those
events are triggered. i am only proposing the additional ability to
continue execution of the "main line" in parrallel to this. there's
nothing wrong with triggers/events, but i believe it is limiting to be
wholly dependent on those and thus having to internalize ones code into
the gui constructs via procs. in effect, and i don't think i have fully
explored this, i am trying to successfully turn the gui to app
interfacing inside-out.

[Massimiliano Mirra]

On Sun, Jul 21, 2002 at 02:00:47AM +0900, Tom Sawyer wrote:
> point. by retaining execution, such that the gui is a spawned processes,
> we retain the ability to modify it "on-the-fly". just think of all the
> neat tricks we can do with that! no longer are we limited to just the
> event model of the gui's engine.

I've done something like that in the past from irb with:

Thread.new { Gtk.main }

> you may wonder how other aspects of avar as a label get designated. well
> since avar was extended to be a label it gained a few things that allow
> us to do that: myobj.avar.style={:color=>'red'},

That last one defies your purpose because it mixes model and
presentation (a lot).

Have you thought about automatic code generation? Rather than
having GUI code mixed in the model (implicitly or explicitly), what
about, given a model class, automatically generating a class that
in turn automatically generates the appropriate GUI? Something like...

class MyModel
def initialize
@avar = ""
@another = 0
end

def avar
@avar
end

def avar=(value)
@avar=value
end

def another
@another
end

def another=(value)
@another=value
end
end

setter_getter_pairs = [
[:avar, :avar=],
[:another, :another]
]

MyGui = GuiFactory.new(MyModel, setter_getter_pairs)

my_instance = MyModel.new

my_instance_gui = MyGui.new(my_instance, parent_widget)

Also consider chances like...

my_instance_gui = MyGui.new(my_instance, parent_widget, stylesheet)

I've defined avar= and another= explicitly. Remember that when you are
calling myobj.var=something, for GUI purposes you probably don't want to
catch the assignment of whatever variable(s) get assigned within the var=()
method of myobj, but rather the symmetrical value returned by the var()
method (think of a class that stores the time in milliseconds
internally but gets it from and tells it to the rest of the world in
form of a string "Sunday 4, Mar...").

My .$02.

Massimiliano

[Tom Sawyer]

On Sat, 2002-07-20 at 13:26, Rich Kilmer wrote:
> Apologize in advance...this is a LONG response...

no no that's great!

> Well I have not looked at this in a bit. I wrote this in an evening as
> more of a proof of concept than anything else. Sean Russell had ideas
> that appear to follow yours more closely than mine. BTW: I have
> uploaded the source that enabled this to:
> http://www.infoether.com/ruby/utopia.zip

great, i'll check it out.

> First, execution control is not necessarily passed off by starting the
> controller. It does not have to be, but since Ruby's threading is
> non-native, most UI toolkits kind of take over. This could be addressed
> (without adding native threads to Ruby)...such as having another process
> that presents and controls the UI and communicates to the Ruby process
> via a socket...like X.

that occured to me too. are there other means to this, or is socket
communication the only way. probably the best way anyway, though.

> Second, I have no problem with binding an object-attribute in as a
> binding to a widget. Like:
>
> class MyClass
> attr_accessor :avar
> def initialize
> @avar = ""
> end
> end
> myobj = MyClass.new
>
> myLabel(:label).text(bind_object(myobj, :avar))
>
> and when the method bind_object is called it aliases the original avar=
> method with one that updates the Label's 'text' attribute (and vice
> versa).

that's great. i didn't see this in utopia. i was able to manage the same
thing with my miterbox (my rouge like project). but that's a one way
street. the difficulty here is going back the other way: when the bound
variable changes the gui gets automagically updated. i found this to be,
as of yet, an insurmountable problem.

> Or to more align with your example below:
>
> myobj.extend Utopia::WidgetBinder
> myobj.bind_widget(mainWindow.myLabel, :avar)

this notation really works? cool!

> Well, in amrita, the hierarchy of the data has to match the hierarchy of
> the (HTML) UI.

..

> OK, now give me syntax for the example I presented on the the rubyide
> site. Your idea of mixing the widget capability into the object is
> cool, but how the widgets get organized on the screen needs to be
> defined somewhere.

..

> I am not hung up on anything done so far (it was a quick hack), but we
> need to see semi-realistic examples with windows, menus, events, etc.

i apologize, my example was not a good one for as showing off the amrita
concepts as applied to guis. i will work on doing so and post it.

also keep in mind, i don't have all this fully flushed out. i have just
been spending a lot of time on the gui abstraction problem, because i
have a big bad old gui forntend to write. given its breadth i have been
trying to create an abstraction to facilitate this and make my life
easier in the long run. hence the source of these concepts. hopefully i
can work it out rather then having to hand code all of it.

in that light, just how far a long is utopia? is there any development
activty going on with it or related to the Rouge project? what's the
status there?

thanks for the in depth reponse!

[Rich Kilmer]

> -----Original Message-----
> From: Tom Sawyer [mailto:tran...@transami.net]
> Sent: Saturday, July 20, 2002 4:01 PM
> To: ruby-talk ML

Well, we could abstract the communications ;-) sockets would allow it
to be remoted...which would rock.

BTW, the "change the object's attribute and you change the widget"
problem can be solved by aliasing the setter method on the attribute
with one that updates the UI and then calls the original method.

> <SNIP>

>
> i apologize, my example was not a good one for as showing off the
amrita
> concepts as applied to guis. i will work on doing so and post it.
>
> also keep in mind, i don't have all this fully flushed out. i have
just
> been spending a lot of time on the gui abstraction problem, because i
> have a big bad old gui forntend to write. given its breadth i have
been
> trying to create an abstraction to facilitate this and make my life
> easier in the long run. hence the source of these concepts. hopefully
i
> can work it out rather then having to hand code all of it.
>
> in that light, just how far a long is utopia? is there any development
> activty going on with it or related to the Rouge project? what's the
> status there?
>

Utopia is what you got. It's an exploration into the GUI abstraction
problem. Rouge stalled some months ago. Sean Russell has been focusing
on REXML and I don't if he has advanced Rouge any. I am interested in
this, but I stopped working on it to focus on some other things
(jabber4r, FreeBASE/FreeRIDE, JXTA/RXTA, My own company, etc).

On an aside, you may actually want to look at FreeRIDE (the Ruby IDE) We
are abstracting GUI components to allow multiple 'renderers'. It's at
that site you were on (www.rubyide.org). It's currently using RXRuby
and VERY alpha-stage, but may give you some ideas.

-rich

[Tom Sawyer]

On Sat, 2002-07-20 at 13:30, Massimiliano Mirra wrote:
> Have you thought about automatic code generation? Rather than
> having GUI code mixed in the model (implicitly or explicitly), what
> about, given a model class, automatically generating a class that
> in turn automatically generates the appropriate GUI? Something like...
>

> My .$02.

and a damn good $.02 it is!

i need your help with one thing though. could you give me a simple
example of generating a class?

thanks!

~transami

[Tom Sawyer]

On Sat, 2002-07-20 at 12:25, Ned Konz wrote:
> Maybe the best strategy would be to have an intervening policy object
> between the data and the widgets that determines how a given piece of
> data would be presented in a particular kind of UI.

hey Ned! your concept of an intervening "object" turned out to be right
on! i didn't realize it at first, but massimiliano was saying essentialy
the same thing. i worked through it all and you two were on the money.
thanks!

hope you like it...

~transami

_(")_ v: i am not an alien
\v/
^ ^

[Curt Hibbs]

Tom Sawyer wrote:

[snipped lots and lots of interesting stuff]

Tom, the RougeProject came from a convergence of two things: Sean Russell's
personal desire for a more elegant way do GUIs in Ruby, and the FreeRIDE
project's frustration of not being able to find a GUI toolkit that fully met
all of our requirements. What you see for the RougeProject on the FreeRIDE
wiki (http://www.rubyide.org/cgi-bin/wiki.pl?RougeProject) is result of a
month long ML discussion back in Feb/Mar amongst about a dozen Ruby
developers.

Most of us who participated in the discussion did so because we were all
intensely interested having a GUI toolkit had both the same sort of elegance
and ease-of-use that REXML brought to XML processing *and* did not have any
of the annoying deficiencies found in the currently available GUI toolkits.
This was a very tall order, both in terms of design and in the amount of
effort that would be required to implement it. But definitely worthwhile, if
it could be achieved.

More than half of the participants in these discussions were FreeRIDE
developers. We wanted to use such a GUI toolkit within FreeRIDE and had a
very personal interest in contributing ideas and helping to shape the
result. But FreeRIDE is, itself, a very large effort and we could not afford
to divert any development effort off of our own project.

So, as Rich Kilmer pointed out, the implementation effort has appeared to
have stalled (Sean, if I'm wrong about that, please correct me), not from
lack of interest, but for the lack of a strong and passionate leader who has
the available time to champion this project and rally other developers to
join in.

I'm hoping that your knowledge, energy, and enthusiasm can translate into a
sustainable project from which all of us in the Ruby community can benefit
(including FreeRIDE).

To that end, I would like to invite you to create one or more pages on the
FreeRIDE wiki to capture the results of your recent discussions and
thoughts. And if you are interested in pushing forward with this, I would
even be willing to set up and host a separate wiki just for this project.

Curt

[Massimiliano Mirra]

On Sun, Jul 21, 2002 at 05:53:48PM +0900, Tom Sawyer wrote:
> i need your help with one thing though. could you give me a simple
> example of generating a class?

I see from your posts about module_eval and define_method that you've
already discovered more than I could have told you. :-)

Massimiliano

[Tom Sawyer]

On Mon, 2002-07-22 at 05:45, Massimiliano Mirra wrote:
> I see from your posts about module_eval and define_method that you've
> already discovered more than I could have told you. :-)

yes, thanks. i managed to hack it out. :-)

--

[Patrick May]

Ned Konz <n...@bike-nomad.com> wrote in message news:<200207201...@ned.bike-nomad.com>...

> On Saturday 20 July 2002 10:00 am, Tom Sawyer wrote:
> > we can think of it like this: instead of widget.displays(x)
> > we get x.widgetized.

This ties into a discussion I was having about coding and testing html
-- that it's better to use widgets to make html easier to test, not to
prevent you from having to write html. i.e., instead of writing:

Form:Text.new( "name", "default name", :size => 30; :maxlength => 40 )
Form:Pass.new( "password", "", :size => 30; :maxlength => 40 )

to replace

Name: <input type=text name=name value="default name" size=30
maxlength=40>
Pass: <input type=password name=name value="" size=30
maxlength=40>

You have:

Login.form # => outputs the above html

which we thought of as an application specific widget containing the
two form elements. The goal here would be to break the presentation
into "widgetize" methods that make it easier to test the html.

However, this isn't something that would the basis for a library.
These widgets need to be as general as possible to be useful, instead
of GUI widgets which are made to be as flexible as possible. I guess
the goal is to code for reuse within your application, not for reuse
outside of your application.

> The main problem with this is that the data shouldn't have to know
> about how it's going to be presented.
>
> When you want to display something on (say) a PDA, you might choose to
> have different representations (shorter strings, no colors, etc.).

I think it's rare that you would want the same application on a PDA
and a desktop. The limitations of a PDA go beyond the size and color
depth of the framebuffer; there are also major input considerations.
In a MVC architecture I don't see much benefit to sharing the the view
or controller code between dramatically different platforms (unless
the problem is dramatically simple, such as a calculater).

~ Patrick

[Tom Sawyer]

a bit of an intro: my original thought on the matter of making a
rubyesque gui api was to use the power of mixins to make objects
automagically linked to a gui form. while that still has some appeal,
massimillano mirra and ned konz pointed that this really meshes the gui
to tightly with the objects them self, resulting in poor SOC (seperation
on concerns) and limited code reuse. i thought about the matter in depth
and decided that they were right. there would be great advantage, if
done well, form creating an intermidiary beteen application objects and
the gui they are to interact with. so i set my sites on that goal and
reworked my ideas --the result looks quite promising. thank you
massimillano and ned.

but before i get into the nitty-gritty of ruby code. lets back up a
attack some over all architecture issues.

it was stated that a main goal of Rouge was to create a cross-compatible
gui api that "boiled down" into the native gui of each platform. in my
first post on these matters, i pointed out how ungodly difficult that
would be (as i had been trying to do that myself). in the end either you
left to "patch" your app for each platform or you simply have to give up
the features that they hold in common (at best). it really is simply too
much of pain to create such an system, not to mention maintaining it as
those underlying native api change. yet the goaol os a native look and
feel is not unachievable by other means. the solution is simply a matter
of using an underlying gui engine that is sufficiantly themeable. since
all the major gui's are now themable themselves, we simply need to code
a theme manager that can import the themes of those other guis. we need
not use their underlying api, only their look and feel! so that's what
can be done to solve that dilemma: use a sufficantly themeable gui api
and crreat and Themes and Behaviors Manger to emulate the look and feel
and even draw upon the native theme configuration files. this is a much
managable task then trying to channel down to the native guis
themselves. the only trick of course is finding that themeable gui api.

well, as things often are, it's a tale of two. my first hope lied in a
gui api called ParaGUI:

http://www.bms-austria.com/projects/paragui/

this is a nice gui api based on SDL which is in turn based on OpenGL. it
is a little immature as of yet, but can be themed. but just to be sure i
looked around a bit more. i filter through a number of others, GLUT and
GLUI come to mind, but then i found something all together better. well,
that's is at least how it looks. you never actually knwo until you get
into it, but even so we could always fall back to ParaGUI. but what i
found wasn't labled strictly as a GUI, becasue it ws so much more. it
was a complete game sdk! but had all the standard gui widgets that one
could want but a whole lot more to boot. and yes, it was themeable. a
god send! check it out:

http://www.clanlib.org/documentation/ClanLib-0.7/Reference/html/classes.html

now were cooking. one last issue: execution control. rich kilmer
mentioned the possibility of using sockets: "This could be addressed

(without adding native threads to Ruby)...such as having another process
that presents and controls the UI and communicates to the Ruby process

via a socket...like X." and i think too that this is a fantastic idea.
so that's the final piece and we end up with basically this:

+------ +--------+ +--------+----------------+
| A ~| Ruby | DRb? | Ruby ; Ruby | ClanLib |
| Ruby ~| GUI |<------------>| GUI ; Wrap +---------+
| App ~| Client | yaml? | Server ; | Themer |
+------ +--------+ +--------+----------------+

now the communications layer can be optional, that's now big task to
have it be able to work both ways, so were speed made be extra critcal
it could be left out. but that's the over layout. and i think its a
design that that is well worth the effort to create.

i'm going to take a break now before going into the ruby code: but i
have created the beginnings of what i'm calling GUtopIa. more in a
bit...

~transami

[Tom Sawyer]

well, i just read over my last post. sorry about all the typos. i needed
a break and didn't bother to proofread. but i'm sure you can make out
what i was trying to say where i blurbed. okay, now to the good stuff!

i spent the last few days hacking out the first steps in the creation of
a super-duper ruby gui api, which i have dubbed GUtopIa (thanks rich).
just to kick things off here's a small clip of one of my examples (note
MyModels is drawn from an unshown require):

INTERFACE = 'PDA'
fruitapp = FruitApp.new
mygui = GUtopIa::GUI.new('Fruity Fun Time')
names = {
'awindow' => fruitapp.appname,
'aradio' => fruitapp.fruitbasket.name
}
bindings = {
fruitapp.fruitbasket.name => {
:value => Proc.new { fruitapp.fruit.isa },
:value= => Proc.new { |x| fruitapp.fruit.isa = x },
:items => Proc.new { fruitapp.fruitbasket.contains },
:event_change => Proc.new { fruitapp.pickafruit }
}
}
model = MyModels.pick_model(mygui, INTERFACE)
mygui.transaction(bindings, names, &model)
mygui.build

the idea is that you take an instance of your application (FruitApp in
this case), completely untouched --you don't have to add or change a
single line of code (unless you want too ;-) you then create a model. a
model (not shown in example) is an executable description of the fixed
aspects of your gui. it has no references to any part of your app
(although you can do so if you don't care about SOC) it is a completely
independent entity and as such can be reused in other fitting contexts.
you can also draw on multiple sub-models. then you create a binding (as
seen above). this describes how an instance of your application
"interfaces" with your model. and then presto out comes you gui-ized
app.

also note that GUtopIa uses a transaction mechinism. this effectivly
bundles an executable model into a single execution. not only does this
increase speed, but also offers a means to rollback the effects of a
transaction should there be an error, adding much greater stability to
your gui-ized application.

some other things to note: bindings are actually integrated directly
into the class models of the widgets. when a widget is created it is
subclassed into a specialized class of that widget which includes
methods to react to the bindings described.

i've attached my work thus far so you can checkout all of this in
detail. be sure to run example.rb (the snipet above) and check out
orig-example.rb, which is a non-SOC version of the original Rouge/Utopia
example. then check out gutopia.rb which is the heart of the matter.

so that's the the word on implementation. i've taken the advice of
others and i have worked out what i think is shaping up to be the best
gui api design in existence. Curt Hibbs has offered me a wiki for this
project. (thanks curt) i will take him up on it. now i hope i can get
YOU enthused enough to help. there's real potential here, to not only
create an awsome gui api for ruby that is unique and powerful, but also
create a full-fledge game sdk! this thing looks to be awesome indeed.

i need people to take on a few tasks. a ruby wrapper needs to be created
for ClanLib and we need to build a Themes and Behaviors manager. someone
needs to hack out the communications layer (i've tried it with DRb and
ROMP but they bomb). and i could use some help finishing off the main
api. if we can pull together on this, ruby, our favorite little
scripting language, will have its very own GUI to rival all others!

as you might be able to tell, i'm very excited! i hope you are too!

thanks for your time and hope to hear from you,

~transami :-)

[Clifford Heath]

Tom Sawyer wrote:
> it was stated that a main goal of Rouge was to create a cross-compatible
> gui api that "boiled down" into the native gui of each platform.

As you've found, it's a *major* piece of work. I should know - I designed
and my company built such a product (called OpenUI) in the 1st half of
the 90's. There are better toolkits out there for this now, of which I like
Qt and fxruby best. You definitely shouldn't build your own, it's a problem
that needs multiple hundreds of thousands of lines of code to solve.

> i think too that this is a fantastic idea.
> so that's the final piece and we end up with basically this:

You've described the architecture of OpenUI, but perhaps haven't understood
the factor that makes it really work: rich asynchronous message passing.

I'm still of the firm opinion that this is the single integrating feature
which is needed to revolutionise GUI programming. Message delivery needs
to be based on hierarchies of objects, including propagation of undelivered
(or partly-delivered) messages up the hierarchy, publish-subscribe propagation
down the hierarchy, and proxy-address mapping for remote objects. Add that to
the basic queueing facilities needed for asynchronous delivery, with a
priority-nesting feature to provide some minimal sequencing control for
consequential messaging (needed for remote validation for example), and you
have an exceptionally powerful and flexible application framework supporting
separation of presentation and semantic content to the fullest extent possible.

The native GUI widgets should be assembled into hierarchies not by API calls,
but by a hierarchical description language - XML probably. In fact I started
making "qtml" - a Qt markup language, which allows simple assembly of arbitrary
widget hierarchies (UIs), and embedded scripting to animate and control the UI.
I'd love to use Ruby with this, it's the most suitable language for the purpose.

Sorry that much of the above discussion is kind-of schematic, incomplete and
probably confusing, I can discuss the ideas further if they ring anyone's
bells. Suffice it to say that people who've used these ideas in the form of
our (now obsolescent) product have found them to be truly revolutionary.

--
Clifford Heath

[Albert Wagner]

Still looks like plain old Model-View-Controller to me. You've split the
controller into client and server parts. What is the purpose of separation
into different processes? I don't mean to sound critical. I really don't
understand what you are trying to achieve.

[Tom Sawyer]

On Tue, 2002-07-23 at 19:07, Clifford Heath wrote:
> Tom Sawyer wrote:
> > it was stated that a main goal of Rouge was to create a cross-compatible
> > gui api that "boiled down" into the native gui of each platform.
>
> As you've found, it's a *major* piece of work. I should know - I designed
> and my company built such a product (called OpenUI) in the 1st half of
> the 90's. There are better toolkits out there for this now, of which I like
> Qt and fxruby best. You definitely shouldn't build your own, it's a problem
> that needs multiple hundreds of thousands of lines of code to solve.

interesting OpenUI...well i'm not really building my own. i'm building a
layer on top of pre-existing api (ClanLib). wouldn't really consider
writing it all from scratch.

> > i think too that this is a fantastic idea.
> > so that's the final piece and we end up with basically this:
>
> You've described the architecture of OpenUI, but perhaps haven't understood
> the factor that makes it really work: rich asynchronous message passing.
>
> I'm still of the firm opinion that this is the single integrating feature
> which is needed to revolutionise GUI programming. Message delivery needs
> to be based on hierarchies of objects, including propagation of undelivered
> (or partly-delivered) messages up the hierarchy, publish-subscribe propagation
> down the hierarchy, and proxy-address mapping for remote objects. Add that to
> the basic queueing facilities needed for asynchronous delivery, with a
> priority-nesting feature to provide some minimal sequencing control for
> consequential messaging (needed for remote validation for example), and you
> have an exceptionally powerful and flexible application framework supporting
> separation of presentation and semantic content to the fullest extent possible.

rich asynchronous message passing. does it really need to be that
"fancy"? perhaps. the communications layer is optional, but i tend to
think standard tcp/ip + marshaling might do the job. after all networked
games these days don't use much more. (i think). if this part proves too
much of a bottle neck we can either do without it or hopefully pull
together something more like what you describe. ClanLib also includes
some networking features for netowked games. perhaps that would be
useful.

> The native GUI widgets should be assembled into hierarchies not by API calls,
> but by a hierarchical description language - XML probably. In fact I started
> making "qtml" - a Qt markup language, which allows simple assembly of arbitrary
> widget hierarchies (UIs), and embedded scripting to animate and control the UI.
> I'd love to use Ruby with this, it's the most suitable language for the purpose.

well, i disagree here. i thought about that option: whether the models
should be in markup versus executable code. i went executable b/c we can
always make markups that "compile" into the transaction code. but you
may be interest in a little program that i threw together that builds tk
interfaces from xml. i've attached it. you'll need rexml to run it and
you may need to tweak the require statements. tkxml-l.rb is the simple
example.

> Sorry that much of the above discussion is kind-of schematic, incomplete and
> probably confusing, I can discuss the ideas further if they ring anyone's
> bells. Suffice it to say that people who've used these ideas in the form of
> our (now obsolescent) product have found them to be truly revolutionary.

no apology required. thanks for the comments. i'm interested to know
more about OpenUI and if you should decide that you could contribute to
the project please let me know.

~transami

[Tom Sawyer]

let me paint a picture:

you have this super application you wrote --the underbelly of an
factastic hoogy-me-whatsy-do-it-all app and now you have to figure out
how to put a front-end on her. so you need a gui. hmmm...you think, i
want a gui thats flexible and fast nad highly functional, runs on just
about any platform, looks good, preferably just like the native
interface, and is easy as pie to code so as not to require much fussing
with the app you've alredy written.

well, if you look around you're going to discover that everything out
there now has shortcomings. beleive me i've looked. so what do you do?
you either pick one that minimizes the shortcomings as suited to your
application, or you do what i'm trying to do: put an end to the problem.
how does that bode for what i'm trying to achieve?

as for plain old Model-View-Controller, honestly, i have no idea what
that even means. i just did what seemed natural. perhpas MVC is just the
right way to go?

~transasmi

--
~transami

[Clifford Heath]

Tom Sawyer wrote:
> wouldn't really consider writing it all from scratch.

cool, just so you know.

> rich asynchronous message passing. does it really need to be that
> "fancy"? perhaps. the communications layer is optional, but i tend to
> think standard tcp/ip + marshaling might do the job.

Actually it isn't much more than tcp/ip and marshalling, until you get into
the distributed object issues. The key thing here is that behaviour inside
the GUI is also controlled by async msgs - every key up/down, every mouse
up/down/motion is a message which is dynamically matched against message
handlers on the objects - so messages act like a delayed dynamic procedure
call with re-routing. If an object has no handler for a message, or the
handler returns false (saying "handling not complete"), the message is
propagated up to the parent and tried there. When/if it hits the session
object, if that session object is one end of a connection, the message is
marshalled and queued for transmission.

Re publish/subscribe, before a message can be delivered to an object, a check
is made whether any descendents of that object are listening (subscribers) on
that object for that message or one of its superclasses. In this way a GUI
main window can be set up to receive a message containing all the data values
required to fill out the fields, and the individual widgets subscribe to that
message on the main window, so that the message is delivered to each of them
before being delivered to the main window object itself. That solves the
scatter part of the scatter/gather problem to be solved with the main window
even needing to know which widgets display which data fields.

The distributed object system is maintained by the marshall process, which
turns any object reference from a pointer into either a "local reference" or
a "remote reference". A local reference corresponds to a local object which
is being exported; the reference is maintained in a table of exported local
objects. On the other end, each local reference received from the other end
gets maintained in a table of proxy objects. When marshalling messages in
return, a pointer to a proxy object gets turned back into the original local
reference from the other end.

In this way, any number of objects spread across arbitrary networks of
point-to-point nodes may be addressed without requiring a UUID scheme, and
any message targeted to any object will be routed back via the connection
from which that object became known. BTW I don't know if anyone else has
invented this scheme or patented it, but I do know that I now can't :-).
It's an exceptionally powerful distributed object paradigm.

> > The native GUI widgets should be assembled into hierarchies not by API calls,
> > but by a hierarchical description language - XML probably.

> well, i disagree here. i thought about that option: whether the models
> should be in markup versus executable code.

The executable code in OpenUI is nearly all in the form of "when" clauses,
which are the message handlers. They're not used for non-UI things though,
in fact despite having a rich O-O language with a VM and fast compiler
interpreter (very similar to Java but on the market six years earlier),
it deliberately doesn't have any local O/S access and no external extension
mechanism. You have to write message handlers in native code (C, Pascal, Ada,
COBOL), which are registered at the session level on either the front or
back end.

> I'm interested to know more about OpenUI and if you should decide that you

> could contribute to the project please let me know.

Hopefully I've satisfied some of your curiosity.

Probably can't contribute much more at this stage, but someday I do want to
rebuild OpenUI's features, using someone else's XP GUI toolkit and preferably
someone else's compiler/interpreter. The async messaging and distributed
object system I expect to need to rebuild myself, though many vaguely similar
things exist.

> tkxml.rb

Will play when I get time.

--
Clifford Heath

[Benjamin Peterson]

>you have this super application you wrote --the
underbelly of an
>factastic hoogy-me-whatsy-do-it-all app and now you
have to figure out
>how to put a front-end on her. so you need a gui.
hmmm...you think, i
>want a gui thats flexible and fast nad highly
functional, runs on just
>about any platform, looks good, preferably just like
the native
>interface, and is easy as pie to code so as not to
require much fussing
>with the app you've alredy written.

Are there people out there who really do this? Build
GUI apps by first writing a non-GUI application, and
only then start to think about what sort of GUI
framework can be bolted on to it?

Certainly I can imagine establishing sections of
functionality, such as financial algorithms or
encryption or whatever, without reference to the GUI.
But the kind of GUI people expect these days is just
not the kind you can attach as an
afterthought--especially as the GUI is perhaps one of
the most structured parts of the application (you may
be able to write your core functionality in a very
linear way, but your GUI will always involve
asynchronous communication).

I think that you are writing a tool aimed very much at
one particular case -- the case where you have a
unix-style command-line application which you might
want to bolt a simple GUI onto if you happen to get a
user who doesn't like typing. I think this case is
already covered pretty well, and a toolkit capable of
producing heavy duty GUIs (like CodeWarrior,
PageMaker, VS .net, Elixir, maybe even Gimp) would be
much more interesting.

Clifford Heath commented:

>...factor that makes it really work: rich

asynchronous message passing.
>I'm still of the firm opinion that this is the single
integrating feature
>which is needed to revolutionise GUI programming.

I agree strongly that asynchronous, hierarchical
message passing is a vital part of GUI infrastructure.
I was under the impression that it revolutionized GUI
programming quite a while back, though.

Benjamin

x

[Tom Sawyer]

On Wed, 2002-07-24 at 04:04, Benjamin Peterson wrote:
> Are there people out there who really do this? Build
> GUI apps by first writing a non-GUI application, and
> only then start to think about what sort of GUI
> framework can be bolted on to it?

you should try it. i used to not write my apps this way. but i now
realize how much more powerful it is to do so. its really just SOC on a
another level. i know that most people probably don't do things this
way, just as i used to not, but i think that's becasue no ones ever
should them how. they simply don't realize that they can; and that the
gui tookits out there do not lend themselves to it :-( you have to
create you own integration/communications layer. but its well worth it.
once done you can create a variety of intefeaces to your application,
with different toolkits and different languages, if you so wish. its
really a good design approach.

"bolted on to it?" you say that like its a bad thing ;-)

> Certainly I can imagine establishing sections of
> functionality, such as financial algorithms or
> encryption or whatever, without reference to the GUI.
> But the kind of GUI people expect these days is just
> not the kind you can attach as an
> afterthought--especially as the GUI is perhaps one of
> the most structured parts of the application (you may
> be able to write your core functionality in a very
> linear way, but your GUI will always involve
> asynchronous communication).

well, certainly it depends to what you writing, but i would guesstimate
that 90%+ of all apps could be written this way. it not like you don't
have some idea about the gui from the get go, but the core functionality
does not have to be, nay should not be dependent on that.

> I think that you are writing a tool aimed very much at
> one particular case -- the case where you have a
> unix-style command-line application which you might
> want to bolt a simple GUI onto if you happen to get a
> user who doesn't like typing. I think this case is
> already covered pretty well, and a toolkit capable of
> producing heavy duty GUIs (like CodeWarrior,
> PageMaker, VS .net, Elixir, maybe even Gimp) would be
> much more interesting.

well, your simply wrong here. right now i have a full blown accounting
application that i have to "bolt on", as you say, a gui to. its
currently has NO interface, not even a command line.

i don't follow you references to CodeWarrior, PageMaker, etc. as
builders of heavy duty GUIs. ?

> Clifford Heath commented:
>
> >...factor that makes it really work: rich
> asynchronous message passing.
> >I'm still of the firm opinion that this is the single
> integrating feature
> >which is needed to revolutionise GUI programming.
>
> I agree strongly that asynchronous, hierarchical
> message passing is a vital part of GUI infrastructure.
> I was under the impression that it revolutionized GUI
> programming quite a while back, though.

well, how does X do it? how does VNC deal with it? in either case, i'm
not seeing a big revolution around here. now, networked gaming, on the
other hand, perhaps we can say there's a small one going on in that
relm. so that could be a source of design inspiration, i.e. why not
bring those capabilities into normal every day gui interfaces as well?
and i think, although indirectly, this may be what Clifford is
suggesting.

but even without this communications layer. a gui toolkit as i have
described would be a very useful tool. personally i am wondering if i
have simply not explained myself clearly. can you not see the utitlity
of what i've described? perhaps you simply don't code gui apps?

~transami

[Dossy]

On 2002.07.24, Benjamin Peterson <bjs...@yahoo.com> wrote:
> Are there people out there who really do this? Build
> GUI apps by first writing a non-GUI application, and
> only then start to think about what sort of GUI
> framework can be bolted on to it?

Yes. There's a reason the Model-View-Controller (MVC)
pattern is so well-known.

Implement a simple non-graphical UI as your View, then
replace it later once you have the "meaty bits" like
the Model and Controller fleshed out.

This works well enough that you can have a seperate
team doing the Model and Controller bits from the
team who is building the View bits.

The Model-Controller team builds everything with a
very simple non-graphical UI View, while the other
team builds the graphical UI View using dummied out
Model-Controller stuff. Typically, the team that
builds the View portion builds what most people
know as a "wireframe prototype" -- it demonstrates
the graphical UI front-end with none of the mechanisms
behind to make the application actually "do" anything.

-- Dossy

--
Dossy Shiobara mail: do...@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[Curt Hibbs]

Tom Sawyer wrote:

[snip]

> it was stated that a main goal of Rouge was to create a cross-compatible
> gui api that "boiled down" into the native gui of each platform. in my
> first post on these matters, i pointed out how ungodly difficult that
> would be (as i had been trying to do that myself). in the end either you
> left to "patch" your app for each platform or you simply have to give up
> the features that they hold in common (at best). it really is simply too
> much of pain to create such an system, not to mention maintaining it as

> those underlying native api change. yet the goal os a native look and

> feel is not unachievable by other means. the solution is simply a matter
> of using an underlying gui engine that is sufficiantly themeable. since
> all the major gui's are now themable themselves, we simply need to code
> a theme manager that can import the themes of those other guis. we need
> not use their underlying api, only their look and feel! so that's what
> can be done to solve that dilemma: use a sufficantly themeable gui api
> and crreat and Themes and Behaviors Manger to emulate the look and feel
> and even draw upon the native theme configuration files. this is a much
> managable task then trying to channel down to the native guis
> themselves. the only trick of course is finding that themeable gui api.

This issue wasn't so much native look-and-feel as it was native integration
(its not the same). Native integration means that the widgets have the same
behavior as native widgets (usually, because they *are* native widgets).
Sean Russell made a pretty clear case for this in this posting:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/32029

Sean also mentioned SWT from the Eclipse project, which *does* this for
Java:

http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

I think I said this before, but (just in case), the problem that the
FreeRIDE project had (and still has) finding an adequate Ruby GUI toolkit
that simultaneously satisfied the need for both native integration and
internationalization. Of course other features are important, too, but these
were the two big ones that just couldn't be found in one package.

Curt

[Steve Tuckner]

What about WX-Windows. There is no ruby bindings for it, but would that fit
the bill?

Steve Tuckner

-----Original Message-----
From: Curt Hibbs [mailto:cu...@hibbs.com]
Sent: Wednesday, July 24, 2002 9:23 AM
To: ruby-talk ML

[Ned Konz]

On Wednesday 24 July 2002 04:11 am, Tom Sawyer wrote:
> > functionality, such as financial algorithms or
> > encryption or whatever, without reference to the GUI.
> > But the kind of GUI people expect these days is just
> > not the kind you can attach as an
> > afterthought--especially as the GUI is perhaps one of
> > the most structured parts of the application (you may
> > be able to write your core functionality in a very
> > linear way, but your GUI will always involve
> > asynchronous communication).
>
> well, certainly it depends to what you writing, but i would
> guesstimate that 90%+ of all apps could be written this way. it not
> like you don't have some idea about the gui from the get go, but
> the core functionality does not have to be, nay should not be
> dependent on that.

I disagree. Unless you're willing to make a horribly modal or limited
UI, or are aware from the start that events will be triggering
behavior asynchronously, you will probably find that sequencing and
ordering assumptions made in the underlying code will cause problems
in the UI.

Some simple single-view dialogs may work OK, but multiple views with
concurrent updates probably won't.

One of the notable hard parts is connecting exception handling with
user notification and intervention.

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

[Chris Gehlker]

On 7/24/02 6:20 AM, "Dossy" <do...@panoptic.com> wrote:

> On 2002.07.24, Benjamin Peterson <bjs...@yahoo.com> wrote:
>> Are there people out there who really do this? Build
>> GUI apps by first writing a non-GUI application, and
>> only then start to think about what sort of GUI
>> framework can be bolted on to it?
>
> Yes. There's a reason the Model-View-Controller (MVC)
> pattern is so well-known.
>
> Implement a simple non-graphical UI as your View, then
> replace it later once you have the "meaty bits" like
> the Model and Controller fleshed out.
>
> This works well enough that you can have a seperate
> team doing the Model and Controller bits from the
> team who is building the View bits.

Dossy is absolutely right here. I would add that if you are building a
program with mutiple interfaces, say a GUI and a scripting/recording
interface for AppleScript/VBA or a GUI and a CORBA interface, you *have to*
use this pattern.

But Benjamin talked about "you may be able to write your core functionality
in a very linear way" and, if I understand him, this is something that one
must avoid. The Model itself can't make any assumptions about the order of
messages that it will receive other than that it will get some kind of
initialize message first and some kind of finalize message last. It can
never initialize communication with a user but must rather passively wait
for messages. If it is written this way, one can indeed "bolt on" sereral
Uis.
--
There is, nevertheless, a certain respect and a general duty of humanity
that ties us, not only to beasts that have life and sense, but even to
trees and plants. -Michel de Montaigne, essayist (1533-1592)

[Curt Hibbs]

Steve Tuckner wrote:
>
>> I think I said this before, but (just in case), the problem that the
>> FreeRIDE project had (and still has) finding an adequate Ruby GUI toolkit
>> that simultaneously satisfied the need for both native integration and
>> internationalization. Of course other features are important,
>> too, but these
>> were the two big ones that just couldn't be found in one package.
>>
>> Curt
>

> What about WX-Windows. There is no ruby bindings for it, but
> would that fit
> the bill?
>
> Steve Tuckner

Yes, WX-Windows would have been a good candidate for FreeRIDE if it had Ruby
bindings.

Back in January (I think it was January), Laurent Julliard did a quick
analysis of various GUI toolkits for the FreeRIDE project, which included
WX-Windows. You can see the results here:

http://www.rubyide.org/cgi-bin/wiki.pl?GUIFrameworkProject/GUIComparison

Curt

[Tom Sawyer]

On Wed, 2002-07-24 at 08:39, Steve Tuckner wrote:
> What about WX-Windows. There is no ruby bindings for it, but would that fit
> the bill?

hi steve,

wxWindows is a good gui tookit, no doubt. but this clip from its webpage
makes it unsuitable for out purposes:

"wxWindows is not a translator from one GUI from another; it cannot take
a Motif application and generate a Windows application, for example. You
need to learn a new API. However, the wxWindows API has been praised for
its intuitiveness and simplicity, and can be far easier to learn and use
than a native GUI API such as Motif or Windows. Porting from MFC is
particularly easy due to its similarity: one user has ported his CASE
tool from MFC to wxWindows in a couple of weeks."

we require something common, i.e one api for all platforms. the Rouge
project sought to do this by translating to native guis where possible,
allowing for extension in the other cases. this translation is a
duanting task, if even reasonably possible. i purpose instead the use of
a themeable gui engine that can thus mimic the look and feel of the
native guis. this is a much more doable endeavor.

thanks for the suggestion though. i wish wxWindows could do the job. but
alas it cannot. did you have a chance to look at ClanLib. it is my hope
that this library will be suitable. i've studied in for awhile and it
looks quite promising.

~transami

--
~transami

[Massimiliano Mirra]

I think he's trying to make the generation of the View and Controller
parts mostly automatic.

Massimiliano

[Albert Wagner]

On Tuesday 23 July 2002 10:25 pm, Tom Sawyer wrote:
> let me paint a picture:
>
> you have this super application you wrote --the underbelly of an
> factastic hoogy-me-whatsy-do-it-all app and now you have to figure out
> how to put a front-end on her.

I have never written such a program, that is, an "application" that I decided,
after the fact, that I need a GUI for. The nearest to that, that I can
remember, is the mainframe batch programs I wrote in the '60s and '70s. User
interface was limited to printing reports and keypunching input data.

I cannot imagine a GUI app where the GUI is an "addon". All of my GUI apps
were GUI-centric. I design the GUI first. Most often my GUI apps are
nothing but widgets with callbacks: existing data is presented to the user
and then the user drives the process.

What drives your application? data, user events, realtime events, what?

<snip>

> as for plain old Model-View-Controller, honestly, i have no idea what
> that even means.

Ah hah! I think I know what the problem is now.

<snip>

[Curt Hibbs]

Tom Sawyer wrote:
>
> On Wed, 2002-07-24 at 08:39, Steve Tuckner wrote:
> > What about WX-Windows. There is no ruby bindings for it, but
> would that fit
> > the bill?
>
> hi steve,
>
> wxWindows is a good gui tookit, no doubt. but this clip from its webpage
> makes it unsuitable for out purposes:
>
> "wxWindows is not a translator from one GUI from another; it cannot take
> a Motif application and generate a Windows application, for example. You
> need to learn a new API. However, the wxWindows API has been praised for
> its intuitiveness and simplicity, and can be far easier to learn and use
> than a native GUI API such as Motif or Windows. Porting from MFC is
> particularly easy due to its similarity: one user has ported his CASE
> tool from MFC to wxWindows in a couple of weeks."
>
> we require something common, i.e one api for all platforms. the Rouge
> project sought to do this by translating to native guis where possible,
> allowing for extension in the other cases. this translation is a
> duanting task, if even reasonably possible. i purpose instead the use of
> a themeable gui engine that can thus mimic the look and feel of the
> native guis. this is a much more doable endeavor.

I cannot claim that I have done a detailed analysis, but I wouldn't assume
that the work needed to mimic a look-and-feel is less work than using native
widgets and filling in missing functionality. The graphics side (themes) is
straighforward, but only one part. There is still the behavior side to
consider (which is also a significant amount of work).

Anyway, I'm not saying I know the answer, only that it should be considered
before jumping to any conclusions.

> thanks for the suggestion though. i wish wxWindows could do the job. but
> alas it cannot. did you have a chance to look at ClanLib. it is my hope
> that this library will be suitable. i've studied in for awhile and it
> looks quite promising.

I looked briefly at ClanLib (not enough to give you any real feedback), but
I do have some concerns about font handling and internationalization.
ClanLib seems to implement its own font handling that is completely
disconnected from the underlying system, and their does not appear to be any
consideration for internationalization.

Curt

[Patrick May]

Tom Sawyer <tran...@transami.net> wrote in message news:<1027481479.853.582.camel@silver>...

> let me paint a picture:
>
> you have this super application you wrote --the underbelly of an
> factastic hoogy-me-whatsy-do-it-all app and now you have to figure out
> how to put a front-end on her. so you need a gui. hmmm...you think, i
> want a gui thats flexible and fast nad highly functional, runs on just
> about any platform, looks good, preferably just like the native
> interface, and is easy as pie to code so as not to require much fussing
> with the app you've alredy written.

What are the relative priorities of these requirements?

> well, if you look around you're going to discover that everything out
> there now has shortcomings. beleive me i've looked. so what do you do?
> you either pick one that minimizes the shortcomings as suited to your
> application, or you do what i'm trying to do: put an end to the problem.
> how does that bode for what i'm trying to achieve?

I don't think it will ever be possible to 'put an end to the problem'.
The problem is that interface code, whether it's html, gui, whatever,
has it's own set of objects with their own hierarchies, etc. Matching
the interface relationships to your existing object relationships will
always be a mess.

This is where I like your x.widgitize() idea -- it's a great *pattern*
for integrating the presentation code into your objects. This pattern
requires you to discard notions about the "separation of
presentation", and instead follow rules such as "put functionality
near the required data". I'm just not sure if it makes a good
*library*, b/c as I said before, x.widgetize() benefits from providing
generalized application specific widgets.

~ Patrick

[Massimiliano Mirra]

On Wed, Jul 24, 2002 at 07:04:28PM +0900, Benjamin Peterson wrote:
> Are there people out there who really do this? Build
> GUI apps by first writing a non-GUI application, and
> only then start to think about what sort of GUI
> framework can be bolted on to it?

Tom is not talking about bolting a GUI onto an *application*, he's
talking about bolting a GUI onto a *model*, i.e. a set of classes that
describe program logic and are ignorant of user interfaces.

Massimiliano

[Tom Sawyer]

On Wed, 2002-07-24 at 11:15, Curt Hibbs wrote:
> I cannot claim that I have done a detailed analysis, but I wouldn't assume
> that the work needed to mimic a look-and-feel is less work than using native
> widgets and filling in missing functionality. The graphics side (themes) is
> straighforward, but only one part. There is still the behavior side to
> consider (which is also a significant amount of work).

yes, i've been thinking about this. personally, i don't think that the
behaviors should be too difficult. a little tricky, yes, and they may
not be perfect, but i think they could be close enough. on the other
hand, the more difficult task will be integrating with native
clipboards, another resposibility of the Themes and Behaviors Manager. I
read sean's post concerning these issues. it is a debate that will have
to be hashed out. we should consider though that a gui engine like
ClanLib's gives us much more then a basic set of GUI widgets. like i
said, it is a full blown game sdk. (not that i personally need such a
thing, but all the better) once the wiki's up, we can begin the debate
on this and figure out which direction is best.

> I looked briefly at ClanLib (not enough to give you any real feedback), but
> I do have some concerns about font handling and internationalization.
> ClanLib seems to implement its own font handling that is completely
> disconnected from the underlying system, and their does not appear to be any
> consideration for internationalization.

i am attempting to contact the ClanLib mailing list about this, but the
email address dosen't seem to work for me. the email address is:
clanlib-user.x.dtu.dk; it dosen't have an @ sign, and evolution is
rejecting it as invalid. so i am unsure about this. i also looked into
the font support a little. ClanLib supports TTF fonts via FreeType, and
FreeType looked promising, mentioning unicode support. but i am unsure.
perhaps you know about this?

~transami

> Curt
>
>
--
~transami

[Wayne Vucenic]

Hi Tom,

Wednesday, July 24, 2002, 8:49:41 AM, you wrote:

TS> wxWindows is a good gui tookit, no doubt. but this clip from its webpage
TS> makes it unsuitable for out purposes:

TS> "wxWindows is not a translator from one GUI from another; it cannot take
TS> a Motif application and generate a Windows application, for example. You
TS> need to learn a new API. However, the wxWindows API has been praised for
TS> its intuitiveness and simplicity, and can be far easier to learn and use
TS> than a native GUI API such as Motif or Windows. Porting from MFC is
TS> particularly easy due to its similarity: one user has ported his CASE
TS> tool from MFC to wxWindows in a couple of weeks."

I seem to read that quote from wxWindows differently than you do. I
think what they're saying is that "it cannot take
a Motif application [written without using wxWindows] and
[automatically] generate a Windows application". But if the
application is written using the wxWindows API, then it can be
moved from one platform to another.

TS> we require something common, i.e one api for all platforms.

This is exactly what wxWindows provides. I used wxWindows a bit about
a year ago. I was only programming on Windows, but my understanding
is that I could have taken my code and recompiled it on Linux or one
of the other supported platforms, and it would have run there with
(essentially) no changes.

I think wxWindows deserves a closer look. It seems mature and stable,
has a fairly large and energetic group of people enhancing it, and
many programmer-years of effort have been expended on it. I
especially like that it has been around about 10 years, and has wide
support, so it's unlikely to go away anytime soon.

Wayne Vucenic
No Bugs Software
C++/Ruby Contract Programming in Silicon Valley

[Tom Sawyer]

On Wed, 2002-07-24 at 11:28, Patrick May wrote:
> What are the relative priorities of these requirements?

off hand i would say:
1. multi-platform
2. native integration (either direct or mimiced)
3. easy to code
4. speed and flexibiity

#3 of course will be taken care of by the GUtoIa API.

> I don't think it will ever be possible to 'put an end to the problem'.

watch me ;-)

> The problem is that interface code, whether it's html, gui, whatever,
> has it's own set of objects with their own hierarchies, etc. Matching
> the interface relationships to your existing object relationships will
> always be a mess.

i believe my implementaion of using intermediary bindings will fix this
mess.

> This is where I like your x.widgitize() idea -- it's a great *pattern*
> for integrating the presentation code into your objects. This pattern
> requires you to discard notions about the "separation of
> presentation", and instead follow rules such as "put functionality
> near the required data". I'm just not sure if it makes a good
> *library*, b/c as I said before, x.widgetize() benefits from providing
> generalized application specific widgets.

i too find the x.widgetize() idea compelling, but also beleive you are
right. it does not ultimately make for a good way of dealing with the
problem. conversely, i think a seperation of concerns is far from a
notion to be discarded. in my work thus far on the project, i have found
proper use of SOC to be much more powerful then my original x.wigitize()
notions.

~transami

[Tom Sawyer]

On Wed, 2002-07-24 at 12:31, Wayne Vucenic wrote:
> I seem to read that quote from wxWindows differently than you do. I
> think what they're saying is that "it cannot take
> a Motif application [written without using wxWindows] and
> [automatically] generate a Windows application". But if the
> application is written using the wxWindows API, then it can be
> moved from one platform to another.

i may indeed stand corrected.

> I think wxWindows deserves a closer look.

i will look into it more.

soon i plan to establish an "official" debate to hash out the best means
of underlying implementation. i encourage you to join in.

thanks,
~transami

>
> TS> we require something common, i.e one api for all platforms.
>
> This is exactly what wxWindows provides. I used wxWindows a bit about
> a year ago. I was only programming on Windows, but my understanding
> is that I could have taken my code and recompiled it on Linux or one
> of the other supported platforms, and it would have run there with
> (essentially) no changes.
>

It seems mature and stable,
> has a fairly large and energetic group of people enhancing it, and
> many programmer-years of effort have been expended on it. I
> especially like that it has been around about 10 years, and has wide
> support, so it's unlikely to go away anytime soon.
>
> Wayne Vucenic
> No Bugs Software
> C++/Ruby Contract Programming in Silicon Valley
>
>

--
~transami

[Tom Sawyer]

Curt, i've registered with savannah. i'll let you know about the success
of that. by the way i used the LGPL. do you think that is the best
choice?

~transami

p.s. tried to mail you direct but the email came back.

[Tom Sawyer]

On Wed, 2002-07-24 at 12:07, Massimiliano Mirra wrote:
> Tom is not talking about bolting a GUI onto an *application*, he's
> talking about bolting a GUI onto a *model*, i.e. a set of classes that
> describe program logic and are ignorant of user interfaces.

hi Massimiliano,

i've just finished reading up on MVC. but i'm little puzzeled about how
the paradigm i have created maps to this pattern. let me explain. i take
the Model to be the back-end application. In my example case that would
the Fruity Fun App. It is the application, indifferent to any user
interface. then the Viewer is the GUI engine? --that which renders the
GUI? In my example that dosen't really yet exist, and at best could be
said to be STDOUT. am i right about this? but then the Controller, it
would seem, is the same entity as the GUI engine which also handles the
user interaction. i'm a bit confused on that point. what i am calling a
model in my GUtopia API is the code to generate the UI, perhaps then it
is really a View? but my model/View is also fully absatracted and knows
nothing about the Model/application for which it will describe the UI.
the two only relate via an intermidiary description called the binding.
so how does that fit into the MVC picture? i hanker this guess: the
underlying engine is irrelevent, the Model is my application, the View
is what i am calling a model (its a model of the UI) and the bindings
are the Controller. would that be correct?

by the way, thanks for the support.

~transami

~transami

[Clifford Heath]

Albert Wagner wrote:
> I have never written such a program

I have. Using OpenUI, you can first define the content of a set of messages
that will be sent between the application and the GUI, then you can code
either or both independently. An anecdote, but first, I must point out that
I'm not spruiking for a product - you can't buy this product any more.

A customer had a team of eight Oracle programmers in Sydney, and a team of
UI programmers in Melbourne whose only experience with OpenUI was the
three-day training course. We got one developer from each team to meet with
one of our blokes for two days and they agreed a set of messages between
the presentation (UI in OpenUI) and semantic (C + Oracle) layers. The tech
leads returned to their teams, and spent three months developing the
application, testing the two parts separately against stubs. When the time
came to glue the two together, the GUI was emailed up to Sydney on the Friday,
and we had our bloke booked on a plane to fly up on the Monday afternoon
and spend three weeks making it work. The Sydney crowd phoned at 11AM
Monday to say "Don't come, it's already working". Even we were blown away.
40,000 lines of C and Oracle application worked first time against a GUI
of forty windows.

You *can* do presentation-semantic independent application design if you
have the right tools. However... call-back-driven widget sets prevent most
people from ever discovering this. You need procedural logic on both sides
of the split, but you need a layer that makes the location of the split
highly evident - the messaging layer did this.

--
Clifford Heath

[Tom Sawyer]

has anyone gotten a chance to take a look at the GUtopIa code yet?

there's something very strange about it. something i can't figure out. i
mean i wrote it and all, but i never explictly told it how to update the
widget when the object changes. yet it does! how? i keep coming back to
this and looking for some place in the code that does it, but i can't
find it. very spooky.

~transami

On Tue, 2002-07-23 at 18:31, Tom Sawyer wrote:
> well, i just read over my last post. sorry about all the typos. i needed
> a break and didn't bother to proofread. but i'm sure you can make out
> what i was trying to say where i blurbed. okay, now to the good stuff!
>
> i spent the last few days hacking out the first steps in the creation of
> a super-duper ruby gui api, which i have dubbed GUtopIa (thanks rich).
> just to kick things off here's a small clip of one of my examples (note
> MyModels is drawn from an unshown require):
>
> INTERFACE = 'PDA'
> fruitapp = FruitApp.new
> mygui = GUtopIa::GUI.new('Fruity Fun Time')
> names = {
> 'awindow' => fruitapp.appname,
> 'aradio' => fruitapp.fruitbasket.name
> }
> bindings = {
> fruitapp.fruitbasket.name => {
> :value => Proc.new { fruitapp.fruit.isa },
> :value= => Proc.new { |x| fruitapp.fruit.isa = x },
> :items => Proc.new { fruitapp.fruitbasket.contains },
> :event_change => Proc.new { fruitapp.pickafruit }
> }
> }
> model = MyModels.pick_model(mygui, INTERFACE)
> mygui.transaction(bindings, names, &model)
> mygui.build
>
> the idea is that you take an instance of your application (FruitApp in
> this case), completely untouched --you don't have to add or change a
> single line of code (unless you want too ;-) you then create a model. a
> model (not shown in example) is an executable description of the fixed
> aspects of your gui. it has no references to any part of your app
> (although you can do so if you don't care about SOC) it is a completely
> independent entity and as such can be reused in other fitting contexts.
> you can also draw on multiple sub-models. then you create a binding (as
> seen above). this describes how an instance of your application
> "interfaces" with your model. and then presto out comes you gui-ized
> app.
>
> also note that GUtopIa uses a transaction mechinism. this effectivly
> bundles an executable model into a single execution. not only does this
> increase speed, but also offers a means to rollback the effects of a
> transaction should there be an error, adding much greater stability to
> your gui-ized application.
>
> some other things to note: bindings are actually integrated directly
> into the class models of the widgets. when a widget is created it is
> subclassed into a specialized class of that widget which includes
> methods to react to the bindings described.
>
> i've attached my work thus far so you can checkout all of this in
> detail. be sure to run example.rb (the snipet above) and check out
> orig-example.rb, which is a non-SOC version of the original Rouge/Utopia
> example. then check out gutopia.rb which is the heart of the matter.
>
> so that's the the word on implementation. i've taken the advice of
> others and i have worked out what i think is shaping up to be the best
> gui api design in existence. Curt Hibbs has offered me a wiki for this
> project. (thanks curt) i will take him up on it. now i hope i can get
> YOU enthused enough to help. there's real potential here, to not only
> create an awsome gui api for ruby that is unique and powerful, but also
> create a full-fledge game sdk! this thing looks to be awesome indeed.
>
> i need people to take on a few tasks. a ruby wrapper needs to be created
> for ClanLib and we need to build a Themes and Behaviors manager. someone
> needs to hack out the communications layer (i've tried it with DRb and
> ROMP but they bomb). and i could use some help finishing off the main
> api. if we can pull together on this, ruby, our favorite little
> scripting language, will have its very own GUI to rival all others!
>
> as you might be able to tell, i'm very excited! i hope you are too!
>
> thanks for your time and hope to hear from you,
>
> ~transami :-)
>
>
> ----
>

> # GUtopIa Example - Application Layer
> # Copyright (c) 2002 Thomas Sawyer, Ruby License
>
> class FruitApp
> attr_accessor :appname
> attr_reader :fruitbasket, :fruit, :basketname
> def initialize
> @appname = 'Fruity Fun'
> @fruitbasket = FruitBasket.new
> @fruit = Fruit.new
> end
> def pickafruit
> puts "You got a #{@fruit.isa}!"
> end
> end
>
> class FruitBasket
> attr_accessor :name, :contains
> def initialize
> @name = 'Fruit Basket'
> @contains = ["None", "Apple", "Orange", "Banana"]
> end
> end
>
> class Fruit
> attr_accessor :isa
> def initialize
> @isa = "None"
> end
> end
> ----
>

> # GUtopIa Daemon Example - Client
> # Copyright (c) 2002 Thomas Sawyer, Ruby License
>
> require 'drb'
> require 'example-app'
> require 'example-pre'
>
>
> # Configure interface
>
> INTERFACE = 'PDA'
> puts "\nINTERFACE: #{INTERFACE}\n"
>
>
> # Make GUI App
>
> fruitapp = FruitApp.new
>
> DRb.start_service()
> mygui = DRbObject.new(nil, 'druby://localhost:8080')
>
> names = {
> 'awindow' => fruitapp.appname,
> 'aradio' => fruitapp.fruitbasket.name
> }
>
> bindings = {
> fruitapp.fruitbasket.name => {
> :value => Proc.new { fruitapp.fruit.isa },
> :value= => Proc.new { |x| fruitapp.fruit.isa = x },
> :items => Proc.new { fruitapp.fruitbasket.contains },
> :event_change => Proc.new { fruitapp.pickafruit }
> }
> }
>
> model = MyModels.pick_model(mygui, INTERFACE)
>
> mygui.transaction(bindings, names, &model)
>
> mygui.build
>
>
> # Run some tests
>
> puts
> puts "MYGUI "
> p mygui
>
> puts
> puts "MYGUI WIDGETS"
> mygui.widgets.each_key do |k|
> puts k
> end
>
> puts
> puts "THE WINDOW"
> p mygui.widgets[fruitapp.appname].class.superclass
> puts "name: #{fruitapp.appname}"
> puts "width: #{mygui.widgets[fruitapp.appname].width}"
> puts "height: #{mygui.widgets[fruitapp.appname].height}"
>
> puts
> puts "THE RADIO"
> p mygui.widgets[fruitapp.fruitbasket.name].class.superclass
> puts "name: #{fruitapp.fruitbasket.name}"
> puts "items: #{mygui.widgets[fruitapp.fruitbasket.name].items.join(', ')}"
> puts "value: #{mygui.widgets[fruitapp.fruitbasket.name].value}"
>
> puts
> puts
> puts "TRY OUT!"
> puts
> puts "Current state of fruit and its widget:"
> puts "fruit=#{fruitapp.fruit.isa}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Changing widget to: #{mygui.widgets[fruitapp.fruitbasket.name].value = 'Banana'}"
> puts "fruit=#{fruitapp.fruit.isa}"
> puts
> puts "Changing fruit to: #{fruitapp.fruit.isa = 'Orange'}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Trigger event_change event:"
> mygui.widgets[fruitapp.fruitbasket.name].event_change
> puts
> puts "Changing fruit to: #{fruitapp.fruit.isa = 'Apple'}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Changing widget to: #{mygui.widgets[fruitapp.fruitbasket.name].value = 'Banana'}"
> puts "fruit=#{fruitapp.fruit.isa}"
>
> puts
> ----
>

> # GUtopIa Example - Models
> # Copyright (c) 2002 Thomas Sawyer, Ruby License
>
> require 'gutopia'
>
> module MyModels
>
> def MyModels.pick_model(gui, which)
> case which
> when 'PC'
> return MyModels.pc_model(gui)
> when 'PDA'
> return MyModels.pda_model(gui)
> end
> end
>
> private
>
> # PC model using serial notatation (slower)
> def MyModels.pc_model(gui)
>
> Proc.new {
>
> # RadioBox
> r = gui.widgetFactory(:RadioBox, 'aradio')
>
> # Window
> w = gui.widgetFactory(:Window, 'awindow')
> w.width = 640
> w.height = 400
> w.grid = [ [ r ] ]
>
> }
>
> end
>
> # PDA model using parallel notation (faster)
> def MyModels.pda_model(gui)
>
> Proc.new {
>
> # RadioBox
> r = gui.widgetFactory(:RadioBox, 'aradio')
>
> # Window
> w = gui.widgetFactory(:Window, 'awindow',
> :width => 320,
> :height => 240,
> :grid => [ [ r ] ]
> )
>
> }
>
> end
>
> end # MyModels
> ----
>

> # GUtopIa Daemon Example - Client
> # Copyright (c) 2002 Thomas Sawyer, Ruby License
>
> require 'romp/romp'
> require 'example-app'
> require 'example-pre'
>
>
> # Configure interface
>
> INTERFACE = 'PDA'
> puts "\nINTERFACE: #{INTERFACE}\n"
>
>
> # Make GUI App
>
> fruitapp = FruitApp.new
>
> client = ROMP::Client.new('tcpromp://localhost:8080')
> mygui = client.resolve('gutopia-romp')
>
> names = {
> 'awindow' => fruitapp.appname,
> 'aradio' => fruitapp.fruitbasket.name
> }
>
> bindings = {
> fruitapp.fruitbasket.name => {
> :value => Proc.new { fruitapp.fruit.isa },
> :value= => Proc.new { |x| fruitapp.fruit.isa = x },
> :items => Proc.new { fruitapp.fruitbasket.contains },
> :event_change => Proc.new { fruitapp.pickafruit }
> }
> }
>
> model = MyModels.pick_model(mygui, INTERFACE)
>
> mygui.transaction(bindings, names, &model)
>
> mygui.build
>
>
> # Run some tests
>
> puts
> puts "MYGUI "
> p mygui
>
> puts
> puts "MYGUI WIDGETS"
> mygui.widgets.each_key do |k|
> puts k
> end
>
> puts
> puts "THE WINDOW"
> p mygui.widgets[fruitapp.appname].class.superclass
> puts "name: #{fruitapp.appname}"
> puts "width: #{mygui.widgets[fruitapp.appname].width}"
> puts "height: #{mygui.widgets[fruitapp.appname].height}"
>
> puts
> puts "THE RADIO"
> p mygui.widgets[fruitapp.fruitbasket.name].class.superclass
> puts "name: #{fruitapp.fruitbasket.name}"
> puts "items: #{mygui.widgets[fruitapp.fruitbasket.name].items.join(', ')}"
> puts "value: #{mygui.widgets[fruitapp.fruitbasket.name].value}"
>
> puts
> puts
> puts "TRY OUT!"
> puts
> puts "Current state of fruit and its widget:"
> puts "fruit=#{fruitapp.fruit.isa}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Changing widget to: #{mygui.widgets[fruitapp.fruitbasket.name].value = 'Banana'}"
> puts "fruit=#{fruitapp.fruit.isa}"
> puts
> puts "Changing fruit to: #{fruitapp.fruit.isa = 'Orange'}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Trigger event_change event:"
> mygui.widgets[fruitapp.fruitbasket.name].event_change
> puts
> puts "Changing fruit to: #{fruitapp.fruit.isa = 'Apple'}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Changing widget to: #{mygui.widgets[fruitapp.fruitbasket.name].value = 'Banana'}"
> puts "fruit=#{fruitapp.fruit.isa}"
>
> puts
> ----
>

> # GUtopIa Example - Presentation
> # Copyright (c) 2002 Thomas Sawyer, Ruby License
>
> require 'gutopia'
> require 'example-app'
> require 'example-pre'
>
>
> # Configure interface
>
> INTERFACE = 'PDA'
> puts "\nINTERFACE: #{INTERFACE}\n"
>
>
> # Make GUI App
>
> fruitapp = FruitApp.new
>
> mygui = GUtopIa::GUI.new('Fruity Fun Time')
>
> names = {
> 'awindow' => fruitapp.appname,
> 'aradio' => fruitapp.fruitbasket.name
> }
>
> bindings = {
> fruitapp.fruitbasket.name => {
> :value => Proc.new { fruitapp.fruit.isa },
> :value= => Proc.new { |x| fruitapp.fruit.isa = x },
> :items => Proc.new { fruitapp.fruitbasket.contains },
> :event_change => Proc.new { fruitapp.pickafruit }
> }
> }
>
> model = MyModels.pick_model(mygui, INTERFACE)
>
> mygui.transaction(bindings, names, &model)
>
> mygui.build
>
>
> # Run some tests
>
> puts
> puts "MYGUI "
> p mygui
>
> puts
> puts "MYGUI WIDGETS"
> mygui.widgets.each_key do |k|
> puts k
> end
>
> puts
> puts "THE WINDOW"
> p mygui.widgets[fruitapp.appname].class.superclass
> puts "name: #{fruitapp.appname}"
> puts "width: #{mygui.widgets[fruitapp.appname].width}"
> puts "height: #{mygui.widgets[fruitapp.appname].height}"
>
> puts
> puts "THE RADIO"
> p mygui.widgets[fruitapp.fruitbasket.name].class.superclass
> puts "name: #{fruitapp.fruitbasket.name}"
> puts "items: #{mygui.widgets[fruitapp.fruitbasket.name].items.join(', ')}"
> puts "value: #{mygui.widgets[fruitapp.fruitbasket.name].value}"
>
> puts
> puts
> puts "TRY OUT!"
> puts
> puts "Current state of fruit and its widget:"
> puts "fruit=#{fruitapp.fruit.isa}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Changing widget to: #{mygui.widgets[fruitapp.fruitbasket.name].value = 'Banana'}"
> puts "fruit=#{fruitapp.fruit.isa}"
> puts
> puts "Changing fruit to: #{fruitapp.fruit.isa = 'Orange'}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Trigger event_change event:"
> mygui.widgets[fruitapp.fruitbasket.name].event_change
> puts
> puts "Changing fruit to: #{fruitapp.fruit.isa = 'Apple'}"
> puts "widget=#{mygui.widgets[fruitapp.fruitbasket.name].value}"
> puts
> puts "Changing widget to: #{mygui.widgets[fruitapp.fruitbasket.name].value = 'Banana'}"
> puts "fruit=#{fruitapp.fruit.isa}"
>
> puts
> ----
>

> # GUtopIa - ROMP Daemon
> # Copyright (c) 2002 Thomas Sawyer, Ruby License
>
> require 'drb'
> require 'gutopia'
>
> gutopia_drb = GUtopIa::GUI.new('DRb')
>
> DRb.start_service('druby://localhost:8080', gutopia_drb)
> DRb.thread.join
> ----
>

> # GUtopIa - ROMP Daemon
> # Copyright (c) 2002 Thomas Sawyer, Ruby License
>
> require 'romp/romp'
> require 'gutopia'
>
> gutopiad = GUtopIa::GUI.new('Romp')
>
> server = ROMP::Server.new('tcpromp://localhost:8080', nil, true)
> server.bind(gutopiad, 'gutopia-romp')
> server.thread.join
> ----
>

> # GUtopIa API
> # Copyright (c)2002 Thomas Sawyer, Ruby License
>
> module GUtopIa
>
> # Returns a GUIFactory object
> class GUI
>
> attr_reader :name, :widgets
>
> def initialize(name)
> @name = name
> #
> @widgets = {}
> @names = {}
> @bindings = {}
> @transactions = []
> end
>
> # Method used to prefab GUI
> def transaction(bindings={}, names={}, &model)
> @names = names
> @bindings = bindings
> @transactions << Proc.new {
> #commit
> #begin
> model.call #(self)
> #commit
> #rescue ScriptError
> #rollback
> #rescue StandardError
> #rollback
> #end
> }
> end
>
> # Method used to build GUI
> # This runs the all pending transactions
> def build
> @transactions.each do |transaction|
> transaction.call(@bindings)
> end
> @transactions.clear # all done with those
> end
>
> # Widget Factory
> # Returns a new widget object of specialized widget class
> def widgetFactory(widget, name, attributes={})
>
> # a widget string name will work too
> widget = widget.intern if widget.is_a?(String)
>
> # makes an anoynomous class as subclass of desired widget
> widgetClass = Class.new(GUtopIa.const_get(widget))
>
> # specialize class via bindings
> if @bindings[@names[name] || name]
> @bindings[@names[name] || name].each do |k, v|
> widgetClass.class_eval {
> define_method(k, v)
> }
> end
> end
>
> w = widgetClass.new(attributes)
> w.name = @names[name] || name
> @widgets[w.name] = w
>
> return w
>
> end
>
> #
> def alert(msg)
> puts msg
> end
>
> #
> def stop
> puts "stopping...#{@name}"
> exit
> end
>
> # Useful Class Methods?
>
> def GUI.screen_realestate
> # { :height => , :width => , :depth => }
> end
>
> end # GUI
>
>
> # Widgets
>
> # ToDo: add a whole bunch more super widgets :-)
> # attributes require validation
>
> class Widget
> attr_accessor :name
> end
>
>
> class Window < Widget
>
> attr_accessor :height, :width, :colordepth, :flags
> attr_accessor :caption, :icon, :background, :grid
>
> def initialize(attributes={})
> @height = attributes[:height] ? attributes[:height] : 200
> @width = attributes[:width] ? attributes[:width] : 200
> @colordepth = attributes[:colordepth] ? attributes[:colordepth] : 16
> @flags = attributes[:flags] ? attributes[:flags] : 0
> @caption = attributes[:caption] ? attributes[:caption] : nil
> @icon = attributes[:icon] ? attributes[:icon] : nil
> @background = attributes[:background] ? attributes[:background] : nil
> @grid = attributes[:grid] ? attributes[:grid] : []
> #
> super()
> end
>
> def show
> puts "showing window....#{@caption}"
> end
>
> def hide
> puts "hiding window...#{@caption}"
> end
>
> end # Window
>
>
> class Panel < Widget
>
> attr_accessor :height, :width
> attr_accessor :background, :grid
>
> def initialize(attributes={})
> @height = attributes[:height] ? attributes[:height] : 200
> @width = attributes[:width] ? attributes[:width] : 200
> @background = attributes[:background] ? attributes[:background] : nil
> @grid = attributes[:grid] ? attributes[:grid] : []
> #
> super()
> end
>
> end # Panel
>
>
> class Label < Widget
>
> attr_accessor :text
>
> def initialize(attributes={})
> @text = attributes[:text] ? attributes[:text] : nil
> #
> super()
> end
>
> end # Label
>
>
> class TextField < Widget
>
> attr_accessor :text, :value
>
> def initialize(attributes={})
> @text = attributes[:text] ? attributes[:text] : nil
> @value = attributes[:value] ? attributes[:value] : nil
> #
> super()
> end
>
> end # TextField
>
>
> class TextArea < Widget
>
> attr_accessor :text, :value, :cols, :lines
>
> def initialize(attributes={})
> @text = attributes[:text] ? attributes[:text] : nil
> @value = attributes[:value] ? attributes[:value] : nil
> @cols = attributes[:cols] ? attributes[:cols] : nil
> @lines = attributes[:lines] ? attributes[:lines] : nil
> #
> super()
> end
>
> end # TextArea
>
>
> class Button < Widget
>
> attr_accessor :text
> attr_accessor :event_pressed
>
> def initialize(attributes={})
> @text = attributes[:text] ? attributes[:text] : nil
> # events
> @event_pressed = attributes[:event_pressed] ? attributes[:event_pressed] : nil
> #
> super()
> end
>
> end # Button
>
>
> class RadioBox < Widget
>
> attr_accessor :value, :items
> attr_accessor :event_change
>
> def initialize(attributes={})
> @value = attributes[:value] ? attributes[:value] : nil
> @items = attributes[:content] ? attributes[:content] : nil
> # events
> @event_change = attributes[:event_change] ? attributes[:event_change] : nil
> #
> super()
> end
>
> end # RadioBox
>
>
> class MenuBar < Widget
>
> attr_accessor :items
>
> def initialize(attributes={})
> @items = attributes[:items] ? attributes[:items] : nil
> #
> super()
> end
>
> end # MenuBar
>
>
> class Menu < Widget
>
> attr_accessor :text, :items
>
> def initialize(attributes={})
> @text = attributes[:text] ? attributes[:text] : nil
> @items = attributes[:items] ? attributes[:items] : nil
> #
> super()
> end
>
> end # Menu
>
>
> class MenuItem < Widget
>
> attr_accessor :text
> attr_accessor :event_selected
>
> def initialize(attributes={})
> @text = attributes[:text] ? attributes[:text] : nil
> # events
> @event_selected = attributes[:event_selected] ? attributes[:event_selected] : nil
> #
> super()
> end
>
> end # MenuItem
>
> end # GUtopIa
> ----
>

> # GUtopIa Example - Presentation
> # Copyright (c) 2002 Thomas Sawyer, Ruby License
>
> require 'gutopia'
>
> app = GUtopIa::GUI.new('My Application')
>
> # here you must refer to widgets with app.widgets['widget's name']
> bindings = {
> 'quit' => {
> :event_selected => Proc.new {
> app.stop
> }
> },
> 'about' => {
> :event_selected => Proc.new {
> app.widgets['aboutWindow'].show
> }
> },
> 'submit' => {
> :event_pressed => Proc.new {
> app.alert("And the fruit is...#{app.widgets['favoriteFruit'].text}")
> app.widgets['mainWindow'].hide
> app.stop
> }
> },
> 'clear' => {
> :event_pressed => Proc.new {
> app.widgets['favoriteFruit'].text = nil
> }
> },
> 'close' => {
> :event_pressed => Proc.new {
> app.widgets['aboutWindow'].hide
> }
> }
> }
>
> # here you can refer to widgets with local name
> # or the app.widgets['widget's name']
> app.transaction(bindings) {
>
> quit = app.widgetFactory(:MenuItem, 'quit',
> :text => 'Quit'
> )
> about = app.widgetFactory(:MenuItem, 'about',
> :text => 'About'
> )
> file = app.widgetFactory(:Menu, 'file',
> :text => 'File',
> :items => [ app.widgets['quit'] ]
> )
> help = app.widgetFactory(:Menu, 'help',
> :text => 'Help',
> :items => [ about ]
> )
> menu = app.widgetFactory(:MenuBar, 'menu',
> :items => [ file, help ]
> )
> firstName = app.widgetFactory(:TextField, 'firstName',
> :label => 'First Name',
> :label_position => :left
> )
> lastName = app.widgetFactory(:TextField, 'lastName',
> :label => 'Last Name',
> :label_position => :left
> )
> favoriteFruit = app.widgetFactory(:TextArea, 'favoriteFruit',
> :text => 'Banana',
> :cols => 5,
> :lines => 4,
> :readonly => false,
> :label => 'Favorite Fruit',
> :label_position => :top
> )
> submit = app.widgetFactory(:Button, 'submit',
> :text => 'Update',
> :image => 'check.png'
> )
> clear = app.widgetFactory(:Button, 'clear',
> :text => 'Clear'
> )
> fruit_panel = app.widgetFactory(:Panel, 'fruit_panel',
> :grid => [ [ firstName ],
> [ lastName ],
> [ favoriteFruit ],
> [ submit ],
> [ clear ] ]
> )
> mainWindow = app.widgetFactory(:Window, 'mainWindow',
> :caption => 'My Cool Window',
> :icon => 'myIcon.ico',
> :grid => [ [ menu ],
> [ fruit_panel ] ]
> )
> aboutLbl = app.widgetFactory(:Label, 'aboutLbl',
> :text => <<-DATA
> This is a very cool application
> that I created using the GUtopIa
> GUI API.
> DATA
> )
> close = app.widgetFactory(:Button, 'close',
> :text => 'Close'
> )
> aboutWindow = app.widgetFactory(:Window, 'aboutWindow',
> :caption => 'About My Cool App',
> :grid => [ [ aboutLbl ],
> [ close ] ]
> )
>
> }
>
> app.build
>
> puts
> puts "select about from menu"
> app.widgets['about'].event_selected
> puts "click on close"
> app.widgets['close'].event_pressed
> puts "click on submit"
> app.widgets['submit'].event_pressed
> puts
--
~transami

[Tom Sawyer]

figures. as soon as post this i figure it out. never mind.

--
~transami

[Chris Gehlker]

On 7/24/02 8:54 AM, "Massimiliano Mirra" <li...@NOSPAMchromatic-harp.com>
wrote:

But Massimiliano, isn't the view part mostly automated anyway? I don't know
about other platforms but I thought they all had things like PowerPlant and
Interface Builder.

--
As an adolescent I aspired to lasting fame, I craved factual certainty, and
I thirsted for a meaningful vision of human life - so I became a scientist.
This is like becoming an archbishop so you can meet girls. -Matt Cartmill,
anthropology professor and author (1943- )

[Chris Gehlker]

Try thinking of it this way:

The Model is as you understand it, It's an object hierarchy that just sits
there and responds to messages. It only gets messages from the controller.
The View also talks only to the controller but it's a two way street. The
view sends messages when the user types or clicks a widget and it updates
it's display when the controller sends it new data. The controller is there
specifically to isolate the Model from the View(s). The notion is that the
Model is portable and the View is easy because you can make it with some
kind of "draw a GUI" program. All the hard interface logic is in the
controllers.

I keep talking about 'the view' and 'the controller' but an app with
multiple windows with multiple panes might have several views and
controllers. The spatial containment hierarchy on screen is mirrored by the
message hierarchy of the controllers.
--
I have suffered from being misunderstood, but I would have suffered a hell
of a lot more if I had been understood. -Clarence Darrow, lawyer and author
(1857-1938)

[Albert Wagner]

OpenUI sounds fantastic. But, it was known beforehand that OpenUI would be
the UI. Could the same Oracle code be connected to another UI without
modification? Or was it unique to OpenUI?

[Clifford Heath]

Any UI platform - Windows, Motif, Mac, OS/2 and character terminals, and
almost any Unix or Windows server platform. But OpenUI provided more than
just a UI toolkit, so perhaps not. The point is that you could have built
any UI using OpenUI and it would still work - in fact we sometimes
completely redid a UI without even recompiling the backend code.

In particular the client/server communications were built around async
messaging with particular delivery methods and expectations, and the UI
was animated by code running in the VM. A replacement UI would have to
mimic those characteristics. I did write a Java version of the server side
of the messaging protocol once, it was about 2,500 lines of code, so not
too hard - the client side is almost identical. The message delivery
algorithms were based on highly optimised data structures, but otherwise
were unremarkable. Add those features to the XP GUI toolkit, wrap the whole
thing in a VB-like drag-drop IDE and interactive symbolic debugger both
written in OpenUI, and you have the whole package. For the toolkit, we
chose the path of wrapping the native widgets on Motif, Windows, Mac,
OS/2 and a curses-style windowing package for terminals. In retrospect
that was a mistake, I think Qt's emulation path is better. The native APIs
are too buggy. Just a shame that Java came along and cruelled the pitch
for us.

--
Clifford Heath

[Massimiliano Mirra]

On Thu, Jul 25, 2002 at 05:26:38AM +0900, Tom Sawyer wrote:
> i've just finished reading up on MVC. but i'm little puzzeled about
> how the paradigm i have created maps to this pattern. let me
> explain. i take the Model to be the back-end application.

Well, not exactly. Consider:

class SpreadSheet
def [](row, column)
...
end

def []=(row, column, value)
...
end

def calc
...
end
end

This is a model, yet not an application. An application presupposes
user interaction, while you can only interact with your SpreadSheet
model from code.

> In my example case that would the Fruity Fun App. It is the
> application, indifferent to any user interface.

I've lost track of examples, but yes, replace the above word
`application' with `model' and you have it.

> then the Viewer is the GUI engine? --that which renders the GUI?

If you say Viewer, I'd guess so. I've always read MVC as Model, View
(not Viewer), Controller. So the View is whatever shows the model
status to the user. It is not implicit in the name, but it is usually
accepted that it also sends user input to the model or to the
Controller (in simpler designs the Controller is sometimes integrated
in the View).

> In my example that dosen't really yet exist, and at best could be
> said to be STDOUT. am i right about this?

As I said I've lost track of examples, but if you have something sent
to STDOUT you've already got some kind of presentation beside the
model, whether this fits in a MVC pattern or not.

> but then the Controller, it would seem, is the same entity as the
> GUI engine which also handles the user interaction. i'm a bit
> confused on that point. what i am calling a model in my GUtopia API
> is the code to generate the UI, perhaps then it is really a View?
> but my model/View is also fully absatracted and knows nothing about
> the Model/application for which it will describe the UI. the two
> only relate via an intermidiary description called the binding. so
> how does that fit into the MVC picture? i hanker this guess: the
> underlying engine is irrelevent, the Model is my application, the
> View is what i am calling a model (its a model of the UI) and the
> bindings are the Controller. would that be correct?

Except for the model/application bit (the application is the whole),
I'd say yes.

Also see if this point of view (no pun) can be useful to you: the View
thinks in terms of appearance: `button', `menu' and `checkbox'; the
Model thinks in terms of meaning: `surname', `telephone', `address';
the Controller translates action on appearance (`click button') into
action on meaning (`edit surname'), and, conversely, change of state
in meaning (`surname changed') into change of state in appearance
(`edit field updated').

By the way, I'm an artisan, not a computer scientist. Take what I
tell you with a grain of salt, and the way I tell it with, well, a
whole bag of it. :-)

Massimiliano

p.s.: Did you receive my mail with the URL for the instant messenger
built around GUI abstraction?

[Massimiliano Mirra]

On Thu, Jul 25, 2002 at 11:17:48AM +0900, Chris Gehlker wrote:
> > I think he's trying to make the generation of the View and Controller
> > parts mostly automatic.
>
> But Massimiliano, isn't the view part mostly automated anyway? I don't know
> about other platforms but I thought they all had things like PowerPlant and
> Interface Builder.

Uhm, I don't know those, what are they?

Also, I don't know if we're referring to the same thing. With `view
part mostly automated' do you mean GUI handling or GUI generation?

BTW, the only time I provided a ruby app with a GUI was through
`window = Gtk::Window.new' etc., and it wasn't the most exciting thing
in the world to do. I knew about libglade, but laying out with a
mouse isn't that much better than laying out with a keyboard,
especially for a console junkie like me ;^). And oddly enough, I
don't miss the 2+ years of GUI design in Borland Delphi (where I was
even writing my own widgets).

I guess I just lack the mental cycles needed to follow up each change
in the model with a change in the GUI, thus the idea idea that some
code might does most of it for me is appealing. I also use
DocBook/SGML and LaTeX for writing, where you create the meaning and
`it' creates the appearance, instead of word processors, so this must
be a personal trend. :-)

Massimiliano

[Curt Hibbs]

Wayne Vucenic wrote:
>
> This is exactly what wxWindows provides. I used wxWindows a bit about
> a year ago. I was only programming on Windows, but my understanding
> is that I could have taken my code and recompiled it on Linux or one
> of the other supported platforms, and it would have run there with
> (essentially) no changes.

Yes, this is true.

> I think wxWindows deserves a closer look. It seems mature and stable,
> has a fairly large and energetic group of people enhancing it, and
> many programmer-years of effort have been expended on it. I
> especially like that it has been around about 10 years, and has wide
> support, so it's unlikely to go away anytime soon.

Tom, I agree with Wayne here -- I would encourage you to take another look
at wxWindows. When the FreeRIDE project did its GUI search, wxWindows may
very well have been our GUI toolkit of choice (it met all of our feature
requirements), if only it had Ruby bindings.

Curt

[Albert Wagner]

Still, you had to have learned an awful lot in that process. And ultimately,
that background and education are our only real profits. Maybe, Tom can pull
it off. I remain sceptical. The project is surely desirable and you've
convinced me that it may be doable. But it is simply to too large and
complex. Enthuisiasm can get you started, but only grit and persistence will
finish it. This is a project that can easily become a life's work.

[Tom Sawyer]

On Thu, 2002-07-25 at 07:13, Albert Wagner wrote:
> Still, you had to have learned an awful lot in that process. And ultimately,
> that background and education are our only real profits. Maybe, Tom can pull
> it off. I remain sceptical. The project is surely desirable and you've
> convinced me that it may be doable. But it is simply to too large and
> complex. Enthuisiasm can get you started, but only grit and persistence will
> finish it. This is a project that can easily become a life's work.

well, if it's any reassurance, i am probably the hardest working man in
the business (since my father retired ;-) 24-7. only break is to sleep
and i've been doing it for years. no plains to burn out either --just
not an option, well, at least until i retire myself. :-)

~transami

[Tom Sawyer]

On Thu, 2002-07-25 at 07:12, Curt Hibbs wrote:
> Tom, I agree with Wayne here -- I would encourage you to take another look
> at wxWindows. When the FreeRIDE project did its GUI search, wxWindows may
> very well have been our GUI toolkit of choice (it met all of our feature
> requirements), if only it had Ruby bindings.
>
> Curt

i looked it over and i agree it looks pretty good. i don't know why i
get a sort "stale" feeling from it though. but that may just be me. i
suppose perhaps that ClanLib is just more exciting becasue it has a lot
of additional capabilities related to game design, including vorbis
support. so its a trade-off. we can get a basic gui, with
native-interfacing and thus less work, using wxWindows, or a load of
extra features, but with more work to get native look&feel, with
ClanLib.

perhaps there's room for both? currently i've bindined GUtopIa to FXRuby
just to have something to actually visualize. its working pretty well.
but either way we will have only a single "meta"-api that the developer
need worry about.

when the wiki's up i'll put up a comparison chart.

--
~transami

[Tom Sawyer]

curt, wayne and the rest,

i've looked over the wxWindows API. very impressed. there are some areas
where cross-compatability are not available. but they are not too
numerous. we'll just leave those out.

so i purpose, rather then spend too much time in debate over this, and
rather get to the core of the matter, as to see it accomplished as soon
as possible, that we create two parrallel but cojoined projects. one for
wxWindows and one for ClanLib, i.e. GUtopIa-Biz and GUtopIa-Joy, or
something like that. opinions?

~transami

p.s.

also i would just like to say i am rather partial to ParaGUI, as i tend
to think that's how GUIs should be done, i.e. built on top of
OpenGL/SDL. but ParaGUI is too immature at this point. so alas.
anyway...

one more aside: i'm debating the addition of an r to GUtopIa, as i keep
finding myself saying it that way: GrUtopIa. what do other's think? and
what do you think of the name in general? also, not that this is all
that important at the moment, but such things do cross one's mind, i was
thinking of a few multicolored grapes on a vine for a logo? trivial, but
what the hell. :-)

[Curt Hibbs]

Tom Sawyer wrote:
>
> when the wiki's up i'll put up a comparison chart.

I got everything all ready to go for the wiki, but I'm having problems with
my ISP and can't get the stuff uploaded. I even accidentally delete the wiki
executable from the FreeRIDE site and can't get that uploaded either (sorry
guys). I'll get it all straightened out as soon as I can.

Curt

[Curt Hibbs]

Tom Sawyer wrote:
>
> one more aside: i'm debating the addition of an r to GUtopIa, as i keep
> finding myself saying it that way: GrUtopIa. what do other's think? and
> what do you think of the name in general? also, not that this is all
> that important at the moment, but such things do cross one's mind, i was
> thinking of a few multicolored grapes on a vine for a logo? trivial, but
> what the hell. :-)
>

Well, if you are into wild names, I'm the wrong person to ask -- I lean
towards the conservative side. I like GUtopIa, except that I dislike the
capital "I" near the end. But, hey, that's just me! :-)

Curt

[Tom Sawyer]

curt,

that's okay do what you need too. savannah, by the way said i wasn't
detailed enough about my project description. my 10 lines weren't good
enough. :-)

any one want to help with that real quick? this is what i had:

GUtopIa is a Ruby GUI API. It is intended to meet all requirements of
such a toolkit: cross-platform, native platform integration, ease of
coding with good SOC (seperation of concerns) and POLS (Principle of
Least Suprise), flexibity and speed. The GUtopIa project is an offspring
of the original RougeProject, a part of FreeRIDE. The project intends to
provide the ultimate GUI API for free use to the Ruby community, and
intends to do so in short order.

i realize i should add something about internationalization. perhaps
also i should go into more details about the implementation?

by the way i think i'm going to change the name to GrUtopIa. just
realized that the r would tie it into ruby better and besides i keep
saying it that way anyway. :*) how does that jive with you all?
massimiliano suggested the name Chaemelon. any input is welcome of
course, and well see.

~tom

--
~transami

[Chris Gehlker]

On 7/25/02 3:13 AM, "Massimiliano Mirra" <li...@NOSPAMchromatic-harp.com>
wrote:

> On Thu, Jul 25, 2002 at 11:17:48AM +0900, Chris Gehlker wrote:

>>> I think he's trying to make the generation of the View and Controller
>>> parts mostly automatic.
>>
>> But Massimiliano, isn't the view part mostly automated anyway? I don't know
>> about other platforms but I thought they all had things like PowerPlant and
>> Interface Builder.
>
> Uhm, I don't know those, what are they?

GUI builders.

> Also, I don't know if we're referring to the same thing. With `view
> part mostly automated' do you mean GUI handling or GUI generation?

I mean that GUI generation is done in some kind of specialized drawing
program and GUI handling is automated to the extent that most widgets send
messages when their state changes. The controller(s) then just need to be
handlers. Some things, like reflowing text when a window resizes just handle
themselves.

> BTW, the only time I provided a ruby app with a GUI was through
> `window = Gtk::Window.new' etc., and it wasn't the most exciting thing
> in the world to do. I knew about libglade, but laying out with a
> mouse isn't that much better than laying out with a keyboard,
> especially for a console junkie like me ;^). And oddly enough, I
> don't miss the 2+ years of GUI design in Borland Delphi (where I was
> even writing my own widgets).

I tried libglade but it seemed really primitive compared to Mac/Windows
stuff. PowerPlant is nice in that one can switch between mouse editing and
text editing.

--
There is, nevertheless, a certain respect and a general duty of humanity
that ties us, not only to beasts that have life and sense, but even to
trees and plants. -Michel de Montaigne, essayist (1533-1592)

[Tom Sawyer]

On Thu, 2002-07-25 at 12:54, Chris Gehlker wrote:
> I mean that GUI generation is done in some kind of specialized drawing
> program and GUI handling is automated to the extent that most widgets send
> messages when their state changes. The controller(s) then just need to be
> handlers. Some things, like reflowing text when a window resizes just handle
> themselves.

> I tried libglade but it seemed really primitive compared to Mac/Windows

> stuff. PowerPlant is nice in that one can switch between mouse editing and
> text editing.

that's the rub. most of these GUI builders are limited in scope and
capability and cost $$$. besides, they end up translating into code any
way. so yes its nice to have such a thing, but often they are more a
pain in the rear then their worth. (though i must abmit MS has doen it
pretty well) but that's why i created Miter, which i will include as a
GUI building tool with GUtopIa (pronouced grootopeea? ;-) Miter allows
you to design GUI layouts visually but with a standard text editor. for
example:

+------------------------+
| "My Stupid GUI Form" |
+----------+-------------+
| <Button> | [textextry] |
+----------+-------------+

you get the idea. suprisingly i've gotten it to support many a widget.
and damn does it make GUI Layout EZ!

~transami

[repeater]

i give my vote for wxWindows, according to my experience with wxPython. it
is the richness of the samples that really convinced me, and i invite
everybody interested to take a look

if you are willing to go through with the python installation:
http://www.wxpython.org/download.php
and some screenshots: http://www.wxpython.org/wxpshots.php

as i recall, there is currently a project to wrap wxwindows for ruby called
wxruby, but i haven't seen much activity.
(http://sourceforge.net/projects/wxruby/)

now if i may give my assessment of this situation:
--------------------------------------------------
1) a good gui system, although not essential to some, is ESSENTIAL to the
widespread acceptance of a language. the best ruby has to offer currently is
fxruby (and it is good), but i've noticed that native look and feel is an
important desire. especially if ruby wants to gain greater popularity under
the windows market. it should offer native look and feel (and behaviour),
but of course also function on other operating systems, hence the reason why
wxwindows is a very good option.

2) gui systems are usually MASSIVE. any attempt to create bindings, or
writing them from scratch is a massive effort. and then we haven't even gone
into keeping the system up to date, bug fixes etc.

**i would like to emphasize that one must have an idea of the immensity of
the situation.**

the impression that i get with gui projects is that they are very likely to
fail, unfortunately. even a system that makes the first step by offering
primitive support, can easily fade into the darkness. (another point in
favour of wxwindows btw: they've taken care of the entire cross OS gui
system. a thing less we have to worry about. as somebody said, doing that
from scratch is a life's work)

this is why i think that we should definitely focus on the path of least
resistance here, because if our goal is to create a new widely accepted
library, it is a rather difficult path.

3) suggested development path:
first we find a very enthusiastic leader, and a good bunch of volunteers
(i'd consider being a volunteer)

then we take the wxpython source, create scripts to translate the python
roughly into ruby (the languages reasonably similar), just to get the
skeleton of the system into realisation. very lazy, very efficient, why
would we do what others have already done ?

now follows the considerable difficult task of getting the system up and
running, and discovering the nature of our new code and its interaction with
the wxWindows system. of equal importance is to throw sufficient and
beautiful ruby idioms into the structure of the language.

well, just my two cents describing a vision how i would see things happen

regards
repeater

[Clifford Heath]

Albert Wagner wrote:
> The project is surely desirable and you've
> convinced me that it may be doable. But it is simply to too large and
> complex. Enthuisiasm can get you started, but only grit and persistence will
> finish it. This is a project that can easily become a life's work.

I thought of it that way, and it's taken several years to grieve over its
commercial failure. But now I believe it can be done *much* more easily,
perhaps as little as two to three months hard work. My QTML prototype used
the expat XML parser, the Qt toolkit, and I was just about to start embedding
the Mozilla Javascript engine when I discovered Ruby. I'm still learning Ruby
and won't decide on the optimum model for a while. The final piece in the
jigsaw was to build local and remote (using SOAP encoding) asynchronous
message delivery services and the back-end API implementations.

Qt was a nuisance, since many of the layout attributes are stored on hidden
objects which attach a widget to a position on the geometry manager. The
attribute-based QTML language needs to see those as attributes, there's no
place for method calls in setting up this kind of stuff. Actually I thought
that the geometry attributes required by the children could be modelled as
namespace extensions, but the area of XML namespaces is a bit grubby so I
left that undecided for now. I haven't learnt enough about FOX and FXRuby to
know whether it's better, but the lack of Unicode support is a worry.

--
Clifford Heath

[Massimiliano Mirra]

On Fri, Jul 26, 2002 at 03:54:54AM +0900, Chris Gehlker wrote:
> I mean that GUI generation is done in some kind of specialized drawing
> program

I see. That's how GUI building in Delphi is, too. It's still you
building the GUI, though.

What I'm dreaming of is a tool or module that takes 90% of that work
off from you, like those web portals were you only have to provide
content and the category of it (`news', `download', `article', ...),
select a template, and an engine takes care of putting them together.

> and GUI handling is automated to the extent that most widgets send
> messages when their state changes.

[...]

> Some things, like reflowing text when a window resizes just handle
> themselves.

True of any reasonable GUI toolkit, I guess.

> I tried libglade but it seemed really primitive compared to Mac/Windows
> stuff. PowerPlant is nice in that one can switch between mouse editing and
> text editing.

I'm wondering about QT designer. Anybody familiar with it?

Massimiliano

[Albert Wagner]

I've found them useful, when they were available. But I usually need
something more finely grained than characters.

[Clifford Heath]

Benjamin Peterson wrote:
> I agree strongly that asynchronous, hierarchical
> message passing is a vital part of GUI infrastructure.
> I was under the impression that it revolutionized GUI
> programming quite a while back, though.

Nearly all existing GUI toolkits use some kind of asynchronous
messaging within a hierarchy, but no others that I'm aware of
(having been away from GUIs for a couple of years now) combine
the characteristics of:
* Rich messaging - you define strong message types with arbitrary
content (in OpenUI that means potentially nested arrays of
structures of...)
* Hierarchical propagation against handlers having the appearance
of dynamically-bound methods that receive the message parameters,
* Message broadcast down towards the leaf nodes that's transparent
to the current delivery node.

In other words, sufficient power in the messaging system that no
widget needs to directly address any other.

Most GUI toolkits make minimal or no use of the hierarchy for message
propagation. Messages are normally of one of the limited standard
types, and there are ad-hoc broadcast mechanisms if any.

--
Clifford Heath

[Ned Konz]

On Thursday 25 July 2002 05:10 pm, Clifford Heath wrote:

> Most GUI toolkits make minimal or no use of the hierarchy for
> message propagation. Messages are normally of one of the limited
> standard types, and there are ad-hoc broadcast mechanisms if any.

A couple of examples come to mind that have the characteristics you
describe (I think) (both, interestingly, are from the world of
prototype-based OO languages):

* NewtonScript and its built-in inheritance of message handling code
down through the containment hierarchy: events are delivered to the
innermost widget, but the code that handles the event may in fact be
"inherited" from some parent, up to the main view itself.

* Squeak's Morphic and its built-in event handling that usually routes
the events down through the containment hierarchy and gives priority
to the innermost components (though this can be overridden as desired
by a parent). You can make new event types if you want, though I
haven't seen any. Most of the "conventional" UIs in Squeak use MVC
for notification because they have to work in either Morphic or the
older MVC graphics system. (I don't know enough about event routing
in Self's Morphic to say if this is the same).

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

[yct]

>
> i give my vote for wxWindows, according to my experience with wxPython. it
> is the richness of the samples that really convinced me, and i invite
> everybody interested to take a look
>
> if you are willing to go through with the python installation:
> http://www.wxpython.org/download.php
> and some screenshots: http://www.wxpython.org/wxpshots.php
>
>

no offence to FOX. but wxWindows look much more native.(therefore much
more attractive, at least in windows).

(Yeah i know FOX is windows inspired...)

[Tomas Brixi]

--- repeater <repe...@lucentprimate.cjb.net> wrote:
> > Wayne Vucenic wrote:
> > >
> > > This is exactly what wxWindows provides. I used wxWindows a bit about
> > > a year ago. I was only programming on Windows, but my understanding
> > > is that I could have taken my code and recompiled it on Linux or one
> > > of the other supported platforms, and it would have run there with
> > > (essentially) no changes.
> >
> > Yes, this is true.
> >
> > > I think wxWindows deserves a closer look. It seems mature and stable,
> > > has a fairly large and energetic group of people enhancing it, and
> > > many programmer-years of effort have been expended on it. I
> > > especially like that it has been around about 10 years, and has wide
> > > support, so it's unlikely to go away anytime soon.
> >
> > Tom, I agree with Wayne here -- I would encourage you to take another look
> > at wxWindows. When the FreeRIDE project did its GUI search, wxWindows may
> > very well have been our GUI toolkit of choice (it met all of our feature
> > requirements), if only it had Ruby bindings.
>
> i give my vote for wxWindows, according to my experience with wxPython. it
> is the richness of the samples that really convinced me, and i invite
> everybody interested to take a look
>
> if you are willing to go through with the python installation:
> http://www.wxpython.org/download.php
> and some screenshots: http://www.wxpython.org/wxpshots.php
>

I vote for wxWindows too. It's a powerful crossplatform native looking GUI see
http://www.wxwindows.org/platform.htm and wxPython proves it to be a really good choice.

Tom

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[Benjamin Peterson]

N.B. This post is rather dull.

>> I agree strongly that asynchronous, hierarchical
>> message passing is a vital part of GUI
infrastructure.
>> I was under the impression that it revolutionized
GUI
>> programming quite a while back, though.

>* Rich messaging - you define strong message types
with arbitrary
> content (in OpenUI that means potentially nested
arrays of
> structures of...)
>* Hierarchical propagation against handlers having
the appearance
> of dynamically-bound methods that receive the
message parameters,
>* Message broadcast down towards the leaf nodes
that's transparent
> to the current delivery node.

Other than curses, I'm not sure I'm aware of *any* GUi
system that does *not* use asynchronous, hierarchical
messaging. Even X used it -- and that was back in the
days of X!

If you leave out the word 'strong' (they sure like
their void pointers over in Redmond), Windows has met
the above 3 items (in an inconsistent and obscure
way)for many years. The proviso that 'no widget needs
to address any other' is a good one, and I can think
of nothing except Windows that meets it (maybe
Swing?). In practise, of course, in Windows you *do*
often have to know the exact object you are talking to
so you can allow for all the inconsistencies.

I guess my conclusion is that having a powerful
messaging system is only useful if you have a set of
components so orthogonal that you actually can
broadcast a message to them and expect them all to do
something sensible with it. And making those
components would be harder than making the messaging
system.

Benjamin Peterson

x

[Lyle Johnson]

yct wrote:
>>
> no offence to FOX. but wxWindows look much more native.(therefore much
> more attractive, at least in windows).

No offense taken ;) There are reasonable arguments for both sides of the
"native look-and-feel" versus "consistent look-and-feel" debate.

But it should be no surprise that wxWindows looks "much more native",
since it's just a wrapper over some other widget toolkit. For example,
if you're using wxGTK, you're using wxWindows, layered on top of GTK,
layered on top of X. Similar story for wxMotif and whatever they do for
the other ports of wxWindows.

FOX *intentionally* takes the approach of relying only on low-level
system facilities and *not* wrapping the native GUI toolkits. It's an
approach similar to that taken by Swing, Qt and other modern GUI
toolkits. For more words on the "Goals & Approach" of FOX, see:

http://www.fox-toolkit.org/goals.html

It is interesting to note that the next generation of wxWindows (the
wxUniversal project) has also adopted this approach.

Hope this helps,

Lyle

[Curt Hibbs]

Lyle Johnson wrote:
>
> But it should be no surprise that wxWindows looks "much more native",
> since it's just a wrapper over some other widget toolkit. For example,
> if you're using wxGTK, you're using wxWindows, layered on top of GTK,
> layered on top of X. Similar story for wxMotif and whatever they do for
> the other ports of wxWindows.
>
> FOX *intentionally* takes the approach of relying only on low-level
> system facilities and *not* wrapping the native GUI toolkits. It's an
> approach similar to that taken by Swing, Qt and other modern GUI
> toolkits. For more words on the "Goals & Approach" of FOX, see:
>
> http://www.fox-toolkit.org/goals.html
>
> It is interesting to note that the next generation of wxWindows (the
> wxUniversal project) has also adopted this approach.

It is also worth noting that the SWT (from the Eclipse project) also takes
the approach of wrapping naive widgets (enhancing them where needed).

Curt

[Curt Hibbs]

Curt Hibbs wrote:

>
> Lyle Johnson wrote:
> >
> > It is interesting to note that the next generation of wxWindows (the
> > wxUniversal project) has also adopted this approach.
>
> It is also worth noting that the SWT (from the Eclipse project) also takes
> the approach of wrapping naive widgets (enhancing them where needed).
>

I hadn't heard for wxUniversal, so I decided to take a look. wxUniversal
looks like an *extension* of wxWindows (like wxHTML and other wx
extensions), and *not* a next-generation replacement.

I felt it was important to point this out because wxWindows and SWT are
among the few GUI toolkits that take the native wrapper approach. Doing this
makes it more difficult to port the toolkit to other platforms (which is
why, I believe, that it is an uncommon approach), but I also believe that it
offers many advantages, including my favorite: tight native platform
integration.

The thought that wsWindows might be giving this up made me want to know why.
I am much relieved to find that this is not so.

Curt

[Tom Sawyer]

> Lyle Johnson wrote:
> > toolkits. For more words on the "Goals & Approach" of FOX, see:
> >
> > http://www.fox-toolkit.org/goals.html
> >
> > It is interesting to note that the next generation of wxWindows (the
> > wxUniversal project) has also adopted this approach.

On Mon, 2002-07-29 at 08:46, Curt Hibbs wrote:
> It is also worth noting that the SWT (from the Eclipse project) also takes
> the approach of wrapping naive widgets (enhancing them where needed).

just to throw my two cents into the pot. i think ultimatly lyle is on
target. your going to have a much better toolkit in the end with one
that is self-contained rather than with one that has to translate into a
variety of others. its just like any translation, something is always
lost in the process and it takes longer. nothing you can do about it.
but even so, i do not think anyone has ever done the the self-contained
deal wholly right. you can't push a single look and feel. just won't
fly. and people will look elsewhere if they can. now if the FOX people
got smart, they would jump on getting a Themes and Behaviors Manager
going like i described in a previous post. Then FOX would truly rock!
But until then, i'm looking at getting a binding to wxWindows instead.
At least that's a direction i can take such that i know eventually i
will have native intergration.

~transami

[Lyle Johnson]

Curt Hibbs wrote:

> It is also worth noting that the SWT (from the Eclipse project) also takes
> the approach of wrapping naive widgets (enhancing them where needed).

Naive widgets? ;) There is a joke there but I am not clever enough to
come up with it.

[Curt Hibbs]

Tom Sawyer wrote:
>
> just to throw my two cents into the pot. i think ultimatly lyle is on
> target. your going to have a much better toolkit in the end with one
> that is self-contained rather than with one that has to translate into a
> variety of others. its just like any translation, something is always
> lost in the process and it takes longer. nothing you can do about it.
> but even so, i do not think anyone has ever done the the self-contained
> deal wholly right.

Probably true.

> you can't push a single look and feel. just won't
> fly. and people will look elsewhere if they can. now if the FOX people
> got smart, they would jump on getting a Themes and Behaviors Manager
> going like i described in a previous post. Then FOX would truly rock!

I do like FOX -- its fairly clean and lean. Although, my top addition to FOX
would be internationalization support.

> But until then, i'm looking at getting a binding to wxWindows instead.
> At least that's a direction i can take such that i know eventually i
> will have native intergration.
>
> ~transami

Curt

[Clifford Heath]

Tom Sawyer wrote:
> but even so, i do not think anyone has ever done the the self-contained
> deal wholly right. you can't push a single look and feel. just won't
> fly.

Have you ever used Qt? I think it does a good job of the whole styles
thing - you can switch between 5+styles on the fly.

--
Clifford Heath

[Tom Sawyer]

On Mon, 2002-07-29 at 22:35, Clifford Heath wrote:
> Have you ever used Qt? I think it does a good job of the whole styles
> thing - you can switch between 5+styles on the fly.

really? that's interesting and sounds impressive. but what kind of
styles are we talking about?

to be clear i'm talking about native integration. so if i'm running
under qt, the app looks and behaves as if it were a qt app, but if i'm
running under windows, the same app looks and behaves as if it were a
windows app. essentially "platform mimicry" vs. "platform parley". the
later is what wxWindows does. but i've never seen a GUI system do the
former.

--
~transami

[Pierre Brengard]

Tom Sawyer wrote:

>On Mon, 2002-07-29 at 22:35, Clifford Heath wrote:
>
>
>>Have you ever used Qt? I think it does a good job of the whole styles
>>thing - you can switch between 5+styles on the fly.
>>
>>
>really? that's interesting and sounds impressive. but what kind of
>styles are we talking about?
>
>

native toolkits styles : Windows, Motif, SGI, CDE, Platinum,... and if
you are not satified with them, you can design your own style.

>to be clear i'm talking about native integration. so if i'm running
>under qt, the app looks and behaves as if it were a qt app, but if i'm
>running under windows, the same app looks and behaves as if it were a
>windows app. essentially "platform mimicry" vs. "platform parley". the
>later is what wxWindows does. but i've never seen a GUI system do the
>former.
>
>

That's exactly what Qt provides but I am not sure of 'running under Qt'
means...
I don't get the difference between "mimicry" and "parley", could you
explain it more ?

Pierre

[Tom Sawyer]

On Tue, 2002-07-30 at 00:38, Pierre Brengard wrote:
> native toolkits styles : Windows, Motif, SGI, CDE, Platinum,... and if
> you are not satified with them, you can design your own style.

..

> That's exactly what Qt provides but I am not sure of 'running under Qt'
> means...
> I don't get the difference between "mimicry" and "parley", could you
> explain it more ?

no problem.

first, there's an import distinction to make here. when qt offers styles
similar to windows, motif, or what have you, you're still running under
qt. what we're talking about here is actually running a cross-platform
application on different platforms.

if your application uses a GUI toolkit such as FOX, which is a
cross-platform toolkit, what you'll get is a FOX look and feel
regardless of the platform your running on. This is becasue FOX is
self-contained --it takes car of everything itself. but it does not
offer mimicry, i.e. it won't pretend to be a native application with the
look and feel of windows under windows, or qt under qt (with whatever
style it is using), etc. wxWindows on the other hand is not
self-contained. it translates its toolkit into the native platform's.
this is what i mean by "parley". thus your application will have the
look and feel of the platform your running on (b/c it is).

but the "parley" approach entails sacrifices. you're simply not going to
be able to cover all the bases of all the possible native GUI's your
translating to. it also takes a toll on speed and efficiency.

what i am suggesting is that the optimal approach would be one of a
self-contained toolkit, like FOX, but that also mimics the native
platform it is running on. hence, the best of both worlds.

~transami

[Pierre Brengard]

Tom Sawyer wrote:

>On Tue, 2002-07-30 at 00:38, Pierre Brengard wrote:
>
>
>>native toolkits styles : Windows, Motif, SGI, CDE, Platinum,... and if
>>you are not satified with them, you can design your own style.
>>
>>
>

>...

Thanks for your reply.
I think you would be interested in Qt, then.
Qt relies on low level layers to do the graphical stuff (X or the MS low
level API) and mimic the look and feel of the native toolkit it is
installed on.

Pierre

[Benjamin Sommerfeld]

Sorry, I'm a newbie here and maybe I'm asking a question that's already been asked, but I'll do it anyway:-)

Due to platform-independency: Isn't GTK the best choice right now? It's free, it's open.
QT isn't totally free for Windows-platforms for example only a non-commercial version is available, for Linux it's totally free (as far as i can see on the website)

WxWindows is also nice I guess. Is there already a Ruby-binding somewhere?

Sorry if I tell you things you've heard already:-)

Ben

[Tom Sawyer]

On Tue, 2002-07-30 at 02:13, Pierre Brengard wrote:
> Thanks for your reply.
> I think you would be interested in Qt, then.
> Qt relies on low level layers to do the graphical stuff (X or the MS low
> level API) and mimic the look and feel of the native toolkit it is
> installed on.

thanks pierre. i did not know that qt was so capable. i checked it out.
very impressive. it was unclear whether they were mimicing or parleying
though. different sections suggested both methods. but i got the overall
feeling that they were translating (parley) but at compile time rather
then at runtime. and that is an excellent way to do it for compiled
code.

but there's one major reason i won't (and can't) use qt: the $4000 price
tag.

thanks for the info though,

~transami

[Tom Sawyer]

hi ben,

no worries on the newbie status.

from my understanding running GTK on macs is some what of a hack, but i
have no real experience with this. i do know that GTK on windows is not
super stable. gimp on windows has crashed on me a number of times. (but
that's okay b/c i use linux ;-) so it dosn't bode well for
cross-platform applications. any one have a different opinion? besides
that, it dosen't offer native integration.

as for wxWindows, we are questing for a binding. has anyone started such
a thing? is anyone willing to take it on?

~transami

--
~transami

[Hal E. Fulton]

----- Original Message -----
From: "Curt Hibbs" <cu...@hibbs.com>
To: "ruby-talk ML" <ruby...@ruby-lang.org>
Sent: Monday, July 29, 2002 9:46 AM
Subject: RE: wxWindows for ruby

> It is also worth noting that the SWT (from the Eclipse project) also takes
> the approach of wrapping naive widgets (enhancing them where needed).

"Naive" widgets!!

What a wonderful, wonderful typo! I nominate
that for Freudian Slip of the Month...

Hal

[repeater]

> as for wxWindows, we are questing for a binding. has anyone started such
> a thing? is anyone willing to take it on?

greetings transami

http://sourceforge.net/projects/wxruby/
currently non-existent, but i wouldn't mind investing some effort. care to
join ?

regards
repeater

[Tom Sawyer]

sign me up. my c/c++ expierence is quite rusty. but i'll contribute
where i can.

--
~transami

[Clifford Heath]

Tom Sawyer wrote:
> really? that's interesting and sounds impressive.

Go straight to www.trolltech.com and download yourself the Unix
source code or binary (if you have Debian or RedHat you'll find
packages in those dists). Do not pass go. Consider getting the
Windows binary version for evaluation while you're there. And if
you need proof of just how good it is, try a copy of the Opera
web browser for your favourite platform - it's built in Qt.

> So if i'm running under qt

You don't "run under" Qt - it's a toolkit not a windowing environment.

> the app looks and behaves as if it were a qt app, but if i'm
> running under windows, the same app looks and behaves as if it were a
> windows app.

Qt mimics Motif and Windows and IMO does better than native at implementing
each.

> essentially "platform mimicry" vs. "platform parley". the
> later is what wxWindows does. but i've never seen a GUI system do the
> former.

The latter is what OpenUI did too, but there are a number of examples which
have taken the mimicry path. Have a (long) read of the platform-independent
GUI faq at <http://www.faqs.org/faqs/portable-GUI-software/part1/>.

--
Clifford Heath

[Lyle Johnson]

"Clifford Heath" <cjh_n...@managesoft.com> wrote in message
news:3D4727AD...@managesoft.com...

> The latter is what OpenUI did too, but there are a number of examples
which
> have taken the mimicry path. Have a (long) read of the
platform-independent
> GUI faq at <http://www.faqs.org/faqs/portable-GUI-software/part1/>.

Do you know if this FAQ has been updated in the last five years? It doesn't
mention some of the more popular cross-platform GUI toolkits available
today, such as FLTK (http://www.fltk.org) or FOX
(http://www.fox-toolkit.org). It doesn't even mention this "GTK" thing that
I keep hearing about ;)

[Clifford Heath]

Lyle Johnson wrote:
> Do you know if this FAQ has been updated in the last five years?

Not sure, but I doubt it. The stuff about OpenUI was way out of date
most of the time even when it was actively being sold.

I guess the owner didn't have time, or perhaps Java just changed the
game so he thought there was no point any longer.

--
Clifford Heath