Hello, Has anyone tested QtRuby? I''m doing a small OpenGL application http://www.discretizer.org and just want to know the arguments for staying with fxruby. This is what I have discovered: Pros: -Fxruby seems to have a very nice OpenGL support (FXGLViewer) which is what I really need. -Nice looks. No unnecessary theming support. -Very fast and light on system resources. Cons: -No complete documentation, very time consuming in some cases. I''ve had real problems to find info on which identifiers that are available (like FXGLShape::ID_FRONT_MATERIAL). Where is that info? Since I''m been working with my application for 1 year (on my spare time) I will stick with fxruby. But the ruby binding for Qt an Kde really look interesting. In another project maybe? Regards Bj?rn Bergqvist
On Jan 18, 2007, at 2:22 PM, Bj?rn Bergqvist wrote:> Has anyone tested QtRuby? I''m doing a small OpenGL application > http://www.discretizer.org and just want to know the arguments for > staying with fxruby.Qt is an excellent GUI toolkit, and although I personally haven''t used Ruby/Qt, I believe it has a lot of fans in the Ruby community. One significant difference between Qt and most of the other GUI toolkits available for Ruby is the licensing arrangement. As stated on Trolltech''s web site, you can use Qt for free only if you are writing Open Source software following the obligations of the GPL license (see http://www.trolltech.com/developer/knowledgebase/118/). Otherwise, you must purchase a commercial license. Furthermore, prior to the release of Qt version 4, developers using the Windows version of Qt were required to purchase a commercial license (regardless of whether they were developing open source software). You are correct about the lack of good documentation for FOX and FXRuby. This has been a problem from the beginning, and it''s unlikely to change unless someone takes it upon themselves to do the work. Like most open source software developers, I''m not paid to work on FXRuby and I do so in my (fleeting) spare time. This is not to say that I wouldn''t pitch in and help if someone were to spearhead a documentation effort; I''m just saying that, if it''s up to me and me alone, it''s probably not going to happen any time soon.
Bj?rn Bergqvist wrote:> Hello, > Has anyone tested QtRuby? I''m doing a small OpenGL application > http://www.discretizer.org and just want to know the arguments for > staying with fxruby. > > This is what I have discovered: > > Pros: > -Fxruby seems to have a very nice OpenGL support (FXGLViewer) which is > what I really need. > -Nice looks. No unnecessary theming support. > -Very fast and light on system resources. > > Cons: > -No complete documentation, very time consuming in some cases. I''ve > had real problems to find info on which identifiers that are available > (like FXGLShape::ID_FRONT_MATERIAL). Where is that info? > > Since I''m been working with my application for 1 year (on my spare > time) I will stick with fxruby. But the ruby binding for Qt an Kde > really look interesting. In another project maybe?It may not matter for your work, but don''t forget about licensing. IIRC: fox/fxruby => LGPL qt => ( GPL ) OR ( $$$ per license ) -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Bj?rn Bergqvist wrote:> Hello, > Has anyone tested QtRuby? I''m doing a small OpenGL application > http://www.discretizer.org and just want to know the arguments for > staying with fxruby. > > This is what I have discovered: > > Pros: > -Fxruby seems to have a very nice OpenGL support (FXGLViewer) which is > what I really need. > -Nice looks. No unnecessary theming support. >Well, I''ve gone back to FLTK, having created now my own FLTK2.0 ruby bindings, which I expect to release probably at the end of month. As for FXRuby vs Qt.... _ FXRuby is:_ Pros: - Truly multi-platform: OSX, Windows and Linux ( QtRuby is just linux, no windows afaik ) - More flexible licensing ( Qt is a commercial toolkit and as such it is not free for commercial ventures on windows, afaik) - Fox bindings use SWIG, which is a well documented API wrapper that anyone can debug (Qt is open source, but the binding is done with a custom wrapper C program, with no docs) Cons: - FxRuby is pretty heavy compared to FLTK. (Qt is worse, thou) - No themes - Ugly looking (particularly on Unix OSes, where there''s no support for AA fonts, for example) - No printing - No good canvas widgets or GDI drawing functions - No marshaling of interfaces (to create GUI skins) If you wonder why I went back to FLTK, for me: _ FLTK_ Pros: - Same as FXRuby plus... - Faster and Lighter - fluid (rfluid in my case to spit ruby code) - Themes - Good drawing functions - Antialias fonts Cons: - No printing - Ugly platform-agnostic file requester. - No marshaling of interfaces (to create GUI skins) - FLTK2.0 is not yet a 100% stable API. -- Gonzalo Garramu?o ggarra at advancedsl.com.ar AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy
On Thursday 18 January 2007 16:15, gga wrote:> Bj?rn Bergqvist wrote: > > Hello, > > Has anyone tested QtRuby? I''m doing a small OpenGL application > > http://www.discretizer.org and just want to know the arguments for > > staying with fxruby. > > > > This is what I have discovered: > > > > Pros: > > -Fxruby seems to have a very nice OpenGL support (FXGLViewer) which is > > what I really need. > > -Nice looks. No unnecessary theming support. > > > Well, I''ve gone back to FLTK, having created now my own FLTK2.0 ruby > bindings, which I expect to release probably at the end of month. As > for FXRuby vs Qt.... > _ > FXRuby is:_ > > Pros: > - Truly multi-platform: OSX, Windows and Linux ( QtRuby is just linux, > no windows afaik ) > - More flexible licensing ( Qt is a commercial toolkit and as such it is > not free for commercial ventures on windows, afaik) > - Fox bindings use SWIG, which is a well documented API wrapper that > anyone can debug (Qt is open source, but the binding is done with a > custom wrapper C program, with no docs) > > Cons: > - FxRuby is pretty heavy compared to FLTK. (Qt is worse, thou)Its not so big, and even then its a non-issue, since the library ought to be shared by multiple FOX applications as a DLL. At any rate, don''t look at the size of the library. Look how big a stripped executable clocks in. The library contains a lot of symbols, and due to C++ name mangling & use of name-spaces, the space for symbols is quite large compared to actual executable code. What counts, when you actually run, is what size your final executable is, after compiling with optimization & stripping unnecessary symbols. For example, my flag-ship executable clocks in about 4MB. It uses a large fraction of what FOX has [GL/3D/widgets/etc]. The "naked" library is only around 4MB, once symbols have been stripped; compare with C runtime library, which is also just under 4MB [on AMD64].> - Ugly looking (particularly on Unix OSes, where there''s no support for > AA fonts, for example)FOX has AA Fonts. Just turn it on [./configure --with-xft=yes ... ]. Cheers, - Jeroen -- +----------------------------------------------------------------------------+ | Copyright (C) 19:10 01/18/2007 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+
Jeroen van der Zijp wrote:> Its not so big, and even then its a non-issue, since the library ought > to be shared by multiple FOX applications as a DLL.Here''s the stats on my linux machine (stripped builds): FXruby - fox16.so - 22Mb (plus a group of 12 additional ruby files or so) FOX1.6 - 12Mb Ruby - fltk2.so - 2.9Mb (no additional ruby files needed) fltk2.so - 1.1Mb (this includes fltk2_gl and fltk2_images. without those two, fltk2 is just 988Kb). Trust me. There''s a significant difference in start-up times between a 22Mb toolkit and a 3Mb one, even on the latest hardware. Sure, if you have multiple applications running (ideally, your window manager) that use the toolkit, the startup times do become negligible. Unfortunately, most people tend to use gnome or kde for their wm, so the startup times of a third party library is still important. I went back to fltk recently just because of that, because I needed to code an image viewer for 3d applications and as such it just had to boot almost immediately. I was gladly surprised to find that fltk2 is now finally usable.> FOX has AA Fonts. Just turn it on [./configure --with-xft=yes ... ]. >Sorry for that. I did not see mention of this anywhere and the Makefile did not detect xft automatically (as it probably should, if installed). You might want to look into that in the current Makefile. -- Gonzalo Garramu?o ggarra at advancedsl.com.ar AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy
On Friday 19 January 2007 00:35, gga wrote:> Jeroen van der Zijp wrote: > > Its not so big, and even then its a non-issue, since the library ought > > to be shared by multiple FOX applications as a DLL. > Here''s the stats on my linux machine (stripped builds): > FXruby - fox16.so - 22Mb (plus a group of 12 additional ruby files or so) > FOX1.6 - 12MbMake sure you''re doing a release-build [--enable-release]. Debug build will be lots bigger.> Ruby - fltk2.so - 2.9Mb (no additional ruby files needed) > fltk2.so - 1.1Mb (this includes fltk2_gl and fltk2_images. without > those two, fltk2 is just 988Kb). > > Trust me. There''s a significant difference in start-up times between a > 22Mb toolkit and a 3Mb one, even on the latest hardware.I trust you. However, a typical FOX application compiled in release mode isn''t anywhere near 22MB, even when statically linked to FOX; again, don''t count symbols; those don''t exist while you''re running!> Sure, if you have multiple applications running (ideally, your window > manager) that use the toolkit, the startup times do become negligible. > Unfortunately, most people tend to use gnome or kde for their wm, so the > startup times of a third party library is still important.Startup time is not dominated by the time to load a library into memory. Even old drives are >40MB/s and that means a 4MB library loads in .1s or thereabouts. The time for startup depends on the number of windows, icons, and other X resources you create. All these things have to be pushed from client to X server. Not to mention, after the window manager places/sizes the window, every widget needs to be placed properly during layout. Compared to all that, load time is completely negligable...> I went back to fltk recently just because of that, because I needed to > code an image viewer for 3d applications and as such it just had to boot > almost immediately. I was gladly surprised to find that fltk2 is now > finally usable. > > FOX has AA Fonts. Just turn it on [./configure --with-xft=yes ... ]. > > > Sorry for that. I did not see mention of this anywhere and the Makefile > did not detect xft automatically (as it probably should, if > installed). You might want to look into that in the current Makefile.It will be on by default once hardware alpha blending is a bit more common; on most machines & typical unaccelerated 2D X server, Xft is about an order of magnitude slower, perhaps more. It really shows when you''re scrolling. Hopefully, X over GL will take care of that one day. Regards, - Jeroen -- +----------------------------------------------------------------------------+ | Copyright (C) 00:50 01/19/2007 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+
On Jan 19, 2007, at 12:35 AM, gga wrote:> I went back to fltk recently just because of that, because I needed to > code an image viewer for 3d applications and as such it just had to > boot > almost immediately. I was gladly surprised to find that fltk2 is now > finally usable.Since I haven''t seen the source code for your FLTK2 bindings, I can''t say for sure why there would be such a significant size difference between it and FXRuby. I am a little curious about how you''re handling things like overriding virtual function calls in Ruby, as well as garbage collection related issues. I know that the code required to support those things takes up a significant part of the FXRuby code base. Please do make an announcement when you get ready to release your code.
Lyle Johnson wrote:> > Since I haven''t seen the source code for your FLTK2 bindings, I can''t > say for sure why there would be such a significant size difference > between it and FXRuby. I am a little curious about how you''re > handling things like overriding virtual function calls in Ruby, as > well as garbage collection related issues. I know that the code > required to support those things takes up a significant part of the > FXRuby code base. >While it is not likely I''ll make an announcement until I have fluid fully written in ruby, you can already take a look at the source with: svn checkout svn://rubyforge.org/var/svn/fltk Things different from FXRuby: - inheritance and virtuals are handled by SWIG, using directors and tracking. This change reduces the code to maintain in the binding to about 1/2 of what FXRuby is currently using, as there''s no need for Rb* classes as in FXRuby. Well, technically, SWIG DOES create something equivalent to Rb* classes itself and I had the SWIG team more or less rewrite their SWIG director code for 1.3.29 onwards to handle this better. Have not delved deeply into the FXRuby source to see if the Rb* classes have any merit over the SWIG ones. Mind you, directors for ruby in swig were pretty much broken until I got to debug them over swig 1.3.28, so you do need some recent swig version. To do a mapping between C/Ruby classes at any point, SWIG''s tracking uses a hash mapping. Personally, I think SWIG''s code could still be improved here, by using a faster hash, like google''s densehashmap. - Callbacks are also handled in C, unlike FXRuby''s overriding of method() in ruby. I use duck typing within the C code. Mainly also because Matz has forgotten to expose rb_cMethod in the 1.8 branch. - Exceptions are also handled by SWIG itself. - Drawing functions are exposed also directly, sans going thru ruby. - FLTK2.0''s binding takes advantage of mapping :symbols to method callbacks within C directly. This is still not as generic as I would like, due to Ruby''s limitations internally, but the idea is to allow both: w.callback( method(:myfunction_cb) ) w.callback( :myfunction_cb ) # treat :symbol as a method in the running scope, automatically # binding to the method. # (currently this works for global methods in Object only, sadly) - FLTK2.0''s binding takes advantage of Ruby''s DSL features, by using instance_eval within blocks instead of yields on its constructor. This allows: window = Window.new( 300, 180 ) { callback :window_callback color(RED) } instead of a more convoluted: window = Window.new( 300, 180 ) { |w| w.callback :window_callback w.color(RED) } or: w = Window.new( 300, 180 ) w.callback :window_callback w.color(RED) However, the other syntaxes are also efficiently supported. SWIG/FLTK still pending issues: - Currently, there are still I think some issues using SWIG classes across multiple DSOs, but for something simpler like FLTK which is just 1 dso, it is no issue. - There''s still some segfault issues, albeit these seem more FLTK2 issues, than binding issues. Currently, the fonts listing api will often segfault on my machine. This happens to me also with FLTK in C++, thou, but I cannot get the FLTK developers to reproduce it on their environment. It seems something funky is going on in FLTK''s X11 code for it. - Sometimes if ruby rises a syntax error, upon quitting SWIG does seem not to handle its unloading properly and sometimes it will also raise a segfault. I still need to delve into this one also more fully, but it is not 100% critical. It might be unavoidable, due to use Ruby''s internal use of longjmp? Off the list, I was also talking to Jeroen about FXRuby''s size. He did seem to have found a bug in the Makefile and a way to reduce Fox symbols size a little bit more. He also made me realize that for FXRuby and my own FLTK''s bindings, it could be interesting to compile the actual FOX/Fltk library as a static library within the ruby dso, as that would remove all symbols from it, which would bring the FXRuby lib to 4mb and the FLTK lib to about 400Kb from their 12Mb and 4Mb size. The only disadvantage of doing so would be that Ruby users would need to recompile the extension every time they upgrade the underlying toolkit library. -- Gonzalo Garramu?o ggarra at advancedsl.com.ar AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy
well, yes, FOX currently always includes debug symbols. strip --strip-debug libFOX.* should reduce the size to normal proportions. Sander gga wrote:> Lyle Johnson wrote: >> Since I haven''t seen the source code for your FLTK2 bindings, I can''t >> say for sure why there would be such a significant size difference >> between it and FXRuby. I am a little curious about how you''re >> handling things like overriding virtual function calls in Ruby, as >> well as garbage collection related issues. I know that the code >> required to support those things takes up a significant part of the >> FXRuby code base. >> > While it is not likely I''ll make an announcement until I have fluid > fully written in ruby, you can already take a look at the source with: > > svn checkout svn://rubyforge.org/var/svn/fltk > > Things different from FXRuby: > - inheritance and virtuals are handled by SWIG, using directors and > tracking. > This change reduces the code to maintain in the binding to about 1/2 of > what FXRuby is currently using, as there''s no need for Rb* classes as in > FXRuby. > Well, technically, SWIG DOES create something equivalent to Rb* classes > itself and I had the SWIG team more or less rewrite their SWIG director > code for 1.3.29 onwards to handle this better. Have not delved deeply > into the FXRuby source to see if the Rb* classes have any merit over the > SWIG ones. Mind you, directors for ruby in swig were pretty much broken > until I got to debug them over swig 1.3.28, so you do need some recent > swig version. > To do a mapping between C/Ruby classes at any point, SWIG''s tracking > uses a hash mapping. Personally, I think SWIG''s code could still be > improved here, by using a faster hash, like google''s densehashmap. > - Callbacks are also handled in C, unlike FXRuby''s overriding of > method() in ruby. I use duck typing within the C code. Mainly also > because Matz has forgotten to expose rb_cMethod in the 1.8 branch. > - Exceptions are also handled by SWIG itself. > - Drawing functions are exposed also directly, sans going thru ruby. > - FLTK2.0''s binding takes advantage of mapping :symbols to method > callbacks within C directly. This is still not as generic as I would > like, due to Ruby''s limitations internally, but the idea is to allow both: > > w.callback( method(:myfunction_cb) ) > w.callback( :myfunction_cb ) # treat :symbol as a method in the > running scope, automatically > # binding to the > method. > # (currently > this works for global methods in Object only, sadly) > > - FLTK2.0''s binding takes advantage of Ruby''s DSL features, by using > instance_eval within blocks instead of yields on its constructor. This > allows: > > window = Window.new( 300, 180 ) { > callback :window_callback > color(RED) > } > > instead of a more convoluted: > > window = Window.new( 300, 180 ) { |w| > w.callback :window_callback > w.color(RED) > } > > or: > w = Window.new( 300, 180 ) > w.callback :window_callback > w.color(RED) > > However, the other syntaxes are also efficiently supported. > > > SWIG/FLTK still pending issues: > > - Currently, there are still I think some issues using SWIG classes > across multiple DSOs, but for something simpler like FLTK which is just > 1 dso, it is no issue. > - There''s still some segfault issues, albeit these seem more FLTK2 > issues, than binding issues. Currently, the fonts listing api will > often segfault on my machine. This happens to me also with FLTK in C++, > thou, but I cannot get the FLTK developers to reproduce it on their > environment. It seems something funky is going on in FLTK''s X11 code for it. > - Sometimes if ruby rises a syntax error, upon quitting SWIG does seem > not to handle its unloading properly and sometimes it will also raise a > segfault. I still need to delve into this one also more fully, but it > is not 100% critical. It might be unavoidable, due to use Ruby''s > internal use of longjmp? > > Off the list, I was also talking to Jeroen about FXRuby''s size. He did > seem to have found a bug in the Makefile and a way to reduce Fox symbols > size a little bit more. > He also made me realize that for FXRuby and my own FLTK''s bindings, it > could be interesting to compile the actual FOX/Fltk library as a static > library within the ruby dso, as that would remove all symbols from it, > which would bring the FXRuby lib to 4mb and the FLTK lib to about 400Kb > from their 12Mb and 4Mb size. The only disadvantage of doing so would > be that Ruby users would need to recompile the extension every time they > upgrade the underlying toolkit library. >