For one of my software, I might need to have to add some objects that could have the same behavior as any of object already present (apps/stack etc.), having a contextual menu.
Is it some how possible ?
Thx.
Not possible. That's the domain of applications, files and folders, configured by the user. You do, however, have the ability to add a menu to your own application whose icon appears in the Dock.
You might consider menu extras, but those come with their own set of problems. One in particular is the OS making them disappear when space in the menu bar becomes tight.
Related
I would like to add my custom command, to a window system menu (the one usually on the left top on titlebar, usually containing Minimize, Maximize and so on), and respond to it in my application.
In ms windows one can do
HMENU hMenu = GetSystemMenu(hwnd, false);
AppendMenu(hMenu, MF_STRING, ...)
Is something like this possible under X11? If not a general method maybe a solution for some specific window manager?
Ok, after your last edit, what I understand is that you want to add your custom menu to the menu that's on the window decoration, which is controlled by the Window Manager.
I don't think that's possible, although I'm not sure. I believe you should read the ICCCM and the EWMH to find if this is possible or not:
http://en.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual
http://en.wikipedia.org/wiki/Extended_Window_Manager_Hints
Or you can send an email to wm-spec-list asking:
http://mail.gnome.org/mailman/listinfo/wm-spec-list
Also, adding an option there makes it quite hidden, doesn't it? I guess most people don't ever click that menu... I don't even think that menu exists on all the possible Window Managers. You should really try to put your menu inside your application's Window instead of the Window Manager's decoration. Some environments don't even have Window Managers: what would your users do in this case?
Note that some applications (like the Chromium browser) don't use the Window Manager decorations: they implement their own decoration, they implement their own close/maximize/minimize buttons. This way, they have complete control over all the decoration buttons and menus, but their decoration doesn't have the same "look and feel" of the rest of the desktop. You could think about doing this, but I wouldn't encourage that... You should probably put your menu somewhere else (where it's not that hidden...).
You mean you want to add your app to the system menu?
I believe most modern desktop environments implement the XDG Menu Standard:
http://standards.freedesktop.org/menu-spec/menu-spec-latest.html
You'll have to learn other standards too probably:
http://standards.freedesktop.org/
They're all somehow short, so they won't consume more than some hours to read and learn.
I've removed the menu from my cocoa app, all of the interaction should happen from within a status item, that links to a menu, that links to different NSPanels. But this seems to have removed the ability to ⌘C or ⌘V within a NSTextField. Is there a way to add this back without having to have a standard menu included with my app?
Even if your app is a faceless background app, so it never shows a menu bar, you should still have a full main menu because that's what provides all of the default actions (and enables the user to redefine the key commands if they so choose). If you remove the main menu, you have to reimplement everything in it, including anything Apple adds in the future, in code.
And I'd especially warn you against trying to handle keyboard shortcuts yourself. That's damned tricky. A lot of applications get it wrong, causing us Dvorak users (among others) to curse their developers.
I assume you can just implement the actions originally connected to the menu items in a keyDown event. Check out this page for details: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html
Just have it respond to cmd-v with paste:, and cmd-C with copy:
Edit: Though I have to agree with Peter, you really should have a main menu...
On the very top of my Mac, there is a bar which has my battery percentage, the date and time, the volume, etc. There is also a dropbox folder. How can I create something that gets thrown up there? I'd like to put a few shortcuts in that menu bar. Is there a way to do it?
That bar is the equivalent to the system notification bar on Windows. You want to place your shortcuts on the dock (normally located at the bottom of your screen). You do this by drag and dropping.
While OS X provides no centralized tool to enable or configure menu extras, some of them can be rearranged and dragged off the menubar while depressing the ⌘ key. Also, all Apple-supplied menu extras can be found in the folder /System/Library/CoreServices/Menu Extras.
From Wikipedia
However, if you are determined to put your shortcuts on the bar, here is how to create menu extras
Alternatively, there are some free apps already created for this purpose. HimmelBar - Free, XMenu - Free, and MoofMenu - $5
You want to use the NSStatusBarItem class (see also the NSStatusBar class which represents the menu bar itself.)
Note that icons/menus created with this API do not "mix and match" with the OS-provided ones, but rather are aligned to the left of them and cannot be dragged by the user. Still, it's good enough for most uses.
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a WM_NCPAINT message and passes it on to DefWindowProc, which is part of User32.dll - the core window manager code.
Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.
That's just one of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!
It would be a far less difficult job to echo the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is very common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application.
What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.
You all know the menu bar (or better said NSStatusBar) in Mac OS X.
There are some items which I can move and other which not.
I would like to be able to drag the NSStatusItem of my app.
Any idea how to implement this?
Although NSStatusItems appear near Apple's internal "menu extras", they are distinct and behave differently. It would be nice if Apple unified the items that can appear in the right-hand area of the menu bar, but for now the section is split into distinct "apple internal" (on the right), and "app-provided (NSStatusItem)" on the left.
You can visualize the distinction by putting your computer into screen capture mode (cmd-shift-4), and pressing the space bar to switch to "capture whole window". When you hover over Apple's menu icons, you'll see that they all live in a single window. This explains their ability to be easily managed and dragged about. Hovering over the other items reveals that each NSStatusItem is in fact living in a single window of its own (which happens to be owned by the application that installed it).
It's best to stick with NSStatusItem even though you can't drag them. It's a shortcoming from Apple which most users will understand, even if it's annoying. Emphasizing the positive tradeoffs of offering a more stable application for the long term will usually soften the opinions of your customers (or managers?) who are pushing for the draggability.
You'll have to use NSMenuExtra, not NSStatusItem, and make the menu item a bundle running inside the SystemUIServer process, not your own app. You'll also need code like that supplied by MenuCracker to get this to work.
NSMenuExtra is undocumented and unsupported, and therefore considered a "hack".
My guess for there being two APIs in the first place: a menu extra crashing (or memory leaking) means the entire SystemUIServer process crashing or memory leaking — including other third party modules as well as system-supplied ones. With a status item, on the other hand, such a problem would only affect your own code.
As of macOS Sierra 10.12 http://www.macworld.co.uk/how-to/mac-software/7-sierra-menu-bar-tips-how-use-mac-menu-bar-in-macos-sierra-3649163/
Third-party apps sometimes install as menu extras, have controls that exist in the menu bar, or can be relaunched as faceless apps despite not initially being so. As of macOS Sierra, these menu extras can be rearranged just like native ones. (This wasn't the case through to OS X El Capitan.)