[fxruby-users] Two questions...
ggarra at advancedsl.com.ar
Mon Aug 29 14:06:41 EDT 2005
> Do I understand that you want the entire dialog box's dimensions to grow
> 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, and
> (as you already noted) there are often a number of incompatibilities
> 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
while if you want to lock yourself to a particular version of fox, you can
This would be the equivalent of rubygems':
require_gem 'fox', '1.4'
More information about the fxruby-users