Giter Club home page Giter Club logo

Comments (13)

indragiek avatar indragiek commented on August 17, 2024

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.

jasonparekh avatar jasonparekh commented on August 17, 2024

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.

indragiek avatar indragiek commented on August 17, 2024

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.

jasonparekh avatar jasonparekh commented on August 17, 2024

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.

indragiek avatar indragiek commented on August 17, 2024

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.

indragiek avatar indragiek commented on August 17, 2024

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.

jasonparekh avatar jasonparekh commented on August 17, 2024

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.

indragiek avatar indragiek commented on August 17, 2024

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.

jasonparekh avatar jasonparekh commented on August 17, 2024

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.

indragiek avatar indragiek commented on August 17, 2024

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.

jasonparekh avatar jasonparekh commented on August 17, 2024

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.

indragiek avatar indragiek commented on August 17, 2024

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.

jasonparekh avatar jasonparekh commented on August 17, 2024

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.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.