Customisable Interface

[OrbWeaver]

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.

 

My personal preference would be to ditch it, but some people like it (I think Crispy preferred it, for instance). With that in mind I think we should keep it unless we can provide an interface which is universally accepted as preferable.

[greebo]

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?

[greebo]

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.

[greebo]

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

[OrbWeaver]

No crashes here (I opened up a couple of windows and closed them without problems).

[greebo]

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.

[OrbWeaver]

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.

 

I've encountered both of those, in one situation or another. Singleton dialogs which should be hidden but get destroyed will give you an error like "GTK_IS_WIDGET failed" next time you try to open them; returning the wrong value from a callback may do all sorts of things if other events should be called but don't anymore.

[Crispy]

The nice thing about the split pane view is that you don't need to faff around with windows as much. None of the views can ever overlap each other, so all you need to worry about is moving the other tool windows out of the way (or you can just close them since they're easily re-opened).

 

I have a couple of friends who wrote their own window manager for Linux that works on a tiling basis (most of the time - you can also "float" windows, so that they behave as they normally do in most windowing systems). They swear by it, and I can see their point. One day I'll probably end up using it myself. (Just like one day I'm going to ditch Windows for everyday stuff...)

[greebo]

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?

[Crispy]

The quad-split one looks the most useful to me. From a personal preference point of view, I can't really see the point of the other two.

 

OTOH, some people may use it - and if you're going to have to support one fixed layout, is it really any more work to support the others? Might as well leave it in.

[OrbWeaver]

What we really want is an Eclipse-style interface. I wouldn't have the first clue how to implement this in GTK however.

[greebo]

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.

[greebo]

I committed another fix for the "feature" that caused XYViews to stay on top even if the main window got minimised. The original GtkRadiant code did implement this and I took the relevant part and packed it into the TransientWindow class.

[greebo]

Now on SVN: the user can edit the shortcut/command associations directly in DarkRadiant:

 

 

Just double click on any of the commands and press the new shortcut. An "overwrite" confirmation dialog is shown if the shortcut is already in use by another command.

[OrbWeaver]

Merging now.

[sparhawk]

NIce! It really looks good, and it seems that our Darkradiant will be much more userfriendly than GTK Radiant.

[greebo]

I've added another functionality to the MouseEventManager: if the user is holding down a modifier, the possible mouse events (Zoom, Toggle Selection, etc.) are shown in the lower left status bar, like this:

 

 

I also changed the status bar updater in mainframe.cpp to accept pango markups, so that the status texts can be properly formatted.

[OrbWeaver]

That's helpful, Inkscape does something like that when you drag stuff with the mouse.

[greebo]

I've committed a first draft of a plugin that should handle the orthoview image overlays. It's not functional yet, should I stop working on it till 0.8.0 is released or should we just omit shipping the dll with the package? It's not relied upon by the main code at the moment.

[OrbWeaver]

I suggest committing into a branch for the time being, so that 0.8.0 can be built from the trunk and the new changes merged in later.

 

If you haven't used a branch before in SVN, it is quite easy - you just choose the "Branch/Tag" menu option (in Eclipse or Tortoise, the dialog is almost identical), then enter a URL underneath the branches/ top-level folder, choose "From Working Copy" and tick the option to "Switch to new branch". Then all of your subsequent commits are made into this branch.

[greebo]

Ok, I'll try it out.

 

Currently, the plugin.cpp file contains a GlobalOverlayModuleRef in its dependencies, I will commit a reverted version.

 

edit: done.