fxruby users - Jul 2004 - radiobuttons are weird in 1.2.x series

Hello all,

Run groupbox.rb example in any of the two alpha versions and
click the radiobutton in the upper right group box (those named Hilvesum 1,
Hilversum 2, etc). You''ll notice that once a radiobutton is checked, 
it remains checked when some other radiobutton is checked.

What''s the reason?

Thank you.

-- 
Best regards,
Yuri Leikind

On Tue, 20 Jul 2004 13:08:03 +0300, Yuri Leikind
<y.leikind@sam-solutions.net> wrote :
> Run groupbox.rb example in any of the two alpha versions and
> click the radiobutton in the upper right group box (those named Hilvesum 1,
> Hilversum 2, etc). You''ll notice that once a radiobutton is
checked,
> it remains checked when some other radiobutton is checked.
> 
> What''s the reason?
Sounds like a bug in that example; the radio button behavior has changed in
FOX 1.2. If you could, please file a bug report here:

    http://rubyforge.org/tracker/?atid=1223&group_id=300&func=browse

Thanks,

Lyle

On 20 Jul 2004 13:09:55 -0000
"lyle@knology.net" <lyle@knology.net> wrote:
>      
>      On Tue, 20 Jul 2004 13:08:03 +0300, Yuri Leikind
>      <y.leikind@sam-solutions.net> wrote :
>      
>      > Run groupbox.rb example in any of the two alpha versions and
>      > click the radiobutton in the upper right group box (those named
Hilvesum 1,
>      > Hilversum 2, etc). You''ll notice that once a radiobutton
is checked,
>      > it remains checked when some other radiobutton is checked.
>      > 
>      > What''s the reason?
>      
>      Sounds like a bug in that example; the radio button behavior has
changed in
>      FOX 1.2. If you could, please file a bug report here:
>      
>         
http://rubyforge.org/tracker/?atid=1223&group_id=300&func=browse
Yes, I was already prompted by Rich Lyman that GroupBox does not group
RadioButtons any more,
and I rewrote my radiobuttons code to use FXDataTarget. With an FXDataTarget
object
my radiobuttons work, but they are redrawn very slowly - a radiobutton is
unchecked after
a whole second after another was checked. I took a look at datatarget.rb and
found out the following:

  # Current threads implementation causes problems for this example, so disable
  application.threadsEnabled = false

With this code radiobuttons work well, but it disables threads. Since
there''s no more GroupBox
magic, threaded FXRuby applications are now doomed to have slow radiobuttons if
they use
 FXDataTarget objects. 


-- 
Best regards,
Yuri Leikind

*********** REPLY SEPARATOR  ***********

On 21/07/2004 at 11:30 Yuri Leikind wrote:
>On 20 Jul 2004 13:09:55 -0000
>"lyle@knology.net" <lyle@knology.net> wrote:
>
>>      
>>      On Tue, 20 Jul 2004 13:08:03 +0300, Yuri Leikind
>>      <y.leikind@sam-solutions.net> wrote :
>>      
>>      > Run groupbox.rb example in any of the two alpha versions and
>>      > click the radiobutton in the upper right group box (those
named
>Hilvesum 1,
>>      > Hilversum 2, etc). You''ll notice that once a
radiobutton is
>checked, 
>>      > it remains checked when some other radiobutton is checked.
>>      > 
>>      > What''s the reason?
>>      
>>      Sounds like a bug in that example; the radio button behavior has
>changed in
>>      FOX 1.2. If you could, please file a bug report here:
>>      
>>         
http://rubyforge.org/tracker/?atid=1223&group_id=300&func=browse
>
>Yes, I was already prompted by Rich Lyman that GroupBox does not group
>RadioButtons any more, 
>and I rewrote my radiobuttons code to use FXDataTarget. With an
>FXDataTarget object
>my radiobuttons work, but they are redrawn very slowly - a radiobutton is
>unchecked after
>a whole second after another was checked. I took a look at datatarget.rb
>and found out the following:
>
>  # Current threads implementation causes problems for this example, so
>disable
>  application.threadsEnabled = false
>
>With this code radiobuttons work well, but it disables threads. Since
>there''s no more GroupBox
>magic, threaded FXRuby applications are now doomed to have slow
>radiobuttons if they use
> FXDataTarget objects. 
>
I''ve had the same problem with data targets, and fixed them by
disabling threads as you have (win2k/Ruby1.8.1/FXRuby1.0.28). I''m not
sure, though, what exactly is disabled by this action. A client/server
application of mine uses Ruby threads and synchonises with these threads using
app.addTimeout (maybe not the best method, but fine for me). It seems to work
fine without "threads"? I couldn''t find any documentation as
to what is actually affected.

bil

On Jul 21, 2004, at 5:21 AM, Bil wrote:
> I''ve had the same problem with data targets, and fixed them by 
> disabling threads as you have (win2k/Ruby1.8.1/FXRuby1.0.28). I''m
not
> sure, though, what exactly is disabled by this action. A client/server 
> application of mine uses Ruby threads and synchonises with these 
> threads using app.addTimeout (maybe not the best method, but fine for 
> me). It seems to work fine without "threads"? I couldn''t
find any
> documentation as to what is actually affected.
The basic problem is that there''s a conflict between FOX''s
event loop,
which wants to be in charge, and Ruby''s thread scheduler, which also 
wants to be in charge. In order to avoid changing either Ruby''s or 
FOX''s source code, we''ve made a compromise which
isn''t great but is the
best I could come up with.

When FXRuby''s support for Ruby threads is enabled, a special background
chore [1] is kicked off. That chore causes the FOX event loop to yield 
some small amount of time to Ruby''s thread scheduler every so often, so
as to let other threads in the application run. The side effect is that 
some of that free time that FOX would have used, say, to update your 
data targets, is now being "stolen" by other threads.

Now, if FXRuby''s support for Ruby threads is disabled, FOX is greedy 
and never lets any of the other threads run. So I''m a little suspicious
when you say that your client-server application''s other threads are 
able to run after you''ve called FXApp#disableThreads. Maybe something 
has changed in Ruby''s threads implementation recently?

Lyle

[1] A chore is a task that runs during idle time in the FOX event loop.

On Thu, 22 Jul 2004 07:46:22 -0500
Lyle Johnson <lyle@knology.net> wrote:
>      Now, if FXRuby''s support for Ruby threads is disabled, FOX is
greedy
>      and never lets any of the other threads run. So I''m a little
suspicious
>      when you say that your client-server application''s other
threads are
>      able to run after you''ve called FXApp#disableThreads. Maybe
something
>      has changed in Ruby''s threads implementation recently?
As for my application, calling  FXApp#disableThreads really doesn''t
allow my threads
run, and I run Ruby 1.8.1 (standard Debian testing package).

Anyway, as far as radiobuttons are concerned, FXDataTarget is way cool, but
one can simply do something like this:

            current_radiobutton.connect(SEL_COMMAND){
                all_radiobuttons.reject{|r| 
                    r == current_radiobutton
                }.each {|r|
                    r.checkState = false
                }
            }

and though it''s not so nice as an FXDataTarget, it solves the problem
in a threaded application.

-- 
Best regards,
Yuri Leikind

I replied to this, but it went to the sender instead of to the group. 
(Did that change on fxruby-users when it moved to rubyforge?)

Yuri Leikind wrote:
> On Thu, 22 Jul 2004 07:46:22 -0500
> Lyle Johnson <lyle@knology.net> wrote:
> 
> 
>>     Now, if FXRuby''s support for Ruby threads is disabled, FOX
is greedy
>>     and never lets any of the other threads run. So I''m a
little suspicious
>>     when you say that your client-server application''s other
threads are
>>     able to run after you''ve called FXApp#disableThreads.
Maybe something
>>     has changed in Ruby''s threads implementation recently?
> 
> 
> As for my application, calling  FXApp#disableThreads really
doesn''t allow my threads
> run, and I run Ruby 1.8.1 (standard Debian testing package).
> 
> Anyway, as far as radiobuttons are concerned, FXDataTarget is way cool, but
> one can simply do something like this:
> 
>             current_radiobutton.connect(SEL_COMMAND){
>                 all_radiobuttons.reject{|r| 
>                     r == current_radiobutton
>                 }.each {|r|
>                     r.checkState = false
>                 }
>             }
> 
> and though it''s not so nice as an FXDataTarget, it solves the
problem in a threaded application.
> 
One alternative which uses direct manipulation of state, as in the 
snippet above, but which has the elegance of FXDataTarget, is in my 
FoxTails lib:

http://redshift.sourceforge.net/foxtails/

Basically, you associate radio and check buttons (and other widgets) 
with ruby object attributes, and the values update as soon as the attrs 
are assigned to (and always reflect the state of the attrs).

See examples/simple.rb for some check and radio buttons.

I''m sorry to say, though, that the docs are weak on foxtails, and I 
haven''t tried it with fox 1.2.

On Jul 23, 2004, at 6:01 PM, Joel VanderWerf wrote:
> I replied to this, but it went to the sender instead of to the group. 
> (Did that change on fxruby-users when it moved to rubyforge?)
Whoops, yes. The default MailMan setting is to reply to the poster 
(sender). Just changed this to reply-to-group.