wxruby users - Oct 2003 - Survey results

Many thanks to the 23 people who took the time to respond to the survey. 
It really will help me spend my time more effectively. As promised, here 
are the results. I have inserted some comments inside [brackets].

1. Have you downloaded wxRuby?
YES  19
NO    4

2. Have you successfully built wxRuby?
YES  14
NO    8

[We really need binary downloads so people don''t have to build
anything.
We also need to fix the few remaining errors in the build scripts and 
documentation. One third of our downloaders were not able to build 
anything useful.]

3. Have you been able to run some wxRuby samples?

YES  15
NO    7

[It''s good that everyone who built it was able to run the samples.]

4. Have you tried writing your own wxRuby programs?

YES  10
NO   12

[This was interesting to me. I am curious how many people intend to 
write wxRuby apps later, and how many never intend to do so.]

5, 6, 7, 8, 9: Are you interested in developing with wxRuby under...

MSVC++ and MS Windows: YES 10, NO 12
MinGW and MS Windows: YES 10, NO 10
Mac OS X: YES 5, NO 13
GNU/Linux: YES 18, NO 4
Other:
   3 people wrote in BSD
   1 person wrote in BCC or Digital Mars

[Clearly BSD support is important, and I apologize for not including it 
in the original survey questions. Fully supporting all these platforms 
will require volunteers to keep the build scripts and binaries up to 
date, since I can only support GNU/Linux.]

10. Based on the alpha release, how would you rate wxRuby (1=terrible, 
5=super)?

1:   nobody
2:   nobody
3:   4 people
4:   8 people
5:   6 people

[This made me happy. I suspect people were gentle because it was our 
first release, but I still expected a couple lower scores. Hopefully 
each release will be much better than the last.]

11. What improvements does wxRuby need most?

[Several people asked for better samples and better API documentation. 
One suggestion was a comprehensive sample like wxPython has. Someone 
requested a tutorial like the one for Ruby-GNOME2. One person asked for 
a document describing how to leverage existing C++ wxWindows docs.]

[Another popular request was support for all the wxWindows widgets, and 
the ability to use widgets that are external to wxWindows. Specifically, 
folks requested xrc, mmedia, OGL, gtk2 editor, wxImage, and more grid 
events. A "how to wrap wxWindows extensions" doc was suggested.]

[It was clear from several of the comments that pre-built binaries would 
be very helpful. This would probably solve most of the problems people 
have been having with the build process. Two people specifically 
mentioned VC++.]

[Two people focused on improved stability.]

[One person requires unicode support.]

[One person stressed the importance of an interactive GUI builder.]

======================================================Summary (by Kevin):

Since my time is limited, and I only have a GNU/Linux box to work on, I 
will rely on other folks to take care of several of these requests.

I think our first priority should be to get binaries built for the major 
platforms. I know we should have: Linux RPM, Linux deb, and Mac OS X. 
Can we create a .so for BSD? Can we release a single MS Windows DLL, or 
do we need one for MinGW and a different one for MSVC++? If you can 
build any of these binaries, please let me know.

Next, I think we should quickly create a document that describes the 
differences between the C++ wxWindows API and the wxRuby API. Or perhaps 
it would be simpler to describe the differences between wxPython and 
wxRuby. My goal here is to leverage the existing wxWindows and/or 
wxPython docs and samples, so with minimal effort we can get a lot of 
value. A volunteer for this would be greatly appreciated.

After that, we have some harder tasks, so this would be the perfect time 
for a 0.2 release. The rest of these ideas will require more time and 
effort, I think.

It would be great if someone could put together a tutorial, and/or 
create better samples. Hopefully some of you already understand the 
basics of wxRuby well enough to do that. wxRuby API documents would also 
be helpful. Perhaps if we got our wiki set up again, we could start 
building these docs interactively.

I''m not sure about the interactive GUI builder. Didn''t someone
say that
the author of the main wxWindows GUI designer was willing to create a 
Ruby version after the wxRuby bindings were stable?

Almost everything I''ve suggested so far can be done by people with no 
C++ experience. The remaining items require C++ coders, so they are 
where I should probably focus my efforts. If anyone else feels 
comfortable in C++, I could sure use some help. These tasks would be 
supporting more widgets and wxWindows extensions, supporting unicode, 
and generally making wxRuby more stable and robust.

Whew. Thanks for reading this long message. Hopefully this will motivate 
some of you to volunteer your talents. A few hours of your time now will 
save other people countless hours as they try to learn wxRuby.

Thanks,

Kevin

Kevin Smith wrote:
>
> I think our first priority should be to get binaries built for the major
> platforms. I know we should have: Linux RPM, Linux deb, and Mac OS X.
> Can we create a .so for BSD? Can we release a single MS Windows DLL, or
> do we need one for MinGW and a different one for MSVC++? If you can
> build any of these binaries, please let me know.
You do need separate binaries for MinGW and MSVC++. I would be happy to
build and provide binaries for MSVC++, but I''m one of those who was not
able
to build successfully. I''m going to give it another try.
> I''m not sure about the interactive GUI builder. Didn''t
someone say that
> the author of the main wxWindows GUI designer was willing to create a
> Ruby version after the wxRuby bindings were stable?
I tried to contact him a couple times (this was before you took over the
development), but I got no response. But I seem to recall someone else
saying that they did make contact.

Curt

> Kevin Smith wrote:
>>
>> I think our first priority should be to get binaries built for the
major
>> platforms. I know we should have: Linux RPM, Linux deb, and Mac OS X.
>> Can we create a .so for BSD? Can we release a single MS Windows DLL, or
>> do we need one for MinGW and a different one for MSVC++? If you can
>> build any of these binaries, please let me know.
First of all: thanks very much for the all the great work on wxRuby.  I am
not a C++ coder so I more or less depend on what you guys are doing out
there.  I also realy liked the poll.
> You do need separate binaries for MinGW and MSVC++.
I don''t understand.  Because I wasn''t able to compile
wxWindows & wxRuby
for MSVC++, I compiled the two within MinGW.  This gave me a wxruby.so
which I then happily dropped in the directory of Andy Hunt''s
one-click-installer version of Ruby 1.8.0.  From there on I could use
wxRuby within MCVC++.

And I think I am not misled by thinking I executed a wxRuby script with
MSVC++ built of Ruby 1.8.0, while my path actually made me execute the
MinGW built..

Just trying to understand things..

gv@cs.uu.nl wrote:
> > Curt Hibbs wrote:
>
> > You do need separate binaries for MinGW and MSVC++.
>
> I don''t understand.  Because I wasn''t able to compile
wxWindows & wxRuby
> for MSVC++, I compiled the two within MinGW.  This gave me a wxruby.so
> which I then happily dropped in the directory of Andy Hunt''s
> one-click-installer version of Ruby 1.8.0.  From there on I could use
> wxRuby within MCVC++.
This probably because you have MinGW installed on your system. I bet if you
removed MinGW from you system you could no longer use your build of wxRuby.

Curt

Curt Hibbs (curt@hibbs.com) wrote:
> You do need separate binaries for MinGW and MSVC++. I would be happy to
> build and provide binaries for MSVC++, but I''m one of those who
was not able
> to build successfully. I''m going to give it another try.
I can also build binaries for MinGW and I''m the one of those was able
to build
it successfully :-)
> I tried to contact him a couple times (this was before you took over the
> development), but I got no response. But I seem to recall someone else
> saying that they did make contact.
I am (so much ego here :-( the one who got reply from author that as soon as
wxRuby bindings would be ready, he''d add support for Ruby.

Sincerely,
Gour

ps. I''ll comment survey later since I''m in a hurry :-)

-- 
Gour
gour@mail.inet.hr
Registered Linux User #278493

Curt Hibbs wrote:
> Kevin Smith wrote:
> 
>>I think our first priority should be to get binaries built for the major
>>platforms. I know we should have: Linux RPM, Linux deb, and Mac OS X.
>>Can we create a .so for BSD? Can we release a single MS Windows DLL, or
>>do we need one for MinGW and a different one for MSVC++? If you can
>>build any of these binaries, please let me know.
> 
> 
> You do need separate binaries for MinGW and MSVC++. I would be happy to
> build and provide binaries for MSVC++, but I''m one of those who
was not able
> to build successfully. I''m going to give it another try.
Excellent. Feel free to post questions to the list, or to me directly, 
and we can try to get the MSVC++ build going as quickly and painlessly 
as possible.

Looking at the rubyforge release system, it looks like we could have one 
"package" for each binary format. That is in addition to the existing 
wxRuby-source package that represented the initial release. But I''m not
sure--maybe it would just be a single "wxRuby" package, with each 
release containing a set of all the binary tarballs/zip files, in 
addition to the source tarball. I''m going to ask the rubyforge folks
for
advice.

Here are the binaries I want to provide. I think we have volunteers to 
create most of the binaries already:
deb:   Kevin
rpm:   ?
so:    Kevin
msvc:  Curt
mingw: Gour
osx:   Nick


Questions:

1. Does this make sense, generally?
2. Do we need cygwin also? Should we have cygwin instead of mingw?
3. Will a single .so release handle BSD, slackware, gentoo, etc?
4. Are these nicknames accurate and clear enough?
6. Is RPM good enough, or do we need different rpm packages for RedHat, 
Mandrake, SuSE, etc?
7. Does anyone know what process works best to get binary contributions 
from several people released (and checked in?) through a *forge system?

Kevin

Kevin Smith wrote:
>
> Curt Hibbs wrote:
> > Kevin Smith wrote:
> >
> >>I think our first priority should be to get binaries built for the
major
> >>platforms. I know we should have: Linux RPM, Linux deb, and Mac OS
X.
> >>Can we create a .so for BSD? Can we release a single MS Windows
DLL, or
> >>do we need one for MinGW and a different one for MSVC++? If you can
> >>build any of these binaries, please let me know.
> >
> >
> > You do need separate binaries for MinGW and MSVC++. I would be happy
to
> > build and provide binaries for MSVC++, but I''m one of those
who
> was not able
> > to build successfully. I''m going to give it another try.
>
> Excellent. Feel free to post questions to the list, or to me directly,
> and we can try to get the MSVC++ build going as quickly and painlessly
> as possible.
Do you think I should use the newest wxWindows 2.4.2 -- or should I stick
with 2.4.1?

Curt

wxWindows 2.4.2 or 2.4.1?
-------------------------

I answered my own question about whether or not I should use wxWindows 2.4.2
or 2.4.1 -- I''m sticking with 2.4.1. Reading the changelog made it
clear
that there were a number of changes in 2.4.2 that can break existing code
and require source code changes and all of the other wxRuby platforms have
been successfully built with 2.4.1.

Since the changes in 2.4.2 will probably require changes in wxRuby, when the
time comes, we should move all platform builds to the new version at the
same time.


Static vs. Shared Lib
---------------------

Looking at extconf.rb and the readme files, it looks like the other
platforms have been built upon a wxWindows that was compiled as a share
library (dll or so). This results in a runtime requirement for both a
wxWindows.so *and* a wxRuby.so file.

I think it makes more sense to build wxWindows as a static library so that
its contents are included in the wxRuby.so -- thus requiring only a single
runtime file. I plan to do my build this way, so let me know is anyone sees
a significant problem with this.


Windows Installer
-----------------

Also, as I stated previously, I plan to create a one-click windows installer
for this binary that will be designed to work seamlessly with Andy''s
one-click windows installed for Ruby.

Curt

Curt Hibbs wrote:
> Since the changes in 2.4.2 will probably require changes in wxRuby, when
the
> time comes, we should move all platform builds to the new version at the
> same time.
Good plan. Since I try to run a stock Debian "Sarge" system, I am 
somewhat at the mercy of the Debian packager to decide when I upgrade. 
Most likely, I will suddenly start having problems because my system got 
upgraded to 2.4.2 without me noticing.

At that point, I should be able to downgrade myself back to 2.4.1, or we 
could choose that time to start moving forward.
> I think it makes more sense to build wxWindows as a static library so that
> its contents are included in the wxRuby.so -- thus requiring only a single
> runtime file. I plan to do my build this way, so let me know is anyone sees
> a significant problem with this.
Yes. Yes. Yes. A couple days ago, I was thinking exactly the same thing 
for the GNU/Linux version. Not only is it a simpler install, but we are 
less likely to have library version conflicts.
> Also, as I stated previously, I plan to create a one-click windows
installer
> for this binary that will be designed to work seamlessly with
Andy''s
> one-click windows installed for Ruby.
That will be excellent. Although many of us developers are working with 
non-Windows systems, most of the folks out in the real world are still 
running MS software, so it will really help us to have solid MS Windows 
support.

Kevin

Curt Hibbs (curt@hibbs.com) wrote:
> Static vs. Shared Lib
> ---------------------
> 
> Looking at extconf.rb and the readme files, it looks like the other
> platforms have been built upon a wxWindows that was compiled as a share
> library (dll or so). This results in a runtime requirement for both a
> wxWindows.so *and* a wxRuby.so file.
> 
> I think it makes more sense to build wxWindows as a static library so that
> its contents are included in the wxRuby.so -- thus requiring only a single
> runtime file. I plan to do my build this way, so let me know is anyone sees
> a significant problem with this.
I had a problem compiling wxWindows as static library and link it with wxruby
with MinGW.

Sincerely,
Gour

-- 
Gour
gour@mail.inet.hr
Registered Linux User #278493

wxruby-users-bounces@rubyforge.org wrote:
> I think it makes more sense to build wxWindows as a static 
> library so that its contents are included in the wxRuby.so -- 
> thus requiring only a single runtime file. I plan to do my 
> build this way, so let me know is anyone sees a significant 
> problem with this.
I''ll just chime in and say that this also makes it much easier when
building
Ruby executables using exerb, which packs any necessary extensions right in
to the generated exe. OTOH, for those who are working on the build system,
I''d like the ability to easily choose static or shared when building
with
MSVC, as I can envision situations where it would be better and more
efficient to use a shared library (and this may already be possible).

My $0.02,


Nathaniel

<:((><

Kevin Smith wrote:
> Curt Hibbs wrote:
>> I think it makes more sense to build wxWindows as a static library 
I just checked in a change to extconf.rb that causes the Linux/BSD build 
to statically link wxWindows into wxruby.so.

Oddly, the resulting .so file was slightly *smaller* after I did this. 
Hmmmm.

I confirmed that it no longer depends on wx by comparing the output of 
ldd before and after this change.

Kevin