Cannot move window by dragging titlebar and using e.g. Ctrl+1 shortcut about inappstorewindow HOT 13 CLOSED

I can't replicate this behaviour on any window (regular windows, e.g. Safari). Is there some sort of setting you need to change to enable these shortcuts?

from inappstorewindow.

Check out the Keyboard system preferences and you should see the shortcuts
there, albeit unchecked by default (my fault, I thought they were enabled
by default). Check the boxes and then you should be able to repro.

Specifically, it looks like if the mouse interaction is mousedowned on a
view added to the titlebar, then the behavior will be abnormal. If the
mousedown is on the empty space in the titlebar, it seems to work fine.

On Thu, Oct 11, 2012 at 9:26 PM, Indragie Karunaratne <
[email protected]> wrote:

I can't replicate this behaviour on any window (regular windows, e.g.
Safari). Is there some sort of setting you need to change to enable these
shortcuts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/71#issuecomment-9364015.

from inappstorewindow.

Did some quick testing and this seems to be the standard, expected behaviour for all OS X windows (e.g. try clicking down on a toolbar button in Safari and using the shortcut, the space will change but the window won't move). Maybe I'm misunderstanding the issue

from inappstorewindow.

Yeah, I think views that handle mouse events themselves, the behavior
you're seeing makes sense. I should have clarified I was seeing the
abnormal behavior on views that wouldn't normally handle the mouse events.

E.g. In Xcode, if you drag the window by mousedowning on the blue status
LCD-like thing in the center of the titlebar, you can still take the window
to another space.

I'm new to Cocoa, so perhaps I'm making a simple mistake. I'm putting a
logo in the titlebar by making a xib for the titlebar, setting that view's
frame to the entire titlebar, and sticking a centered NSImageView as a
child. What ends up happening is I can't use this drag-and-move-to-space
interaction because my titleView spans the entire titlebar and is
conflicting with the normal behavior. If I temporarily comment out the
adding of my titleView ot the titlebar, then my empty titlebar works as
normal (can drag-and-move-to-space).

Thanks for the quick responses, BTW.

On Thu, Oct 11, 2012 at 9:38 PM, Indragie Karunaratne <
[email protected]> wrote:

Did some quick testing and this seems to be the standard, expected
behaviour for all OS X windows (e.g. try clicking down on a toolbar button
in Safari and using the shortcut, the space will change but the window
won't move). Maybe I'm misunderstanding the issue

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/71#issuecomment-9364181.

from inappstorewindow.

The behaviour you're seeing is an issue with NSImageView, which traps your mouse down events and doesn't pass them on to the superview. I don't really know the reason for this behaviour, but a quick fix would be to subclass NSImageView and override -hitTest: to return self like so:

- (NSView *)hitTest:(NSPoint)aPoint
{
    return self;
}

Let me know if it works :)

from inappstorewindow.

Should mention, you should add that code to whatever view is actually trapping the mouse events. If you're overriding -mouseDown: in your title view class, you should be calling [super mouseDown:theEvent]; in order to pass the mouse event down the responder chain.

from inappstorewindow.

Hmm, I'll play around with that, but not sure that's the problem.

I can still drag the window around fine by clicking-and-dragging anywhere
in my titlebar (including the NSImageView), which would lead me to believe
that the mouse events are reaching INAppStoreWindow. It just doesn't move
with me to the future Space when I tap e.g. ctrl+3 while my mouse is still
down.

FWIW, I found some weirdness with the sample app as well. If you initiate
the drag from the bottom ~10px of the fat titlebar in the sample app, it
won't work. But if initiating the drag from above the bottom ~10px, it
works fine ("it" meaning the interaction to bring the window with you to
the new Space you switch to.)

On Thu, Oct 11, 2012 at 9:51 PM, Indragie Karunaratne <
[email protected]> wrote:

Should mention, you should add that code to whatever view is actually
trapping the mouse events. If you're overriding -mouseDown: in your title
view class, you should be calling [super mouseDown:theEvent]; in order to
pass the mouse event down the responder chain.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/71#issuecomment-9364366.

from inappstorewindow.

Ah, I know what the issue is. Basically, OS X will only provide native dragging functionality for the height of the actual system title bar (which is 22px). For the remaining height of the bar that exceeds the height of the normal title bar, we have a custom window dragging implementation that simply handles dragging the window around, but doesn't process shortcuts like these. I'll have to play around and see if I can get it to extend native dragging functionality to the entire height of the title bar without us having to do a hacky custom implementation

from inappstorewindow.

Alright, been poking around for a couple of hours and found some useful
info that might be helpful to you:

• setMovableByWindowBackground is the missing piece of the puzzle. In the
  sample app, a quick test of setting it to true before the tight loop to
  handle drag events and setting it to false after the loop resulted in even
  the bottom ~10px acting normal (i.e. working with the
  drag-and-move-to-space interaction)
• NSControl return NO from mouseDownCanMoveWindow by default. In my case,
  I needed to return YES from the NSImageView, so I subclassed
• Since my app's content view spans the entire window (except titlebar), I
  could get away with always setting movableByWindowBackground to YES. This
  coupled with the second bullet above fixes my problems.

On Thu, Oct 11, 2012 at 10:11 PM, Indragie Karunaratne <
[email protected]> wrote:

Ah, I know what the issue is. Basically, OS X will only provide native
dragging functionality for the height of the actual system title bar (which
is 22px). For the remaining height of the bar that exceeds the height of
the normal title bar, we have a custom window dragging implementation that
simply handles dragging the window around, but doesn't process shortcuts
like these. I'll have to play around and see if I can get it to extend
native dragging functionality to the entire height of the title bar without
us having to do a hacky custom implementation

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/71#issuecomment-9364627.

from inappstorewindow.

Yep, the hack we're using to replicate window dragging only comes into effect when movableByWindowBackground is NO. When it's set to YES, the dragging area covers the entire window (instead of just the 22px title bar section) so the problem isn't there. I'll need to look into a better solution.

On Thursday, 11 October, 2012 at 9:50 PM, jasonparekh wrote:

Alright, been poking around for a couple of hours and found some useful
info that might be helpful to you:

• setMovableByWindowBackground is the missing piece of the puzzle. In the
  sample app, a quick test of setting it to true before the tight loop to
  handle drag events and setting it to false after the loop resulted in even
  the bottom ~10px acting normal (i.e. working with the
  drag-and-move-to-space interaction)
• NSControl return NO from mouseDownCanMoveWindow by default. In my case,
  I needed to return YES from the NSImageView, so I subclassed
• Since my app's content view spans the entire window (except titlebar), I
  could get away with always setting movableByWindowBackground to YES. This
  coupled with the second bullet above fixes my problems.

On Thu, Oct 11, 2012 at 10:11 PM, Indragie Karunaratne <
[email protected] (mailto:[email protected])> wrote:

Ah, I know what the issue is. Basically, OS X will only provide native
dragging functionality for the height of the actual system title bar (which
is 22px). For the remaining height of the bar that exceeds the height of
the normal title bar, we have a custom window dragging implementation that
simply handles dragging the window around, but doesn't process shortcuts
like these. I'll have to play around and see if I can get it to extend
native dragging functionality to the entire height of the title bar without
us having to do a hacky custom implementation

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/71#issuecomment-9364627.

—
Reply to this email directly or view it on GitHub (#71 (comment)).

from inappstorewindow.

Yeah, for my app I just forced it to always be movableByWindowBackground.

But, I think a general fix (which appears to work with the sample app) is
to set movableByWindowBackground to YES during the duration of the drag,
and reset to previous value after the mouseUp. Specifically, set to YES
before the while-loop at
https://github.com/indragiek/INAppStoreWindow/blob/master/INAppStoreWindow.m#L289and
set to previous value after that while-loop.

On Sat, Oct 13, 2012 at 12:39 AM, Indragie Karunaratne <
[email protected]> wrote:

Yep, the hack we're using to replicate window dragging only comes into
effect when movableByWindowBackground is NO. When it's set to YES, the
dragging area covers the entire window (instead of just the 22px title bar
section) so the problem isn't there. I'll need to look into a better
solution.

On Thursday, 11 October, 2012 at 9:50 PM, jasonparekh wrote:

Alright, been poking around for a couple of hours and found some useful
info that might be helpful to you:

• setMovableByWindowBackground is the missing piece of the puzzle. In
  the
  sample app, a quick test of setting it to true before the tight loop to
  handle drag events and setting it to false after the loop resulted in
  even
  the bottom ~10px acting normal (i.e. working with the
  drag-and-move-to-space interaction)
• NSControl return NO from mouseDownCanMoveWindow by default. In my
  case,
  I needed to return YES from the NSImageView, so I subclassed
• Since my app's content view spans the entire window (except titlebar),
  I
  could get away with always setting movableByWindowBackground to YES.
  This
  coupled with the second bullet above fixes my problems.

On Thu, Oct 11, 2012 at 10:11 PM, Indragie Karunaratne <
[email protected] (mailto:[email protected])> wrote:

Ah, I know what the issue is. Basically, OS X will only provide native
dragging functionality for the height of the actual system title bar
(which
is 22px). For the remaining height of the bar that exceeds the height
of
the normal title bar, we have a custom window dragging implementation
that
simply handles dragging the window around, but doesn't process
shortcuts
like these. I'll have to play around and see if I can get it to extend
native dragging functionality to the entire height of the title bar
without
us having to do a hacky custom implementation

—
Reply to this email directly or view it on GitHub<
https://github.com/indragiek/INAppStoreWindow/issues/71#issuecomment-9364627>.

—
Reply to this email directly or view it on GitHub (
#71 (comment)).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/71#issuecomment-9400852.

from inappstorewindow.

Hmm, what you suggested didn't seem to work. Tried this:

BOOL originalMovable = [window isMovableByWindowBackground];
    [window setMovableByWindowBackground:YES];    
    while ((theEvent = [NSApp nextEventMatchingMask:NSLeftMouseDownMask | NSLeftMouseDraggedMask | NSLeftMouseUpMask untilDate:[NSDate distantFuture] inMode:NSEventTrackingRunLoopMode dequeue:YES]) && ([theEvent type] != NSLeftMouseUp)) {
        @autoreleasepool {
            NSPoint now = [window convertBaseToScreen:[theEvent locationInWindow]];
            origin.x += now.x - where.x;
            origin.y += now.y - where.y;
            [window setFrameOrigin:origin];
            where = now;
        }
    }
    [window setMovableByWindowBackground:originalMovable];

from inappstorewindow.

Weird, I tried again and now the vanilla SampleApp always works -- even the
bottom ~10px that I mentioned wasn't working before.

Thanks for the help.

On Sat, Oct 13, 2012 at 9:54 PM, Indragie Karunaratne <
[email protected]> wrote:

Hmm, what you suggested didn't seem to work. Tried this:

BOOL originalMovable = [window isMovableByWindowBackground];
[window setMovableByWindowBackground:YES];
while ((theEvent = [NSApp nextEventMatchingMask:NSLeftMouseDownMask | NSLeftMouseDraggedMask | NSLeftMouseUpMask untilDate:[NSDate distantFuture] inMode:NSEventTrackingRunLoopMode dequeue:YES]) && ([theEvent type] != NSLeftMouseUp)) {
@autoreleasepool {
NSPoint now = [window convertBaseToScreen:[theEvent locationInWindow]];
origin.x += now.x - where.x;
origin.y += now.y - where.y;
[window setFrameOrigin:origin];
where = now;
}
}
[window setMovableByWindowBackground:originalMovable];

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/71#issuecomment-9415115.

from inappstorewindow.