Re: [E-devel] e-16.8 cvs bug: slightly broken focus behavior
On Saturday 09 July 2005 11:44 am, Kim Woelders wrote: Mike Frysinger wrote: On Tuesday 05 July 2005 07:56 pm, Tres Melton wrote: On Tue, 2005-07-05 at 19:05 -0400, Mike Frysinger wrote: i prefer to use the 'focus follows mouse click' behavior but ive noticed a quirk in using mouse bindings with it ... for example, say i have two windows open, Eterm and Gimp ... Eterm currently has the focus (it gets key strokes, uses the window border has the 'active' color, and is on top) ... if i alt+left click the Gimp window to move it around, it is raised to the top most level, but it is not set as active (Eterm still receives my key strokes and the window border has the 'active' color) ... as soon as i just left click Gimp (no keyboard modifiers), it is properly set as the active window I believe kwo is still out till the end of the week but he may be checking his email. What are you saying you would like the behavior to be? An Alt+Left-click: alt+left click was an example ... i'm saying that any click/mouse behavior should raise focus the window, regardless of whether there was a key modifier in use or not This should be fixed now. just synced up and still experiencing the issue originally described :/ -mike --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e-16.8 cvs bug: slightly broken focus behavior
On Sunday 10 July 2005 12:19 pm, Mike Frysinger wrote: just synced up and still experiencing the issue originally described :/ err nm, as kwo pointed out, the checkout tree i was using was out of date all works now, thanks :) -mike --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e-16.8 cvs bug: slightly broken focus behavior
Mike Frysinger wrote: On Tuesday 05 July 2005 07:56 pm, Tres Melton wrote: On Tue, 2005-07-05 at 19:05 -0400, Mike Frysinger wrote: i prefer to use the 'focus follows mouse click' behavior but ive noticed a quirk in using mouse bindings with it ... for example, say i have two windows open, Eterm and Gimp ... Eterm currently has the focus (it gets key strokes, uses the window border has the 'active' color, and is on top) ... if i alt+left click the Gimp window to move it around, it is raised to the top most level, but it is not set as active (Eterm still receives my key strokes and the window border has the 'active' color) ... as soon as i just left click Gimp (no keyboard modifiers), it is properly set as the active window I believe kwo is still out till the end of the week but he may be checking his email. What are you saying you would like the behavior to be? An Alt+Left-click: alt+left click was an example ... i'm saying that any click/mouse behavior should raise focus the window, regardless of whether there was a key modifier in use or not -mike This should be fixed now. /Kim --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e-16.8 cvs bug: slightly broken focus behavior
i prefer to use the 'focus follows mouse click' behavior but ive noticed a quirk in using mouse bindings with it ... for example, say i have two windows open, Eterm and Gimp ... Eterm currently has the focus (it gets key strokes, uses the window border has the 'active' color, and is on top) ... if i alt+left click the Gimp window to move it around, it is raised to the top most level, but it is not set as active (Eterm still receives my key strokes and the window border has the 'active' color) ... as soon as i just left click Gimp (no keyboard modifiers), it is properly set as the active window -mike --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e-16.8 cvs bug: slightly broken focus behavior
On Tue, 2005-07-05 at 19:05 -0400, Mike Frysinger wrote: i prefer to use the 'focus follows mouse click' behavior but ive noticed a quirk in using mouse bindings with it ... for example, say i have two windows open, Eterm and Gimp ... Eterm currently has the focus (it gets key strokes, uses the window border has the 'active' color, and is on top) ... if i alt+left click the Gimp window to move it around, it is raised to the top most level, but it is not set as active (Eterm still receives my key strokes and the window border has the 'active' color) ... as soon as i just left click Gimp (no keyboard modifiers), it is properly set as the active window -mike I believe kwo is still out till the end of the week but he may be checking his email. What are you saying you would like the behavior to be? An Alt+Left-click: 1) raises and focuses the window for movement. 2) moves the window without bringing it to the top. Personally I prefer focus follows mouse (sloppily) but I really like the ability to have a window focused without bringing it to the top. If you were to choose option 1 then that would be impossible (except maybe w/ Alt-Tab selection??). If you prefer option 2 then I'll look into xlib and see what that entails. Either way I'll probably wait for kwo to weigh in on the way it is supposed to work. We might need to add an additional option to dis/enable that behavior. What if you push Alt, press the left button, and release the Alt. Should the window still be movable until you release the left button or should the movement be aborted? In light of the last issue you posted and the way that kwo patched it I would have to guess that movement stops with either Alt-key-release OR Left-button-up. Would you agree? This all relates to the grab-keyboard/mouse stuff in the main event loop. -- Tres --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e-16.8 cvs bug: slightly broken focus behavior
On Tuesday 05 July 2005 07:56 pm, Tres Melton wrote: On Tue, 2005-07-05 at 19:05 -0400, Mike Frysinger wrote: i prefer to use the 'focus follows mouse click' behavior but ive noticed a quirk in using mouse bindings with it ... for example, say i have two windows open, Eterm and Gimp ... Eterm currently has the focus (it gets key strokes, uses the window border has the 'active' color, and is on top) ... if i alt+left click the Gimp window to move it around, it is raised to the top most level, but it is not set as active (Eterm still receives my key strokes and the window border has the 'active' color) ... as soon as i just left click Gimp (no keyboard modifiers), it is properly set as the active window I believe kwo is still out till the end of the week but he may be checking his email. What are you saying you would like the behavior to be? An Alt+Left-click: alt+left click was an example ... i'm saying that any click/mouse behavior should raise focus the window, regardless of whether there was a key modifier in use or not -mike --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
