[fxruby-users] Re: FXRuby issues

Lyle Johnson lyle at knology.net
Sat Sep 3 11:15:17 EDT 2005

On Sep 3, 2005, at 3:58 AM, Gonzalo Garramuno wrote:

> Sorry to bother you personally, but after working with FXRuby for the 
> first time on a relatively medium-sized project, I collected a list of 
> things that seem to be broken in fxruby (or fox), and I thought it 
> would be good for you guys to be aware of.
> Some of these things I consider them somewhat serious in term of 
> recommending fxruby for larger projects, which is unfortunate, cause I 
> overally really liked how the API is designed.
> Unless specified, problems seem to show in both 1.2 and 1.4, under 
> Windows, at least.  The main things I run into problems were:
> * Segfaults.
> FXRuby segfaults quite a lot.  This, for once, happens when things are 
> not created, which is understandable, but bad anyway, compared to 
> other toolkits like FLTK, TK, etc. where segfaults are simply not 
> possible (other than the library is buggy).

When an FXRuby application segfaults, it's almost always the fault of 
the FXRuby bindings themselves and not the underlying FOX library.

> But more so, I also found segfaults with:
>     - crashes when creating large canvases/images.  These were pretty 
> weird.  I basically could not get FxRuby to have a 4K or 
> 8K canvas+image buffer.  I am not sure how this could be as a 128Mb + 
> 2GB swap should be enough for handling this with no problem.  Worse, 
> fxruby would just segfault upon creation.  No "out of memory" message 
> or anything.  This is overall pretty bad.
>     - segfaults sometimes when an actual ruby exception was raised 
> (runtime error, syntax error, etc).  What was bad about this is that 
> it would
>       often not allow ruby to actually flush and print the actual 
> error that caused the crash, leaving you somewhat in the dark as to 
> what
>       happened (Fox issue?  issue in my code?)  Again, this was pretty 
> bad.
>     - 1.4 seems to have some issues with the garbage collector.  
> GC.start will often segfault it.

It would be great if you could submit a bug report to the tracker at 
(http://rubyforge.org/tracker/?atid=1223&group_id=300&func=browse) that 
describes in detail how to reproduce any of these problems. A short 
example program that does so is even better.

> * The whole versioning thing.  I mentioned this already. 

Yes, we disagree about this. There are usually non-trivial API changes 
between major releases of FOX. This was true going from FOX 1.0 to 1.2, 
and again from 1.2 to 1.4. I'm glad that your application required few, 
if any, changes to "port" it from FXRuby 1.2 to 1.4, but that's the 
exception and not the rule, as I think long-time users will attest.

> * Windows focus bugs

This sounds like a bug (or feature) of the FOX library itself. You 
might try reporting it to the foxgui-users mailing list to see if 
anyone has any suggestions.

> * Custom mouse icons will not allow hotspot to be changed.  Setting 
> hotspot to anything positive in the constructor, crashes fxruby.  
> Using setHotX/Y on 1.4 does nothing.  At least on windows.

If the FOX library doesn't allow you to change the hotspot for custom 
icons, I can't do anything about that in the FXRuby layer either, but 
I'll check into it. The code shouldn't crash when setting the hotspot, 
and that should be easy enough for me to test.

> * The way the DC classes are designed are great but:
>     - FXDCPrint is just way too buggy and incomplete.  It probably 
> should be removed from the release (or a word of warning in the docs 
> should be present)
>     - FXDC is in serious need of supporting:
>         * bezier/bspline drawing
>         * hit testing
>         * FXDCWindow's with double buffering (sans opengl)
>       Three things that are relatively common in other toolkits (Tk, 
> FLTK, etc).

These are again shortcomings of FOX itself. You can report them to the 
foxgui-users list if you like.

>     * The new 1.4 tooltip callback is buggy.  On startup of the 
> program, it will often not get called until the user clicks on 
> something.  And other times, the tooltip will popup for no reason, 
> using the default popup text.

OK, will check into this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5595 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/fxruby-users/attachments/20050903/7c82fc3a/attachment.bin

More information about the fxruby-users mailing list