-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The big menu issue #152
Comments
I think the messages you're looking for on Windows for the Edit Control are |
Yes, but that's only for the edit control. I'd have to monitor what the currently focused control is to see which messages I need to send. |
Something else to consider is the native "Quit" vs "Exit" phrasing that each platform uses. Might be nice to have a function that sets up a default set of menus for that platform, and one could provide flags for what menus they may want. For example an Exit/Quit menu, a Preference/Settings/Options menu, a Help menu, an Edit menu, etc. |
Part of the problem for OS X is that the Cocoa framework is very much built upon XIB files and Xcode... it isn't designed to be wrapped by an API such as libui, and this is why most Mac apps that aren't programmed in Objective-C/Swift tend to have little quirks that "native" apps don't. I don't really see how to proceed here in a way that also makes sense on other platforms; on one of my applications I ended up scrapping using libui for the Mac version (I'm still using it for Windows and OS X) and just using plain Cocoa instead. |
Just a proposal from my side (I'm not a C guy but I wanted such a library for years - to be easily ported to almost every language). Why don't you take some ideas from wxWidgets or even Lazarus LCL? Both libraries are wrappers and have implementations for all 3 platform that you need. In addit ion they have working menu system + forms + dialogs + all of the elementary controls. Just observer their implementation and may be you can take some ideas. Tahnk you for the amazing job! |
Why not let applications detect the OS and use different phrasing/controls on each? |
No. OS detection is evil, that would defeat the goal of libui. If you want different controls on each platform, just use directly the native libraries. |
Then in that case we should just not do anything special regarding macOS's special menus and use the same controls that we'd use on windows or gtk. |
@PaulBGD @emersion As I pointed out in this comment above, the Mac's user experience is not meant to be wrapped in a separate framework. There really is no good cross-platform way to handle menus on OS X. Either you add lots of new code to handle OS X (which can't be re-used on other platforms) or you settle for a sub-par user experience. That, unfortunately, is the reality. |
Which is why I was suggesting allowing applications to handle macOS. |
Would it make sense to create a new library (outside of |
What would that library do? |
It would offer the supplemental macOS-specific APIs that are unwanted in
|
I think the suggestion to look at wxWidgets is a good one. I've used it on OSX and Windows and it doesn't hve a "subpar" feeling for either platform. It is certainly possible to build menus in code and have a common api in libui that translates to the appropriate menus on each platform |
I'd say, provide a method to create menu items in general form and implement platform conventions in a separate component (maybe declarative). uiMenuAppendCutItem can be a building block in the conventions layer. We probably will need quite a number of such high-level conventions like OK/Cancel button placement, client area in a window with menu etc. |
Replaced with #321. |
The current menu API is a huge kludge right now.
OS X PROBLEMS
Everything is an informal protocol.
Many of the standard menu items, most notably in the Edit menu, work by sending a predefined selector, such as
cut:
, to the first responder. Things like NSTextField and NSTextView already implement all of this; we can do this in uiArea with a bunch of extensions to uiAreaHandler.But all those items would need to be made predefined menu items, such as
uiMenuAppendCutItem()
. Maybe a macro would be better.Also keyboard accelerators only work if tied to a menu item. Command+C for copy has to be on the Copy item. (Corollary: programmable accelerators would allow us to override these conventions. Should we? Right now the Application Menu is hardcoded to do Command+, be Preferences and Command+Q to be Quit, and Command+(Option+)H for the various Hide options.)
I want to eventually support the Document-Based Application framework. This might add a bunch more predefined menu items.
Unsure about:
performClose:
, a NSWindow method which simulates clicking the Close buttonThere are also canonical text editing shortcuts handled by the text system. Relevant to the uiArea text discussion as well.
Finally, there's the global menubar. If we have per-window menus, we would need to watch when the key window changes to change the menubar...
GTK+ ISSUES
I'm not sure how copy/paste/etc. work. Is it keybinding signals or GtkAccelGroup? Or is it
gtk_window_add_mnemonic()
?WINDOWS ISSUES
There is no standard editing interface, but there are some editing messages like WM_UNDO and WM_COPY. Unfortunately, the Edit control also provides its own which it prefers under some circumstances. Unfortunately unfortunately, there's nothing like WM_CANUNDO (as far as I know).
So we would need an interface for cut/copy/paste/etc. somehow.
Microsoft recommends against using Preferences, instead suggesting Options
IIRC can't have a hard tab in a menu label; that's how keyboard shortcuts work
So I'm not sure what to do. What kind of API would be better? It shouldn't be purely declarative as opposed to functional (declarative APIs can be written on top of non-declarative APIs easily, but not the other way around).
The text was updated successfully, but these errors were encountered: