Re: [rox-devel] [ANN]: OroboROX 0.9.1

[Jonatan L. <th...@ho...>]

On Fri, 01 Oct 2004 20:35:33 +0000
Guido Schimmels <__g...@we...> wrote:

> Am 01.10.2004 19:31:38 schrieb(en) Jonatan Liljedahl:
> > On Fri, 01 Oct 2004 01:56:35 +0000
> > Guido Schimmels <__g...@we...> wrote:
> >
> > * Clicking on a window title (frame) should raise it!
> 
> 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.

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 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...)

> > * Ctrl-Alt-drag with button1 on a window should move it. (I think
> > the rule should be like this: Anything done inside a window while
> > holding Ctrl-Alt should do the same thing as if you did it on the
> > window titlebar!)
> > Now Ctrl-Alt-drag with button2 moves it, and with button1 resizes
> > it. At
> > least flip those and it would be somewhat more intuitive, IMHO. But
> > I still think it should follow the same settings as for titlebar.
> 
> Behaviour of Button2+Button3 is now all optional. Open up the GUI!

Yes, I have opened the Windows capplets. =) But there's no way to set
the options so that it behaves like 0.8.7.3.

> I changed it such that behaviour for those buttons is always the same 
> 
> for title+sides+(content+window_ops_modifier). Things would get out of
>  
> control if you differentiated here.
> 
> Button1 is different. Title is hardwired to "move". Sides are optional
>  
> handles for moving and resizing. window_op action follows the option  
> for the sides. You think for Button1 it should follow the title-bar  
> behaviour, so as to be hardwired to "move", right?
> What do other think?

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.
 
> > * In my version you was able to toggle _NET_WM_STATE_ABOVE with
> > mouse button2 on the titlebar's sticky-button, which I thought was
> > quite nice.
> > Not a big deal though,
> 
> Ok. I can re-implement this. But it could be a bit confusing if the  
> user triggers this accidentally, not knowing about this behaviour.  
> There is no visual clue for this state.

You have a point there. And since there already is a keyboard-shortcut
for it, I could live without this feature.

> > * I think you should rename the button names in the Windows capplet 
> > 
> > to
> > "Left, Middle, Right" or "1, 2, 3".. I think that "Menu-button" is a
> > somewhat strange name.
> 
> The problem is what happens when sinistrals like me have left and
> right  buttons switched? Therefore I went for "semantical" naming.
> Another  thing is that X's idea of what are button 2 and 3 are
> different from  mine. X counts from left to right. I thought
> scroll-wheel was button 3,  especially as button4+button5 are
> scroll-up/down. So this is all very  tricky. I'd like to know how
> Windows/Mac handle naming here.

Yes, but what is the "menu-button" ?? =)
My proposal: name them left, middle, right and then all of you who have
them switched will anyhow know that they are switched and will know that
"left" actually means your right button.

> > * I think it's bad to depend on ROX CVS to get the panel layer
> > right...
> > I use the last released ROX and the panels are always on top. Maybe
> > you
> > could have a toggle box in the settings to NOT keep DOCK-windows on
> > top?
> > (For compatibility with ROX's that doesn't use the ABOVE/BELOW stuff
> > on
> > the panels) [1]
> 
> I squirm a bit at the thought to add a work-around to OroboROX to work
> around a work-around in ROX-Filer for other broken window-managers.
> As this is still a pre 1.0 release I thought I could get away with  
> depending on CVS.

See my other posts about this, you can still depend on CVS but just
change the already present work-around (that checks for name "ROX-Panel"
and makes it DOCK) to only set non_focusable=True and it will work as
expected).
 

> > Otherwise everything seems to work fine! I can't find any other bugs
> > right now, which seems very promising. Nice work! =)
> > 
> > 
> > [1] I think it's strange that the latest rox-filer sets window type 
> > 
> > to
> > DOCK but doesn't use the BELOW hint to lower it, (since EWMH says  
> > that
> > docks always should be on top...)
> 
> Well it does set BELOW unless you select "Don't cover panels".
> Only when the mouse enters the panel, state BELOW is removed  
> temporarly, so it can be raised above all other windows. That's  
> perfectly in order. Nice work by Tony Houghton.

But that's CVS version, right? The latest official release of ROX
doesn't do this, at least not for me...
It doesn't set type to DOCK and it doesn't use BELOW. So I changed
OroboROX to at least make clients named "ROX-Panel" be non-focusable and
now it works (my GTK isn't compatible with ROX use of non-focusable, so
the panels are focusable at first...)


/Jonatan    -=( http://kymatica.com )=-