Time to change our GUI toolkit?

[Daniel Lucraft]

Hi everyone,

I am considering porting Redcar from Ruby+GTK to JRuby+Swing. This is
by no means certain, so please comment now if you have any thoughts on
the matter.

(For those of you who aren't aware, JRuby is a 100% Ruby compatible
interpreter for the JVM. JRuby performance is now better than Ruby
1.8, though not Ruby 1.9, and has good interoperability with Java.)

Reasons for the possible move:

- continuing difficulties with the Ruby-GNOME2 platform, in
particular:

* installation problems;
* seemingly random and undiagnosable segfaults;
* a tendency to segfault when using threads that has led to serious
compromises in way we use dialogs just so they can be tested;
* great difficulty in installation on Mac OS X and poor OS X
integration.

- I haven't yet tried, but getting Vala to compile and link on OS X is
not something I am looking forward to, considering my failure in
getting RG2 to build.

- Swing native look and feel is good on Gnome and Mac OS X. This is
quite important to me.

- We can reuse the JEdit editor widget, which is excellent: it's quick
and it supports rectangular selections. Since it's written in Java
we'll have an easier time of hacking it if we need to as well.

- I have more confidence in ongoing support for the JRuby+Swing
combination than I do for Ruby/GTK.

- The possibility of using any JVM language for scripting Redcar, and
a more well-known low-level language than Vala for writing performant
sections. This would be helpful because no one involved in Redcar
except me knows anything about Vala, and I wouldn't want to ask anyone
to learn it just for this project.

- The possibility of using Scala for the highlighting parser.

What it would take:

- Port a lot of the Redcar code from GTK -> Swing. For things like
Redcar::Window and Redcar::Pane and most of the text commands this is
essentially a rewrite.

- A lot of the Textmate compatibility stuff written in Ruby can be
moved across with no changes. Also the plugin system (FreeBASE) would
make the move with no problems.

- Port GtkMateView to Java/Scala. This is tedious but not risky since
it is currently written in Vala, which is a C#-like language.


Let us know what you think.

thanks,
Dan

_______________________________
Daniel Lucraft

twitter.com/danlucraft
danlucraft.com/blog

[Henrik Hodne]

On Aug 3, 3:12 pm, Daniel Lucraft <d...@fluentradical.com> wrote:
> Hi everyone,
>
> I am considering porting Redcar from Ruby+GTK to JRuby+Swing. This is
> by no means certain, so please comment now if you have any thoughts on
> the matter.

I think moving away from Ruby+GTK (Ruby-GNOME2) would be a good idea. I
never liked it too much, and it's been (as you said) troublesome to
install and errors at it's own will. However, I'm not sure if JRuby
+Swing is the best thing. I've used RubyQt4 for 1-2 weeks or so now, and
I really like it. But, if you feel more comfortable with (or by some
other reason prefer JRuby+Swing), by all means use that. I could use to
learn JRuby and Swing.

> What it would take:
>
> - Port a lot of the Redcar code from GTK -> Swing. For things like
> Redcar::Window and Redcar::Pane and most of the text commands this is
> essentially a rewrite.

I can help with this, just tell me if (when?) you decide to make the
switch (and to what (Swing / Qt / something completely else)).

> - Port GtkMateView to Java/Scala. This is tedious but not risky since
> it is currently written in Vala, which is a C#-like language.

I don't think this'll be too hard either, mostly a line-by-line port. I
think we could make some sort of automatic (search-replace?) thing do
the dirt work, and then look over it and change the rest ourselves.
Please note that I haven't looked at the Vala code, so I don't know how
similar the syntax is to Java, but since you say it's similar to C# (and
I know C# is quite similar to Java, I guess it's not too far away).

>
> Let us know what you think.

In short, a great idea which I'll think will help Redcar be an even more
awesome editor.

>
> thanks,
> Dan
>
> _______________________________
> Daniel Lucraft
>
> twitter.com/danlucraft
> danlucraft.com/blog

--
Henrik Hodne <henrik...@gmail.com> / PGP 0x592B62568DB635CA

ASCII ribbon campaign - stop HTML mail

[pciambrone]

In general, I agree that a toolkit change would be totally beneficial
to Redcar and help to alleviate a lot of the continuing headaches that
occur. I would be partial to the idea of JRuby/Swing since I have a
good amount of Java/Swing experience and wouldn't mind helping out
with any of the conversions you outlined.

I've been toying around with Clojure recently and have been curious
about JRuby, so this would give me an excuse to check it out :)

Even if this particular scenario isn't what happens, I'm all for the
idea of removing Ruby/GTK from the picture.

-Pat

[kungfoo]

I too vote in favor of a toolkit change.

Let me outline a few of my thoughts here:

I will definitely help with the development and the rewrite of the
necessary classes to fit them to any JVM-based GUI framework. I have
extensive experience in developing java applications and I do write
mainly using JVM languages at work (java, groovy, scala). In my
department I have been involved with the Groovy Eclipse plugin, on
which we are currently waiting for the rewrite of the groovy compiler.

Considering the toolkit: I have done a fair amount of coding in Swing
but also (for the eclipse IDE) SWT. I'd cosider both a possible path
to go for redcar. SWT already has a stylable editor component.

Porting to jRuby seems like a good way to alleviate the current
deployment problems, since jRuby apps can be packed up as a jar file
and then deployed in that form or via webstart.
Another great thing of the marriage between ruby and the JVM is that
it offers tremendous leverage. Ruby is great. Lots gems for Ruby are
totally awesome. But the JVM also offers quite a bit of leverage in
terms of libraries and such. Also there is the speed advantage of java
and that advantage comes at not as much developer/end user overhead as
the vala -> C <- ruby way.

To sum up, let's decide on the toolkit (maybe not immediately decide
but gradually) and start on this.

One thing I will also get my hands dirty with is setting up a
continuous integration server for redcar and an automated ant build
for it.

[Daniel B Lucraft]

I'm glad the response has been positive so far. And thank you all for
your offers of help, it is very much appreciated.

There are still some more people who I would like to weigh in so let's
not consider it settled just yet.

As for the choice of toolkit:

### Ruby/Qt

I think there are some negatives here that rule it out:

(1) I am not qualified to convert the Vala to C++, which would be
required in this case (?). In general fewer people are ready to work
on C++ than Java.
(2) What is OS X support for Qt like? I understand VLC is written in
it, so it must work, but I'm now very skeptical of Ruby-GUI binding
support for anything other than the happy-path.
(3) When I first looked into Qt/Ruby for Redcar back in 2007 it didn't
have a browser widget. Has this changed? A browser widget is essential
for Redcar.

### Swing

Pros:
(1) Included with Java.
(2) Plenty of people are using JRuby with it.
(3) Good look and feel.
(4) JEdit text component, which is designed for source code and
supports rectangular selections.

Cons:
(1) Not a native look and feel.

### SWT

Pros:
(1) Native look and feel. (As I understand it: I never thought Eclipse
looked that native actually.... those tabs!)
(2) Other intangibles??? Silvio?

Cons:
(1) Not included with Java
(2) Not so much JRuby usage - don't know if this is a real problem?

I don't know enough about Swing/SWT to know which is best. Can anyone
add any more points to these?

Silvio: is it possible to run Java+Swing/SWT tests on a headless linux
server? I tried and tried to get it working with Ruby-GNOME2 but I was
unsuccessful. If this is something we can do then it is another point
in favour of switching toolkits.

Henrik: a regex converter for Vala might help us save some finger
typing... though we'd still need to go through line by line I imagine.
It's quite ironic because there was recently a big discussion on the
Vala mailing list about an automated Mono -> Vala converter. To
encourage migration, you know :)

Thanks everyone, keep it coming.

Dan

[kungfoo]

>
> Henrik: a regex converter for Vala might help us save some finger
> typing... though we'd still need to go through line by line I imagine.
> It's quite ironic because there was recently a big discussion on the
> Vala mailing list about an automated Mono -> Vala converter. To
> encourage migration, you know :)
>
> Thanks everyone, keep it coming.
>
> Dan

I think this won't work. I think GTKMateView will have to be rewritten
drawing inspiration from the "old" code. Search+Replace won't cut it.

On GUI testing:
There are frameworks for functional GUI testing in both Swing and SWT.
Especially useful at first glance seems UISpec4J which is for Swing.

I will have a look into the jEdit codebase now in order to find out
how hard it would be to flesh out the juicy editor component :D

[Henrik Hodne]

On Tue, 2009-08-04 at 01:53 -0700, Daniel B Lucraft wrote:

> ### Ruby/Qt
>
> I think there are some negatives here that rule it out:
>

> (2) What is OS X support for Qt like? I understand VLC is written in
> it, so it must work, but I'm now very skeptical of Ruby-GUI binding
> support for anything other than the happy-path.

Qt itself runs with native look and feel on most desktop environment
(see http://doc.qtsoftware.com/4.5/gallery.html for examples)

> (3) When I first looked into Qt/Ruby for Redcar back in 2007 it didn't
> have a browser widget. Has this changed? A browser widget is essential
> for Redcar.

QtRuby4 has all of the classes, including a browser widget based on
WebKit. It also has a Rich Text Editor which uses HTML/WebKit.

However, QtRuby4 is C-based, so no JRuby for that. Another option would
be to use JavaQt, but I don't know how JRuby supports that.

> Henrik: a regex converter for Vala might help us save some finger
> typing... though we'd still need to go through line by line I imagine.
> It's quite ironic because there was recently a big discussion on the
> Vala mailing list about an automated Mono -> Vala converter. To
> encourage migration, you know :)

Indeed. Just poke me when you have decided it needs porting to Java, and
I'll throw together a converter.

>
> Thanks everyone, keep it coming.
>
> Dan

--

[Daniel B Lucraft]

On Aug 4, 10:30 am, kungfoo <silvio.heuber...@gmail.com> wrote:
> I think this won't work. I think GTKMateView will have to be rewritten
> drawing inspiration from the "old" code. Search+Replace won't cut it.

You are right, but we will draw more than inspiration. Some of the
logic in there is quite complicated so, in particular, the Parser will
be ported pretty much line for line. I did it once before in going
from Ruby+C to Vala. This is going to be one well-travelled library!

> On GUI testing:
> There are frameworks for functional GUI testing in both Swing and SWT.
> Especially useful at first glance seems UISpec4J which is for Swing.

I'm keen to keep using Cucumber, and apparently there's a library for
Swing called swinger that does what our Gutkumber does. I more meant
how easy is it run Swing outside of an X environment? (Or any graphics
environment)

> I will have a look into the jEdit codebase now in order to find out
> how hard it would be to flesh out the juicy editor component :D

Please do! You can build the code for the StandaloneEditArea
separately using the ant target build-jeditTextArea. I had further
trouble only because I don't know any Java :)

best,
Dan

[aokai]

I think switching from GTK is a good idea. Ruby gnome seems not to be
developed actively any more.

Both swing and swt seems to be a nice choice. I know some Swing (I
worked with 3 years ago I think) and some Swt. The wrapper for SWT
(http://www.eclipse.org/glimmer/) seems nice, but the last commit was
in december 08, so it seems to be abandoned. Swing has some nice
wrappers so it seems to be the better choice.
SWT uses native widgets when possible (like awt) and generates
platform independant ones when it is needed. This brings a performance
boost in comparison to Swing which generates all widgets, but Redcars
bottleneck is not the GUI components, so I think that should be no
problem.

I think the most important task here is to find a way to abstract the
GUI-Toolkit as much as possible. I don't mean we should write an ORM
or sth. for the GUI-Toolkit but really think about where the GUI
specific code should be called. At the moment the GTK code is
splattered all over the place. It is in the plugin files, the commands
and of course the GUI elements. Concentrating the code in one location
would allow a much easier change of the GUI Toolkit.

I vote for a gui toolkit change.

And i would propose jate as a new name, j for Java , ate for (text)
mate and well jade fits nicely to ruby ;)

[kungfoo]

>
> I think the most important task here is to find a way to abstract the
> GUI-Toolkit as much as possible. I don't mean we should write an ORM
> or sth. for the GUI-Toolkit but really think about where the GUI
> specific code should be called. At the moment the GTK code is
> splattered all over the place. It is in the plugin files, the commands
> and of course the GUI elements. Concentrating the code in one location
> would allow a much easier change of the GUI Toolkit.

I second that. We need quite some more cohesion in a lot of the
classes and calls.

[Daniel Lucraft]

On 4 Aug 2009, at 12:48, aokai wrote:
> I think switching from GTK is a good idea. Ruby gnome seems not to be
> developed actively any more.

OK thanks. Though I think this is a little unfair to Ruby-GNOME2, it
is under active development with new releases, bug fixes and new
binding features. Still the problems remain.

> I think the most important task here is to find a way to abstract the
> GUI-Toolkit as much as possible. I don't mean we should write an ORM
> or sth. for the GUI-Toolkit but really think about where the GUI
> specific code should be called. At the moment the GTK code is
> splattered all over the place. It is in the plugin files, the commands
> and of course the GUI elements. Concentrating the code in one location
> would allow a much easier change of the GUI Toolkit.

Yes. This can be overdone, but I certainly wish I'd done something
similar for Redcar in the past. FreeBASE has a very clear separation,
we should take another look at how they do it.

> And i would propose jate as a new name, j for Java , ate for (text)
> mate and well jade fits nicely to ruby ;)

Nice name, but I'm going to have to vote no to this. I've been working
on Redcar for 2.5 years and this port is going to be wrenching enough.
(In case you're wondering, I used it to teach myself Ruby...)

Also, Redcar = Red for Ruby + Char for Text, all wrapped up in a Roger
Rabbit reference. :)

thanks,
Dan

[kungfoo]

imho 'recar' has to stay.

[aokai]

With the name was just a stupid idea. I like redcar and actually I
don't really care for the name ;)

I haven't really looked into Ruby/Gnome or how active it has. But as
the moment getting it to work work with ruby1.9 is really hard and
ruby1.9 is out so long and seems at least kinda stable (thanks to the
Japanese government).

We just need to make a convention on where in a plugin we can use
Swing/Toolkit code so we only have one place to look and force people
to write a lot of the code in ruby only.

My Java is actually much better than C/C++ or Vala. I think Java is
the language I know the most of how you should code in it*. So I think
i can help there.

* In Java I have to learn how to write good Java code (patterns,
patterns, patterns**) in ruby writing good code seems natural. ;)

** Don't get me wrong, I love patterns (especially architectural ones)
but in java it is just to much. I don't want to call a factory to
generate a builder, that generates a document that can parse XML ( and
then do a type conversion on every element I get, cause it returns
Nodes even if I search for elements)

[Daniel Lucraft]

On 4 Aug 2009, at 13:45, aokai wrote:
> ruby1.9 is out so long and seems at least kinda stable (thanks to the
> Japanese government).

Really? Explain, please!

DBL

[aokai]

Japanese government is considering ruby as a language for official
projects, but they want a stable release. This seems to be the driving
factor behind ruby 1.9.1 and the to some extend stable api of ruby
1.9. Thats only second hand information. I know some guys that can be
speak and read japanese + follow the ruby mailing list.

[Mark H. Wilkinson]

On Mon, 2009-08-03 at 06:12 -0700, Daniel Lucraft wrote:
> I am considering porting Redcar from Ruby+GTK to JRuby+Swing. This is
> by no means certain, so please comment now if you have any thoughts on
> the matter.

Having mulled it over for most of the day I'm still largely 50:50 on the
idea - I'm not convinced porting to Swing will move things forward more
quickly, but at the same time I'm not deeply attached to Ruby-GNOME2.

My immediate thought is that changing the GUI toolkit may just leave us
in a similar place in a few months time, and not actually move Redcar
forward in terms of being a day-to-day usable editor. I've seen (and
read about) enough projects getting bogged down in architectural
rewrites that are interesting for the developers involved but don't
necessarily deliver much benefit for users. If we are going to change
the toolkit, then we really need to get it over and done with as quickly
as possible (more on this later).

> - continuing difficulties with the Ruby-GNOME2 platform, in
> particular:
>
> * installation problems;

I might be atypical, but I've not run into problems running Redcar on a
standard Ubuntu installation. I've *seen* the problems others have
reported on the mailing list, but I don't get a feeling for whether
that's representative of the majority experience or the minority.

I've been working on packaging Redcar as a .deb file - if we had a
Launchpad PPA with Redcar and up-to-date Ruby-GNOME2 .deb files on it,
would that resolve the installation problems? Or is the real problem
supporting people who install Ruby from source instead of using their
distribution's packages?

> * seemingly random and undiagnosable segfaults;
> * a tendency to segfault when using threads that has led to serious
> compromises in way we use dialogs just so they can be tested;

Again, I might be atypical (or lucky!) but I've been using the stock
Ubuntu Jaunty ruby-gnome2 packages (0.17) and haven't found Redcar to be
noticeably crashy. That said, I appreciate that I've not exactly being
hacking around in the internals of Redcar's GTK interface so I may just
be missing out on all the fun you guys are having avoiding the
Ruby-GNOME2 bugs! ;-)

> * great difficulty in installation on Mac OS X and poor OS X
> integration.

Hmm; is OS X support an important target? Why would an OS X user not
just buy Textmate?

> - Swing native look and feel is good on Gnome and Mac OS X. This is
> quite important to me.

Does this go as far as integrating nicely with the GNOME environment?
For example, using DBus or similar to open new files in an existing
instance of the application, without having to start up a whole new JVM
to send the message through.

I've had mixed experience with Swing's emulation of GNOME/Gtk widgets.
Netbeans seems to struggle with things like true fidelity of font
rendering - it's obvious that Netbeans isn't a native application in my
experience. SWT has provided a closer match for me.

> - We can reuse the JEdit editor widget, which is excellent: it's quick
> and it supports rectangular selections. Since it's written in Java
> we'll have an easier time of hacking it if we need to as well.

That sounds like a positive - I have wondered whether the GNOME editor
widget is up to the task. Would reusing JEdit limit toolkit choice to
Swing? I seem to recall that SWT had developed the capability to host
Swing widgets.

> - The possibility of using any JVM language for scripting Redcar, and
> a more well-known low-level language than Vala for writing performant
> sections. This would be helpful because no one involved in Redcar
> except me knows anything about Vala, and I wouldn't want to ask anyone
> to learn it just for this project.

Agreed - I'm much more familiar with Java (years of experience) than
Vala (none!).

Later in the discussion, aokai and Dan write this:

> > I think the most important task here is to find a way to abstract the
> > GUI-Toolkit as much as possible. I don't mean we should write an ORM
> > or sth. for the GUI-Toolkit but really think about where the GUI
> > specific code should be called. At the moment the GTK code is
> > splattered all over the place. It is in the plugin files, the commands
> > and of course the GUI elements. Concentrating the code in one location
> > would allow a much easier change of the GUI Toolkit.
>
> Yes. This can be overdone, but I certainly wish I'd done something
> similar for Redcar in the past. FreeBASE has a very clear separation,
> we should take another look at how they do it.

The standard design pattern for GUI applications is the MVC model, and
over the last couple of weeks I'd been thinking that starting work on a
'Project' model object would probably be a useful start at building out
the support for projects. Although keeping the data and UI code for a
given part of the UI in one class has a tidy simplicity to it, it soon
starts to get unwieldy as functionality gets added. I think
gtksourceview already has a model/view separation - there are probably
some other model classes that could be extracted to build up the core of
the application. In many ways the Command classes represent the
controllers in an MVC model - we just need to pull the model and view
parts out.

So, my suggestion would be to start by refactoring the code to separate
the existing (ruby-gnome2) UI code from the model classes without
rewriting the UI code. Then, once the architecture of the application is
sorted out it should localise the changes needed to flip from
ruby-gnome2 to Swing (or whatever toolkit is preferred), allowing the
switch to be made with minimal disruption if we decide that's the right
direction.

-Mark.

[aokai]

Well redcar already abstracts most of its widgets generation nicely
and that's really not the point here.

The problem is that we don't have an transparent representation of the
text the user typed in. We use the Widget (EditView) for handling
input for us and then use the Widget as a model. The code that
interacts directly with the widget is all over Redcar (and implemented
like a gazillion times in different ways). We need to find a place for
this code. Well we already had a discussion here (http://
groups.google.com/group/redcar-editor/browse_thread/thread/
85ee2111f3c30336?hl=en) but new input is always welcome ;)

[Daniel Lucraft]

Hi Mark,

thanks for sharing your thoughts

On 4 Aug 2009, at 22:45, Mark H. Wilkinson wrote:
> My immediate thought is that changing the GUI toolkit may just leave
> us
> in a similar place in a few months time, and not actually move Redcar
> forward in terms of being a day-to-day usable editor. I've seen (and
> read about) enough projects getting bogged down in architectural
> rewrites that are interesting for the developers involved but don't
> necessarily deliver much benefit for users.

Don't want that.

> If we are going to change
> the toolkit, then we really need to get it over and done with as
> quickly
> as possible (more on this later).

I agree. I was thinking I would block out a couple of hours a day
until the changeover was complete. A lot of people have expressed
interest in helping as well, so I hope that we could make some
progress quickly.

> I've been working on packaging Redcar as a .deb file - if we had a
> Launchpad PPA with Redcar and up-to-date Ruby-GNOME2 .deb files on it,
> would that resolve the installation problems? Or is the real problem
> supporting people who install Ruby from source instead of using their
> distribution's packages?

The deb would help (and thanks for your work on that), but yes a lot
of problems come from people who have messed up their Ruby install.

> Again, I might be atypical (or lucky!) but I've been using the stock
> Ubuntu Jaunty ruby-gnome2 packages (0.17) and haven't found Redcar
> to be
> noticeably crashy. That said, I appreciate that I've not exactly being
> hacking around in the internals of Redcar's GTK interface so I may
> just
> be missing out on all the fun you guys are having avoiding the
> Ruby-GNOME2 bugs! ;-)

Let me give you an example so you can see where I am coming from.
(You'll be sorry you asked ;-) )

I wanted to get Cucumber running in a second Thread so that it could
test the application. And I coded it up fine but it kept segfaulting
for no apparent reason. I swear I did everything humanly possible to
make it work, but in the end concluded that Ruby-GNOME2 just doesn't
like threads.

The solution has been to drive the Gtk event loop ourselves from Ruby,
the problem is that now we can't test any Gtk code that blocks. For
instance: Dialogs. So Redcar now has to simulate modal dialogs itself
by overriding the Gtk modal dialog runner and suppressing all key and
mouse events that aren't directed at the dialogs. And we can't write
code that waits on the dialog response, it all has to be handled in
code blocks. You can look at the Save command for an example of the
mess that leads to.

Anyway, I spent probably a day's worth of time trying to get the
Threaded option to work and failing in frustration, and I'm not happy
with what we've got now.

Some more examples:
* have you noticed that often when Redcar quits it segfaults? Why is
that? I don't know.
* try calling Open and have it open up in a deep directory, then press
Alt+Up a few times fast. You're lucky if it doesn't segfault.
* how do you create a click event on a button for testing? it seems to
be impossible.

> Hmm; is OS X support an important target?

Well, it is for me ;) I got a Mac for work recently. Songkick
developers are now 100% Mac based. I have always intended Redcar to
work on OS X eventually, but this has forced my hand and then nailed
it to the desk.

> Does this go as far as integrating nicely with the GNOME environment?
> For example, using DBus or similar to open new files in an existing
> instance of the application, without having to start up a whole new
> JVM
> to send the message through.

There is a Java DBus implementation. But I'd be interested to see how
other Java apps handle it.... presumably there is some way.

> I've had mixed experience with Swing's emulation of GNOME/Gtk widgets.
> Netbeans seems to struggle with things like true fidelity of font
> rendering - it's obvious that Netbeans isn't a native application in
> my
> experience. SWT has provided a closer match for me.

Is Eclipse an example of this? It seems to look the same everywhere.
We had a discussion of font rendering on IRC yesterday. Here is a
comparison of Gedit and Jedit: http://danlucraft.com/jedit-gedit.png
The fonts are a bit off in Jedit but it's not something I would care
about much. Do you feel this would spoil Redcar for linux a lot?

> That sounds like a positive - I have wondered whether the GNOME editor
> widget is up to the task. Would reusing JEdit limit toolkit choice to
> Swing? I seem to recall that SWT had developed the capability to host
> Swing widgets.

Yes, but we'd still have the bad font rendering wherever we put the
JEdit widget.

> Agreed - I'm much more familiar with Java (years of experience) than
> Vala (none!).

It would be nice to have other people to help out with the
highlighting stuff. :)

> So, my suggestion would be to start by refactoring the code to
> separate
> the existing (ruby-gnome2) UI code from the model classes without
> rewriting the UI code.

That seems like the right way to do it. Dvyjones is having a stab at
some of the core modules right now, as I understand it. (He needs
something to do on his holiday.)

My feelings on Redcar right now are that I want to have a solid,
simple editor that I can use and be proud of. Ruby-GNOME2 seems too
flaky to ever get there, and even if I can get it working on OS X I'm
not sure that I'll want to use it there. I am quite pissed that after
so much work there is yet more work staring me in the face, but it
will be interesting to do, and I do not want to give up until I am
happy that I have made something useful.

Thanks

[kungfoo]

> > I've had mixed experience with Swing's emulation of GNOME/Gtk widgets.
> > Netbeans seems to struggle with things like true fidelity of font
> > rendering - it's obvious that Netbeans isn't a native application in
> > my
> > experience. SWT has provided a closer match for me.
>
> Is Eclipse an example of this? It seems to look the same everywhere.
> We had a discussion of font rendering on IRC yesterday. Here is a
> comparison of Gedit and Jedit: http://danlucraft.com/jedit-gedit.png
> The fonts are a bit off in Jedit but it's not something I would care
> about much. Do you feel this would spoil Redcar for linux a lot?

The font rendering of SWT is really good (with the right fonts, but we
could provide opensource fonts with redcar). I tend to think that the
LookAndFeel is not that important for a good, programmable text editor
(does TextMate have a lot of GUI?)
Also there is a pluggable GTKLookAndFeel for Swing.
Looks like this:
http://www.semanticmetadata.net/wp-content/uploads/2007/06/netbeans-gtk.png

This is Netbeans, which has a complicated GUI. The editor should not
need more than popup menus for choices and such and the Application
menus.

I'd say functionality/extensibility and font rendering trumps a system-
like LookAndFeel.

>
> > That sounds like a positive - I have wondered whether the GNOME editor
> > widget is up to the task. Would reusing JEdit limit toolkit choice to
> > Swing? I seem to recall that SWT had developed the capability to host
> > Swing widgets.

Yeah, but having just the menus in SWT and the editor in Swing is
probably not optimal (Think about context menus, they would look
different in different areas...).

[Tonio]

Hi,

>Here is a comparison of Gedit and Jedit: http://danlucraft.com/jedit-gedit.png
>The fonts are a bit off in Jedit but it's not something I would care about much.

I can't help you with coding (ruby or java), ut from a user point of
view, I do care about integration, and especially font.
I don't use jedit partially for that reason & I won't use redcar with
such a difference (but I'm perhaps the only one here :) ).

My 2 cents...

Tonio

[Tom Murray]

+1 For using SWT. While I agree with the comment that Eclipse doesn't feel complete native, it also doesn't feel like it comes from another planet, like the Swing interface (and that being a massive planet, with higher gravity sloooooowing everything to a crawl). Speaking of Scala, I've been doing some Scala + SWT and it has worked seamlessly.

+1 Also for being Mac friendly. TextMate is very nice but very dependent on one very smart guy in Denmark, and I for one would very much like source access for writing plug-ins, etc. (the flexibility of bundles certainly gets one a long way, but....). And I believe the latest SWT has a full Cocoa implementation so it's super native for Macs.

Cheers,

tm

[aokai]

We should really decide on somethings.

We should decide if we want to use the JVM as a platform

We should decide which language we want to use for low level
programming. We could use more than one, but this would really not
make any sense ;)
We could use either Scala or Java I guess. Both seem reasonably fast.
Java plus that a lot of people know it really well, it is easy to use
Java classes from other JVM languages, but Java code is bloated and
just doesn't look that nice. Scala is really the better (easier)
language, cons are that a lot of people don't know Scala (I don't,
tried it some month ago + yesterday) and while it does compile down
to byte code, I don't know if it as usable from jRuby as Java.

We should decide which GUI-Toolkit we want to use. SWT and Swing are
the options. Swing offers more components (SWT does too, but a lot of
them seem to rely on eclipse or parts of it). SWT has more of a native
look. Using SWT and Swing are really similar in code style and I don't
seem much of a difference there.

This would basically give people enough to start working on some
things (like the porting GTKMAteView)

[Daniel Lucraft]

We've been doing some exploratory work.

Redcar needs an Oniguruma compatible regex library. There is a Java
port for JRuby called Joni, and we're benchmarking it now to determine
if it's going to be fast enough. (GtkMateView makes serious use of
regular expressions for highlighting.). It's looking good.

Silvio has been showing me how to do that, and has also

__________________________
Daniel Lucraft

twitter.com/danlucraft
danlucraft.com/blog

[Daniel Lucraft]

Sorry, sent that before it was ready.

We still need to compare the regex against our Vala library that we
currently use.

And we've been looking more closely at SWT. Silvio has got rect.
selections working in a beta of the next SWT release, and of course
the font rendering is much better for SWT.

So we're progressing, but there's still a few things to check first.

DBL

__________________________
Daniel Lucraft

twitter.com/danlucraft
danlucraft.com/blog

[Henrik Hodne]

I'll be back from Sweden om Monday, and I will continue making Redcar
GUI-toolkit agnostic then. My digestion is to make Redcar run on both
JRuby and YARV, and then people that somehow doesn't want/can't use
JRuby can use YARV with Ruby-GNOME (or QtRuby, or Tk (or something
completely else)). Then we can focus on JRuby/SWT and then GTK/Qt/
whatever can be provided as plugins.

[Tom Murray]

I'm not a big fan of Java the language, but I've become a big fan of Java the platform, which has come to support of variety of languages much more pleasant IMO to work with than Java.

That said, I think choosing a really nice language like Scala or Clojure is probably infeasible at this time for a project that actually wants lots of people to contribute -- I'll be bold and say Redcar is one of those :-). So that leaves vanilla Java or another popular language that has been ported to the Java platform, like jRuby or Jython. Since Redcar has some history with Ruby, I would guess much of the user base would prefer jRuby to working in Java, and my impression is that there might be a speed benefit over regular Ruby!

But the exciting thing for me about using any language on the Java platform is that plug-ins, DSLs, etc. can pretty much be written in any of the other platform languages.

tm

[Daniel Lucraft]

Henrik tossed me a link for SWT testing today: http://wiki.eclipse.org/SWTBot/

This question is in the FAQ:

-----
# Why do tests run on a non-UI thread?

A lot of events that SWTBot sends to the UI are blocking. SWT dialogs
are one of them. This means that functions opening dialogs, will block
until the dialog closes. Since we do not want tests to block when a
dialog open up, SWTBot runs in a non-UI thread, and posts events to
the UI thread.
There are two solutions to this:
• Make the dialog non-modal, by invoking Dialog#setBlockOnOpen(false)
• Open the dialog in a non-ui thread
SWTBot chooses the later approach, since the first approach is not
always practical.
-----

Sound familiar? Earlier in the thread I talked about having exactly
this problem with Ruby-GNOME2. I'm very happy that it's possible to do
better in SWT.

Also, check out the automation API:

bot.tree().select("Java Project");
bot.button("Next >").click();
bot.textWithLabel("Project name:").setText("MyFirstProject");
bot.button("Finish").click();
Nice or what!

best,
DBL

[kungfoo]

I alreasy stumbled accross that one before. But when you said, you
wanted to stick to cucumber i figured, it's not going to be that
important.
Anyway, yes I too think it's pretty cool.
One of the nce things is component localization, which is not exact,
so if the Button "finish >" changes it's name to "finish" it'll still
work, as far as I've seen.
It's also pretty low ceremony, which is great.

From jRuby this would look about as follows:

bot.tree.select("Java Project")
bot.button("Next").click
bot.textWithLabel("Project name").text = "MyFirstProject"
bot.button.("Finish").click

Maybe this can be made even more consise by throwing some more ruby at
it.
I will ponder this and try to check it out.

[Henrik Hodne]

I think it would be easy to make some sort of Cucumber tasks for this.
As Silvio pointed out, it is callable from JRuby. Maybe we should make
"sweetcumber"?

[Daniel Lucraft]

Good name.

[rogerdpack]

> I am considering porting Redcar from Ruby+GTK to JRuby+Swing. This is
> by no means certain, so please comment now if you have any thoughts on
> the matter.

Sounds reasonable. My suggestion would be jruby, or perhaps wxruby.
Except I've never used them so don't count my opinion for much :)
-r