Comments (13)
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.
Related Issues (20)
- when click minButton to hidden the window, then reopen,move mouse to traffic button and remove mouse, the traffic button always show RollOverImage
- Exit full screen mode in Yosemite HOT 7
- dragging to another virtual desktop is not working
- window frame.height grows from start to start if autosave name is not empty, OS X 10.9.3
- README needs update
- setMovable flag doesn't work
- Box behind title Xcode 6.1 GM HOT 2
- Yosemite double click title bar to maximum window not working HOT 1
- Cocoa pod can't find INAppStoreWindow 1.5
- bad window button positioning on Yosemite HOT 4
- TitleTextColor changes only the Window Title !
- bad way to detect yosemite
- crash, creating window from code inherit INAppStoreWindow 10.10.1 HOT 3
- Window widgets are positioned incorrectly in document-based application when showing sheets HOT 2
- Graphite system appearance appears to be ignored
- Where do I start HOT 1
- AppleMiniaturizeOnDoubleClick Isn't working HOT 2
- Window flicker when drag in the original titlebar area and move to top of the screen
- Traffic light buttons HOT 2
- Every Time At the time of Launch : NSWindow warning: adding an unknown subview: HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from inappstorewindow.