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
> ### 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
--
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
Really? Explain, please!
DBL
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.
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
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