X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/2dc5505ebcf8412d425028e91297f061e685368f..641cdc233d23344b88a6e24151708f669c429917:/docs/html/faqgtk.htm
diff --git a/docs/html/faqgtk.htm b/docs/html/faqgtk.htm
new file mode 100644
index 0000000000..6da8b25c07
--- /dev/null
+++ b/docs/html/faqgtk.htm
@@ -0,0 +1,126 @@
+
+
+
+
+wxWidgets 2 for GTK FAQ
+
+
+
+
+
+
+
+
+
+
+wxWidgets 2 for GTK FAQ
+
+ |
+
+
+
+
+
+See also top-level FAQ page
+and Unix FAQ page.
+
+List of questions in this category
+
+
+
+
+
+
+
+wxWidgets 2 for GTK is a port of wxWidgets to the GTK+ toolkit,
+which is freely available for most flavours of Unix with X. wxWidgets 2 for GTK is
+often abbreviated to wxGTK. wxGTK has a separate home page here.
+
+
+
+
+If your program reads the floating point numbers in the format 123.45
+from a file, it may suddenly start returning just 123 instead of the
+correct value on some systems -- which is all the more mysterious as the same
+code in a standalone program works just fine.
+
+
+The explanation is that GTK+ changes the current locale on program startup. If
+the decimal point character in the current locale is not the period (for
+example, it is comma in the French locale), all the standard C functions won't
+recognize the numbers such as above as floating point ones any more.
+
+
+The solution is to either use your own function for reading the floating point
+numbers (probably the best one) or to call setlocale(LC_NUMERIC, "C")
+before reading from file and restore the old locale back afterwards if needed.
+
+
+
+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. Other features may be supported in the
+future, probably as a separate library.
+
+
+
+
+It seems that some versions of RedHat include a badly patched version of GTK+ (not wxGTK)
+which causes some trouble with wxWidgets' socket code. Common symptoms are that when
+a client tries to establish a connection to an existing server which refuses the request,
+the client will get notified twice, first getting a LOST event and then a CONNECT event.
+This problem can be solved by updating GTK with an official distribution of the library.
+
+
+
+
+Robert Roebling replies:
+
+"The important thing is the libc version that your app
+is linked against. The most recent version is 2.2.5
+and programs linked against it will not run with version
+2.1.X so that you will fare best if you compile your app
+on a 2.1.X system. It will then run on practically all
+Linux distros (if you link you app statically against
+the image libraries and std C++ lib)."
+
+
+
+
+No, this is not possible. It leads to crashes in GTK+.
+
+
+
+
+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 wxPanel
+inside the frame and register the key event handlers for the panel, not the
+frame.
+
+
+
+
+
+When a fatal X11 error occurs, the application quits with no stack trace.
+To find out where the problem is, put a breakpoint on g_log (b g_log
+in gdb).
+
+
+
+
+
+
+
+