[ANN] QtRuby 1.4.7

URIS

    http://rubyforge.org/projects/korundum/
    http://developer.kde.org/language-bindings/ruby/index.html

NAME

   QtRuby 1.4.7

SYNOPSIS

   Ruby bindings for the Qt4 GUI apis. Many fixes and
   improvements. QtDBus now works.

DESCRIPTION

   Highlights from the QtRuby ChangeLog since release 1.4.7:

* Support for Qt 4.2 final

* The Qt4 version of QtRuby can be installed at the same time as
   the Qt3 version.
   * Use:
       - require 'Qt3'
       - require 'Qt4'
       - require 'Qt'
     The last option will default to Qt4 QtRuby.
   * The command line api introspection tool can be used to query
      both Qt3 and Qt4 apis:
       - rbqt3api
       - rbqt4api
       - rbqtapi
     Again the last option will default to the Qt4 api for QtRuby
   * The 'rbuic' tool has been renamed 'rbuic4' to avoid a clash with
      the Qt3 one.
   * The Qt3 and Qt4 versions of the Smoke library have different
      versions and can be installed in the same directory

* Added the rbrcc Ruby resource compiler tool

* Optional support for the QtDbus classes, and Qt QDBus examples
   ported to ruby

* Optional support for the Qwt plotting library

* Blocks can be used as targets for connect calls as well as ordinary
slots:

  * Added a new variant of connect, which takes a SIGNAL as an
          argument, along with a block. For example:

          quit.connect(SIGNAL(:clicked)) { puts 'quit pressed' }

    The block is called in the context of where the connect call was
          made, and 'self' needn't be a Qt::Object. It is similar to
the
          signal_connect() method in ruby-gnome. This was suggested by
          rickdangerous on the #qtruby irc channel.

  * Here is an example of the class method connect() call with a block
          as a target:

          app = Qt::Application.new(ARGV)
          quit = Qt::PushButton.new('Quit')
          Qt::Object.connect(quit, SIGNAL('clicked()'), app) do
              puts 'quit clicked'
          end

    The block is executed in the context of the target instance,
          'app' in this case.

  * And the instance method form:

          class MyButton < Qt::Button
               def initialize(text)
                    super(text)
                    connect(self, SIGNAL(:clicked)) do
                         puts 'button clicked'
                    end
               end
               ...

    The block is executed in the context of self - the instance making
          the connect() call.

CONFIG

   See the qtruby/INSTALL file for details of configuration, building
   and installation.

BUILDING ON WINDOWS

   * The smoke library can be built on windows by manually editing
      qtguess.pl.in and generate.pl.in (automake doesn't work with
      qtruby on Windows). Run 'perl qtguess.pl' to for the configure
      tests. Then run 'perl generate.pl' to generate the Smoke sources,
      and build with qmake. Use extconf.rb and qmake to build the
      qtruby extension and rbuic tool.

ENVIRONMENTS

   Linux, BSD*, Unix etc
   Mac OS X, Windows

AUTHORS

  Richard Dale with Caleb Tennis, Alexander Kellett and others.
  Special thanks to kelko and rickdangerous for suggesting how
  to implment 'blocks as slots' for this release.

Awesome!! Questions:

1. Does all this magic work on Windows?
2. Is it packaged as a gem?
3. Is Caleb going to update his excellent tutorial on QT Ruby?

···

richard.j.dale@gmail.com wrote:

URIS

    http://rubyforge.org/projects/korundum/
    http://developer.kde.org/language-bindings/ruby/index.html

NAME

   QtRuby 1.4.7

SYNOPSIS

   Ruby bindings for the Qt4 GUI apis. Many fixes and
   improvements. QtDBus now works.

DESCRIPTION

   Highlights from the QtRuby ChangeLog since release 1.4.7:

* Support for Qt 4.2 final

* The Qt4 version of QtRuby can be installed at the same time as
   the Qt3 version.
   * Use:
       - require 'Qt3'
       - require 'Qt4'
       - require 'Qt'
     The last option will default to Qt4 QtRuby.
   * The command line api introspection tool can be used to query
      both Qt3 and Qt4 apis:
       - rbqt3api
       - rbqt4api
       - rbqtapi
     Again the last option will default to the Qt4 api for QtRuby
   * The 'rbuic' tool has been renamed 'rbuic4' to avoid a clash with
      the Qt3 one.
   * The Qt3 and Qt4 versions of the Smoke library have different
      versions and can be installed in the same directory

* Added the rbrcc Ruby resource compiler tool

* Optional support for the QtDbus classes, and Qt QDBus examples
   ported to ruby

* Optional support for the Qwt plotting library

* Blocks can be used as targets for connect calls as well as ordinary
slots:

  * Added a new variant of connect, which takes a SIGNAL as an
          argument, along with a block. For example:

          quit.connect(SIGNAL(:clicked)) { puts 'quit pressed' }

    The block is called in the context of where the connect call was
          made, and 'self' needn't be a Qt::Object. It is similar to
the
          signal_connect() method in ruby-gnome. This was suggested by
          rickdangerous on the #qtruby irc channel.

  * Here is an example of the class method connect() call with a block
          as a target:

          app = Qt::Application.new(ARGV)
          quit = Qt::PushButton.new('Quit')
          Qt::Object.connect(quit, SIGNAL('clicked()'), app) do
              puts 'quit clicked'
          end

    The block is executed in the context of the target instance,
          'app' in this case.

  * And the instance method form:

          class MyButton < Qt::Button
               def initialize(text)
                    super(text)
                    connect(self, SIGNAL(:clicked)) do
                         puts 'button clicked'
                    end
               end
               ...

    The block is executed in the context of self - the instance making
          the connect() call.

CONFIG

   See the qtruby/INSTALL file for details of configuration, building
   and installation.

BUILDING ON WINDOWS

   * The smoke library can be built on windows by manually editing
      qtguess.pl.in and generate.pl.in (automake doesn't work with
      qtruby on Windows). Run 'perl qtguess.pl' to for the configure
      tests. Then run 'perl generate.pl' to generate the Smoke sources,
      and build with qmake. Use extconf.rb and qmake to build the
      qtruby extension and rbuic tool.

ENVIRONMENTS

   Linux, BSD*, Unix etc
   Mac OS X, Windows

AUTHORS

  Richard Dale with Caleb Tennis, Alexander Kellett and others.
  Special thanks to kelko and rickdangerous for suggesting how
  to implment 'blocks as slots' for this release.

Quoting "richard.j.dale@gmail.com" <richard.j.dale@gmail.com>:

Awesome!

···

URIS

    http://rubyforge.org/projects/korundum/
    http://developer.kde.org/language-bindings/ruby/index.html

NAME

   QtRuby 1.4.7

SYNOPSIS

   Ruby bindings for the Qt4 GUI apis. Many fixes and
   improvements. QtDBus now works.

DESCRIPTION

   Highlights from the QtRuby ChangeLog since release 1.4.7:

* Support for Qt 4.2 final

* The Qt4 version of QtRuby can be installed at the same time as
   the Qt3 version.
   * Use:
       - require 'Qt3'
       - require 'Qt4'
       - require 'Qt'
     The last option will default to Qt4 QtRuby.
   * The command line api introspection tool can be used to query
      both Qt3 and Qt4 apis:
       - rbqt3api
       - rbqt4api
       - rbqtapi
     Again the last option will default to the Qt4 api for QtRuby
   * The 'rbuic' tool has been renamed 'rbuic4' to avoid a clash with
      the Qt3 one.
   * The Qt3 and Qt4 versions of the Smoke library have different
      versions and can be installed in the same directory

* Added the rbrcc Ruby resource compiler tool

* Optional support for the QtDbus classes, and Qt QDBus examples
   ported to ruby

* Optional support for the Qwt plotting library

* Blocks can be used as targets for connect calls as well as ordinary
slots:

  * Added a new variant of connect, which takes a SIGNAL as an
          argument, along with a block. For example:

          quit.connect(SIGNAL(:clicked)) { puts 'quit pressed' }

    The block is called in the context of where the connect call was
          made, and 'self' needn't be a Qt::Object. It is similar to
the
          signal_connect() method in ruby-gnome. This was suggested by
          rickdangerous on the #qtruby irc channel.

  * Here is an example of the class method connect() call with a block
          as a target:

          app = Qt::Application.new(ARGV)
          quit = Qt::PushButton.new('Quit')
          Qt::Object.connect(quit, SIGNAL('clicked()'), app) do
              puts 'quit clicked'
          end

    The block is executed in the context of the target instance,
          'app' in this case.

  * And the instance method form:

          class MyButton < Qt::Button
               def initialize(text)
                    super(text)
                    connect(self, SIGNAL(:clicked)) do
                         puts 'button clicked'
                    end
               end
               ...

    The block is executed in the context of self - the instance making
          the connect() call.

CONFIG

   See the qtruby/INSTALL file for details of configuration, building
   and installation.

BUILDING ON WINDOWS

   * The smoke library can be built on windows by manually editing
      qtguess.pl.in and generate.pl.in (automake doesn't work with
      qtruby on Windows). Run 'perl qtguess.pl' to for the configure
      tests. Then run 'perl generate.pl' to generate the Smoke sources,
      and build with qmake. Use extconf.rb and qmake to build the
      qtruby extension and rbuic tool.

ENVIRONMENTS

   Linux, BSD*, Unix etc
   Mac OS X, Windows

AUTHORS

  Richard Dale with Caleb Tennis, Alexander Kellett and others.
  Special thanks to kelko and rickdangerous for suggesting how
  to implment 'blocks as slots' for this release.

Great, that's exactly what was missing from 1.4.6 !! I'll make a new
upload as soon as the previous one is in the Debian archive (shoudln't
take too long, hopefully...)

  Cheers !

  Vince

···

richard.j.dale@gmail.com wrote:

URIS

    http://rubyforge.org/projects/korundum/
    http://developer.kde.org/language-bindings/ruby/index.html

NAME

   QtRuby 1.4.7
* Blocks can be used as targets for connect calls as well as ordinary
slots:

BUILDING ON WINDOWS

   * The smoke library can be built on windows by manually editing
      qtguess.pl.in and generate.pl.in (automake doesn't work with
      qtruby on Windows). Run 'perl qtguess.pl' to for the configure
      tests. Then run 'perl generate.pl' to generate the Smoke sources,
      and build with qmake. Use extconf.rb and qmake to build the
      qtruby extension and rbuic tool.

The qtruby tarball I downloaded does not seem to have any of the aforementioned perl files. My qt4 install is MSVC-2005. I just want qt bindings, not KDE.

The INSTALL files don't seem to even mention win32.

What am I missing?

~S

M. Edward (Ed) Borasky wrote:

Awesome!! Questions:

1. Does all this magic work on Windows?
2. Is it packaged as a gem?

Seconded, mswin32 gem or bust. I'm not particularly in the mood for
polluting my machine with things related to compiling C, I sure as hell
don't have the presence of mind to keep results thereof between the
inevitable full reinstalls, and that it's overall a Good Thing for use
outside personal code I don't need to remember.

Please, give me a reason to quit Python for GUI work, clashing naming
conventions of DOOM keep making me want to scream at someone on that
side of the ballpark.

*idly daydreams of mswin64 Ruby and native gems*

David Vallner

Vincent Fourmond wrote:

···

richard.j.dale@gmail.com wrote:
> URIS
>
> http://rubyforge.org/projects/korundum/
> http://developer.kde.org/language-bindings/ruby/index.html
>
> NAME
>
> QtRuby 1.4.7
> * Blocks can be used as targets for connect calls as well as ordinary
> slots:

  Great, that's exactly what was missing from 1.4.6 !! I'll make a new
upload as soon as the previous one is in the Debian archive (shoudln't
take too long, hopefully...)

  Cheers !

  Vince

I forgot to include your Debian patch in the release. I hope to rectify
that and do another release in 2-3 weeks along with a rbqdbusxml2rb
tool and more fixes for QtDBus, and more work on fixing the examples.

-- Richard

3. Is Caleb going to update his excellent tutorial on QT Ruby?

I am, but I'm in the final stages of another book project at the moment so I've put it off until that one is complete. Luckily, if you're familiar with the Qt3 version, jumping into the Qt4 version isn't too big of a stretch.

Thanks,
Caleb

M. Edward (Ed) Borasky wrote:

1. Does all this magic work on Windows?

Yes, once you get it built - I'm not sure whether QtDBus works on
Windows yet but everything else should. Look at the help forum posts on
the Korundum site for info about building on Windows.

2. Is it packaged as a gem?

No, it really needs to be. I haven't personally good easy access to a
Windows machine for development, and I'm not particularly familiar with
the development environment either. Sooner or later I hope there will
be a binary gem for Windows..

Shea Martin wrote:

>
> BUILDING ON WINDOWS
>
> * The smoke library can be built on windows by manually editing
> qtguess.pl.in and generate.pl.in (automake doesn't work with
> qtruby on Windows). Run 'perl qtguess.pl' to for the configure
> tests. Then run 'perl generate.pl' to generate the Smoke sources,
> and build with qmake. Use extconf.rb and qmake to build the
> qtruby extension and rbuic tool.
>

The qtruby tarball I downloaded does not seem to have any of the
aforementioned perl files. My qt4 install is MSVC-2005. I just want qt
bindings, not KDE.

The INSTALL files don't seem to even mention win32.

What am I missing?

mardigras rdale 165% find . -name qtguess.pl.in -print
./smoke/qt/qtguess.pl.in
mardigras rdale 166% find . -name generate.pl.in -print
./smoke/qt/generate.pl.in

You're right about the INSTALL not mentioning Windows though, that is
certainly an important omission and I'll fix it for the next release.
You need to change the '@thing@' variables in the perl scripts to be
what the configure should have set them to. Edit qtguess.pl.in and save
as qtguess.pl, and then edit generate.pl.in and save as generate.pl.

David Vallner wrote:

M. Edward (Ed) Borasky wrote:

Awesome!! Questions:

1. Does all this magic work on Windows?
2. Is it packaged as a gem?

Seconded, mswin32 gem or bust. I'm not particularly in the mood for
polluting my machine with things related to compiling C, I sure as hell
don't have the presence of mind to keep results thereof between the
inevitable full reinstalls, and that it's overall a Good Thing for use
outside personal code I don't need to remember.

I will second that. I would love to use ruby and qt together. But my apps are multi-platform, and I can't assume that people who use windows will already have Qt installed. If there was a simple way to get the minimum amount of Qt binaries installed for them, then I would do it for them.

~S

mardigras rdale 165% find . -name qtguess.pl.in -print
./smoke/qt/qtguess.pl.in
mardigras rdale 166% find . -name generate.pl.in -print
./smoke/qt/generate.pl.in

You're right about the INSTALL not mentioning Windows though, that is
certainly an important omission and I'll fix it for the next release.
You need to change the '@thing@' variables in the perl scripts to be
what the configure should have set them to. Edit qtguess.pl.in and save
as qtguess.pl, and then edit generate.pl.in and save as generate.pl.

Sorry to be so stupid, but then what? Do I run them individually?
~S

Shea Martin wrote:

David Vallner wrote:

M. Edward (Ed) Borasky wrote:

Awesome!! Questions:

1. Does all this magic work on Windows?
2. Is it packaged as a gem?

Seconded, mswin32 gem or bust. I'm not particularly in the mood for
polluting my machine with things related to compiling C, I sure as hell
don't have the presence of mind to keep results thereof between the
inevitable full reinstalls, and that it's overall a Good Thing for use
outside personal code I don't need to remember.

I will second that. I would love to use ruby and qt together. But my apps are multi-platform, and I can't assume that people who use windows will already have Qt installed. If there was a simple way to get the minimum amount of Qt binaries installed for them, then I would do it for them.

~S

What are the legal issues of creating a rubygem for Qt (which included necessary .so/.dll's)? I am starting a GUI project in about a month, and am trying to decide whether to go with wx or qt. The fact that there is a wx gem, makes it sooo much easier for people to install my app.

I guess I am just trying to gauge the chances of a qt ruby gem being built?

Thanks,

~S

Shea Martin wrote:

> mardigras rdale 165% find . -name qtguess.pl.in -print
> ./smoke/qt/qtguess.pl.in
> mardigras rdale 166% find . -name generate.pl.in -print
> ./smoke/qt/generate.pl.in
>
> You're right about the INSTALL not mentioning Windows though, that is
> certainly an important omission and I'll fix it for the next release.
> You need to change the '@thing@' variables in the perl scripts to be
> what the configure should have set them to. Edit qtguess.pl.in and save
> as qtguess.pl, and then edit generate.pl.in and save as generate.pl.
>

Sorry to be so stupid, but then what? Do I run them individually?

Yes, 'perl qtguess.pl' and then 'perl generate.pl'.

I'm not sure if I actually need to run qtguess.pl, all it does is to
run various tests to see which options Qt was built with, and it writes
to the file qtdefines.

When you run the generate.pl script it starts a perl program called
'kalyptus' which uses the contents of the qtdefines file to skip any
methods/classes in the qt headers which were found to be missing from
the installed version of Qt. kalyptus generates the c++ code for the
smoke library from the qt headers, and you can compile them using qmake
to build a makefile from the project file 'qtsmoke.pro' in the smoke/qt
directory.

Here are the changes I made to generate.pl.in to create generate.pl and
get it to work:

$ diff generate.pl generate.pl.in
18c18
< my $headerlist = "./header_list";

···

---

my $headerlist = "@srcdir@/header_list";

24c24
< if("no" eq "yes")
---

if("@qtextscintilla@" eq "yes")

32c32
< if("no" eq "yes")
---

if("@qtextscintilla@" eq "yes")

92c92
< if("no" eq "yes")
---

if("@qtextscintilla@" eq "yes")

100c100
< if("no" eq "yes")
---

if("@KDE_HAVE_GL@" eq "yes")

119c119
< $qtinc= '/cygdrive/c/qt/4.1.2/include';
---

$qtinc= '@qt_includes@';

140c140
< system "perl -I../../kalyptus ../../kalyptus/kalyptus @ARGV --qt4
--globspace
-fsmoke --name=qt $macros --no-cache --outputdir=$outdir @headers";
---

system "perl -I@top_srcdir@/kalyptus @top_srcdir@/kalyptus/kalyptus @ARGV --qt

4 --globspace -fsmoke --name=qt $macros --no-cache --outputdir=$outdir
@headers"
;

This is the contents of my qtdefines file on windows:

$ cat qtdefines
QT_DEBUG
QT_CHECK_NULL
QT_LARGEFILE_SUPPORT
QT_PRODUCT_LICENSE
QT_MODULE_ICONVIEW
QT_MODULE_KERNEL
QT_STATIC_CONST_IMPL
QT_NO_REMOTE
QT_MODULE_TABLE
QT_MODULE_WIDGETS
QT_NO_COP
QT_MODULE_STYLES
QT_MODULE_XML
QT_NO_WARNINGS
QT_CHECK_STATE
QT_STATIC_CONST
QT_CHECK_MATH
QT_CHECK_RANGE
QT_MODULE_NETWORK
QT_VERSION_STR
QT_MODULE_CANVAS
QT_MODULE_TOOLS
QT_BUILD_KEY
QT_MODULE_SQL
QT_MODULE_DIALOGS
QT_VERSION
QT_PRODUCT_LICENSEE
QT_POINTER_SIZE
QT_MODULE_OPENGL
QT_MODULE_WORKSPACE

-- Richard

Shea Martin wrote:

What are the legal issues of creating a rubygem for Qt (which included
necessary .so/.dll's)? I am starting a GUI project in about a month,
and am trying to decide whether to go with wx or qt. The fact that
there is a wx gem, makes it sooo much easier for people to install my app.

  Qt4 and QtRuby are GPL, which means that if you distribute you project
to anyone, you'll need to do so under GPL -- so you'll have to make
OpenSource software. If that doesn't bother you, that's all the legal
problems you'll have. It also applies to any Qt rubygem.

I guess I am just trying to gauge the chances of a qt ruby gem being built?

  If I understood right, you're looking for a gem that would also
include Qt4 libraries, is it right ? There would be no legal problem in
distributing it, but I think it will be rather tricky to make. I hope
I'm wrong.

  Vince

···

--
Vincent Fourmond, PhD student
http://vincent.fourmond.neuf.fr/

Vincent Fourmond wrote:

I guess I am just trying to gauge the chances of a qt ruby gem being built?

  If I understood right, you're looking for a gem that would also
include Qt4 libraries, is it right ? There would be no legal problem in
distributing it, but I think it will be rather tricky to make. I hope
I'm wrong.

I'm fairly sure that the wx gem comes / used to come (no idea about the
changes with the SWIG rewrite) with wx linked into it. I'm not quite
sure that it's the best solution (people might want to use a custom wx
version), but if the build configuration was sane, it's probably good
enough for most purposes people will need and the ones that can make a
custom wx build can as well make a custom wxRuby from it.

Digressions aside, I don't think this would be technically infeasible
for Qt. Either Qt is designed (on Windows) to be statically linked into
an executable, in which case doing so for a Ruby extension library
shouldn't be a problem, or to be provided as a separate runtime DLL, in
which case dropping in this DLL into Ruby's bin directory should solve
the problem on any NT-based version of Windows - and I think rubygems
already lets you install an executable, so making this the DLL for
qtruby-mswin32 shouldn't be a problem.

David Vallner