Help the gnu-smalltalk project

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Help the gnu-smalltalk project

MrGwen
Hi,

I'm new to gnu-smalltalk and I would like to help you.
During this summer I've worked on the gtk plugin for squeak.
May be I can help you on that side or adding the support of webkit
for gnu-smalltalk or the support of multiprocessors for the vm ;)

If you want that I do other stuffs there are no problems ;)

Cheers,
Gwenael


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Help the gnu-smalltalk project

Paolo Bonzini-2

> I'm new to gnu-smalltalk and I would like to help you.
> During this summer I've worked on the gtk plugin for squeak.
> May be I can help you on that side or adding the support of webkit
> for gnu-smalltalk or the support of multiprocessors for the vm ;)

You look like a UI guy, but if you don't have problems with more
infrastructure work (that *will* have an effect on the UI in the medium
term), one thing that you can do is to a file-based change management
system: that would be making a set of classes that represent changes
(patches to methods, adding/removing instance variables, and so on), and
being able to apply them to files.  A lot of the code from the
Refactoring Browser can actually be leveraged.

To apply changes to files, you'd need a parser for the GNU Smalltalk
syntax; right now there is one in packages/stinst/parser/GSTParser.st
but it just converts the syntax to doits.  You can hijack most of the
code, but what you need is a little different because you have to track
the syntax elements (i.e. there should be a visitor API similar to SAX,
tracking the locations so that you can reconstruct the original file as
accurately as possible).  It's not a syntax tree, it's not a lot of code
to write.

Plugging that in the browser should not be hard, and would provide the
single missing block that's needed to program GNU Smalltalk in the browser.

I know about your GSOC project, and it's a pity that you cannot leverage
it fully.  Unfortunately, even though I ported OB-Core and it all went
fine, the OmniBrowser-based browsers were completely unportable, and it
is easier to rewrite them than to port them.  I have some ideas for an
alternative UI model, but it's stuck on the lack of support in GTK+ (it
should go in 2.16, hopefully).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Help the gnu-smalltalk project

Paolo Bonzini-2
Martin Beck wrote:

> Paolo Bonzini wrote:
>> I know about your GSOC project, and it's a pity that you cannot leverage
>> it fully.  Unfortunately, even though I ported OB-Core and it all went
>> fine, the OmniBrowser-based browsers were completely unportable, and it
>> is easier to rewrite them than to port them.  I have some ideas for an
>> alternative UI model, but it's stuck on the lack of support in GTK+ (it
>> should go in 2.16, hopefully).
>>
> Just out of curiosity: Did you ever think of integrating Qt instead of
> Gtk?

I didn't write the entire Gtk+ binding, though I enhanced it a bit after
it was contributed.  If you want to write Qt bindings, I'll be pleased
to integrate them of course.

BTW, Gwanael, one other thing you could do is to rewrite the Gtk+
binding to base it on GObject-introspection (parsing the XML type
libraries) instead of awk scripts.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk