1) In my GUI, I have dialog boxes that have groups of widgets that I want to create once and hide/show depending on some conditions. The problem I am running into, is that fox/fxruby''s packer seems to be unaware of hide/show and it does not recalculate the window to fit the visible widgets appropiately. This results in windows that are either too wide or too small. FOX only seems to recalculate the layout if I do any of the following: a) Move the window. b) Call a dummy resize (but this also changes focus). I''ve tried to call layout() and recalc() but this does not work. Thus... the question is... how do I get Fox to update the layout of a window if I hide/unhide some frames without changing window focus? 2) FXRuby versioning. Is there a particular reason why each main fxruby release is given a new name for its require (we''ve had fox, fox12 and fox14 so far)? While I understand that there may be incompatabilities between releases, this sort of naming convention kind of goes against the grain of rubygems, where versioning is to be handled automatically upon require (not to mention it is a pain in the neck to have to change your code with each fox release, even if the new release didn''t change substantially the api). Could I suggest that with fox1.4 on, we revert back to just "require ''fox''" and let rubygems (or users'' ruby include path) handle the versioning? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/fxruby-users/attachments/20050829/1259bd59/attachment.htm
On Mon, 29 Aug 2005 10:54:21 -0300, Gonzalo Garramuno <ggarra@advancedsl.com.ar> wrote :> 1) In my GUI, I have dialog boxes that have groups of widgets that I wantto create once and hide/show depending on some conditions. The problem I am running into, is that fox/fxruby''s packer seems to be unaware of hide/show and it does not recalculate the window to fit the visible widgets appropiately. This results in windows that are either too wide or too small. FOX only seems to recalculate the layout if I do any of the following:> a) Move the window. > b) Call a dummy resize (but this also changes focus). > I''ve tried to call layout() and recalc() but this does not work. Thus...the question is... how do I get Fox to update the layout of a window if I hide/unhide some frames without changing window focus? Do I understand that you want the entire dialog box''s dimensions to grow (or shrink) to fit the visible contents? If so, I''m pretty sure that that will require a call to resize() on the dialog box itself, e.g. dialogBox.resize(dialogBox.defaultWidth, dialogBox.defaultHeight) Are you saying that this causes the window to lose focus?> 2) FXRuby versioning. Is there a particular reason why each main fxrubyrelease is given a new name for its require (we''ve had fox, fox12 and fox14 so far)? While I understand that there may be incompatabilities between releases, this sort of naming convention kind of goes against the grain of rubygems, where versioning is to be handled automatically upon require (not to mention it is a pain in the neck to have to change your code with each fox release, even if the new release didn''t change substantially the api). Could I suggest that with fox1.4 on, we revert back to just "require ''fox''" and let rubygems (or users'' ruby include path) handle the versioning? If everyone were using RubyGems, you''re correct that it would be appropriate to let the application dictate which version of FXRuby to require. The fact of the matter, however, is that a lot of people are *not* using FXRuby as a gem -- for proof, just look at the download statistics for the different packagings of FXRuby 1.2.6. Given the reality that a majority of people aren''t using gems yet, and that (as you already noted) there are often a number of incompatibilities between major releases of FXRuby, I think it makes more sense to stick with the established versioning approach.
> Do I understand that you want the entire dialog box''s dimensions to grow(or> shrink) to fit the visible contents? If so, I''m pretty sure that that will > require a call to resize() on the dialog box itself, e.g. > > dialogBox.resize(dialogBox.defaultWidth, dialogBox.defaultHeight) > > Are you saying that this causes the window to lose focus? >Correct. Doing this changes the focus to the resized window (and what''s more, I cannot even revert it back to the parent window that had the focus -- a MDI child window -- using setFocus. The focus just gets locked to the resized dialog box-- yuck). Seems to happen both on 1.2 and 1.4.> Given the reality that a majority of people aren''t using gems yet, andthat> (as you already noted) there are often a number of incompatibilitiesbetween> major releases of FXRuby, I think it makes more sense to stick with the > established versioning approach.Sorry, Lyle, but this makes little sense to me. If code remains compatible, it shouldn''t need change. With the current scheme, a user could have a valid fxruby version, yet previously written code will break... just because the require line is wrong! What''s worse, the coder writing for the current fxruby version cannot do anything on his side to prevent that from happening in the future, cause he doesn''t know what will the future name of fxruby be some years down the line. That means that pretty much *any* code I write with fxruby will break as soon as there is a new release. I''d argue strongly that to keep doing this is a very bad idea for a library. Imagine, if say, the C++ comittee were to follow this similar approach with all the STL include files. It would be a nightmare. This issue is the same if you are *not* using rubygems. If you are not using rubygems, and you *were* to run into compatability issues with a library (which is rare), you can deal with the issue just by adding/removing paths to ruby''s standard include path pointing to different versions of the library to handle any versioning issues with any of your modules (which you can easily do from $LOAD_PATH for just the offending code, or by changing an environment variable if the change is more general... this just becomes a simple sysadmin task, not a programming task that needs changing code). A programmer can also check the value of, say, fxrubyversion() to keep code compatible with multiple versions while things are in transition. All of these are things that one simply cannot do if you keep changing the name of the require on every release. If you want to keep a fox14 stub, that''s fine, but please just add a ''fox.rb'' that includes the proper fox14 or whatever on each release. That way, if you want to have code remain future compatible, you can just code: require ''fox'' while if you want to lock yourself to a particular version of fox, you can then code: require ''fox14'' This would be the equivalent of rubygems'': require_gem ''fox'' vs: require_gem ''fox'', ''1.4''