Munki 2 - Main menu text not clickable only icons

[GoogleCodeExporter]

Not very important, but sometimes i click and nothing happens, because i 
clicked the text under the main icons.

Enhancement is to make a clickable square around the main icons and text.

Original issue reported on code.google.com by yves.zie...@googlemail.com on 30 Aug 2014 at 7:46

[GoogleCodeExporter]

This looks like it will be very difficult to fix.

Originally Managed Software Center had a "fake" toolbar with normal buttons at 
the top-center. When this caused problems when translating the labels in to 
other languages, I switched to a real NSToolbar, which automatically resizes 
items to display the full label.

But in order to get the icons to display properly (correct size, blue highlight 
when clicked) I needed to use NSButtons instead of simple toolbar images. It 
appears that once you use anything other than an image for a toolbar item that 
the label text does not respond to clicks.

Therefore fixing this behavior may be difficult.

Original comment by gregnea...@mac.com on 1 Sep 2014 at 2:21

[GoogleCodeExporter]

How do you feel about calling private APIs? If you don't plan to ever put this 
in the App Store then it shouldn't be a problem. If Apple ever changes the API 
it should just stop working (the method would never be called in the first 
place).

I have this fixed in a test program by overloading the NSButton hitTest: method 
to include the adjacent label view and by overloading the NSButtonCell 
_hitTestForTrackMouseEvent:inRect:ofView: (this is the private API one) to 
again include the adjacent label view. This seems to produce reliable results 
in all my click testing.

If you don't have any qualms about overloading the private API to append new 
behavior to it I will submit a pull request. I still have to see about 
converting the .m subclass files to .py (or does that matter?)

Original comment by danielha...@gmail.com on 1 Sep 2014 at 8:10

[GoogleCodeExporter]

It looks, by the way, that when you use a custom view / control all mouse 
events get passed to the control rather than handled internally by the toolbar. 
Thus, the control knows nothing about a label and just ignores any mouse events 
that are not inside it's own rect frame.

Original comment by danielha...@gmail.com on 1 Sep 2014 at 8:11

[GoogleCodeExporter]

I wish clicking on the label was also forwarded to the control, but it appears 
not to be so.

Apple is clearly doing something very custom in their App Store toolbar, which 
of course, they are free to do.

I'd like to see your test program demonstrating your solution to the issue, or 
a pull request so I can play. But wondering why you needed to override the 
private _hitTestForTrackMouseEvent:inRect:ofView: method instead of the public 
hitTestForTrackMouseEvent:inRect:ofView: method..?

Original comment by gregnea...@mac.com on 2 Sep 2014 at 4:55

[GoogleCodeExporter]

There isn't a public hitTestForTrackMouseEvent:inRect:ofView:, just a generic 
hitTestForEvent:inRect:ofView: which never gets called in this case. If there 
is a public method I can't find it in the docs, and Xcode also complains about 
it not existing.

I haven't had time to re-work the code into python form (it may be easier than 
I expect), but here is the test project attached. The real code is in the 
MUToolbarButton and MUToolbarButtonCell files. The only change to the stock 
toolbar settings in "interface builder" was to change the class of the NSButton 
and NSButtonCell to use the custom classes.

The only artifact I noticed visually is that the text itself doesn't highlight 
the same way it does on a standard image toolbar button, but I almost didn't 
notice until I was a few inches away from the screen.

Original comment by danielha...@gmail.com on 2 Sep 2014 at 8:24

Attachments:

• NSToolbarTestProject.zip

[GoogleCodeExporter]

"The only artifact I noticed visually is that the text itself doesn't highlight 
the same way it does on a standard image toolbar button"  in App Store, the 
label text doesn't highlight at all when clicked.

Original comment by gregnea...@mac.com on 2 Sep 2014 at 8:40

[GoogleCodeExporter]

Never noticed, good to know.

I could never get PyObjC to call the private method of the superclass. It let 
me override the method, but not call the super so I had to slightly change the 
way the NSButtonCell subclass works, but everything still seems pretty much to 
work the same. Not sure how google code handles pull requests, but here is the 
commit to my clone:

https://code.google.com/r/danielhazelbaker-munki/source/detail?r=1e7503d046309d8
d8ebcc25baf7bb7b0cb1a5651&name=Munki2

Original comment by danielha...@gmail.com on 3 Sep 2014 at 2:09

[GoogleCodeExporter]

"I could never get PyObjC to call the private method of the superclass" I found 
the same today when testing. I could call public methods of the superclass, but 
the PyObjC bridge complained about the private method. I'll be interested to 
see how your workaround compares to the things I tried.

Note that we can just use the original Objective-C implementations; they work 
as-is.

i need to test this on all the supported OSes (10.6-10.10). I'm uncomfortable 
relying on private methods, but it seems necessary to get the desired behavior. 
Given the other issues with the toolbar under Yosemite, though, I worry that 
this is all house of cards ready to collapse, as we hack around trying to 
duplicate the non-standard things Apple is doing.

Original comment by gregnea...@mac.com on 3 Sep 2014 at 3:06

[GoogleCodeExporter]

Fix merged here:
https://code.google.com/p/munki/source/detail?r=1e7503d046309d8d8ebcc25baf7bb7b0
cb1a5651&name=Munki2

Original comment by gregnea...@mac.com on 3 Sep 2014 at 5:09

• Changed state: Started

[GoogleCodeExporter]

I'm calling this resolved.

Original comment by gregnea...@mac.com on 4 Sep 2014 at 8:47

• Changed state: Fixed