I'm talking about the icons that show up on the right hand side of the menu bar. I can get access to that menu bar with (py-appscript)
app(u'System Events').processes[u'SystemUIServer'].menu_bars[1]
& menu_bar_item[1], menu_bar_items[1] & so on refer to each of the icons.
But, there are couple of icons up there that cannot be referenced using this method. For e.g. the search icon in the corner doesn't belong to SystemUIServer. Similarly, our app's icon also shows up there but cannot be referenced like the above example. So how can I reference those icons? I want to perform actions like click, right-click etc. IS there any way to list all the icons displayed on the bar? That way I can always grab the position & click them that way. Any suggestions?
Easiest way to script the spotlight menu is to just send the keys via GUI scripting. I don't think it can be accessed in the fashion you want. As for why your icon won't list I'm not sure. Does it have a menu associated with it?
It's easy to list all the menulings. Here's a Python script to do so. You can then use that data to access them directly with Appscript.
http://www.libertypages.com/clarktech/?p=2193
Related
In decarbonizing I have now come to creating a menubar programmatically using NSMenu.
Carbon seems to be so nice to add standard items to the application menu: Services, Hide app, Hide Others, Show All, Quit app,
and they are even added using the user’s Preferred Language setting in System Preferences’s Language & Region,
so in German Hide Others is added as Andere ausblenden.
I only had to add the About and Preferences items.
However, it seems that in Cocoa I have to add these standard items myself,
but how can I find out what Hide Others is called in the user’s Preferred Language ?
And what is the Cocoa equivalent of CreateStandardWindowMenu ?
If you have Xcode create a new Cocoa application project, it will make a MainMenu.xib that you can examine. It looks like "Hide Others", "Quit" etc. are just menu items with particular actions assigned, but "Services" seems to have some special magic. Even if you don't want to present a whole menu bar from a nib, you could load it from a nib and then pick out certain menu items and move them to another menu, rename them or whatever. Though I'm not sure I understand what you're trying to accomplish. Even if you don't want to localize, you can use a nib.
To address the last part of your revised question, the NSApplication object has a windowsMenu property, i.e., you could create a menu and say [NSApp setWindowsMenu: myMenu]. But I don't know if that adds items like Bring All to Front or if you must create those yourself.
If I right-click on the toolbar > click Customize > click Commands tab > then click the Context Menu radio button, there are a rather large amount of choices. Sometimes what I'm trying to find an item to add or remove, I have to wade through a lot of the choices before I finally find the item and looking for (if I even can). Sometimes the groups are not at all intuitive.
Is there any way I can search the available options in all categories? In Visual Studio itself, or even an extension.
Two options I use:
If you're trying to search for something specific, Quick Launch
should be pretty useful to you. CTRL+Q will take you to it or just
type in the text box in the top right of the main VS window.
Another option that comes to mind: go to Tools->Customize and click
on the Keyboard button. That has a search box for commands that
can also be useful. Tip: make the window bigger to make the list
larger.
desktop: window server 2003
Assume i have a cmd.sh that echo a message, here i want to run it in anywhere , when i right click the mouse and choose the echo function.
hope for your answer, thanks
Editing the registry as #dbvega indicates works if you always want the same menu item to appear. This is called a static menu. But if you want to do have more control over your menu item, such as changing the visibility, text, and icon depending on various runtime conditions, you need to create a dynamic context menu shell extension, which involves programming a COM object. This MSDN article describes the difference.
I'd like to know if it ever makes sense to provide some functionality in a piece of software that is only available to the user through a context (right click) menu. It seems that in most software I've worked with the right click menu is always used as a quick way to get to features that are otherwise available from other buttons or menus.
Below is a screen shot of the UI I'm developing. The tree view on the right shows the user's library of catalogs. Users can create new catalogs, or add and remove existing catalogs to and from their library. Catalogs in their library can then be opened or closed, or set to read-only.
The screen shot shows the context menu I've created for the browser. Some commands can be executed independently from any specific catalog (New, Add). Yet the other commands must be applied to a specifically selected catalog (Close, Open, Remove, ReadOnly, Refresh, Clean UP, Rename).
Currently the "Catalog" menu at the top of the window looks identical to this context menu. Yet I think this may be confusing to the users as the tree view which shows the currently selected catalog may not always be visible. The user may have switched to the Search or Filters tab, or the left pane may be hidden entirely.
However, I'm hesitant to change the UI so that the commands that depends on a specifically selected catalog are only available through the context menu.
The Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista states (pg233):
“Don’t make commands only available through context menus. Like shortcut keys, context menus are alternative means of performing commands and choosing options.”
The Apple Human Interface Guidelines states (pg189):
“Always ensure that contextual menu items are also available as [pulldown] menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command.”
In your case, opening and closing the catalogue appears already available through the +/- buttons in the tree itself, so you’re already consistent with the Windows guidelines, if not the Apple guidelines. IMO, the only reason to put them on the context menu at all is if they're the default (double-click) action (which they're not right now). Rename may also already be available by directly selecting the name of a selected catalog, but you may want a pulldown menu item for that any way since that may be no more discoverable than the context menu. The rest of the commands probably belong on a pulldown menu in addition to the context menu.
As far as the Catalog pulldown menu being redundant with the Catalog context menu, you may want to consider organizing your pulldown menus by type of action, rather than class of object, in order to provide an alternative organization. As you’ve realized, context menus already organize commands by class of object. In addition to providing an alternative organization that some of you users may find more intuitive, this may simplify your menubar. For example, rather than a Catalog and Family menus, you can have a single Edit menu with Add, Delete, Rename, Copy, etc. where these commands apply to whatever is selected, whether it be a catalog, folder, or family. If they don't apply to the current selection, they're disabled, but if it makes any sense in your app, make them apply.
BTW, what’s the difference between Add Catalog and New Catalog?
In general, it's a bad idea to have menu items accessible only through a contextual menu. Many users may not think to right click on an item to find out what actions can be performed on an item.
From your description, it sounds like it would make sense to have a 'Catalog' menu that disables menu options that are not currently relevant. For example, if no catalog is open, the 'Close' menu item would be greyed out. Similarly, the 'Open', 'Remove', 'Refresh', etc. items would be greyed out if no catalog is selected.
I suppose this depends on your user base, and who you're targetting your software at. Personally I wouldn't expect the user to be able to deduce what functionality is available when it is essentially "hidden" until they right-click on the correct item.
If it were me, I'd have a toolbar shown with the functionality exposed on there. By default the buttons would be disabled, and clicking on a node would enable the appropriate buttons based on the context. You could have this in addition to your current right-click options.
As a rule, I've always treated right-click menus as a redundant (i.e not necessary for operation of the software) shortcut to functionality for "power users".
I would leave the menu item out because the user doesn't have a way to see what catalog they are modifying if the treeview is hidden which can create problems if they think a different one is being shown.
Though, the accessible solution would be to trigger it with the keyboard also.
Yes. One key feature of UI is "discoverability": can the user find the function?
If you think that having a top-level menu doesn't make sense, based on the context, then you could have a menu button (scroll down) labelled (e.g.) "Actions" at the top of the pane.
My application is context-sensisitve and I dynamically build menus for the main window / context/popup, and other places. I typically know if a given menu command will be valid given the current state of the application. Is it better practice to DISABLE/GREY the menu options which currently do not apply OR since I'm generating the menu anyway, OMIT them entirely?
The application is a Java/Swing is anyone is curious. The question seems GUI toolkit agnostic but may be platform dependent.
The old apple guidelines say to Disable for fixed menus (in the menu bar), and omit for context menus.
I guess the motivation is that a context menu is supposed to only show options that are available to the particular context, and the main menus are supposed to show all commands, so the user knows where "Save" would be even if it's not selectable at the moment.
For right-click menus, I'd say that if the item is applicable to what was right-clicked but is for some other outside reason unavailable, disable it. If it is not applicable to the right-clicked thing then hide it as there's no chance of it ever showing up. Case in point:
When I right-click on the background area of this page in Firefox the first four items are Back, Forward, Reload, and Stop. Forward and Stop are disabled because they aren't valid actions right now (I have no forward history and the page is not loading anymore). These four guys are very consistently offered, they are expected, global, often-used commands. They are the four main "navigation" controls and by default they have toolbar counterparts (in the form of big dedicated buttons).
However, if I right-click on an image, I get completely different options in the context-menu all related to viewing, saving, and copying the image under where I clicked. These options don't appear at all (not even disabled) under normal use because they are very specific to what I right-clicked on. When right-clicking on the background area, Stop and Forward, while currently not valid actions, are still applicable to what I clicked on (the page) but they are unavailable for other reasons...
Like the rule for menus on the top menu bar, the goal is not to surprise users with commands suddenly appearing for, from the user's point of view, inexplicable reasons.