Hi all,
I’m trying to develop a desktop application, and since I’ve done a fair
bit of work with RoR before, I figured ruby is a good way to go about
it. My application will be largely database driven.
I’m looking for a sample desktop application which I can learn a few
things from. Obviously the less restrictive the license the better, and
it’d also be good if I can find one which is database driven. Google
seems to provide very little… or at least, the results are cluttered by
RoR things. I was wondering if anyone in the group knows of any.
Nathan
Hi Nathan
Nathan Macinnes wrote:
I’m trying to develop a desktop application, and since I’ve done a fair
bit of work with RoR before, I figured ruby is a good way to go about
it. My application will be largely database driven.
I’m looking for a sample desktop application which I can learn a few
things from. Obviously the less restrictive the license the better, and
it’d also be good if I can find one which is database driven. Google
seems to provide very little… or at least, the results are cluttered by
RoR things. I was wondering if anyone in the group knows of any.
There’s a list of some wxRuby applications on the wiki:
http://wxruby.rubyforge.org/wiki/wiki.pl?OnlineCodeExamples
Of those, Weft QDA is a database (SQLite) backed application, and has a
public domain licence.
http://rubyforge.org/projects/weft-qda/
It uses its own ActiveRecord-like persistence layer, with an Observer
pattern to update the relevant GUI elements as changes to the database
are saved. I’d recommend you look at the code in Subversion as its a
better model for designing database apps.
A disadvantage for study purposes is that its a relatively complex app -
15k lines of ruby code, with a schema running to several hundred
lines using triggers and views:
http://weft-qda.rubyforge.org/svn/trunk/weft-qda/share/schema.sql
A simpler example to look at might be Ruby SQLite GUI, which is a
desktop browser for SQLite databases:
http://rsqlitegui.rubyforge.org/
It uses Ruby-GTK2, rather than wxRuby. GTK2 is another good GUI library,
long established and with a wide range of widgets. However IMHO it works
considerably less well on Windows and OS X than it does on Linux,
whereas wxRuby is equally good on all three.
hth
alex
Just be sure to organize your code from the beginning. It’s too easy to
write spaghetti code in a scripting language. Stick with your MVC
roots.
It’s useful with any kind of application development, not just the web.
But also, don’t try to mimic rails, there’s a lot of ways to implement
MVC,
not just the way rails does.
-jk
Nathan Macinnes wrote:
John, thanks for the heads-up. I do plan on sticking to MVC as much as
possible… I’m not quite sure what that looks like yet though.
I think John’s advice was sound. I’ve never sat down and read a book
about MVC and I’m not a professionaly programmer, though in a previous
life I did a lot of web programming in Perl. But I can say what enabled
Weft QDA to go from a specialised and limited program to something to
which its now quite extensible - I mean, that I can add quite radical
new features to without breaking lots of stuff. It probably roughly fits
an MVC model…
M: your non-GUI classes stand alone and can be unit-tested. So you know
that the objects you’re going to display (in Weft, Documents,
Categories, Text Fragments, etc) can be created, changed, saved and
restored without problems. This means you don’t waste time clicking
round in a GUI to fix issues with databases or how they translate to
ruby classes.
V: Your GUI code is strictly separate - in Weft, it’s all in a wxgui
directory. All the GUI code deals with layout (whether that’s through
XRC, some kind of sugary syntax, or bog-standard wxRuby code - Weft uses
all three) and event handling. The sort of logic that deals with saving
non-GUI objects, and updating related objects should be outside the GUI
code. So you say:
def on_click_ok
document.title = gui_text_box.value
document.save
rescue BadDocumentTitleError
display_gui_error_message “The title was invalid”
end
The validation, and the mechanics of how the object is saved are hidden
from the GUI code. It just has to know how to deal with errors.
The biggest jump for Weft was separating the GUI code that made changes
to objects, from the GUI code that updates the state of objects.
Otherwise every place that changes a database object has to know about
every place that that object might be displayed. This quickly becomes
impossible, and you get endless problems with stale/inconsistent object
data being presented to the user.
One way of tackling this is to use Observer: when an object is saved,
all interested GUI representations are informed and deal with the new
state of the object (eg a new title) accordingly. Another is using
wxRuby’s UpdateUIEvent - this is handy when, for example, you want menu
items to be enabled or disabled based on a criterion, but don’t want to
have to keep track of that every time it changes, just when the relevant
menu item is displayed.
So, if you want a “Save” menu item that is only active when there are
unsaved changes in a model object called document, you can do something
like
evt_update_ui(Wx::ID_SAVE) { | e | e.enable(true) if
document.has_unsaved_changes }
hth
alex
Thanks for the help guys. Weft looks like a good option for me to use…
and because it’s public domain, I can even use the code without any
worries.
The Ruby SQLite GUI is a bit easier for me to get my head around, but at
the same time, the code isn’t as well organised… I suppose for a
smaller project it doesn’t matter so much. And you’re right about the
Ruby-GTK2 point… I’d already decided I want to use wxWidgets because I
use Linux but most of my target audience use Windows… and it wouldn’t
hurt to make it work for Macs too.
John, thanks for the heads-up. I do plan on sticking to MVC as much as
possible… I’m not quite sure what that looks like yet though.