From: Matthew W. O'P. <mwe...@gm...> - 2005-06-06 18:40:17
|
I don't know why I haven't asked about this before, as I've noticed the behaviour for a long time now... This is with ROX-Filer >=3D 2.0.0 and OroboROX >=3D 0.9.6. When I choose 'Window|New Window' from the context menu of a filer (which I= have bound to the key 'W'), the new window opened opens in the upper left of the screen, not directly under the cursor as I would expect. Is this intentiona= l, or isolated to my own system? Any light Guido, Thomas, Jonatan, et.al could shed on the situation I'd appreciate -- and, of course, I'll be a willing guinea pig for any code cha= nges resulting from this request! --=20 Matthew Weier O'Phinney mwe...@gm... http://weierophinney.net/matthew/ |
From: Bungee <bu...@er...> - 2005-06-06 18:51:25
|
Matthew Weier O'Phinney <mwe...@gm...> wrote: > I don't know why I haven't asked about this before, as I've noticed the > behaviour for a long time now... > > This is with ROX-Filer >= 2.0.0 and OroboROX >= 0.9.6. > > When I choose 'Window|New Window' from the context menu of a filer (which I have > bound to the key 'W'), the new window opened opens in the upper left of the > screen, not directly under the cursor as I would expect. Is this intentional, or > isolated to my own system? > > Any light Guido, Thomas, Jonatan, et.al could shed on the situation I'd > appreciate -- and, of course, I'll be a willing guinea pig for any code changes > resulting from this request! I can't repeat this using ROX 2.2.0 and OrboROX 0.9.6-13. I don't have a key binding set, but a mouse click on Window>New Window opens it centered on the pointer as I would have expected. -- Bungee |
From: Matthew W. O'P. <mwe...@gm...> - 2005-06-06 18:58:53
|
On 6/6/05, Bungee <bu...@er...> wrote: > Matthew Weier O'Phinney <mwe...@gm...> wrote: > > I don't know why I haven't asked about this before, as I've noticed the > > behaviour for a long time now... > > > > This is with ROX-Filer >=3D 2.0.0 and OroboROX >=3D 0.9.6. > > > > When I choose 'Window|New Window' from the context menu of a filer (whi= ch I > > have bound to the key 'W'), the new window opened opens in the upper le= ft of > > the screen, not directly under the cursor as I would expect. Is this > > intentional, or isolated to my own system? > > > > Any light Guido, Thomas, Jonatan, et.al could shed on the situation I'd > > appreciate -- and, of course, I'll be a willing guinea pig for any code > > changes resulting from this request! >=20 > I can't repeat this using ROX 2.2.0 and OrboROX 0.9.6-13. >=20 > I don't have a key binding set, but a mouse click on Window>New Window op= ens > it centered on the pointer as I would have expected. Okay, I've done some experimentation and it's ONLY when I use the keyboard shortcut that this happens. Using the mouse, I get the correct behaviour. I= 'd like to have the behaviour when using the keypress to mimic that behaviour. --=20 Matthew Weier O'Phinney mwe...@gm... http://weierophinney.net/matthew/ |
From: Ken H. <ke...@ha...> - 2005-06-06 19:37:22
Attachments:
ken.vcf
|
Matthew Weier O'Phinney wrote: >On 6/6/05, Bungee <bu...@er...> wrote: > > >>Matthew Weier O'Phinney <mwe...@gm...> wrote: >> >> >>>I don't know why I haven't asked about this before, as I've noticed the >>>behaviour for a long time now... >>> >>>This is with ROX-Filer >= 2.0.0 and OroboROX >= 0.9.6. >>> >>>When I choose 'Window|New Window' from the context menu of a filer (which I >>>have bound to the key 'W'), the new window opened opens in the upper left of >>>the screen, not directly under the cursor as I would expect. Is this >>>intentional, or isolated to my own system? >>> >>>Any light Guido, Thomas, Jonatan, et.al could shed on the situation I'd >>>appreciate -- and, of course, I'll be a willing guinea pig for any code >>>changes resulting from this request! >>> >>> >>I can't repeat this using ROX 2.2.0 and OrboROX 0.9.6-13. >> >>I don't have a key binding set, but a mouse click on Window>New Window opens >>it centered on the pointer as I would have expected. >> >> > >Okay, I've done some experimentation and it's ONLY when I use the keyboard >shortcut that this happens. Using the mouse, I get the correct behaviour. I'd >like to have the behaviour when using the keypress to mimic that behaviour. > > Ditto. More annoying is that the mouse jumps to the close button of the newly created window. |
From: Bungee <bu...@er...> - 2005-06-06 20:14:03
|
Ken Hayber <ke...@ha...> wrote: > Matthew Weier O'Phinney wrote: > > >On 6/6/05, Bungee <bu...@er...> wrote: > > > > > >>Matthew Weier O'Phinney <mwe...@gm...> wrote: > >> > >> > >>>I don't know why I haven't asked about this before, as I've noticed the > >>>behaviour for a long time now... > >>> > >>>This is with ROX-Filer >= 2.0.0 and OroboROX >= 0.9.6. > >>> > >>>When I choose 'Window|New Window' from the context menu of a filer (which I > >>>have bound to the key 'W'), the new window opened opens in the upper left of > >>>the screen, not directly under the cursor as I would expect. Is this > >>>intentional, or isolated to my own system? > >>> > >>>Any light Guido, Thomas, Jonatan, et.al could shed on the situation I'd > >>>appreciate -- and, of course, I'll be a willing guinea pig for any code > >>>changes resulting from this request! > >>> > >>> > >>I can't repeat this using ROX 2.2.0 and OrboROX 0.9.6-13. > >> > >>I don't have a key binding set, but a mouse click on Window>New Window opens > >>it centered on the pointer as I would have expected. > >> > >> > > > >Okay, I've done some experimentation and it's ONLY when I use the keyboard > >shortcut that this happens. Using the mouse, I get the correct behaviour. I'd > >like to have the behaviour when using the keypress to mimic that behaviour. > > > > > Ditto. More annoying is that the mouse jumps to the close button of the > newly created window. Just done a few checks myself having set up <shift>W for this action, and can confirm the results. However, the mouse pointer goes to the top LH corner of the active area of the window regardless of which icon is there. Also the effect is exactly the same with kwin (KDE) as the window manager. Therefore I assume it is in fact a ROX filer issue not an OroboROX one. -- Bungee |
From: Matthew W. O'P. <mwe...@gm...> - 2005-06-06 20:32:47
|
On 6/6/05, Bungee <bu...@er...> wrote: > Ken Hayber <ke...@ha...> wrote: > > Matthew Weier O'Phinney wrote: > > > On 6/6/05, Bungee <bu...@er...> wrote: > > > > Matthew Weier O'Phinney <mwe...@gm...> wrote: > > > > > I don't know why I haven't asked about this before, as I've notic= ed > > > > > the behaviour for a long time now... > > > > > > > > > > This is with ROX-Filer > =3D 2.0.0 and OroboROX > =3D 0.9.6. > > > > > > > > > > When I choose 'Window|New Window' from the context menu of a file= r > > > > > (which I have bound to the key 'W'), the new window opened opens = in > > > > > the upper left of the screen, not directly under the cursor as I = would > > > > > expect. Is this intentional, or isolated to my own system? > > > > > > > > > > Any light Guido, Thomas, Jonatan, et.al could shed on the situati= on > > > > > I'd appreciate -- and, of course, I'll be a willing guinea pig fo= r any > > > > > code changes resulting from this request! > > > > > > > > > I can't repeat this using ROX 2.2.0 and OrboROX 0.9.6-13. > > > > > > > > I don't have a key binding set, but a mouse click on Window> New Wi= ndow > > > > opens it centered on the pointer as I would have expected. > > > > > > Okay, I've done some experimentation and it's ONLY when I use the key= board > > > shortcut that this happens. Using the mouse, I get the correct behavi= our. > > > I'd like to have the behaviour when using the keypress to mimic that > > > behaviour. > > > > > Ditto. More annoying is that the mouse jumps to the close button of th= e > > newly created window. >=20 > Just done a few checks myself having set up <shift> W for this action, an= d can > confirm the results. However, the mouse pointer goes to the top LH corner= of > the active area of the window regardless of which icon is there.=20 I'll confirm that -- it goes to the top LH corner of the window for me as w= ell -- I wonder if what Ken's seeing (over the close button) has to do with the= icon theme and/or window decorations he's using? > Also the effect is exactly the same with kwin (KDE) as the window manager= . > Therefore I assume it is in fact a ROX filer issue not an OroboROX one. My initial assumption was that it was a ROX bug, but since it had to do wit= h window placement and I couldn't remember if I'd seen it with XFWM, I began = to think it might be WM specific. Good sleuthing! Could a different WM hint be being set based on if the action is selected v= ia mouse vs. keystroke? --=20 Matthew Weier O'Phinney mwe...@gm... http://weierophinney.net/matthew/ |
From: Ken H. <ke...@ha...> - 2005-06-07 02:18:43
Attachments:
ken.vcf
|
Matthew Weier O'Phinney wrote: >On 6/6/05, Bungee <bu...@er...> wrote: > > >>Ken Hayber <ke...@ha...> wrote: >> >> >>>Matthew Weier O'Phinney wrote: >>> >>> >>>>On 6/6/05, Bungee <bu...@er...> wrote: >>>> >>>> >>>>>Matthew Weier O'Phinney <mwe...@gm...> wrote: >>>>> >>>>> >>>>>>I don't know why I haven't asked about this before, as I've noticed >>>>>>the behaviour for a long time now... >>>>>> >>>>>>This is with ROX-Filer > = 2.0.0 and OroboROX > = 0.9.6. >>>>>> >>>>>>When I choose 'Window|New Window' from the context menu of a filer >>>>>>(which I have bound to the key 'W'), the new window opened opens in >>>>>>the upper left of the screen, not directly under the cursor as I would >>>>>>expect. Is this intentional, or isolated to my own system? >>>>>> >>>>>>Any light Guido, Thomas, Jonatan, et.al could shed on the situation >>>>>>I'd appreciate -- and, of course, I'll be a willing guinea pig for any >>>>>>code changes resulting from this request! >>>>>> >>>>>> >>>>>> >>>>>I can't repeat this using ROX 2.2.0 and OrboROX 0.9.6-13. >>>>> >>>>>I don't have a key binding set, but a mouse click on Window> New Window >>>>>opens it centered on the pointer as I would have expected. >>>>> >>>>> >>>>Okay, I've done some experimentation and it's ONLY when I use the keyboard >>>>shortcut that this happens. Using the mouse, I get the correct behaviour. >>>>I'd like to have the behaviour when using the keypress to mimic that >>>>behaviour. >>>> >>>> >>>> >>>Ditto. More annoying is that the mouse jumps to the close button of the >>>newly created window. >>> >>> >>Just done a few checks myself having set up <shift> W for this action, and can >>confirm the results. However, the mouse pointer goes to the top LH corner of >>the active area of the window regardless of which icon is there. >> >> > >I'll confirm that -- it goes to the top LH corner of the window for me as well >-- I wonder if what Ken's seeing (over the close button) has to do with the icon >theme and/or window decorations he's using? > > Just to be clear, I meant the ROX-Filer close button. Not the WM close button. The one to the left of the Up arrow. I guess not everyone has that one enabled or you are indeed seeing something a bit different than I am. For me the pointer is pretty much exactly centered over than button. |
From: Matthew W. O'P. <mwe...@gm...> - 2005-06-13 15:50:40
|
On 6/6/05, Matthew Weier O'Phinney <mwe...@gm...> wrote: > I don't know why I haven't asked about this before, as I've noticed the > behaviour for a long time now... >=20 > This is with ROX-Filer >=3D 2.0.0 and OroboROX >=3D 0.9.6. >=20 > When I choose 'Window|New Window' from the context menu of a filer (which= I > have bound to the key 'W'), the new window opened opens in the upper left= of > the screen, not directly under the cursor as I would expect. Is this > intentional, or isolated to my own system? >=20 > Any light Guido, Thomas, Jonatan, et.al could shed on the situation I'd > appreciate -- and, of course, I'll be a willing guinea pig for any code > changes resulting from this request! I found the offending piece of code. It's in filer.c -- I didn't produce a = diff, as I was working off an old CVS version. Basically, in filer_window_set_siz= e(), there was a section of code at the end that was to do some pointer warping = if the window was opened from a key event. It starts as: if (event && event-type =3D=3D GDK_KEY_PRESS) I found that by commenting out that conditional area (the if statement and = the code to execute on the condition), the behaviour is then correct.=20 I'll see if I can create a patch later off of current CVS. --=20 Matthew Weier O'Phinney mwe...@gm... http://weierophinney.net/matthew/ |
From: Matthew W. O'P. <mwe...@gm...> - 2005-06-14 01:56:26
Attachments:
filer.diff
|
On 6/13/05, Matthew Weier O'Phinney <mwe...@gm...> wrote: > On 6/6/05, Matthew Weier O'Phinney <mwe...@gm...> wrote: > > I don't know why I haven't asked about this before, as I've noticed the > > behaviour for a long time now... > > > > This is with ROX-Filer >=3D 2.0.0 and OroboROX >=3D 0.9.6. > > > > When I choose 'Window|New Window' from the context menu of a filer (whi= ch I > > have bound to the key 'W'), the new window opened opens in the upper le= ft of > > the screen, not directly under the cursor as I would expect. Is this > > intentional, or isolated to my own system? > > > > Any light Guido, Thomas, Jonatan, et.al could shed on the situation I'd > > appreciate -- and, of course, I'll be a willing guinea pig for any code > > changes resulting from this request! >=20 > I found the offending piece of code. It's in filer.c -- I didn't produce = a > diff, as I was working off an old CVS version. Basically, in > filer_window_set_size(), there was a section of code at the end that was = to do > some pointer warping if the window was opened from a key event. It starts= as: >=20 > if (event && event-type =3D=3D GDK_KEY_PRESS) >=20 > I found that by commenting out that conditional area (the if statement an= d the > code to execute on the condition), the behaviour is then correct. >=20 > I'll see if I can create a patch later off of current CVS. The patch is attached; it simply comments out the area that causes the unde= sired behaviour. I'll leave it as an exercise for somebody else to figure out why= that section of code causes problems (somebody with more knowledge of C than myself!). --=20 Matthew Weier O'Phinney mwe...@gm... http://weierophinney.net/matthew/ |
From: Kacper W. <ka...@on...> - 2005-06-15 00:23:05
|
On 06/13/05 21:56:22, Matthew Weier O'Phinney wrote: > The patch is attached; it simply comments out the area that causes =20 > the undesired behaviour. I'll leave it as an exercise for somebody =20 > else to figure out why that section of code causes problems =20 > (somebody with more knowledge of C than myself!). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /cvsroot/rox/rox/ROX-Filer/src/filer.c,v > retrieving revision 1.360 > diff -r1.360 filer.c > 299a300 > > /* > 321a323 > > */ A unified diff with some context would probably make the devs more =20 inclined to take a look at the problem. -K |