Gtk and Win32 differences
- Behaviour and appearance
- Other Issues
- Other Pages
Gtk and Win32 differences
If you plan your app using on Windows and Linux, use Generic Static Text instead of statictext. Otherwiese on Linux, lines are truncated and look terrible.
Annoyance: The alt-down key is only working partly for open a combobox. The focus has to be on the arrow down field, which can't me navigated by the keyboard. For closing, you have to take a different(!) key alt + up arrow. Is this possible programmatically? By sending a mouse event? That is almost a joke in my eyes, to not be able to access all gui elements by keyboard only, and that on a linux system. Solution: Don't know any yet. Live with that.
In SetValue, in gtk a EVT_TEXT is fired, in win32 not.
SetBackgroundColour on a ComboBox
Shows no effect, the combobox stays white.
SetPos on a ComboBox or TextCtrl
This does not work for reasons, I do not know. Also a wx.CallAfter did not show success.
Listbox and Listctrl
By typing the first letter, nothing happens. On windows, the marked entry is jumping to the first matching entry. Solution: maybe bind EVT_CHAR to a function, evaluate and mark the according entry.
EnsureVisible on a wx.ListBox
* In windows, if you create a messagebox with wx.YES|wx.NO, the default selection is on yes, in gtk it is on no! * If a Messagebox pops up, the application loses the focus on gtk, on windows not (thus an EVT_ACTIVATE_APP is fired, event if a simple Messagebox is shown; this is annoying, if you do something with this event; for example saving unsaved buffers).
Some are not working for example ctrl-space. Does Linux reserve that hotkey for itself?
Accelerator Key on StaticText
for example wx.StaticText(self, -1, "File &Pattern:"), 0) the accelerator key for gtk does not work here. One has to insert "File Pattern:" with captalized letter.
Behaviour and appearance
wx.MessageBox does not have the focus automatically
<s>That is very annoying. Do we always have to call SetFocus afterwards? And the Messagebox is sometimes not in the foreground. So it is not visible by default. The thing is, the Messagebox has to be confirmed. Otherwise until then, the app do not respond. So it sometime seems, the app hangs, but in reality, a messagebox in the background has to be confirmed.</s> It seems to not happen again with newer Versions of linux...
On Gtk, there is an intially size event, in win32 not.
wx.Window.FindFocus() That is mostly not working on gtk.
In gtk these are only working for menu accelerators, but not for Dialog controls with accelerator keys. Workaround: don't know yet.
bring a frame to the foreground
In Windows, that is done automatically. In Gtk you need to call Raise for that.
Newly created Dialogs do not gain focus automatically
On Gtk, a newly created window (several different dialogs) do not have automatically the focus. You have to call dlg.SetFocus() after the creation.
Annoyance: The bold font is (mostly) bigger than the normal one. Solution: Take a normal font, if you want to have the same sizes for example in a listctrl.
Take care of this, they are not always delivered the way as it is in windows.
Quit an application
If a segmentation fault happen on gtk, but not on windows, the gdb debugger can be very useful. Also useful is commenting out code and try to narrow down the problem. In one case, the frame was being destroyed, and in that process, a function (SetStatusText) was called. That led to a segmentation fault on gtk, but not on windows. A <frameinstance>IsBeingDeleted(): query before solved a problem
In my experience, it happens rather often, that an application crashes in gtk. Most often an little saying segementation fault, the most annoying one. (Please add other experiences and/or tips). Windows seems to me much more robust. It seems also, there are a few differences in sending events. Please see below under debugging, how one can try to isolate and/or find the problem.
The segmentation faults can be best debugged (from what Robin said in the mailing list) with the gdb debugger. (I don't know how to get the debug symbols, if anyone know, please add it here). So you can start gdb xy.py, then type run, and if the program crashes, you get with the backtrace command the stack and hopefully the culprit of the segmentation fault. Here the debug symbols are needed, otherwise, the stack says very little. For that, downloading the Python and wxPython DBG(!) packages is very helpful. (Please add/correct the texts, if they are wrong or somehting is missing or new ideas could be added here).
Ther is the page wxPython Platform Inconsistencies, but the last edits are about four years old. So I doubt, that these entries are up to date.