Re: rightMouseDown: never called in NSView subclass
Re: rightMouseDown: never called in NSView subclass
- Subject: Re: rightMouseDown: never called in NSView subclass
- From: Mark Munz <email@hidden>
- Date: Fri, 26 Aug 2011 10:03:55 -0700
OK, I misread your first message. That said, I'd go with the option to
just put your "toolbar" view as part of the contentView of the window.
If your view is within the contentView of the window, it will be part
of the fullscreen window in Lion. Just make sure it can resize with
the window. Xcode gives an example of this. All the navigation stuff
that doesn't sit in the toolbar is still displayed when in fullscreen
mode.
You can specify a custom window to use when in fullscreen mode if you
want a different layout.
If you're set on doing it as an NSToolbarItem, work within its
limitations. If you just need a global right-click option, consider
adding a simple button to give you that access, like the Action button
in the Finder. You might also employ click & hold (like the navigation
buttons in Safari).
I'd also file a bug so that this behavior may change in the future.
Don't count on it, but it's good for Apple to know what developers
need.
On Fri, Aug 26, 2011 at 9:36 AM, Indragie Karunaratne
<email@hidden> wrote:
> Thats actually what I'm doing right now, its an NSToolbarItem with a custom view but like I said, the right mouse events are not passed to it by NSToolbarView without that little hack. I could, as you said, circumvent NSToolbar completely, but when a view is placed outside of the toolbar, it disappears when Lion goes into fullscreen mode. I don't know if this is a bug or intended behaviour.
>
> On 2011-08-26, at 12:03 AM, Mark Munz wrote:
>
>> The description of what you're trying to do is a bit vague, but
>> couldn't you just create an NSToolbarItem with a custom view? You
>> might need to do a few tweaks if it needs to resize with the window,
>> but that sure seems easier than trying to circumvent the framework as
>> you are describing. You'd be able to do virtually anything you want in
>> that custom view and you wouldn't be necessarily fighting the
>> framework.
>>
>> Alternatively, you could just create a custom view that is placed at
>> the top of your content view of the window and just ignore the
>> NSToolbar class completely.
>>
>>
>> On Thu, Aug 25, 2011 at 9:46 PM, Indragie Karunaratne
>> <email@hidden> wrote:
>>> Is there any other way to do this aside from what I'm doing right now? As far as I know, I have two choices:
>>>
>>> a) Use this method and risk something breaking
>>> b) Write an NSToolbar clone
>>>
>>> I know the risks, but if I could get this to pass through Mac App Store submission then I'd rather deal with possibility of something breaking later on that than to rewrite NSToolbar. The one last thing I can think of is to use the ObjC runtime to retain the original implementation, swizzle hitTest: and check whether my view is under the cursor, and if not, just call the original implementation. However, method swizzling always feels like a dirty workaround so I'm not sure if it would be much better than this (and if it would be acceptable in the MAS).
>>>
>>> On 2011-08-25, at 10:40 PM, Quincey Morris wrote:
>>>
>>>> Ah, well, yes, if IB doesn't expose the class you need, that makes subclassing impractical. But in that case, replacing the NSToolbarView method seems even more undesirable.
>>>>
>>>>
>>>> On Aug 25, 2011, at 20:55 , Indragie Karunaratne wrote:
>>>>
>>>>> I'm not sure how I would get NSToolbar to use my subclass of NSToolbarView. I can't set the class of the toolbar *view* itself in IB (nor programatically, as far as I know), because NSToolbarView is a private class that NSToolbar uses to implement the UI. I can of course change the class of the NSToolbar object itself to a subclass, but this wouldn't help me much as there is no public NSToolbar method that allows me to change the class of its view.
>>>>
>>>>
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>>
>>
>>
>>
>> --
>> Mark Munz
>> unmarked software
>> http://www.unmarked.com/
>
>
--
Mark Munz
unmarked software
http://www.unmarked.com/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden