In Symbian S60 (not QT), if a menu item is not applicable to my current menu state, can I make it appear but greyed out, or is it always removed from the menu (i.e. invisible)?
In Symbian S60, CEikMenuPane::SetItemDimmed() removes menu options.
In the now defunct Symbian UIQ, the same function dimmed/greyed out menu options.
See this book.
So just use that function and have them removed in Symbian 60 (which has merged and is just called Symbian nowadays).
I never saw this in past 8yrs I am developing on Symbian, the item is always hidden. I had made custom menu on my own - but I cannot advice this approach. With Symbian source code I could probably hack it for your application, but the effort will not be paid back.
BR
STeN
Related
I need to make a form visible even when I switch desktop on Windows 10 (by pressing Ctrl-Windows-Arrow) if possible, without any 2nd party lib
You can create multiple desktops by pressing Windows-Tab and clicking the + on the bottom-right corner.
Normally, a form only appears in the original desktop it was shown, and can be dragged to another desktop, but won't appear in multiples at the same time.
I know it's possible, because the splash forms of some applications do this. (Ex: Word, Excel)
I searched all over the web, but couldn't find a solution.
EDIT: Another app that I know that does this is the Task Manager, when you mark the "Always Show" checkbox.
This may be of some help. You have to dive into the world of AutoHotKey but this will solve your issues I'm pretty sure:
https://superuser.com/questions/950960/pin-applications-to-multiple-desktops-in-windows-10
Set your form's topmost property to true? Have you tried that?
A quick search of Apple's Human Interface Guidelines and Developer Library yields an unequivocal guideline:
Users, and not apps, place menu bar extras in the menu bar.
Anecdotal data backs that up: submitting an app where - upon quit of a dock process/main view, the extra is left running - yields a tidy rejection.
Now - I'm a User experience designer (UXD) who typically plays, I mean, works in the mobile and web space. So please pardon my lack of Obj C chops, thanks.
I understand well the guideline and behavior/pattern: apps like Skitch, Wunderlist, Evernote, et al however very clearly leave the extra (often termed HelperApp) running in the menu bar on quit of main app. They all, do offer explicit user toggle of this w/i preferences.
There's no additional Human Interface Guidelines w/ specifics around handling this requirement for user control. Must this be included in onboarding? Dialog at 1st quit? Again: I can speak to best behavior UX wise, but my (very senior) dev wants the mandate - how are others not getting rejected?
Focus: what means of user control is/are mandated to avoid rejection?
Known/given: include in preferences
Other: ???
After hours of searching online and Apple Dev guidelines, I humbly bring this question here. There simply isn't time to play a carnival game of requirements: guess, get rejected, repeat. Thanks in advance.
Do you have a button somewhere in your user interface that adds the menu extra to the menu bar? Or does your app just do it automatically without the user telling it to do so?
I think that's the distinction, your app must only add an extra when instructed to do so. Also if the primary purpose of your app is to create a menu extra (eg, I have one that puts a calendar in the menu bar) then just launching the app is an implicit instruction, so it can be added automatically.
Ultimately, this rule really is vague and can't be clarified. What it comes down to, is that there should not be many menu extras in a user's menu bar unless the user explicitly chooses to have them. So unless your app really needs a menu extra, you must disable it by default.
If you think the reviewer should have allowed your app through then reply to the rejection explaining your position. I've had an app change to approved once after doing that.
If they still reject your app, then you can appeal the app rejection.
Alternatively, just disable the menu extra by default and have a button somewhere to add it to the menu bar.
Also, all of this assumes you are using NSStatusItem and not the "real" menu extra system — which is a private API. Only NSStatusItem menu extras can be placed in the app store as far as I know.
The built in battery, wi-fi, sound, etc, Apple supplied status items, can be dragged to any position on the menu by using cmd + click and drag:
How can I support similar functionality in my own status item?
There are two ways to get menus on the right side of the menu bar. The officially supported way is creating an NSStatusItem in your app. The other ways is creating an NSMenuExtra. You've noticed one difference: NSStatusItem menus are fixed in place, whereas the menu extras can be moved around by cmd-dragging them.
The other major difference, and the reason 3rd-party menu extras are not officially supported, is that unlike status items (which run as separate applications), menu extras are loaded into the address space of the SystemUIServer process. That means if they go haywire and crash, they can take down the UI.
You can see the Menu Extras installed on your system at /System/Library/CoreServices/Menu Extras. It may still be possible to create your own and have the OS load them, but you will run into problems if you try to ship the result. Better to go to bugreport.apple.com and let them know that NSStatusItems ought to be draggable.
Wikipedia has more info on Menu Extras, including some links to a tutorial on building your own.
I am writing Contextual Menu Plugins for Leopard OS and referring Writing Contextual Menu Plugins for OS X, part 1 article by Brent Simmons. My plugin is working fine.
Is there any way to move my test menu into main menu (above the Label)?
The short answer is "no".
The OS controls what gets displayed in that menu, so in order to change it around, you would need to call private methods, reimplement system-level functionality, and just in general do some Very Bad Things which would be unsafe, could break at a moment's notice, and possibly work differently between even dot releases of the same OS.
Yes, it's called a system service, and was introduced in OS X 10.5. I know for a fact that many applications can do this, and Automator routines can be triggered this way because Automator itself is a system service. To see a service applicable for an application (i.e. Finder) go to the Application menu on the top bar (for lack of better name T_T), such as the Finder bolded text, and go down to Services > and it will show you all services that can be used in the app. If you need pointers on how to build this, just comment here.
EDIT: Yes, a SIMBL plugin is also considered a service, and on second read of your question, that's what you want.
I am a newbie in Mac application development. I want to write a GUI application in Cocoa using Interface Builder. I want multiple screens i.e. when one button on a screen is clicked, another screen should be displayed. How can I activate a new screen at button click event?
I would heartily recommend Aaron Hilegass's book Cocoa Programming for Mac OS X. It took me from feeling like everything was impossible to being relatively competent in the space of a few short weeks. I was very impressed with it.
Apple's documentation is amazingly good, but it takes a while to get used to the style, and you will need to know which objects actually exist before you can look up how to use them, which is where Aaron's book comes in.
Your library may have a copy of it, or be able to order one for you if they don't.
I think you mean windows, not screens. Screens are the displays (monitors) on which all the user's windows from all the user's applications appear.
And I second Jonathan's recommendation of the Hillegass book.
The button has a target. That should link to the new window. As its action you can tell the window to show itself.
Take a look at:
http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/WinPanel/WinPanel.html
I think what you want is the type of interface like that seen in Coda, or System Preferences where there is a toolbar on the top of the screen that can be used to select between the content of the window.
The simplest method I have found is to use BWToolkit.
Another method is to use a series of views, and switch between them when the toolbar is clicked. I've found one description here, but that's not the one I used first (which may have been originally in Ruby Cocoa, IIRC).
NSTabView.