greebo

I hate to say it, but I noticed a crash (in the latest SVN). If one destroys an xyview and types a few times on Ctrl, Alt or Shift (haven't tested with other keys, but this is bad enough), DarkRadiant bails out. As the number of times I have to press the keys till the crash is actually happening is not the same each time, I suspect this is GDK-related, and I hopefully will find the source. edit: I could find the source, fix is in progress and is committed soon. Looks like the GtkRadiant WindowObservers weren't designed to be actually deleted during runtime. edit2: fixed.

I can't say anything about whether some things should be put into D3 scripting or into the C++ code, but - by all means - give this guy a chance.

I have ironed the small issues I mentioned in the other thread concerning the keypress events not being passed to the EventManager when the top-level dialogs are in focus (Entity Window, Surface Dialog, etc.). These dialogs can now be connected via connectDialogWindow() and get a chance to process "their" keypress events before the global shortcuts are fired by them.

Ok, I've updated the versioning and the upgradepaths. The XMLRegistry should be ready to go.

Those issues are not too big, I will hopefully have them resolved in a few hours. What we need to do is to upgrade the registry version, I will do this at once.

Well, I have some smaller issues regarding the keyboard handler on my list (the ESC key is not propagated to the keyboard handler when the entity inspector is focused, for instance), but in principle the version is ready to go. The more people work with DarkRadiant, the more bugs will be discovored as well, which in turn is good for us. How much work does the compiling of a new release imply for you?

Glad you like it. It's perfectly safe to observe several keys, the XMLRegistry maintains a multimap like this containing all the RegistryKeyObservers: typedef std::multimap<const std::string, RegistryKeyObserver*> KeyObserverMap; Currently there are approximately 30-40 KeyObservers registered at runtime, some even observing the same keys.

According to his profile he is still a "Member". Or were his rights set independently from his member type?

It also hold the callbacks to connect them with the EventManager. At the moment, only function calls with no arguments can be connected, therefore I decided to create a set of GridItem instances that provide such a callback. Do you suggest to implement something different?

There were some problems with the grid not reacting to the hotkeys, so I rewrote the grid code into a separate module. Please check, if everything is compiling, or if I forgot something.

I'm currently hunting after another crash that occurs after closing any XYview and going into freelook mode in the camview (latest SVN). The crash happens as soon as the freelook mode is enabled so there may be some handler still attached. I don't know exactly where it happens, so this may take a while. Edit: I think I have an idea where this could be happening. Edit²: fixed.

On SVN: the XY view window sizes and positions are now saved into the XMLRegistry and restored on Radiant startup. Still to come: Make the camwindow use the new WindowPosition class and dump the legacy code from window.h.

Well then, let's keep it . As there are three different kinds of splitplaned views, do you know if one of them is preferable over the others / or if one is completely obsolete?

Have you heard any news from namespace? Has his account been approved already?

I've learned now that it is bad to return true in an GTK "delete-event" callback. And there were some problems with the XYWnd destructor dereferencing its GLWidget instead of hiding it. This way my destroyOrthOView() method could not destruct them anymore.

Ok, I think I fixed the crashes. Can you test it on your system, Orbweaver? Just add a new xyview and close it.

Whoopsie, just realised that I get a crash after closing one of the newly created xy views. I'm off to investigate this... edit: Damn, the crashing call is hidden somewhere. Orbweaver, could you give me a hint, where the crash is happening? Perhaps it is some GTK-related crash with some widget still referenced? edit2: I think I already have a trace, stay tuned.

Well, it's always possible to position the windows in the same way as the splitpaned layout does, or is it the coupled resizing which makes this viewtype preferable?

On a similar note: Do we still need the splitplane view? Otherwise the window management would be a bit easier, as there are lot of if clauses involved to determine which window can be toggled and which can not.

I introduced a new command ("NewOrthoView", shortcut is Ctrl-Alt-N by default) to create a new XY view. This can of course be repeated: Now the view menu toggle "XZ Side View" and other stuff will become obsolete. What's still left is the ability to save the current number of windows and their size/position to the registry and restore them on restart.

Be sure to clean your install/modules/ folder to remove any legacy .dll/.so files before rebuilding.

I haven't touched that code, so perhaps there is something else broken? I had this problem a while ago when creating AI, which was caused by an old module object (.dll/.so) left in the modules/ folder. Are you compiling under Linux?

I forgot to remove the typdef from the plugin after moving the IEventPtr definition into the include files. I have a working version now that will committed as I type. Please do test, if DarkRadiant still crashes. I will continue to work in the other changes you suggested.

I just saw that there is a dynamic_cast for boost::shared_ptrs: shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const & r); But I will nevertheless work around the above behaviour. Currently I'm googling for this problem: IEventPtr(new Command(name, callback)); which tries to allocate a new Command object (deriving from Event deriving from IEvent), and turn it into a boost::shared_ptr. However, I'm getting this error: boost.w32/include/boost/shared_ptr.hpp:211: error: invalid conversion from `IEvent* const' to `Event*' Maybe this problems has to do with the const although I don't know exactly how I can work around it. Would it be safe to use this: IEvent* event = new Command(name, callback); _events[name] = IEventPtr(event); or is it mandatory to place the new into the IEventPtr constructor? edit: Nevermind, the above doesn't work either. edit2: Even more nevermind, I think I found the problem...

Well, it may be that my IEvent ABC is kept a bit too general then. The above example was the only case I needed to distinguish between a Toggle and an IEvent anyway. I will work around this.