Moved OF menu to under the Xcode menu #25
Conversation
So… here's the thing. OFPlugin really shouldn't have its own menu, because… that's not really how menus work. I mean, it's a great idea and all, or would be a great idea if we all had screens that were 30"-wide. Or if OS X were really designed around menu bars— like, if we could drag menus off to floating palettes, and if too many menu items added a little “more items” icon… you know, if they worked like app toolbars do. But they don't. OS X's menu bar is somewhat of a broken UX concept as it is— if there's not enough room it just starts truncating stuff, and many 3rd-party always-running extension (like Dropbox and every competing service) already fight for what space there is. And Apple's not making things better by introducing Retina displays— the future is high-res, not real-estate. So… I hate to have to do this but… the OF menu has to be under a different menu. I mean, I still love you OFPlugin, but you gotta play along with everyone else. We don't want people deleting you just because you standing in the wrong spot. This is for the best, okay? <3 On a more serious note… • Moved the “OF” menu to a “openFrameworks” menu item section under the Xcode menu, after the Open Developer Tool/Services section and before the Hide/Show section. » “Menu item section” as in “separated by menu item separator lines”; it add both a new separator and the item. » Searches for the “Xcode” menu first by name, falling back to using a hard-coded `kExpectedXcodeMenuIndex`. » Searches for the first “Hide…” menu item first by name, then falling back to `kExpectedXcodeMenuPreHideShowSeparatorItemIndex`, and finally ensuring that it isn't past the end of the end of the existing menu items. We really don't want this to cause any future version of Xcode to crash— it's far better for it to be in the wrong spot.
|
Yes I agree for the most part. The standalone menu item decision was made when I thought this was basically going to be a cute hack for myself and maybe a couple other people. It makes sense to give it a less intrusive menu position, given that it's in heavier use now. That said, I think this should be toggle-able via NSUserDefaults and a minimal "Preferences..." dialog. I personally prefer the menu where it is, though I certainly acknowledge that it's not really the correct place for it. |
|
I also like where it is now. It's such a short menu (2 characters) that it doesn't really bother me, even when I'm on my 11" air |
|
@admsyn: Good point. Putting together an injected preferences pane may be a little beyond my capability, however. |
|
I like it the way it is...cause if you change it...I won't know where it is! On Wed, Nov 12, 2014 at 5:22 PM, Slipp Douglas Thompson <
|
|
@capnslipp No worries! A preferences dialog has been something I've been thinking of adding for a while, but this PR is a good push for me to actually go do it. |
|
@admsyn Cool. Works for me. |
So… here's the thing. OFPlugin really shouldn't have its own menu, because… that's not really how menus work. I mean, it's a great idea and all, or would be a great idea if we all had screens that were 30"-wide. Or if OS X were really designed around menu bars— like, if we could drag menus off to floating palettes, and if too many menu items added a little “more items” icon… you know, if they worked like app toolbars do. But they don't. OS X's menu bar is somewhat of a broken UX concept as it is— if there's not enough room it just starts truncating stuff, and many 3rd-party always-running extension (like Dropbox and every competing service) already fight for what space there is. And Apple's not making things better by introducing Retina displays— the future is high-res, not real-estate. So… I hate to have to do this but… the OF menu has to be under a different menu. I mean, I still love you OFPlugin, but you gotta play along with everyone else. We don't want people deleting you just because you standing in the wrong spot. This is for the best, okay? <3
On a more serious note…
• Moved the “OF” menu to a “openFrameworks” menu item section under the Xcode menu, after the Open Developer Tool/Services section and before the Hide/Show section.
» “Menu item section” as in “separated by menu item separator lines”; it add both a new separator and the item.
» Searches for the “Xcode” menu first by name, falling back to using a hard-coded
kExpectedXcodeMenuIndex.» Searches for the first “Hide…” menu item first by name, then falling back to
kExpectedXcodeMenuPreHideShowSeparatorItemIndex, and finally ensuring that it isn't past the end of the end of the existing menu items. We really don't want this to cause any future version of Xcode to crash— it's far better for it to be in the wrong spot.