[ardour-dev] More Thoughts on TearOff

[Taybin Rutkin]

I think the reason it handles dragability is that it didn't always use to have window manager decorations.  We set it to UTILITY now, but at the time, the only way to drag it was to click in the unused space between widgets.

-----Original Message-----
>From: Brian Ahr <brianahr at gmail.com>
>Sent: Nov 17, 2006 2:18 AM
>To: Ardour-dev <ardour-dev at lists.ardour.org>
>Subject: [ardour-dev] More Thoughts on TearOff
>
>Hi all.
>I had a few thoughts on #1091, which I should have included in the last 
>email on the subject. So I thought I'd share them with you here.
>
>It looks like the problem is pretty much due to the TearOff widget 
>trying to handle its own dragability (is that a word?). Ie, it tries to 
>catch the button_pressed and button_released events and handles moving 
>itself manually. The patch for #1091 is more of a proof-of-concept, 
>demonstrating that the button_released signal isn't getting called 
>often. Its not fool-proof, because some of the widgets intercept the 
>button_released signal before it gets down to the TearOff 
>widget/panel/thing.
>
>Example: Detach the transport, right click on the rightmost AudioClock, 
>and select "off". The transport will be stuck to the mouse again, and 
>usually, your cursor will land on one of the buttons to the right there. 
>Now they intercept the button_released signal, and the TearOff widget 
>doesn't get it.
>
>I'm not 100% sure why the tearoff widget tries to manage "dragability". 
>Perhaps someone can explain this to me. It would seem that most window 
>managers will provide decorations (ie title bar, etc) to allow the user 
>to move the tearoff. Additionally, it seems that in order to completely 
>get rid of this problem, the "dragability" code in tearoff needs to be 
>removed. Included is a patch to remove that code, against r1137.
>
>~Brian