[ANN] wxRubyTemplate

Desktop wxRuby
1

Hey folks,

You may be interested in a project I’ve published on Github,
wxRubyTemplate.

See the blog post and visit the project on Github.

http://daniel.zepeda.ws/blog/2009/04/18/announcement-wxrubytemplate/

Introduction

The aim of the wxRubyTemplate is to provide a starting structure within
which to program your wxRuby project. The template provides a directory
structure, a set of Rakefiles to manage, and most importantly, to
package your Ruby application for distribution as a standalone program
when completed. It also includes an environment to get the application
running and provide basic services to the program code. For now, the
template only supports packaging for Mac OSX and Windows, although
various flavors of Linux should be easily accommodated and are planned
for the future.

Let me know what you think.

DZ

2

Hi Daniel

Daniel Zepeda wrote:

which to program your wxRuby project. The template provides a directory
structure, a set of Rakefiles to manage, and most importantly, to
package your Ruby application for distribution as a standalone program
when completed.

Thanks - this is a positive development. I’d recommend it to anyone
considering a semi-serious app as a model of how to organise a GUI
project.

A couple of things that I needed to get going:

  • rspec should be in the list of requirements
  • the rakefile can detect which ruby is running it more portably (patch
    attached)
  • The copying of executables for installation isn’t fully working -
    app_ruby_executable in tasks/package_lib.rake is probably better
    something like “Environment.app_name + Config::CONFIG[‘EXEEXT’]” but
    I couldn’t quite figure it out.

More generally it seems there’s two distinct tasks here: setting up a
model project, and later packaging. Some nice ruby DSL that hid the
details of the .nsi installer file would be great. NSIS has roughly 6
million options and generally you want about four (what extra files to
include, what version/app name/branding, what shortcuts to create).

Please keep us posted.

alex

3

Alex F. wrote:

Hi Daniel

Daniel Zepeda wrote:

which to program your wxRuby project. The template provides a directory
structure, a set of Rakefiles to manage, and most importantly, to
package your Ruby application for distribution as a standalone program
when completed.

Thanks - this is a positive development. I’d recommend it to anyone
considering a semi-serious app as a model of how to organise a GUI
project.

A couple of things that I needed to get going:

  • rspec should be in the list of requirements

Ah yes, thanks. Fixed in the documentation.

  • the rakefile can detect which ruby is running it more portably (patch
    attached)

I read this through the Ruby Forum’s web interface, I don’t get the
emails, so I didn’t see the attached patch. Should I change my
preferences or something?

  • The copying of executables for installation isn’t fully working -
    app_ruby_executable in tasks/package_lib.rake is probably better
    something like “Environment.app_name + Config::CONFIG[‘EXEEXT’]” but
    I couldn’t quite figure it out.

By ‘not fully working’ do you mean you weren’t able to get a working
package on Windows? I verified it on my copy of Windows XP, so maybe
you are using a different kind of Windows?

Really all that does is rename the ruby executable to a name associated
with the packaged program. I’m not sure that it is really necessary.

Yes, Config::CONFIG[‘EXEEXT’] would be more portable I suppose, but that
code only executes for mswin, so I figured .exe was safe enough.

More generally it seems there’s two distinct tasks here: setting up a
model project, and later packaging.

Agreed. The rub is that for the packaging to work right, everything must
be required in a specific way, thus packaging successfully is dependent
on the project structure, so they really go hand-in-hand.

What I was thinking of was a ripped-off idea from rails, have a script
that generates the structure and scripts initially, going the
‘convention-over-configuration’ route as much as possible. The
pre-defined structure also makes it easier to get off-and-running on a
new project.

Some nice ruby DSL that hid the
details of the .nsi installer file would be great. NSIS has roughly 6
million options and generally you want about four (what extra files to
include, what version/app name/branding, what shortcuts to create).

Ah yes, that is a great idea. I was pondering how to handle the grubby
details of NSIS.

Please keep us posted.

Will do.

DZ

alex

4

Daniel Zepeda wrote:

Alex F. wrote:

  • the rakefile can detect which ruby is running it more portably (patch
    attached)

I read this through the Ruby Forum’s web interface, I don’t get the
emails, so I didn’t see the attached patch. Should I change my
preferences or something?

Strange, the reply has also disappeared completely from our own
archives:
http://rubyforge.org/pipermail/wxruby-users/2009-April/thread.html

Patch copied inline below.

By ‘not fully working’ do you mean you weren’t able to get a working
package on Windows? I verified it on my copy of Windows XP, so maybe
you are using a different kind of Windows?

It was on OS X. The methods app_ruby_executable and ruby_executable test
RUBY_PLATFORM for “i686-darwin9”, but for my standard ruby
(/usr/bin/ruby) the platform is “universal-darwin9” so the case
statement falls through and raises. That’s why I tried

def ruby_executable_name
Config::CONFIG[‘RUBY_INSTALL_NAME’] + Config::CONFIG[‘EXEEXT’]
end

def app_ruby_executable_name
Environment.app_name + Config::CONFIG[‘EXEEXT’]
end

But that’s not quite all that’s needed, because build/bin/ruby hasn’t
been copied.

Really all that does is rename the ruby executable to a name associated
with the packaged program. I’m not sure that it is really necessary.

It’s just a little bit of polish. It affects how the app is labelled in
the Dock (OSX) and in Alt-Tab, Task Manager (Windows), otherwise it
shows as ‘ruby’.

What I was thinking of was a ripped-off idea from rails, have a script
that generates the structure and scripts initially, going the
‘convention-over-configuration’ route as much as possible. The
pre-defined structure also makes it easier to get off-and-running on a
new project.

Yep, I’ve only tried rails once a while ago, but I liked the ‘scaffold’
feature.

best
alex

diff --git a/Rakefile b/Rakefile
index 7750810…4689030 100644
— a/Rakefile
+++ b/Rakefile
@@ -15,7 +15,9 @@ end
desc “Run Project”
task :run => Environment.base_class_path do
ENV[Environment.app_env_const] = ‘development’

  • executable = RUBY_PLATFORM =~ /darwin/ ? “/opt/local/bin/ruby” :
    “c:/ruby-1.8.7-p72/bin/ruby.exe”
  • executable = File.join( Config::CONFIG[‘bindir’],
  •                      Config::CONFIG['RUBY_INSTALL_NAME'] +

  •                      Config::CONFIG['EXEEXT'] )
    exec(“#{executable} #{Environment.app_file}”)
    end

@@ -40,4 +42,4 @@ def make_bases_relative
end
end

-task :default => :spec
\ No newline at end of file
+task :default => :spec

5

Alex F. wrote:

Daniel Zepeda wrote:

Alex F. wrote:

Patch copied inline below.

Thanks!

By ‘not fully working’ do you mean you weren’t able to get a working
package on Windows? I verified it on my copy of Windows XP, so maybe
you are using a different kind of Windows?

It was on OS X. The methods app_ruby_executable and ruby_executable test
RUBY_PLATFORM for “i686-darwin9”, but for my standard ruby
(/usr/bin/ruby) the platform is “universal-darwin9” so the case
statement falls through and raises.

Ah, I get it now. I was wondering if specifying it so thoroughly would
cause a problem, and apparently it does. Probably just shortening the
test of ruby platform to /darwin/ would fix that, and shortening the
directory names and other things that depend on RUBY_PLATFORM.

That’s why I tried

def ruby_executable_name
Config::CONFIG[‘RUBY_INSTALL_NAME’] + Config::CONFIG[‘EXEEXT’]
end

def app_ruby_executable_name
Environment.app_name + Config::CONFIG[‘EXEEXT’]
end

But that’s not quite all that’s needed, because build/bin/ruby hasn’t
been copied.

Yeah, again, I think just cutting down the specification of
RUBY_PLATFORM should take care of it. It really shouldn’t matter, I’m
just checking if it’s mswin or OSX, I don’t think it should matter if it
is 386/686 etc.

Thanks for the patch.

DZ