-
Notifications
You must be signed in to change notification settings - Fork 6
FAQ : Platform specific questions
![](assets/logo-header.png)
In principle any recent Windows version (>= Windows XP) is most likely supported but wxRuby3 has only been tested on Windows 10 versions.
The most likely reason is that you have a High DPI display but your application does not state High DPI support. Please see High DPI Support in wxWidgets Overview. If you need more information about High DPI on Windows, please read Microsoft Windows High DPI Guide.
This can happen if you have a child window intercepting Wx::EVT_CHAR events and swallowing all keyboard input. You should ensure that Wx::Event#skip is called for all input that isn’t used by the event handler.
It can also happen if you append the submenu to the parent menu before you have added your menu items. Append submenus after adding menu items, or accelerators may not register properly.
Short answer: you can't.
Long(er) answer: in Ruby being able to retrieve native handles has no practical use so this functionality is not available
(in any port).
Short answer: you can't.
Long(er) answer: this would require far more platform specific interfacing than advisable for a Ruby application and is
therefor not supported. If you need that level of platform specific interaction, stick to wxWidgets.
Apple in all it's wisdom (?) has decreed that the standard Apple Application menu (right of the Apple menu icon on the
menubar) should be titled with the name of (executable) app you are running without providing an (official) API with which
to (reliably) change that at runtime. Since in case of wxRuby the executable/app is the ruby
interpreter your wxRuby app
will show the title ruby for the Application menu.
To workaround this piece of Apple crap wxRuby will insert a disabled menuitem at the start of the Application menu as installed for every menubar created followed by a separator. That menuitem will have the app's display name as set for the Wx::App instance as it's title. This provides some sort of (stunted I grant you) app title in the Application menu.
Can't we change that
By default the WXOSX port forces standard About and Exit items to conform to the Apple OSX interface guidelines and moves these items to the standard OSX Application menu.
Any menu item with the Wx::App.mac_exit_menu_itemid
will be hidden and a standard item to exit the application will be added to
the OSX Application menu. The 'mac_exit_menu_itemid' is by default assumed to be Wx::ID_EXIT
, but that can be changed by
Wx::App.set_mac_exit_menu_itemid.
For the About menu item or the Help menu the wxRuby MacOSX port uses some standard rules to help the engine make the right decisions:
- It assumes that the About menu item is part of a Help menu.
- The title of the Help menu is by default assumed to be “&Help”, but you can change it with Wx::App.set_mac_help_menu_title.
- The item Id of the About menu is by default assumed to be `Wx::ID_ABOUT’, but that can be changed as well with Wx::App.set_mac_about_menu_itemid.
- In case a menu with the
Wx::App.mac_help_menu_title
exists in a menubar and that menu contains a menu item with theWx::App.mac_about_menu_itemid
Id the menu item in question will be moved to the OSX Application menu - The other items of the wxRuby help menu are appended to the OSX Help menu and the translation of Ids is handled transparently for your application.
Currently WXGTK does not have any features that would involve dependence on any desktop environment’s libraries, so it can work on GNOME, KDE and with other window managers without installation hassles. Some GNOME and KDE integration features are file based, and so may be added without dependence on libraries.
In WXGTK, the frames never get focus and so can never receive CHAR nor KEY events so an evt_char
handler for a frame
will be never called. To receive these events, you should create a Wx::Panel
inside the frame and register the key event
handlers for the panel, not the frame.
Unfortunately programs using GTK often output scarily looking messages on the standard error stream, which is connected to the controlling terminal by default. Please be aware that most of these messages, even those using “CRITICAL” severity, are not actually harmful and can be just ignored.
If these messages are annoying for the users of your application (although most users probably won’t see them, as they wouldn’t be running the program from the terminal), you can use Wx::App.gtk_suppress_diagnostics function to disable them.
-
-
- What is wxRuby3?
- Can I use wxRuby3 for proprietary or open source projects?
- What is the origin of wxRuby3?
- How is wxRuby3 supported?
- What platforms are supported by wxRuby3?
- What features does wxRuby3 support?
- Does wxRuby3 support platform-specific features?
- How is wxRuby3 developed?
- How do I get wxRuby3?
- How do I use wxRuby3
- Can I help?
- Is there another, more declarative way, for writing wxRuby3 desktop GUI applications?
-