DarkRadiant 2.0.0 released

[greebo]

@OrbWeaver: I'd propose a change to the GroupDialog destructor. Before the owned wxNotebook is destroyed, the GroupDialog should unsubscribe from the page switch event, since the whole instance is in process of going down the drain anyway. Let me know whether I should work on that and push a commit or whether you have time to do it.

[OrbWeaver]

@OrbWeaver: I'd propose a change to the GroupDialog destructor. Before the owned wxNotebook is destroyed, the GroupDialog should unsubscribe from the page switch event, since the whole instance is in process of going down the drain anyway. Let me know whether I should work on that and push a commit or whether you have time to do it.

 

It's definitely something along those lines, since removing the call to removeLayout from the MainFrame's shutdown code stops the crash, but I don't yet understand why, because while the EmbeddedLayout does explicitly remove the "textures" page from the GroupDialog, the implementation uses wxNotebook::DeletePage() which seems to be the correct way to remove a page from a wxNotebook and should not leave it in a broken state when its destructor is called (it would make more sense if we were simply deleting the page without calling DeletePage, since this would result in double deletion).

 

I also wondered if this is a double deletion caused by the fact that GroupDialog is both owned by a shared_ptr (which is visible in the stack trace) and embedded into a parent wx window which will try to delete it as a child widget in the usual fashion. But this doesn't make sense, because (with my local changes) the call to RadiantModule::broadcastShutdownEvent happens in a function called from the main window's wxCloseEvent which happens before the call to wxWindow::Destroy(), not afterwards.

 

In any case, if you think you have any useful quick fixes feel free to make them; otherwise I will look into this but it might take some time as I have to familiarise myself with the wxWidgets mechanics as well as our existing code.

 

EDIT: After re-reading the stack trace I now see what your suggested fix is referring to: the GroupDialog destructor has finished and its parent classes are being destroyed, but the parent window class owns the child wxNodebook which is still connected to the signal handlers in GroupDialog which is already destroyed in C++ terms. So probably what we need to do is tell wxWidgets to destroy/delete the wxNodebook in the GroupDialog destructor rather than waiting for the parent class destructors to do it.

[greebo]

The fix is in my master branch, does it fix this specific crash on your end?

[OrbWeaver]

The fix is in my master branch, does it fix this specific crash on your end?

 

Ah, I was so busy investigating this I forgot to check if you had already committed a fix. My own fix was actually very simple: the GroupDialog now owns a wxWindowPtr to the notebook rather than a raw pointer, which ensures that the notebook is destroyed as soon as the GroupDialog destructor finishes, rather than waiting for the top-down wxWidgets hierarchy to delete it. I had to do this with the toolbars in the TopLevelFrame too for the same reason.

 

I haven't merged your branch yet but I will do so soon since it looks like you've made an important change to the menu systems. I have pushed my changes so far into Github — they are probably not ready for full merging yet (in particular I need to figure out why the camera panel is becoming bigger with each shutdown/restart cycle) but it might be worth checking I haven't introduced any problems on Windows that weren't there already.

[SeriousToni]

Congratiulations on the 2.0 full release! Good to see there's still some nice development going on with DR!

 

But what is this important GTK thingy that makes it a major release? (couldn't get my hands on the new version yet)

[AluminumHaste]

The installer on the website wants to create a uninstall entry called DarkRadiant 1.8.1 x64, instead of DarkRadiant 2.0.0 x64

EDIT: Just got a crash.

 

I went from maximized to restored and then pressed the X to close and got this:

 

[greebo]

Yes, that bug has already been fixed in source. Don't know about the uninstaller entry, I set everything to 2.0.0 in the innosetup scripts.

[motorsep]

Interesting: http://www.curiousconstructs.com/projects/headitor-toolset/ (about Prefabs).

 

Would it be something that could be added to DR via Python add-on or would it be something requiring complete re-design of DR ?

[Tels]

Interesting: http://www.curiousco...aditor-toolset/ (about Prefabs).

 

Would it be something that could be added to DR via Python add-on or would it be something requiring complete re-design of DR ?

 

That sounds awefully like what I'm doing with Swift Mazes Shameless plug: see here: http://forums.thedarkmod.com/topic/14119-procedural-dungeon-crawler-generation-swift-mazes/page__fromsearch__1 and http://www.swift-mazes.com/

[Goldwell]

Thanks for your hard work and congratulations on the release going to give this a try right now!