From Ray at Bovet.org Thu Jan 4 00:57:12 2007 From: Ray at Bovet.org (Ray Bovet) Date: Wed, 03 Jan 2007 22:57:12 -0700 Subject: [fxruby-users] hasTimeout? in fxruby 1.6.1 Message-ID: <459C9738.3020502@Bovet.org> I bet someone else has already noticed this, but I'll bring it up just in case it has slipped through the cracks. I encountered errors when attempting to use the hasTimeout? method in fxruby 1.6.1. It appears that there is a slight typo in the file timeout.rb which makes up a part of that distribution. Specifically, at line 8 it says: alias hasTimeoutOrig hasTimeout? Since the code later refers to hasTimeoutOrig? it appears to me that the line should be changed to: alias hasTimeoutOrig? hasTimeout? When I made this change it resolved the issues that I was having. By the way, a HUGE thanks to Lyle for creating and maintaining fxruby! It is really extremely nice to use!!! Ray From lyle at knology.net Thu Jan 4 10:56:47 2007 From: lyle at knology.net (Lyle Johnson) Date: Thu, 4 Jan 2007 09:56:47 -0600 Subject: [fxruby-users] hasTimeout? in fxruby 1.6.1 In-Reply-To: <459C9738.3020502@Bovet.org> References: <459C9738.3020502@Bovet.org> Message-ID: <9458CB07-94D4-4DBB-8BCB-CAC16B862984@knology.net> On Jan 3, 2007, at 11:57 PM, Ray Bovet wrote: > It appears > that there is a slight typo in the file timeout.rb which makes up a > part > of that distribution. Specifically, at line 8 it says: > alias hasTimeoutOrig hasTimeout? > Since the code later refers to hasTimeoutOrig? it appears to me > that the > line should be changed to: > alias hasTimeoutOrig? hasTimeout? > When I made this change it resolved the issues that I was having. Thanks, Ray! I have submitted a bug report on your behalf and this should get fixed in the next release. From bjorn.bergqvist at gmail.com Thu Jan 18 15:22:32 2007 From: bjorn.bergqvist at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Bergqvist?=) Date: Thu, 18 Jan 2007 21:22:32 +0100 Subject: [fxruby-users] QtRuby Message-ID: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> 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 From vjoel at path.berkeley.edu Thu Jan 18 16:49:17 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Thu, 18 Jan 2007 13:49:17 -0800 Subject: [fxruby-users] QtRuby In-Reply-To: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> Message-ID: <45AFEB5D.9040108@path.berkeley.edu> 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 From ggarra at advancedsl.com.ar Thu Jan 18 17:15:20 2007 From: ggarra at advancedsl.com.ar (gga) Date: Thu, 18 Jan 2007 19:15:20 -0300 Subject: [fxruby-users] QtRuby In-Reply-To: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> Message-ID: <45AFF178.1060102@advancedsl.com.ar> 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 From lyle at knology.net Thu Jan 18 15:53:45 2007 From: lyle at knology.net (Lyle Johnson) Date: Thu, 18 Jan 2007 14:53:45 -0600 Subject: [fxruby-users] QtRuby In-Reply-To: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> Message-ID: <62E7E038-2202-463F-B209-281FD2F810A2@knology.net> 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. From jeroen at fox-toolkit.org Thu Jan 18 20:49:52 2007 From: jeroen at fox-toolkit.org (Jeroen van der Zijp) Date: Thu, 18 Jan 2007 19:49:52 -0600 Subject: [fxruby-users] QtRuby In-Reply-To: <45AFF178.1060102@advancedsl.com.ar> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> <45AFF178.1060102@advancedsl.com.ar> Message-ID: <200701181949.52511.jeroen@fox-toolkit.org> 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. | +----------------------------------------------------------------------------+ From jeroen at fox-toolkit.org Fri Jan 19 02:09:38 2007 From: jeroen at fox-toolkit.org (Jeroen van der Zijp) Date: Fri, 19 Jan 2007 01:09:38 -0600 Subject: [fxruby-users] QtRuby In-Reply-To: <45B066CD.1060908@advancedsl.com.ar> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> <200701181949.52511.jeroen@fox-toolkit.org> <45B066CD.1060908@advancedsl.com.ar> Message-ID: <200701190109.39114.jeroen@fox-toolkit.org> 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 - 12Mb Make 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. | +----------------------------------------------------------------------------+ From ggarra at advancedsl.com.ar Fri Jan 19 01:35:57 2007 From: ggarra at advancedsl.com.ar (gga) Date: Fri, 19 Jan 2007 03:35:57 -0300 Subject: [fxruby-users] QtRuby In-Reply-To: <200701181949.52511.jeroen@fox-toolkit.org> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> <"45A FF178.1060102"@advancedsl.com.ar> <200701181949.52511.jeroen@fox-toolkit.org> Message-ID: <45B066CD.1060908@advancedsl.com.ar> 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 From bjorn.bergqvist at gmail.com Fri Jan 19 05:29:18 2007 From: bjorn.bergqvist at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Bergqvist?=) Date: Fri, 19 Jan 2007 11:29:18 +0100 Subject: [fxruby-users] Beryl Message-ID: <44936e730701190229q75c470c8s47816303ea0036b7@mail.gmail.com> Hello, I installed beryl on a computer running ubuntu edgy x86_32. Beryl considered my fxruby application to be "unresponsive" and the window was dimmed. The opengl frame was black most of the time and when I did a rotation it was flickering a lot (like there was no double buffer present). The "unresponsive"-window problem was no big problem (just unchecked that "dim unresponsive window" option). The OpenGL issue was a bit more annoying. Is there a workaround for this issue? Does this phenomenon occur on some graphics cards sometimes only? Regards Bj?rn Bergqvist From philippe.lang at attiksystem.ch Fri Jan 19 08:56:02 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Fri, 19 Jan 2007 14:56:02 +0100 Subject: [fxruby-users] "This FXTextField * already released" error.. Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CD3C@poweredge.attiksystem.ch> Hi, I have a strange bug that comes up now and then, and for which I cannot find code that reproduces it, unfortunately. It happens once, the application crashes, I do exactly the same, and this time it works. The message is: "This FXTextField * already release". Does anyone have an idea where it could come from? I never release anything under FXRuby, since Ruby is supposed to take care of that, so I'm not sure where to track that problem... Full message is here: --------------- This FXTextField * already releasedc:/ruby/lib/ruby/site_ruby/1.8/fox16/aliases.rb:4789:in `setText'c:/ruby/lib/ruby/site_ruby/1.8/fox16/aliases.rb:4789:in `text='./lib/gui/widget/db_text_field.rb:13:in `val='./lib/gui/editor/db_fk_editor.rb:93:in `chooseLookup'./lib/gui/editor/db_fk_editor.rb:39:in `initialize'c:/ruby/lib/ruby/site_ruby/1.8/fox16/responder2.rb:57:in `call'c:/ruby/lib/ruby/site_ruby/1.8/fox16/responder2.rb:57:in `onHandleMsg'./db_fk_fields.rb:5:in `execute'./db_fk_fields.rb:5:in `showEditor'./lib/gui/widget/db_fk_field.rb:64:in `onKeyPress'c:/ruby/lib/ruby/site_ruby/1.8/fox16/responder2.rb:57:in `call'c:/ruby/lib/ruby/site_ruby/1.8/fox16/responder2.rb:57:in `onHandleMsg'my_app.rb:127:in `run'my_app.rb:127 --------------- Thanks for your ideas! Philippe Lang From lyle at knology.net Fri Jan 19 09:49:56 2007 From: lyle at knology.net (Lyle Johnson) Date: Fri, 19 Jan 2007 08:49:56 -0600 Subject: [fxruby-users] Beryl In-Reply-To: <44936e730701190229q75c470c8s47816303ea0036b7@mail.gmail.com> References: <44936e730701190229q75c470c8s47816303ea0036b7@mail.gmail.com> Message-ID: <0007BC49-B631-4435-B412-EAA98E63316F@knology.net> On Jan 19, 2007, at 4:29 AM, Bj?rn Bergqvist wrote: > Is there a workaround for this issue? Does this phenomenon occur on > some graphics cards sometimes only? Jeroen (or someone else) is going to have to address this one, I'm afraid. I didn't even know what "Beryl" was. From fkchang2000 at yahoo.com Fri Jan 19 12:32:24 2007 From: fkchang2000 at yahoo.com (Forrest Chang) Date: Fri, 19 Jan 2007 09:32:24 -0800 (PST) Subject: [fxruby-users] Beryl Message-ID: <20070119173224.9363.qmail@web82811.mail.mud.yahoo.com> Hi Bj?rn: Black windows under XGL/Beryl/Compiz/etc. is generally an indication of running out of video RAM. It took me months to figure that out. Possible solutions: 1) get a new video card w/more RAM 2) lower your screen resolution. On my laptop, which is happily loving beryl after a long time of hacking, I was forced to lower the resolution from the native 1680x1050 to 1280x960, which largely handles well, but still has a quirk here or there. XGL apps generally respond ok on my machine. Forrest ----- Original Message ---- From: Bj?rn Bergqvist To: fxruby-users at rubyforge.org Sent: Friday, January 19, 2007 2:29:18 AM Subject: [fxruby-users] Beryl Hello, I installed beryl on a computer running ubuntu edgy x86_32. Beryl considered my fxruby application to be "unresponsive" and the window was dimmed. The opengl frame was black most of the time and when I did a rotation it was flickering a lot (like there was no double buffer present). The "unresponsive"-window problem was no big problem (just unchecked that "dim unresponsive window" option). The OpenGL issue was a bit more annoying. Is there a workaround for this issue? Does this phenomenon occur on some graphics cards sometimes only? Regards Bj?rn Bergqvist _______________________________________________ fxruby-users mailing list fxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/fxruby-users From lyle at knology.net Fri Jan 19 11:10:46 2007 From: lyle at knology.net (Lyle Johnson) Date: Fri, 19 Jan 2007 10:10:46 -0600 Subject: [fxruby-users] FLTK2 (was: QtRuby) In-Reply-To: <45B066CD.1060908@advancedsl.com.ar> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> <"45A FF178.1060102"@advancedsl.com.ar> <200701181949.52511.jeroen@fox-toolkit.org> <45B066CD.1060908@advancedsl.com.ar> Message-ID: <9B31C760-8D0B-4DCF-9A54-AFF7642DECEF@knology.net> 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. From lyle at knology.net Fri Jan 19 16:14:30 2007 From: lyle at knology.net (Lyle Johnson) Date: Fri, 19 Jan 2007 15:14:30 -0600 Subject: [fxruby-users] Preliminary Support for Keyword Arguments Message-ID: All, FXRuby 1.6.5 (coming real soon now) will introduce preliminary, experimental support for using keyword-style arguments in FXRuby method calls. The initial implementation of this feature will only work for class constructors (i.e. the "new" class methods), but the intent is to gradually extend this feature so that it covers all FXRuby methods. What this means in practice is that for calls to methods that have one or more optional arguments, you can replace all of the optional arguments with a hash that sets only the values for which the default isn't appropriate. So, for example, consider a typical call to FXMainWindow.new: main = FXMainWindow.new(app, "Title Goes Here", nil, nil, DECOR_ALL, 0, 0, 800, 600) In this case, the programmer wants to set the initial window width and height to 800 and 600. In order to do that (with the current release of FXRuby), however, she's required to fill in all of the optional arguments in between the window title string and the width and height values. As anyone who's worked with FXRuby for any amount of time will tell you, it's easy to accidentally leave out one of those intermediate arguments and it can be difficult to figure out what's wrong afterwards. Now consider how this method call could be written using the new keyword arguments support. First, the programmer would need to require the keyword arguments library: require 'fox16/kwargs' Then she would look up the API documentation for the FXMainWindow#initialize method (e.g. at http://www.fxruby.org/doc/api/ classes/Fox/FXMainWindow.html) and see that the names of the width and height arguments are, in fact, "width" and "height". Armed with that information, she would be able to rewrite the previous code as: main = FXMainWindow.new(app, "Title Goes Here", :width => 800, :height => 600) Here, the programmer has omitted the intermediate optional arguments (thus accepting their default values) and specified only the width and height values. This code is obviously a lot more readable and maintainable. It is important to observe the difference between required and optional arguments when using this feature. If the API documentation for a particular method doesn't indicate that an argument has a default value, then it is by definition not an optional argument. So one could *not* write the example as, e.g. main = FXMainWindow.new(app, :width => 800, :title => "Title Goes Here", :height => 600) This example is incorrect because the title argument is required, and it must be the second argument in the call. Obviously, this means that the optional arguments in a method call (if they're specified) will always follow all of the required arguments. Finally, note that the keyword arguments feature has been implemented so that it's backwards-compatible with the current positional arguments (or it's intended to be, at any rate). What that means is that you can immediately start making use of this feature in your existing code, even if you don't have time to update all of the method calls to use keyword arguments. I expect to release FXRuby 1.6.5 with this feature very soon, possibly as soon as this weekend. As stated in the opening paragraph, the initial release of this feature will only work for class constructors (i.e. the "new" class methods), but the intent is to gradually extend this feature so that it covers all FXRuby methods. All feedback/questions/comments are welcome and appreciated. Thanks, Lyle From lyle at knology.net Fri Jan 19 19:25:42 2007 From: lyle at knology.net (Lyle Johnson) Date: Fri, 19 Jan 2007 18:25:42 -0600 Subject: [fxruby-users] "This FXTextField * already released" error.. In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CD3C@poweredge.attiksystem.ch> References: <6C0CF58A187DA5479245E0830AF84F4218CD3C@poweredge.attiksystem.ch> Message-ID: <85B8DEE1-DCB3-4753-9F47-B1D598432965@knology.net> On Jan 19, 2007, at 7:56 AM, Philippe Lang wrote: > I have a strange bug that comes up now and then, and for which I > cannot > find code that reproduces it, unfortunately. It happens once, the > application crashes, I do exactly the same, and this time it works. > > The message is: "This FXTextField * already release". > > Does anyone have an idea where it could come from? That message indicates that the underlying C++ object (in this case, an FXTextField) that a Ruby object is pointing to has already been deleted (freed). It's not something that you should see under normal circumstances, and it may indicate a bug in FXRuby's GC code (especially since you report that the behavior is inconsistent). If it's something you'd like for me to take a look at, please send me the code off-line. Thanks, Lyle From ggarra at advancedsl.com.ar Fri Jan 19 23:43:15 2007 From: ggarra at advancedsl.com.ar (gga) Date: Sat, 20 Jan 2007 01:43:15 -0300 Subject: [fxruby-users] FLTK2 In-Reply-To: <9B31C760-8D0B-4DCF-9A54-AFF7642DECEF@knology.net> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> <"45 A FF178.1060102"@advancedsl.com.ar> <45B066CD.1060908@advancedsl.com.ar> <9B31C760-8D0B-4DCF-9A54-AFF7642DECEF@knology.net> Message-ID: <45B19DE3.8080407@advancedsl.com.ar> 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 From sander at knology.net Sat Jan 20 01:20:22 2007 From: sander at knology.net (Sander Jansen) Date: Sat, 20 Jan 2007 00:20:22 -0600 Subject: [fxruby-users] FLTK2 In-Reply-To: <45B19DE3.8080407@advancedsl.com.ar> References: <44936e730701181222m5120466eif527e7261f43e68@mail.gmail.com> <"45 A FF178.1060102"@advancedsl.com.ar> <45B066CD.1060908@advancedsl.com.ar> <9B31C760-8D0B-4DCF-9A54-AFF7642DECEF@knology.net> <45B19DE3.8080407@advancedsl.com.ar> Message-ID: <45B1B4A6.7050802@knology.net> 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. > From grauenwolf at gmail.com Sat Jan 20 16:28:44 2007 From: grauenwolf at gmail.com (Jonathan Allen) Date: Sat, 20 Jan 2007 13:28:44 -0800 Subject: [fxruby-users] FreeRIDE - Way too many warnings Message-ID: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> Whenever I start FreeRIDE I get a ton of warnings. It takes a long time to start as well, probably because it is I/O bound to the console window. Suggestions? Jonathan 2.so: warning: already initialized constant FOLDINGLIST_ROOT_BOXES C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant FOLDINGLIST_NORMAL C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_LOOKUPTIMER C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_HEADER_CHANGE C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_LAST C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_EXTENDEDSELECT C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_SINGLESELECT C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_BROWSESELECT C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_MULTIPLESELECT C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_AUTOSELECT C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_SHOWS_LINES C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_SHOWS_BOXES C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_ROOT_BOXES C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant TREELIST_NORMAL C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_LOOKUPTIMER C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_LAST C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant DIRLIST_SHOWFILES C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant DIRLIST_SHOWHIDDEN C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant DIRLIST_NO_OWN_ASSOC C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_REFRESHTIMER C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_SHOW_FILES C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_HIDE_FILES C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_TOGGLE_FILES C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_SHOW_HIDDEN C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_HIDE_HIDDEN C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_TOGGLE_HIDDEN C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_SET_PATTERN C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_SORT_REVERSE C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_SORT_CASE C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_REFRESH C:/Program Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 2.so: warning: already initialized constant ID_LAST From meinrad.recheis at gmail.com Sat Jan 20 16:37:24 2007 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Sat, 20 Jan 2007 22:37:24 +0100 Subject: [fxruby-users] FreeRIDE - Way too many warnings In-Reply-To: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> References: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> Message-ID: <43d756720701201337g3fbeee5er1f7c99cae45035a8@mail.gmail.com> just launch the app with $VERBOSE=nil hth, -- henon On 1/20/07, Jonathan Allen wrote: > Whenever I start FreeRIDE I get a ton of warnings. It takes a long time > to start as well, probably because it is I/O bound to the console > window. > > Suggestions? > > Jonathan > > 2.so: warning: already initialized constant FOLDINGLIST_ROOT_BOXES > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant FOLDINGLIST_NORMAL > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_LOOKUPTIMER > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_HEADER_CHANGE > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_LAST > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_EXTENDEDSELECT > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_SINGLESELECT > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_BROWSESELECT > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_MULTIPLESELECT > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_AUTOSELECT > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_SHOWS_LINES > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_SHOWS_BOXES > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_ROOT_BOXES > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant TREELIST_NORMAL > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_LOOKUPTIMER > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_LAST > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant DIRLIST_SHOWFILES > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant DIRLIST_SHOWHIDDEN > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant DIRLIST_NO_OWN_ASSOC > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_REFRESHTIMER > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_SHOW_FILES > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_HIDE_FILES > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_TOGGLE_FILES > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_SHOW_HIDDEN > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_HIDE_HIDDEN > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_TOGGLE_HIDDEN > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_SET_PATTERN > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_SORT_REVERSE > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_SORT_CASE > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_REFRESH > C:/Program > Files/Ruby/lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox1 > 2.so: warning: already initialized constant ID_LAST > > > _______________________________________________ > fxruby-users mailing list > fxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/fxruby-users > From lyle at knology.net Sat Jan 20 16:38:35 2007 From: lyle at knology.net (Lyle Johnson) Date: Sat, 20 Jan 2007 15:38:35 -0600 Subject: [fxruby-users] FreeRIDE - Way too many warnings In-Reply-To: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> References: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> Message-ID: On Jan 20, 2007, at 3:28 PM, Jonathan Allen wrote: > Whenever I start FreeRIDE I get a ton of warnings. It takes a long > time > to start as well, probably because it is I/O bound to the console > window. This bug was introduced in Ruby 1.8.5 and it's unclear whether it will be fixed. I added a workaround for this Ruby bug in FXRuby 1.6.4. FXRuby 1.2 is two generations "old" and is no longer being maintained by me. One option is to just ignore the warnings. Another is to downgrade to Ruby 1.8.4, which did not have this problem. Yet another is to convince the FreeRIDE project to update FreeRIDE for compatibility with FXRuby 1.6. From lyle at knology.net Sat Jan 20 16:39:12 2007 From: lyle at knology.net (Lyle Johnson) Date: Sat, 20 Jan 2007 15:39:12 -0600 Subject: [fxruby-users] FreeRIDE - Way too many warnings In-Reply-To: <43d756720701201337g3fbeee5er1f7c99cae45035a8@mail.gmail.com> References: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> <43d756720701201337g3fbeee5er1f7c99cae45035a8@mail.gmail.com> Message-ID: <310ABCE8-83E7-442A-A1CD-66FE49C4543D@knology.net> On Jan 20, 2007, at 3:37 PM, Meinrad Recheis wrote: > just launch the app with $VERBOSE=nil Ah, an even better option! Thanks for this tip. From grauenwolf at gmail.com Sat Jan 20 16:59:20 2007 From: grauenwolf at gmail.com (Jonathan Allen) Date: Sat, 20 Jan 2007 13:59:20 -0800 Subject: [fxruby-users] FreeRIDE - Way too many warnings In-Reply-To: <43d756720701201337g3fbeee5er1f7c99cae45035a8@mail.gmail.com> References: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> <43d756720701201337g3fbeee5er1f7c99cae45035a8@mail.gmail.com> Message-ID: <000501c73cde$3df37480$6501a8c0@radicaljay> What is the full command line? I tried: ruby freeride.rb $VERBOSE=nil ruby $VERBOSE=nil freeride.rb The former doesn't change anything and the latter says "No such file or directory" Jonathan -----Original Message----- From: fxruby-users-bounces at rubyforge.org [mailto:fxruby-users-bounces at rubyforge.org] On Behalf Of Meinrad Recheis Sent: Saturday, January 20, 2007 1:37 PM To: fxruby-users at rubyforge.org Subject: Re: [fxruby-users] FreeRIDE - Way too many warnings just launch the app with $VERBOSE=nil hth, -- henon From grauenwolf at gmail.com Sat Jan 20 17:04:26 2007 From: grauenwolf at gmail.com (Jonathan Allen) Date: Sat, 20 Jan 2007 14:04:26 -0800 Subject: [fxruby-users] FreeRIDE - Way too many warnings In-Reply-To: References: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> Message-ID: <000601c73cde$f526b770$6501a8c0@radicaljay> Forgive my ignorance, by why is Ruby distributing a nearly 2 year-old version? Jonathan -----Original Message----- From: fxruby-users-bounces at rubyforge.org [mailto:fxruby-users-bounces at rubyforge.org] On Behalf Of Lyle Johnson Sent: Saturday, January 20, 2007 1:39 PM To: fxruby-users at rubyforge.org Subject: Re: [fxruby-users] FreeRIDE - Way too many warnings On Jan 20, 2007, at 3:28 PM, Jonathan Allen wrote: > Whenever I start FreeRIDE I get a ton of warnings. It takes a long > time > to start as well, probably because it is I/O bound to the console > window. This bug was introduced in Ruby 1.8.5 and it's unclear whether it will be fixed. I added a workaround for this Ruby bug in FXRuby 1.6.4. FXRuby 1.2 is two generations "old" and is no longer being maintained by me. One option is to just ignore the warnings. Another is to downgrade to Ruby 1.8.4, which did not have this problem. Yet another is to convince the FreeRIDE project to update FreeRIDE for compatibility with FXRuby 1.6. _______________________________________________ fxruby-users mailing list fxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/fxruby-users From meinrad.recheis at gmail.com Sat Jan 20 17:10:18 2007 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Sat, 20 Jan 2007 23:10:18 +0100 Subject: [fxruby-users] FreeRIDE - Way too many warnings In-Reply-To: <000501c73cde$3df37480$6501a8c0@radicaljay> References: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> <43d756720701201337g3fbeee5er1f7c99cae45035a8@mail.gmail.com> <000501c73cde$3df37480$6501a8c0@radicaljay> Message-ID: <43d756720701201410q5899dae3j8c6df8a15cab454a@mail.gmail.com> should be: ruby -e"$VERBOSE=nil;require 'freeride' " hth, -- henon On 1/20/07, Jonathan Allen wrote: > What is the full command line? > > I tried: > ruby freeride.rb $VERBOSE=nil > ruby $VERBOSE=nil freeride.rb > > The former doesn't change anything and the latter says "No such file or > directory" > > Jonathan > > -----Original Message----- > From: fxruby-users-bounces at rubyforge.org > [mailto:fxruby-users-bounces at rubyforge.org] On Behalf Of Meinrad Recheis > Sent: Saturday, January 20, 2007 1:37 PM > To: fxruby-users at rubyforge.org > Subject: Re: [fxruby-users] FreeRIDE - Way too many warnings > > just launch the app with $VERBOSE=nil > > hth, > -- henon > > > > _______________________________________________ > fxruby-users mailing list > fxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/fxruby-users > From lyle at knology.net Sat Jan 20 17:17:09 2007 From: lyle at knology.net (Lyle Johnson) Date: Sat, 20 Jan 2007 16:17:09 -0600 Subject: [fxruby-users] FreeRIDE - Way too many warnings In-Reply-To: <000601c73cde$f526b770$6501a8c0@radicaljay> References: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> <000601c73cde$f526b770$6501a8c0@radicaljay> Message-ID: On Jan 20, 2007, at 4:04 PM, Jonathan Allen wrote: > Forgive my ignorance, by why is Ruby distributing a nearly 2 year-old > version? That is a fantastic question. I would love for more people to ask this of the people who make that decision. From lyle at knology.net Sat Jan 20 17:24:54 2007 From: lyle at knology.net (Lyle Johnson) Date: Sat, 20 Jan 2007 16:24:54 -0600 Subject: [fxruby-users] FreeRIDE - Way too many warnings In-Reply-To: <000601c73cde$f526b770$6501a8c0@radicaljay> References: <000401c73cd9$f7e5f0c0$6501a8c0@radicaljay> <000601c73cde$f526b770$6501a8c0@radicaljay> Message-ID: On Jan 20, 2007, at 4:04 PM, Jonathan Allen wrote: > Forgive my ignorance, by why is Ruby distributing a nearly 2 year-old > version? I'm sorry, let me make a less sarcastic attempt at answering your question. FXRuby 1.2 is still included with the Ruby One-Click Installer for Windows because FreeRIDE depends on that version of FXRuby. So if that version of FXRuby was not included with the Windows installer, FreeRIDE wouldn't work. I believe that FXRuby 1.6 is also included with the One-Click Installer, by the way, as an optional feature (but I'm not 100% sure about that). So a better question would be, why hasn't the FreeRIDE project updated their code to use a more recent version of FXRuby? And the answer is that they have very few people working on the project at any one time, and no one has really led the charge to make this happen. If I recall correctly, FreeRIDE was updated to some extent to work with FXRuby 1.4, but I don't think that version of the code has ever been released. I apologize for my previous, jackass-like answer. I just have to answer these kinds of questions a lot and there's not much I can do to fix the underlying problem(s). From lyle at knology.net Sat Jan 20 20:51:48 2007 From: lyle at knology.net (Lyle Johnson) Date: Sat, 20 Jan 2007 19:51:48 -0600 Subject: [fxruby-users] [ANN] FXRuby 1.6.5 Now Available Message-ID: <5E66212B-C707-4F16-B33F-CA4D7BCEF86D@knology.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, FXRuby version 1.6.5 is now available for download from this page: http://rubyforge.org/frs/?group_id=300&release_id=9145 Note that you should be using FOX 1.6.16 or later due to some important changes made in that release of FOX. For a summary of the changes in this release of FXRuby, please see this page: http://www.fxruby.org/doc/changes.html As usual, the code is provided as a Win32 installer or a binary Gem (both compatible with the latest One-Click Installer for Ruby 1.8.5), as a source gem, and as a source tarball. For instructions on compiling FXRuby from source, please see: http://www.fxruby.org/doc/build.html And as always, the FXRuby home page is here: http://www.fxruby.org Enjoy, Lyle -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFssc1FXV/hD6oMd0RAhSXAJ92nYUIJDooG6+yX6/Zns3x+SwX2QCfTsn5 FyFP6PzOv6QiTPoujfz4su0= =hHKX -----END PGP SIGNATURE----- From philippe.lang at attiksystem.ch Sun Jan 21 17:53:03 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Sun, 21 Jan 2007 23:53:03 +0100 Subject: [fxruby-users] addAccel Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CD3D@poweredge.attiksystem.ch> Hi, I'm trying to add keyboard accelerators in my app, without success. Does anyone see the problem in the following code? I always get a segmentation fault when I hit Ctrl-S: C:/test/accell.rb:35: [BUG] Segmentation fault ruby 1.8.5 (2006-08-25) [i386-mswin32] Thanks! ------------------------- require 'fox16' include Fox class MyWindow < FXMainWindow include Responder ID_SAVE = FXMainWindow::ID_LAST def initialize(app) super(app, "Window", nil, nil, DECOR_ALL, 0, 0, 200, 100) FXMAPFUNC(SEL_COMMAND, MyWindow::ID_SAVE, 'onSave') accelTable.addAccel(fxparseAccel("Ctrl-S"), self, FXSEL(SEL_COMMAND, MyWindow::ID_SAVE)) end def onSave(sender, selector, data) puts "save" end def create super show(PLACEMENT_SCREEN) end end if __FILE__ == $0 application = FXApp.new("Fox", "FXRuby Test") MyWindow.new(application) application.create application.run End ------------------------- I'm using FXRuby 1.6.5 / Ruby 1.8.5 under XP. Philippe From lyle at knology.net Sun Jan 21 18:58:16 2007 From: lyle at knology.net (Lyle Johnson) Date: Sun, 21 Jan 2007 17:58:16 -0600 Subject: [fxruby-users] addAccel In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CD3D@poweredge.attiksystem.ch> References: <6C0CF58A187DA5479245E0830AF84F4218CD3D@poweredge.attiksystem.ch> Message-ID: On Jan 21, 2007, at 4:53 PM, Philippe Lang wrote: > I'm trying to add keyboard accelerators in my app, without success. > Does > anyone see the problem in the following code? It's working OK under Mac OS X, although it does print out an assert message before it prints "save": pepper:~/src/FXRuby-1.6/examples lyle$ ruby p.rb FXRuby.cpp:880: FXASSERT(FALSE) failed. save I will try it out under Windows in a while and see what happens. That assert failure may have a (crashy) side effect on Windows that doesn't show up under Mac OS X. From vjoel at path.berkeley.edu Sun Jan 21 20:37:39 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Sun, 21 Jan 2007 17:37:39 -0800 Subject: [fxruby-users] addAccel In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CD3D@poweredge.attiksystem.ch> References: <6C0CF58A187DA5479245E0830AF84F4218CD3D@poweredge.attiksystem.ch> Message-ID: <45B41563.7020604@path.berkeley.edu> Philippe Lang wrote: > Hi, > > I'm trying to add keyboard accelerators in my app, without success. Does > anyone see the problem in the following code? > > I always get a segmentation fault when I hit Ctrl-S: I get that too on windows; ruby-1.8.5, fxruby-1.6.5. -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 From bjorn.bergqvist at gmail.com Wed Jan 24 04:36:23 2007 From: bjorn.bergqvist at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Bergqvist?=) Date: Wed, 24 Jan 2007 10:36:23 +0100 Subject: [fxruby-users] Beryl In-Reply-To: <20070119173224.9363.qmail@web82811.mail.mud.yahoo.com> References: <20070119173224.9363.qmail@web82811.mail.mud.yahoo.com> Message-ID: <44936e730701240136g4d896f01s7e2d2cea7f058998@mail.gmail.com> Hello, If I lower the resolution the FXGLViewer is still black and flickery. But I saw that when I looked on a video that window also was black sometimes. Probably it's just someting wrong with the graphics driver. Bj?rn Bergqvist On 1/19/07, Forrest Chang wrote: > Hi Bj?rn: > > Black windows under XGL/Beryl/Compiz/etc. is generally an indication of running out of video RAM. > > It took me months to figure that out. Possible solutions: 1) get a new video card w/more RAM 2) lower your screen resolution. > > On my laptop, which is happily loving beryl after a long time of hacking, I was forced to lower the resolution from the native 1680x1050 to 1280x960, which largely handles well, but still has a quirk here or there. XGL apps generally respond ok on my machine. > > Forrest > > ----- Original Message ---- > From: Bj?rn Bergqvist > To: fxruby-users at rubyforge.org > Sent: Friday, January 19, 2007 2:29:18 AM > Subject: [fxruby-users] Beryl > > Hello, > I installed beryl on a computer running ubuntu edgy x86_32. Beryl > considered my fxruby application to be "unresponsive" and the window > was dimmed. > The opengl frame was black most of the time and when I did a rotation > it was flickering a lot (like there was no double buffer present). > > The "unresponsive"-window problem was no big problem (just unchecked > that "dim unresponsive window" option). > The OpenGL issue was a bit more annoying. > > Is there a workaround for this issue? Does this phenomenon occur on > some graphics cards sometimes only? > > Regards > Bj?rn Bergqvist > _______________________________________________ > fxruby-users mailing list > fxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/fxruby-users > > > > _______________________________________________ > fxruby-users mailing list > fxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/fxruby-users > From fkchang2000 at yahoo.com Wed Jan 24 14:38:22 2007 From: fkchang2000 at yahoo.com (Forrest Chang) Date: Wed, 24 Jan 2007 11:38:22 -0800 (PST) Subject: [fxruby-users] Beryl Message-ID: <20070124193822.24730.qmail@web82807.mail.mud.yahoo.com> NOt sure, but still sounds like video ram exhaustion, if I read your symptoms right. How much video ram do you have, and how low resolution did you go? Forrest ----- Original Message ---- From: Bj?rn Bergqvist To: fxruby-users at rubyforge.org Sent: Wednesday, January 24, 2007 1:36:23 AM Subject: Re: [fxruby-users] Beryl Hello, If I lower the resolution the FXGLViewer is still black and flickery. But I saw that when I looked on a video that window also was black sometimes. Probably it's just someting wrong with the graphics driver. Bj?rn Bergqvist On 1/19/07, Forrest Chang wrote: > Hi Bj?rn: > > Black windows under XGL/Beryl/Compiz/etc. is generally an indication of running out of video RAM. > > It took me months to figure that out. Possible solutions: 1) get a new video card w/more RAM 2) lower your screen resolution. > > On my laptop, which is happily loving beryl after a long time of hacking, I was forced to lower the resolution from the native 1680x1050 to 1280x960, which largely handles well, but still has a quirk here or there. XGL apps generally respond ok on my machine. > > Forrest > > ----- Original Message ---- > From: Bj?rn Bergqvist > To: fxruby-users at rubyforge.org > Sent: Friday, January 19, 2007 2:29:18 AM > Subject: [fxruby-users] Beryl > > Hello, > I installed beryl on a computer running ubuntu edgy x86_32. Beryl > considered my fxruby application to be "unresponsive" and the window > was dimmed. > The opengl frame was black most of the time and when I did a rotation > it was flickering a lot (like there was no double buffer present). > > The "unresponsive"-window problem was no big problem (just unchecked > that "dim unresponsive window" option). > The OpenGL issue was a bit more annoying. > > Is there a workaround for this issue? Does this phenomenon occur on > some graphics cards sometimes only? > > Regards > Bj?rn Bergqvist > _______________________________________________ > fxruby-users mailing list > fxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/fxruby-users > > > > _______________________________________________ > fxruby-users mailing list > fxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/fxruby-users > _______________________________________________ fxruby-users mailing list fxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/fxruby-users From philippe.lang at attiksystem.ch Thu Jan 25 02:50:37 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Thu, 25 Jan 2007 08:50:37 +0100 Subject: [fxruby-users] SEL_CHANGED event for FXText and FXTextfield Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CD47@poweredge.attiksystem.ch> Hi, I have noticed a small difference between the SEL_CHANGED event of an FXText and an FXTextfield: in an FXText, the SEL_CHANGED event gets fired even if the content does not "change", like when the selection changes. You can test that with the following test program. I imagine this is no bug at all. But from a "symetry" point of view :), I was expecting both events to mean the same in two similar widgets. The equivalent event for an FXText is actually SEL_REPLACED. It took me some time to figure it out! Anyway, this is not a big deal at all. Regards, Philippe ----------------------------------------- require 'fox16' include Fox class MyWindow < FXMainWindow def initialize(app) super(app, "Window", nil, nil, DECOR_ALL, 0, 0, 200, 100) text_field = FXTextField.new(self, 15) text_field.text = "1234567890abcd" text_field.connect(SEL_CHANGED, method(:onTextFieldChange)) text_area = FXText.new(self, nil, 0, LAYOUT_FILL_X|LAYOUT_FILL_Y) text_area.text = "1234567890abcd" text_area.connect(SEL_CHANGED, method(:onTextAreaChange)) end def onTextFieldChange(sender, selector, data) puts "onTextFieldChange" end def onTextAreaChange(sender, selector, data) puts "onTextAreaChange" end def create super show(PLACEMENT_SCREEN) end end if __FILE__ == $0 application = FXApp.new("Fox", "FXRuby Test") MyWindow.new(application) application.create application.run end From jeroen at fox-toolkit.org Thu Jan 25 08:10:12 2007 From: jeroen at fox-toolkit.org (Jeroen van der Zijp) Date: Thu, 25 Jan 2007 07:10:12 -0600 Subject: [fxruby-users] SEL_CHANGED event for FXText and FXTextfield In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CD47@poweredge.attiksystem.ch> References: <6C0CF58A187DA5479245E0830AF84F4218CD47@poweredge.attiksystem.ch> Message-ID: <200701250710.12784.jeroen@fox-toolkit.org> On Thursday 25 January 2007 01:50, Philippe Lang wrote: > Hi, > > I have noticed a small difference between the SEL_CHANGED event of an > FXText and an FXTextfield: in an FXText, the SEL_CHANGED event gets > fired even if the content does not "change", like when the selection > changes. You can test that with the following test program. > > I imagine this is no bug at all. But from a "symetry" point of view :), > I was expecting both events to mean the same in two similar widgets. The > equivalent event for an FXText is actually SEL_REPLACED. It took me some > time to figure it out! I'm actually thinking of FXTextField as a kind of valuator [like FXSlider and FXDial], and FXText as something else. Its often a judgement call as you can also come up with arguments why FXTextField should be like FXText. Regards, - Jeroen -- +----------------------------------------------------------------------------+ | Copyright (C) 07:00 01/25/2007 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+ From philippe.lang at attiksystem.ch Thu Jan 25 08:20:02 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Thu, 25 Jan 2007 14:20:02 +0100 Subject: [fxruby-users] SEL_CHANGED event for FXText and FXTextfield References: <6C0CF58A187DA5479245E0830AF84F4218CD47@poweredge.attiksystem.ch> <200701250710.12784.jeroen@fox-toolkit.org> Message-ID: <6C0CF58A187DA5479245E0830AF84F421D1730@poweredge.attiksystem.ch> Jeroen van der Zijp wrote: > On Thursday 25 January 2007 01:50, Philippe Lang wrote: >> Hi, >> >> I have noticed a small difference between the SEL_CHANGED event of an >> FXText and an FXTextfield: in an FXText, the SEL_CHANGED event gets >> fired even if the content does not "change", like when the selection >> changes. You can test that with the following test program. >> >> I imagine this is no bug at all. But from a "symetry" point of view >> :), I was expecting both events to mean the same in two similar >> widgets. The equivalent event for an FXText is actually SEL_REPLACED. >> It took me some time to figure it out! > > I'm actually thinking of FXTextField as a kind of valuator [like > FXSlider and FXDial], and FXText as something else. > > Its often a judgement call as you can also come up with arguments why > FXTextField should be like FXText. OK I understand now, this is clear. Anyway, this is really a detail, FXRuby works just fine, and let me thanks you again for that! Cheers, Philippe From philippe.lang at attiksystem.ch Wed Jan 31 12:11:11 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Wed, 31 Jan 2007 18:11:11 +0100 Subject: [fxruby-users] Closing a modal FXDialogBox correctly? Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CD5D@poweredge.attiksystem.ch> Hi, Very rarely, I have a bug when closing a modal dialog box. What is the 100% correct way of closing a modal dialog box, programmatically, from within the dialog code itself? Until now, I was using: ---------------------- self.handle(self, FXSEL(SEL_COMMAND, ID_ACCEPT), nil) ---------------------- ... and it works 99% of the time. After checking the fox C++ code, I found that such a call triggers code like: ---------------------- getApp()->stopModal(this,FALSE); hide(); ---------------------- Where hide() does: ---------------------- if(flags&FLAG_SHOWN){ killFocus(); flags&=~FLAG_SHOWN; if(xid){ #ifndef WIN32 XWithdrawWindow(DISPLAY(getApp()),xid,DefaultScreen(DISPLAY(getApp()))); #else // if(getOwner() && getOwner()->id()){ // SetActiveWindow((HWND)getOwner()->getShell()->id()); // Fix from Sander // } ShowWindow((HWND)xid,SW_HIDE); #endif } } ---------------------- Is there a chance some code might be executing WHILE the dialog is being closed, what could explain the crashes? I have tried replacing: ---------------------- self.handle(self, FXSEL(SEL_COMMAND, ID_ACCEPT), nil) ---------------------- ... with: ---------------------- close $app.stopModal ---------------------- The "close" function has got code that might help: ---------------------- // Target will receive no further messages from us setTarget(NULL); setSelector(0); ---------------------- We'll see if helps. Unfortunately I cannot reproduce the bug. Does anyone have the same rare problem maybe? Philippe Lang From jeroen at fox-toolkit.org Wed Jan 31 12:49:53 2007 From: jeroen at fox-toolkit.org (Jeroen van der Zijp) Date: Wed, 31 Jan 2007 11:49:53 -0600 Subject: [fxruby-users] Closing a modal FXDialogBox correctly? In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CD5D@poweredge.attiksystem.ch> References: <6C0CF58A187DA5479245E0830AF84F4218CD5D@poweredge.attiksystem.ch> Message-ID: <200701311149.53415.jeroen@fox-toolkit.org> On Wednesday 31 January 2007 11:11, Philippe Lang wrote: > Hi, > > Very rarely, I have a bug when closing a modal dialog box. > > What is the 100% correct way of closing a modal dialog box, > programmatically, from within the dialog code itself? To close the dialog, the ID_ACCEPT or ID_CANCEL message is used, which (1) breaks out of the modal loop and (2) hides the window. Implied herein is that you've started the modal loop via the dialog's execute() function [or with runModalFor()]. The modal event loop is a re-incarnation of the event loop which won't return to the caller until the stopModal() function is invoked. Note that the window argument in runModalFor() and stopModal() must match up; perhaps that is the problem? At any rate, a modal loop is required. Hope this helps, - Jeroen From philippe.lang at attiksystem.ch Wed Jan 31 13:07:38 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Wed, 31 Jan 2007 19:07:38 +0100 Subject: [fxruby-users] Closing a modal FXDialogBox correctly? References: <6C0CF58A187DA5479245E0830AF84F4218CD5D@poweredge.attiksystem.ch> <200701311149.53415.jeroen@fox-toolkit.org> Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CD5E@poweredge.attiksystem.ch> Jeroen van der Zijp wrote: > On Wednesday 31 January 2007 11:11, Philippe Lang wrote: >> Hi, >> >> Very rarely, I have a bug when closing a modal dialog box. >> >> What is the 100% correct way of closing a modal dialog box, >> programmatically, from within the dialog code itself? > > To close the dialog, the ID_ACCEPT or ID_CANCEL message is used, > which (1) breaks out of the modal loop and (2) hides the window. > > Implied herein is that you've started the modal loop via the dialog's > execute() function [or with runModalFor()]. > > The modal event loop is a re-incarnation of the event loop which > won't return to the caller until the stopModal() function is invoked. > > Note that the window argument in runModalFor() and stopModal() must > match up; perhaps that is the problem? Hi, Thanks for your answer. I'm starting all the dialogs with a call to "execute", so I don't have to pass any specific parameter as an argument. Is there a chance there can be in very rare occasions some sort of "concurrency" problem when closing a dialog which is receving a fox message mostly in the same time? And that the code triggered by the fox message relies on a "half-closed" dialog somehow? I ask this because I got twice a message which is "This FXTextField * already release". All my dialogs contain at least one "FXTextField"... Note that I'm using the Ruby bindings. Is there a chance the problems comes from here? Regards, Philippe From jeroen at fox-toolkit.org Wed Jan 31 13:29:55 2007 From: jeroen at fox-toolkit.org (Jeroen van der Zijp) Date: Wed, 31 Jan 2007 12:29:55 -0600 Subject: [fxruby-users] Closing a modal FXDialogBox correctly? In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CD5E@poweredge.attiksystem.ch> References: <6C0CF58A187DA5479245E0830AF84F4218CD5D@poweredge.attiksystem.ch> <200701311149.53415.jeroen@fox-toolkit.org> <6C0CF58A187DA5479245E0830AF84F4218CD5E@poweredge.attiksystem.ch> Message-ID: <200701311229.55901.jeroen@fox-toolkit.org> On Wednesday 31 January 2007 12:07, Philippe Lang wrote: > Jeroen van der Zijp wrote: > > On Wednesday 31 January 2007 11:11, Philippe Lang wrote: > >> Hi, > >> > >> Very rarely, I have a bug when closing a modal dialog box. > >> > >> What is the 100% correct way of closing a modal dialog box, > >> programmatically, from within the dialog code itself? > > > > To close the dialog, the ID_ACCEPT or ID_CANCEL message is used, > > which (1) breaks out of the modal loop and (2) hides the window. > > > > Implied herein is that you've started the modal loop via the dialog's > > execute() function [or with runModalFor()]. > > > > The modal event loop is a re-incarnation of the event loop which > > won't return to the caller until the stopModal() function is invoked. > > > > Note that the window argument in runModalFor() and stopModal() must > > match up; perhaps that is the problem? > > Hi, > > Thanks for your answer. > > I'm starting all the dialogs with a call to "execute", so I don't have > to pass any specific parameter as an argument. > > Is there a chance there can be in very rare occasions some sort of > "concurrency" problem when closing a dialog which is receving a fox > message mostly in the same time? And that the code triggered by the fox > message relies on a "half-closed" dialog somehow? I ask this because I > got twice a message which is "This FXTextField * already release". All > my dialogs contain at least one "FXTextField"... The only thing you need to be aware of is that there is some nastiness when you use the SEL_COMMAND from FXTextField to close the dialog using ID_ACCEPT. This is because the SEL_COMMAND may be generated when you're focusing out of the FXTextField into another widget, and this could cause the FXTextField to commit its value. The fix is to pass TEXTFIELD_ENTER_ONLY, which will stop FXTextField from issueing SEL_COMMAND due to focus-out. Most likely, however, this is not your problem here. > Note that I'm using the Ruby bindings. Is there a chance the problems > comes from here? Yes, indeed. It appears to have to do with the Ruby garbage collector; I believe Lyle was in the process of fixing this, however. I've bounced this mail to him to see if he's aware of any specifics. - Jeroen From philippe.lang at attiksystem.ch Wed Jan 31 16:23:04 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Wed, 31 Jan 2007 22:23:04 +0100 Subject: [fxruby-users] Backspace in an FXText does not generate a SEL_REPLACED event Message-ID: <6C0CF58A187DA5479245E0830AF84F421D177D@poweredge.attiksystem.ch> Hi, Backspace in an FXText does not generate a SEL_REPLACED event, although return, and all other keys do. Is that normal? Philippe Lang From jeroen at fox-toolkit.org Wed Jan 31 16:39:46 2007 From: jeroen at fox-toolkit.org (Jeroen van der Zijp) Date: Wed, 31 Jan 2007 15:39:46 -0600 Subject: [fxruby-users] Backspace in an FXText does not generate a SEL_REPLACED event In-Reply-To: <6C0CF58A187DA5479245E0830AF84F421D177D@poweredge.attiksystem.ch> References: <6C0CF58A187DA5479245E0830AF84F421D177D@poweredge.attiksystem.ch> Message-ID: <200701311539.46376.jeroen@fox-toolkit.org> On Wednesday 31 January 2007 15:23, Philippe Lang wrote: > Hi, > > Backspace in an FXText does not generate a SEL_REPLACED event, although > return, and all other keys do. Is that normal? You need to catch SEL_DELETED, SEL_INSERTED, and SEL_REPLACED; not just SEL_REPLACED only. FXText is going through a bit of an overhaul for 1.7, and I welcome any comments for improvements. - Jeroen