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
lyle@knology.net
2004-Jul-20 09:12 UTC
[fxruby-users] radiobuttons are weird in 1.2.x series
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=browseYes, 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
Lyle Johnson
2004-Jul-22 08:46 UTC
[fxruby-users] Re: FXRuby and Threads (was: radiobuttons are weird in 1.2.x series)
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.
Yuri Leikind
2004-Jul-22 12:03 UTC
[fxruby-users] Re: FXRuby and Threads (was: radiobuttons are weird in 1.2.x series)
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.