- Updated Windows build doc, very slight revision. Changed 37 targets to 38.

[xonotic/netradiant.git] / radiant / main.cpp

diff --git a/radiant/main.cpp b/radiant/main.cpp
index 553e878065bcc5e035dde4eafcbfacb7b0eb0a94..0d6d566871da140551184d90f52084f613c87672 100644 (file)
--- a/radiant/main.cpp
+++ b/radiant/main.cpp
@@ -34,6 +34,7 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 #endif
 
 #include <gtk/gtk.h>
+#include <gtk/gtkgl.h>
 #include <glib/gi18n.h>
 #include "stdafx.h"
 #include <assert.h>
@@ -44,6 +45,7 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 
 #include "watchbsp.h"
 #include "filters.h"
+#include "glwidget.h"
 
 bool g_bBuildList = false;
 int g_argc;
@@ -427,6 +429,53 @@ int main( int argc, char* argv[] ) {
        char *libgl, *ptr;
        int i, j, k;
 
+
+  /*
+    Rambetter on Sat Nov 13, 2010:
+
+    The following line fixes parsing and writing of floating point numbers in locales such as
+    Italy, Germany, and others outside of en_US.  In particular, in such problem locales, users
+    are not able to use certain map entities such as "light" because the definitions of these entities
+    in the entity definition files contain floating point values written in the standard "C" format
+    (containing a dot instead of, for example, a comma).  The call sscanf() is all over the code,
+    including parsing entity definition files and reading Radiant preferences.  sscanf() is sensitive
+    to locale (in particular when reading floating point numbers).
+
+    The line below is the minimalistic way to address only this particular problem - the parsing
+    and writing of floating point values.  There may be other yet-undiscovered bugs related to
+    locale still lingering in the code.  When such bugs are discovered, they should be addressed by
+    setting more than just "LC_NUMERIC=C" (for example LC_CTYPE for regular expression matching)
+    or by fixing the problem in the actual code instead of fiddling with LC_* variables.
+
+    Another way to fix the floating point format problem is to locate all calls such as *scanf()
+    and *printf() in the code and replace them with other functions.  However, we're also using
+    external libraries such as libxml and [maybe?] they use locale to parse their numeric values.
+    I'm just saying, it may get ugly if we try to fix the problem without setting LC_NUMERIC.
+
+    Usage of sscanf() throughout the code looks like so:
+      sscanf(str, "%f %f %f", &val1, &val2, &val3);
+    Code like this exists in many files, here are 4 examples:
+      tools/quake3/q3map2/light.c
+      tools/quake3/q3map2/model.c
+      radiant/preferences.cpp
+      plugins/entity/miscmodel.cpp
+
+    Also affected are printf() calls when using formats that contain "%f".
+
+    I did some research and putenv() seems to be the best choice for being cross-platform.  It
+    used to be a function in Windows (now deprecated):
+      http://msdn.microsoft.com/en-us/library/ms235321(VS.80).aspx
+    And of course it's defined in UNIX.
+
+    One more thing.  the gtk_init() call below modifies all of the locale settings.  In fact if it
+    weren't for gtk_init(), we wouldn't have to set LC_NUMERIC (parsing of floating points with
+    a dot works just fine before the gtk_init() call on a sample Linux system).  If we were to
+    just setlocale() here, it would get clobbered by gtk_init().  So instead of using setlocale()
+    _after_ gtk_init(), I chose to fix this problem via environment variable.  I think it's cleaner
+    that way.
+  */
+  putenv("LC_NUMERIC=C");
+
 #ifdef _WIN32
   libgl = "opengl32.dll";
 #endif
@@ -457,6 +506,11 @@ int main( int argc, char* argv[] ) {
 //  gtk_disable_setlocale();
 
   gtk_init(&argc, &argv);
+  gtk_gl_init(&argc, &argv);
+  gdk_gl_init(&argc, &argv);
+
+  // TODO: Find a better place to call this.
+  gtk_glwidget_create_font();
 
   if ((ptr = getenv ("Q3R_LIBGL")) != NULL)
     libgl = ptr;
@@ -586,7 +640,6 @@ int main( int argc, char* argv[] ) {
   we need to catch when it happens, to cleanup the stateful prefs which might be killing it
   and to turn on console logging for lookup of the problem
   this is the first part of the two step .pid system
-  http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=297
   */
   g_pidFile = g_strTempPath.GetBuffer ();
   g_pidFile += "radiant.pid";
@@ -644,7 +697,6 @@ int main( int argc, char* argv[] ) {
   // (otherwise, they run it, crash it, and blame us for not forcing them hard enough to pay attention while installing)
   // make something idiot proof and someone will make better idiots, this may be overkill
   // let's leave it disabled in debug mode in any case
-  // http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=431
 #ifndef _DEBUG
   //#define CHECK_VERSION
 #endif
@@ -724,7 +776,6 @@ int main( int argc, char* argv[] ) {
 
   /*!
   now the secondary game dependant .pid file
-  http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=297
   */
   g_pidGameFile = g_PrefsDlg.m_rc_path->str;
   g_pidGameFile += "radiant-game.pid";
@@ -800,7 +851,6 @@ int main( int argc, char* argv[] ) {
     Sys_LogFile();
   }
 
-  // FIXME http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=639
   // we should search in g_strTempPath, then move over to look at g_strAppPath?
 #ifdef _WIN32
   // fine tune the look of the app using a gtk rc file
@@ -856,7 +906,7 @@ int main( int argc, char* argv[] ) {
 
   // spog - creates new filters list for the first time
   g_qeglobals.d_savedinfo.filters = NULL;
-  g_qeglobals.d_savedinfo.filters = FilterUpdate(g_qeglobals.d_savedinfo.filters);
+  g_qeglobals.d_savedinfo.filters = FilterAddBase(g_qeglobals.d_savedinfo.filters);
 
   g_pParentWnd = new MainFrame();