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
> <cocoa...@indragie.com> 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 (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> http://lists.apple.com/mailman/options/cocoa-dev/unmarked%40gmail.com
>> 
>> This email sent to unmar...@gmail.com
>> 
> 
> 
> 
> -- 
> Mark Munz
> unmarked software
> http://www.unmarked.com/

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to