Squeak-like Ruby env

[capnregex]

Hi,

If you read

http://codespeak.net/pipermail/pypy-dev/2006q2/003036.html

right after reading about and checking out

http://www.mike-austin.com/inertia/

do you also think about an effort to use the latter to create
something in the line of the former to give something like in the
subject?

Comments? Good? Bad? Worth the effort? What about moving FreeRIDE onto
something like Inertia? Much more freedom in what can be
visualized/done since there is no GUI framework restricting us…

Regards,

Robert

[capnregex]

Could be very cool. If Mike A. releases his project and lets others
join in I’d help out for sure. As long as we don’t make it look like a
teddy bear book for kids like squeak… It can be easy to use and
beautiful, can’t it?

-Jeff

[capnregex]

On 4/24/06, Robert F. [email protected] wrote:

do you also think about an effort to use the latter to create
something in the line of the former to give something like in the
subject?

Comments? Good? Bad? Worth the effort? What about moving FreeRIDE onto
something like Inertia? Much more freedom in what can be
visualized/done since there is no GUI framework restricting us…

Very nice. I would love to see something like this become available.

Curt

[capnregex]

On 4/24/06, Ryan L. [email protected] wrote:

just sweetens the pot.

It would be nice if we could build off of Mike’s work on Intertia, but
if that isn’t possible, we at least have his work as a
proof-of-concept, and 1500 lines of Ruby code isn’t too bad for what
Inertia can do.

Much like Guido’s plea in the Python community, we probably just need
someone to spearhead this effort. Has anyone contacted Mike about
this? Mike are you listening?

I’m not the guy to lead this since I have my hands full but I have a
pre-release of Inertia (now circa 2500 lines including an editor and
quite a few widgets) so I definetely think Mike intend to release this
publically at some point. So planning now is a good idea, imho.

Regards,

Robert

[capnregex]

On 4/24/06, Robert F. [email protected] wrote:

Comments? Good? Bad? Worth the effort? What about moving FreeRIDE onto
something like Inertia? Much more freedom in what can be
visualized/done since there is no GUI framework restricting us…

I’ve had thoughts that SDL could be used for a “native” Ruby GUI, and
this just proves that it is entirely possible, if not a good idea.
Certainly within the context of a self-contained “Squeak-like”
programming environment, it makes sense. Adding OpenGL into the mix
just sweetens the pot.

It would be nice if we could build off of Mike’s work on Intertia, but
if that isn’t possible, we at least have his work as a
proof-of-concept, and 1500 lines of Ruby code isn’t too bad for what
Inertia can do.

Much like Guido’s plea in the Python community, we probably just need
someone to spearhead this effort. Has anyone contacted Mike about
this? Mike are you listening?

Ryan

[capnregex]

Ryan L. wrote:

I’m in. I live object system with a refactoring browser would be really
great in ruby, and with opengl on the back end from the start we could
quickly improve on the teddy bear look & feel of squeak.

This could be a perfect candidate for the google summer of code projects
from ruby central… I’m applying as a student, but someone out there
should send it in as a mentor!

-Jeff

[capnregex]

On 4/24/06, Robert F. [email protected] wrote:

Certainly within the context of a self-contained “Squeak-like”
this? Mike are you listening?

Just another reply of full encouragement, looks great and promising and
ruby
definetly would profit a lot of such a project.

Cheers
Robert

Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.

• Albert Einstein

[capnregex]

On 4/24/06, David P. [email protected] wrote:

My 2 cents.

Thanks,

David

Is it this one (http://developer.apple.com/tools/interfacebuilder.html)
you
are referring to?
Would there not be licence issues?

Robert

On 4/24/06, Robert D. [email protected] wrote:

proof-of-concept, and 1500 lines of Ruby code isn’t too bad for what
publically at some point. So planning now is a good idea, imho.
Cheers
Robert
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.

• Albert Einstein

–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.

• Albert Einstein

[capnregex]

Folks,

How about looking at OS X’s Interface Builder. It comes out of the
SmallTalk world and is totally amazing. A Ruby implementation would be
totally killer and perhaps allow Ruby to be a desktop app authoring
language
as well as a web-app authoring language and avoiding one of Java’s
mis-steps.

My 2 cents.

Thanks,

David

[capnregex]

On Apr 24, 2006, at 12:41 PM, Robert D. wrote:

Is it this one (http://developer.apple.com/tools/
interfacebuilder.html) you
are referring to?
Would there not be licence issues?

Robert

Doubtful. Dragging widgets onto forms has been around forever, and as
far as the other stuff goes, there’s some good evidence[1] that there
aren’t any patent problems.
[1] GNUstep Developer Tools: Gorm

[capnregex]

On 4/24/06, Logan C. [email protected] wrote:

Doubtful. Dragging widgets onto forms has been around forever, and as
far as the other stuff goes, there’s some good evidence[1] that there
aren’t any patent problems.
[1] GNUstep Developer Tools: Gorm

Excellent point we have prior art here, than maybe it would be worth
looking
at it too!

–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.

• Albert Einstein

[capnregex]

On 4/24/06, Ilmari H. [email protected] wrote:

this just proves that it is entirely possible, if not a good idea.
re-implementing GUI widgets is a lot of work.
Take a simple text editing box for instance:
that’s one vim (or emacs) worth of code right there.

I agree it is lots of work but the Editor widget in Inertia is
currently 230 LOC including empty lines. Granted it has only very
basic functionality but getting to a useful state cannot be too hard.

Not to mention HTML renderers.

Yes, there are many hard stuff out there but look at it this way
instead: It would be a great vehicle for GUI innovation. For apps
where the standard widgets are the way to go maybe this is not the
right framework. But what about LiveUpdatableGraphs etc? Where are
they in standard widget kits? etc…

Integrating kparts would be a way (
no idea how doable that is though,
ie. how to render a kpart to a texture and
translate input events for it.
)

Sounds interesting. What is kparts?

Regards,

Robert

[capnregex]

Ilmari,

On a related note: Since you have been into Ruby and OpenGL stuff
before (librend, right?) what are your thoughts on the main
event/drawing loop? Inertia currently takes quite a large percentage
of my CPU time (I could get down to about 15% without noticeable lag
in the UI); I guess Mike has not been considering optimizations much
at this stage. If you do things in OpenGL will it update only the
portions that need updating or what are some different strategies for
optimizing the drawing? Care to enlighten us? But maybe in librend
it’s not a problem cause you use all the cpu time you can get for
better frame rates?

On the widgets-are-much-work question: Also remember that much code is
already out there and we can base things on that. Squeak, other widget
kits etc. For an editor there are also several pure-Ruby offerings out
there that can be used (Simon had AEditor, there is a ruby-vim/ruvim)
etc.

Thanks,

Robert

[capnregex]

Hi,

On 4/24/06, Ryan L. [email protected] wrote:

just sweetens the pot.

It would be nice if we could build off of Mike’s work on Intertia, but
if that isn’t possible, we at least have his work as a
proof-of-concept, and 1500 lines of Ruby code isn’t too bad for what
Inertia can do.

I don’t want to rain on your parade but
re-implementing GUI widgets is a lot of work.
Take a simple text editing box for instance:
that’s one vim (or emacs) worth of code right there.

Not to mention HTML renderers.

Integrating kparts would be a way (
no idea how doable that is though,
ie. how to render a kpart to a texture and
translate input events for it.
)

Never got far in re-implementing GUI widgets
so if anyone did, speak up,
with the grisly war stories.

Ilmari

[capnregex]

I’m in. I live object system with a refactoring browser would be really
great in ruby, and with opengl on the back end from the start we could
quickly improve on the teddy bear look & feel of squeak.

This could be a perfect candidate for the google summer of code projects
from ruby central… I’m applying as a student, but someone out there
should send it in as a mentor!

I could be a mentor but I don’t really know what it entails. Any
links? (Better yet maybe if Mike wants to be a mentor but maybe you
can have several?)

/Robert

[capnregex]

On 4/24/06, Robert F. [email protected] wrote:

I could be a mentor but I don’t really know what it entails. Any
links? (Better yet maybe if Mike wants to be a mentor but maybe you
can have several?)

http://code.google.com/soc/mentorfaq.html

Regarding Ilmari’s reservations about re-inventing GUI components
(which has been done too much already), I certainly see your point and
agree in many ways. But if you think about it game programmers do this
all the time, and it works because of the focus involved (they only
need certain things in the game.)

I think if the same can be applied in this scenario, where the first
focus is simply an all-encompassing Ruby programming system, a la
Squeak, things could be more simple. Things like a complex HTML
rendering just would not be needed. Because of the nature of the
entire environment, the editor may not have to be as powerful as VIM
or Emacs or . Another point would be
that while all these GUI components already exist in various
frameworks, none are pure Ruby. A pure Ruby GUI framework would
probably be much simpler and allow for some true innovation, at least
with the Ruby world. It would be easier to play around with UI
concepts in such an environment.

Ryan

[capnregex]

On 4/24/06, Robert F. [email protected] wrote:

On 4/24/06, Ilmari H. [email protected] wrote:

re-implementing GUI widgets is a lot of work.
Take a simple text editing box for instance:
that’s one vim (or emacs) worth of code right there.

I agree it is lots of work but the Editor widget in Inertia is
currently 230 LOC including empty lines. Granted it has only very
basic functionality but getting to a useful state cannot be too hard.

A lot could be achieved by making a method call widget that’d
bring up a form for the method’s params:
Right-click/use call-method kb shortcut on a String object,
select gsub, up pops a form with a pattern field,
a (optional) replacement field, and a block editor.
Type in the params and it creates a new String object.

GUIs are programming languages, in a way. So leveraging
the underlying programming language for as much existing
functionality as possible would be really great.

The hard work that remains is: rendering, user preferences,
undo, different text directions, layout, input methods, integrating
all this into a usable GUI, letting other people benefit from it

It would be a great vehicle for GUI innovation. For apps
where the standard widgets are the way to go maybe this is not the
right framework. But what about LiveUpdatableGraphs etc? Where are
they in standard widget kits? etc…

Yes, for new stuff it’d be great. Just native 3D capability in a gui
toolkit
opens the door for all kinds of nifty things that are not that doable
with
pure 2D drawing (smooth zooming, distortions, lenses, panning a
landscape, perspective, etc.)

Integrating kparts would be a way (
no idea how doable that is though,
ie. how to render a kpart to a texture and
translate input events for it.
)

Sounds interesting. What is kparts?

KDE’s component framework [1]. E.g. KWrite, Kate and KDevelop all
can use the same KTextEditor part for their editing needs instead
of writing their own (and the part can be switched to another too[2].)

I don’t know how they would fit the Self/Morphic/Naked Objects -system,
but they seem to be very mimetype-centric; there’s an image kpart,
video kpart, html kpart. And mimetypes map to classes well.

[1] KDE Frameworks - Wikipedia
[2] http://www.freenux.org/mirrors/kvim/screenshots.html

Ilmari

[capnregex]

On 4/24/06, Ryan L. [email protected] wrote:

On 4/24/06, Robert F. [email protected] wrote:

I could be a mentor but I don’t really know what it entails. Any
links? (Better yet maybe if Mike wants to be a mentor but maybe you
can have several?)

http://code.google.com/soc/mentorfaq.html

Hmm, sounds roughly equivalent to being a thesis advisor or tech/dev
lead. Personlly, I will be away from 13th June to 1st July so is not
good timing when it comes to the mid-term eval. But if someone is
willing to team up on the mentoring side I’d volounteer to do this.

entire environment, the editor may not have to be as powerful as VIM
or Emacs or . Another point would be
that while all these GUI components already exist in various
frameworks, none are pure Ruby. A pure Ruby GUI framework would
probably be much simpler and allow for some true innovation, at least
with the Ruby world. It would be easier to play around with UI
concepts in such an environment.

Well expressed, Ryan.

/Robert

[capnregex]

On 4/24/06, Robert F. [email protected] wrote:

it’s not a problem cause you use all the cpu time you can get for
better frame rates?

OpenGL redraws everything all of the time,
much like a ninja flipping out.
The good thing about that is that OpenGL is fast enough to do that.
The bad thing is that Ruby becomes the limiting factor
(at least in librend.)

Optimizing drawing 2D elements is pretty much:
draw costly stuff into texture, use massive fillrate for compositing.
So you’d draw the glyphs of a font into a texture then draw ~2000
triangles with correct texture coordinates to create a 1000 letter
paragraph of text.) Current graphics cards can push around 100
times more texels than triangles per second, so this makes some sense.

Optimizing the CPU part is, roughly:

• do as few method (and proc) calls as possible
• create as few new objects as possible (Floats included)
• have as few individual objects in the scene as possible
• update the display only when something has changed
• limit the framerate to 60
• don’t write your own 3D engine but use Ogre3D or something

On the widgets-are-much-work question: Also remember that much code is
already out there and we can base things on that. Squeak, other widget
kits etc. For an editor there are also several pure-Ruby offerings out
there that can be used (Simon had AEditor, there is a ruby-vim/ruvim)
etc.

Yeah, granted. Working from existing code would make reimplementing go
much faster.

Ilmari

[capnregex]

On Apr 24, 2006, at 6:00 AM, Robert F. wrote:

do you also think about an effort to use the latter to create
something in the line of the former to give something like in the
subject?

Comments? Good? Bad? Worth the effort? What about moving FreeRIDE onto
something like Inertia? Much more freedom in what can be
visualized/done since there is no GUI framework restricting us…

What do you envision when you say “Squeak like”?

In the context of the second link it looks like you want something
like persistent irb with a fancier editor.

If you want Squeak’s Ruby written in Ruby with a cool editor and
persistent everything so you can change it all then help out with
Metaruby.

–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com