Funny, two savannah accounts for the same objective:
https://savannah.gnu.org/projects/rouge/
But the only code I know of is for the so-called Gamma part of Rouge
(by me, doh), building on Xlib, called Ruby-Wise:
http://httpd.chello.nl/k.vangelder/ruby/wise/
To give an idea of usability: I’m running an addressbook app with it on my
iPAQ. It is far from finished, but very much alive.
Bye,
Kero.
Funny, two savannah accounts for the same objective:
Rouge - Summary [Savannah]But the only code I know of is for the so-called Gamma part of Rouge
(by me, doh), building on Xlib, called Ruby-Wise:
http://httpd.chello.nl/k.vangelder/ruby/wise/To give an idea of usability: I’m running an addressbook app with it on my
iPAQ. It is far from finished, but very much alive.
Maybe his energy can be used on your project,
if the paradigms are not incompatible.
Unfortunately, there are as many perceptions
of what a GUI ought to be as there are GUI
programmers. That is why we have so many GUIs.
And it is so much harder than it looks. That
is why none of them is perfect.
Hal
----- Original Message -----
From: “Kero van Gelder” kero@chello.nl
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, August 07, 2002 2:04 PM
Subject: [OT] GUI’s and the Rouge, Part IV
well, both rich and i have some code. check the cvs on gutopia’s
savannah site. it’s very alpha but i do get a semi-working gui to come
up. i have been creating a proof-of-concept fox backend for gutopia, but
i really am not enjoying how fox works. so i also threw together a gtk
one, which is almost as functional. get that to the cvs soon.
but all this leads me to…i’ll take your ruby-wise and give it a go as
the backend. our main hope has been for a wxWindows binding on the omega
layer. but i’d be more then happy to check yours out as the gamma! --i
really hadn’t considerd a gamma unitl now. in fact granted that
ruby-wise is capable enough, i’ll make it my main focus for the time
being. should be sweet!
if you haven’t caught it yet. gutopia’s main focus is on the alpha
layer. if you’d like to have any input on this please join the gutopia
dev mailing list.
~transami
On Wed, 2002-08-07 at 13:04, Kero van Gelder wrote:
Funny, two savannah accounts for the same objective:
Rouge - Summary [Savannah]But the only code I know of is for the so-called Gamma part of Rouge
(by me, doh), building on Xlib, called Ruby-Wise:
http://httpd.chello.nl/k.vangelder/ruby/wise/
quick question for you kero (cool name by the way),
i read over the wise user guide. one of the things gutopia requires is
to be able to create widgets without parents and allow the parents to
pick them up later. do i just use nil as the widget’s parent for this?
becasue the fox toolkit requires a parent i had to create an invisible
“foo” window that held the widgets until the parent needed them. kind of
a kludge.
~transami
On Wed, 2002-08-07 at 13:04, Kero van Gelder wrote:
To give an idea of usability: I’m running an addressbook app with it on my
iPAQ. It is far from finished, but very much alive.
hey kero,
having a problem getting ruby-wise to run. i found the test.rb script
and tried to run it, but i get an error:
./wise.rb:in ‘require’: No such file to load – wise/native (LoadError)
looking at the files in wise, i notice native.so is the only .so file
there. did this perhaps not get moved to the right place on install?
i would love to get this running and check it out.
thanks,
~transami
On Wed, 2002-08-07 at 13:04, Kero van Gelder wrote:
Funny, two savannah accounts for the same objective:
Rouge - Summary [Savannah]But the only code I know of is for the so-called Gamma part of Rouge
(by me, doh), building on Xlib, called Ruby-Wise:
http://httpd.chello.nl/k.vangelder/ruby/wise/To give an idea of usability: I’m running an addressbook app with it on my
iPAQ. It is far from finished, but very much alive.Bye,
Kero.
–
~transami
“Tom Sawyer” transami@transami.net wrote in message
news:1028761083.1778.100.camel@silver…
becasue the fox toolkit requires a parent i had to create an invisible
“foo” window that held the widgets until the parent needed them. kind of
a kludge.
Could you maybe defer the construction of the actual FOX widget until it’s
added to a parent (or however it is in GUtopIa that you associate child
widgets with parent containers)? I’m not familiar enough with the GUtopIa
architecture to know if this is doable or not.
To give an idea of usability: I’m running an addressbook app with it on my
iPAQ. It is far from finished, but very much alive.quick question for you kero (cool name by the way),
i read over the wise user guide. one of the things gutopia requires is
to be able to create widgets without parents and allow the parents to
pick them up later. do i just use nil as the widget’s parent for this?
nil-parent causes the window to be top-level, as for Ruby/Tk.
becasue the fox toolkit requires a parent i had to create an invisible
“foo” window that held the widgets until the parent needed them. kind of
a kludge.
reparenting is a kludge. Ruby-Wise can’t reparent, yet.
On Thu, 08 Aug 2002 00:51:37 +0200, Tom Sawyer wrote:
run from the parent directory of wise.
ruby wise/test.rb
I’ll check whether the test program still works, I tend to edit it
heavily, then not at all for a while… works for me, hope it does for you.
On Thu, 08 Aug 2002 09:06:00 +0200, Tom Sawyer wrote:
hey kero,
having a problem getting ruby-wise to run. i found the test.rb script
and tried to run it, but i get an error:./wise.rb:in ‘require’: No such file to load – wise/native (LoadError)
looking at the files in wise, i notice native.so is the only .so file
there. did this perhaps not get moved to the right place on install?
i thought about this, breifly. i will consider it some more.
quick example on how children are assoc. to parents:
abutton = GUtopIa::Button.new
awindow = GUtopIa::Window.new
awindow.body = [ [ abutton ] ]
so as you can see from this, the button needs to have some sort of
existence prior to being told were it will show up. we have done it this
way to allow for greater flexibility with regards to layout definition
(ie. in the example above GUtopIa knows this is a grid layout b/c of the
double array structure of body) and also for the ability to easily and
dynamically reassign widget locations. (in fox you do this with the
reparent method)
so i hesitate to adjust the way GUtopIa handles this, just for fox’s
sake. the “foo” window may be a kludge, but it seems to work okay --i
don’t see any problems with doing this, but perhaps there are?
~transami
On Wed, 2002-08-07 at 20:25, Lyle Johnson wrote:
Could you maybe defer the construction of the actual FOX widget until it’s
added to a parent (or however it is in GUtopIa that you associate child
widgets with parent containers)? I’m not familiar enough with the GUtopIa
architecture to know if this is doable or not.
Could you maybe defer the construction of the actual FOX widget until
it’s
added to a parent (or however it is in GUtopIa that you associate child
widgets with parent containers)? I’m not familiar enough with the
GUtopIa
architecture to know if this is doable or not.i thought about this, breifly. i will consider it some more.
quick example on how children are assoc. to parents:
abutton = GUtopIa::Button.new
awindow = GUtopIa::Window.new
awindow.body = [ [ abutton ] ]so as you can see from this, the button needs to have some sort of
existence prior to being told were it will show up. we have done it this
way to allow for greater flexibility with regards to layout definition
(ie. in the example above GUtopIa knows this is a grid layout b/c of the
double array structure of body) and also for the ability to easily and
dynamically reassign widget locations. (in fox you do this with the
reparent method)so i hesitate to adjust the way GUtopIa handles this, just for fox’s
sake. the “foo” window may be a kludge, but it seems to work okay --i
don’t see any problems with doing this, but perhaps there are?
I don’t know if there are problems or not.
Thought I’d comment even though I don’t understand the
overview that well.
If what I say is junk, just ignore it.
If you’re wanting to delay instantiating the widgets, I would
say you might replace the widget itself with (say) an array
that contained enough information to create that widget – the
class and any parameters to new.
abutton = [GUtopIa::Button, any, params, we, might, need]
awindow = GUtopIa::Window.new
awindow.body = [ [ abutton ] ]
Code could easily tell that abutton was an array rather than a
widget, and later could do
abutton = abutton[0].new(*abutton[1…-1]) # Now I’m a real button
Just a crazy thought. Past my bedtime here.
Hal
----- Original Message -----
From: “Tom Sawyer” transami@transami.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, August 08, 2002 2:15 AM
Subject: Re: [OT] GUI’s and the Rouge, Part IV
On Wed, 2002-08-07 at 20:25, Lyle Johnson wrote:
Tom Sawyer wrote:
Could you maybe defer the construction of the actual FOX widget until it’s
added to a parent (or however it is in GUtopIa that you associate child
widgets with parent containers)? I’m not familiar enough with the GUtopIa
architecture to know if this is doable or not.i thought about this, breifly. i will consider it some more.
quick example on how children are assoc. to parents:
abutton = GUtopIa::Button.new
awindow = GUtopIa::Window.new
awindow.body = [ [ abutton ] ]so as you can see from this, the button needs to have some sort of
existence prior to being told were it will show up.
To be sure you’re clear about what I meant by deferring construction of
the FOX widget:
Yes, the GUtopIa::Button instance needs to exist prior to being told
where it will show up (i.e. who its parent will be). But am I correct in
assuming that a GUtopIa::Button is a wrapper around an FXButton (or a
GTK::Button, or whatever)? And if so, maybe you can delay instantiating
the FXButton instance until late in the game. A lazy evaluation strategy
of sorts.
So i hesitate to adjust the way GUtopIa handles this, just for FOX’s
sake. the “foo” window may be a kludge, but it seems to work okay --i
don’t see any problems with doing this, but perhaps there are?
I’m not sure that you would need to adjust the way that GUtopIa handles
things (at least from the public API standpoint that you’ve described).
I mean, it’s going to be true for any GUI toolkit that you choose that
until a child widget is associated with a parent window you’re not going
to be able to realize that child widget. GTK isn’t going to let you
create a standalone GTK::Button widget and show it onscreen before you
pack it into some parent container. But it is true that (at least for
the FOX-based implementation) you’d need to structure things so that
this deferred creation strategy works properly.
OTOH, if a “fake” parent window kludge is already working for you, I
can’t think of any problem with that.
On Wed, 2002-08-07 at 20:25, Lyle Johnson wrote:
~transami
not a bad notion. could do all of them that way and only bring them in
existence later. but i’d want to name the parameters ie.:
abutton = { GUtopIa::Button, :any => any, :params => params, … }
awindow = { GUtopIa::Window, :body => [ [ abutton ] ] }
i’ll think on it.
On Thu, 2002-08-08 at 01:26, Hal E. Fulton wrote:
If you’re wanting to delay instantiating the widgets, I would
say you might replace the widget itself with (say) an array
that contained enough information to create that widget – the
class and any parameters to new.abutton = [GUtopIa::Button, any, params, we, might, need]
awindow = GUtopIa::Window.new
awindow.body = [ [ abutton ] ]Code could easily tell that abutton was an array rather than a
widget, and later could doabutton = abutton[0].new(*abutton[1…-1]) # Now I’m a real button
Just a crazy thought. Past my bedtime here.
–
~transami