I first tried to make the current selected game a latched value but I did not managed to get something working correctly. The current code, much simpler, works. There can be an unknown issue when the user does not restart after having changed the game, but if this hypothetical issue exists this issues was already there and is not introduced by this MR. This MR is already an improvement on that part since user is informed the editor has to be restarted, and the user is asked to do it. And if the user refuse to restart, the user knows he had too.

Then, fixing that hypothetical issue may be another MR, to fix an issue that is close to the current topic but not introduced by the current MR.

This is an usability improvement I dream about since years, see #42 (three years ago), !55, !63, etc. Previous work to make radiant able to load map by command line where done with that feature in mind.

Radiant editor is now able to restart itself when needed, and it reload itself with the current edited map if needed.

The command line map opening is now fixed on Windows, so if support is not on par with Linux (see !109) because of missing integration, it's now possible to open a map on radiant by opening the file once the user set-up the association. This fix was required to make Radiant able to restart itself with the current map on Windows.

Modifying the UI layout and other options like that now asks the user to restart immediately, if user say yes, radiant is restarted with the new layout and other options applied, with current map and environment and so on.

Changing the current game now requires a restart. It always required a restart but user was not informed, now the user is not only informed but can restart immediately the editor by clicking “OK”. It makes Radiant very more convenient for people mapping for more than one game. In fact that was the reason I do this MR, and I think about it since I think about command line support: click a Xonotic map on you file browser, get Radiant opening it, discover your editor is currently set-up for Unvanquished, open preference and set the current game to Xonotic, say yes when Radiant asks for restarting, you are now editing your Xonotic map with your Xonotic environment with the Xonotic NetRadiant profile.

Note: I would like to see that huge improvement: have the game list in the toolbar: allowing people to change the game without opening any menu neither any preference window. Perhaps a less advanced solution would be to have in toolbar an icon that is a shortcut to the game option in preference Window. It maybe easier to do, I don't know. But I currently think the drop-down list would be better, especially because it would also displays to the user what is the current game.

Note: the restart mechanism starts the child in background and since the parent stops as long the child is started, for the user it behaves like the application going in background and losing foreground control in a terminal on restart.

First, this feature leads to an horrible behavior on Windows where the application ends in a loop of endless minimization and restoration, probably because the window manager minimizes or restores the whole application once a floating window in minimized or restored, leading to a race condition between all floating windows, some being minimized and others being restored at the same time, triggering the minimization and the restoration of the others, and so on. It's difficult to say such issue will never happen on other OS or with some window manager.

Second, those floating windows are expected to be displayed or hidden using menu or keyboard shortcut, it's a design choice. Then the OS-specific way to minimize/restore them is superflous and less efficient.

Finally, the mainframe is not created as a floating window so the user minimizes the application by minimizing the mainframe.

use a dedicated heretic2 subdirectory for Heretic 2 stuff, and do other things like h2data printing h2data instead of qdata in messages.

Thomas Debesse (ae813919) at 13 Jul 18:06

Merge branch 'heretic2' into 'master'

... and 5 more commits

mac compilation is fixed. In anyway it does not mean it works (it currently requires a patched gtkglext, and there is some bugs), but compilation is fixed.

macOS Sierra Version 1.12.4

In cmake/FindGtkGlExt.cmake, it's searching for gtkglext-x11-1.0 when it should be searching for gtkglext-1.0.

[ 70%] Building CXX object libs/gtkutil/CMakeFiles/gtkutil.dir/glwidget.cpp.o
At revision 138.
/Users/viroemer/Devel/wtfbbqhax/ghub/netradiant/libs/gtkutil/glwidget.cpp:31:10: fatal error: 'gtk/gtkglwidget.h'
      file not found
#include 
         ^
1 error generated.

I dunno how to fix this one

/Users/viroemer/Devel/wtfbbqhax/ghub/netradiant/radiant/qgl.cpp:62:10: fatal error: 'gdk/gdkx.h' file not found
#include 
         ^
1 error generated.

Or this one

/Users/viroemer/Devel/wtfbbqhax/ghub/netradiant/radiant/server.cpp:154:44: error: use of undeclared identifier
      'RTLD_DEEPBIND'
        m_library = dlopen( filename, RTLD_NOW | (RTLD_DEEPBIND + 0) );

polishing stuff a bit more…

use a dedicated heretic2 subdirectory for Heretic 2 stuff, and do other things like h2data printing h2data instead of qdata in messages.

Thomas Debesse (5bacc7d8) at 05 Jul 22:07

Merge branch 'winconsole' into 'master'

... and 2 more commits

Previously on Windows the stdout stuff was only printed on MinTTY console or SSH shell, this change makes the tools to target the console subsystem so they also print stdout on cmd console.

This also makes the tool spawning a cmd console windows when not started from a console, allowing people to monitor what is printed.

It's not very intuitive and explicit but the WIN32 cmake keyword in add_executable call is to not target the console subsystem but only the graphical one.

So console tools just have to not use that keyword, even if they may display in a window like when doing q2map -glview.

Then the WIN32 keyword is a kind of “no console” keyword.

This is a way to check if an exe targets the console subsystem or only the windows subsystem:

$ objdump -p netradiant.exe | egrep '^Subsystem'
Subsystem		00000002	(Windows GUI)

This is a way to check if an exe targets the console subsystem:

$ objdump -p q3map2.exe | egrep '^Subsystem'
Subsystem		00000003	(Windows CUI)

Note that this one targets console and only console is reported, but is expected to display a windows with -glview option:

$ objdump -p q2map.exe | egrep '^Subsystem'
Subsystem		00000003	(Windows CUI)

See it in action:

♦

now the diff is very small.

Without I_KNOW_MAKEFILE_IS_DEPRECATED=1 being set, calling legacy Makefile with make tells user this is deprecated and aborts telling what to do to override:

$ make
DEPRECATED: Makefile build is deprecated, use CMake instead, see README.md

Makefile:3: *** I_KNOW_MAKEFILE_IS_DEPRECATED is not set.  Stop.

requires make to be called this way:

make I_KNOW_MAKEFILE_IS_DEPRECATED=1

WIP: because it must not be merged before xonotic!45 is merged

Previously on Windows the stdout stuff was only printed on MinTTY console or SSH shell, this change makes the tools to target the console subsystem so they also print stdout on cmd console.

This also makes the tool spawning a cmd console windows when not started from a console, allowing people to monitor what is printed.

It's not very intuitive and explicit but the WIN32 cmake keyword in add_executable call is to not target the console subsystem but only the graphical one.

So console tools just have to not use that keyword, even if they may display in a window like when doing q2map -glview.

Then the WIN32 keyword is a kind of “no console” keyword.

This is a way to check if an exe targets the console subsystem or only the windows subsystem:

$ objdump -p netradiant.exe | egrep '^Subsystem'
Subsystem		00000002	(Windows GUI)

This is a way to check if an exe targets the console subsystem:

$ objdump -p q3map2.exe | egrep '^Subsystem'
Subsystem		00000003	(Windows CUI)

Note that this one targets console and only console is reported, but is expected to display a windows with -glview option:

$ objdump -p q2map.exe | egrep '^Subsystem'
Subsystem		00000003	(Windows CUI)

See it in action:

♦