Re: [ROOT] Grabby GUI, long running slots and cursors.

From: Fons Rademakers (Fons.Rademakers@cern.ch)
Date: Thu May 08 2003 - 19:44:02 MEST


Hi Brett,


On Mon, 2003-05-05 at 21:26, Brett Viren wrote:
> Hi,
> 
> Two issues related to signals in the TG GUI classes:
> 
> 1) Many GUI elements emit signals while the the pointer is grabbed.
> When a very time consuming slot is attached to such signals it has the
> effect of essentially locking out input from all other running X
> applications.  
> 
> I haven't done an exhaustive check, but at least for the GUI element
> that is giving me trouble (TGSlider) it looks like an easy fix would
> be to reverse the order of the:
> 
>       Released();
>  
>       gVirtualX->GrabPointer(0, 0, 0, 0, kFALSE);  // ungrab pointer
> 
> calls.
> 
> Note, in my test I found that I can call the ungrab myself inside
> Released() (in my subclass of TGSlider) but that alone doesn't
> actually ungrab the pointer.  A call to gVirtualX->Update() is needed.
> 
I've made the change for the sliders.

> 
> 2) This one is not as importatnt, but I think it would be a nice touch
> to temporarily change the cursor (say, to a clock face) just before
> any signal method is called so the user can get feedback that the app
> is busy.  Of course, this can be done inside the slot, but that would
> involve everyone doing it over an over for each slot, worrying about
> the order of slot calls, etc.
> 
This would cause a lot of cursor flicker for many short lasting slot
methods.

Better to set it when you know your slot is going to take a lot of time.

Cheers, Fons.


-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers@cern.ch              Phone: +41 22 7679248
WWW:    http://root.cern.ch/~rdm/            Fax:   +41 22 7679480



This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:11 MET