From: Kymatica <th...@ho...> - 2004-10-02 15:00:41
|
>> > This is now optional. Controlled by raise_on_click and >> raise_on_focus. > >> This was a request by Terry Blunt as it seems to be Risc OS > >behaviour. > >> I could change the defaults though. >=20 >> No, that's not the same thing. I don't want raise_on_click, as I want >> to >> be able to drag stuff from windows without raising them. But I want =20 >> to >> raise them when I click their windowtitle. If raise_on_click is off, >> Button1 should still raise&move windows when clicked on titlebar! >How >> else could you raise a window? (except that you could set button2 to >> raise, but it's not logical that button1 (which is the most used >> button) >> only moves without raising...) >Selecting raise_on_focus does the trick, no? >(be sure not to have selected Risc OS focus change.) No, it doesn't do the trick. I don't want raise on focus, I want focus foll= ows mouse with no auto-raising, and I want to be able to raise a window b= y clicking on the titlebar, but not when clicking inside the window. I th= ink this is a very standard behaviour with other WMs if you have focus-fo= llows-mouse and no-raise-on-click. (where "click" means inside the window= , not the titlebar, and that's my point) >> Yes, absolutely. It's allright if button1 is hardcoded for "move" but >> then it should be so also when using window_ops_modifier and clicking >> anywhere in a window, and not then suddenly mean "resize". That's > >strange behaviour. >It doesn't anything "suddenly". It does what you told it with the "Drag >Border:" option. You think the window_ops_modifier action should >follow >title-bar behaviour. I made it follow the left+right+bottom drag >option. Neither is per se more logical IMHO. I don't want to upset you, but I do think it's more logical if it followed = the title-bar behaviour. =3D) What do you other think? - K Y M A T I C A - ----------------------- http://kymatica.com |