Jump to content
The Dark Mod Forums

Recommended Posts

While reorganising the selection system I found some code parts that are relevant for determining which modifier & mouse button combination is needed to perform which action. I also found some stuff in include/windowobservers.h that is related to the mouse button mapping.

 

At the moment Radiant recognises only three buttons (with IDs 1, 2 and 3 for left, middle and right button).

 

I did a quick check and could find out that the thumb button of my Logitech MouseMan Optical has ID=4. I use this button a lot (mainly as double click button).

 

I will dig in some more and post my progress here, eventually I can come with some flexible system, that allows the user to assign even more mouse buttons if he wanted to (and if he knows the button ID, which is not a problem, as I already added some notify message when an "unknown" button ID is incoming).

 

I would think of some sort of translator class that gets the mouse button IDs and keyboard modifiers as input and returns the according state. The information of what combination is translated into which state is stored in the registry. So, if the RadiantSelectionSystem wants to know how to interpret the incoming input signals, it asks this class and retrieves the according state.

Link to post
Share on other sites

I've implemented an EventWrapper class (don't know if the name is appropriate) that interprets all the incoming button/modifier combination and returns a result. All the buttons/modifier combinations are defined in the user.xml file. Currently I'm planting this system into the XY View, which is progressing well so far.

Link to post
Share on other sites

Current status: The RadiantWindowObserver and the XY View are already using the new system.

 

I already tested it with a Blender-style view drag (Alt-Shift LMB) and a Selector that's not using shift, i.e. pure LMB for selecting. I also de-coupled the NewBrushDrag feature from the selection event such that one can define anything else for a BrushDrag (like Alt-LMB drag). The GTKRadiant defaults are of course working as well.

 

What's left is the Camera Controls (won't be too hard) and the code clean-up (there is a lot of unneeded stuff in the window observers).

Link to post
Share on other sites

Sounds good. Is the idea that the mapping between control combinations and the Radiant-internal modifier state is abstracted, so that it can be modified to allow different key combinations to set the same internal state?

 

I'd like to be able to ditch the horrible Shift-to-select key interface, I really cannot understand the point of it.

Link to post
Share on other sites
Is the idea that the mapping between control combinations and the Radiant-internal modifier state is abstracted, so that it can be modified to allow different key combinations to set the same internal state?

Yes, this was the idea to introduce an intermediate layer who takes care of all the distinguishing.

 

I'd like to be able to ditch the horrible Shift-to-select key interface, I really cannot understand the point of it.

It's of course possible to change it, I tested the system with the Radiant default settings as well as with a LMB selector without any modifiers. One has to look out for double assignments of button/modifier combinations, as it may be possible, that one combination is recognised and hence catched by an "earlier" callback method and never reaches the "deeper" queries. It's perfectly safe to experiment with the settings, not everything is possible.

 

One can also use up to five mouse buttons now (three is the default). I tested my setup with my thumb button assigned to the "Paste Texture" command, works like a charm.

Link to post
Share on other sites

Ok, the first implementation is committed, along with some changes and documentation here and there.

 

The XYViews, the CamView and the RadiantWindowObserver are using the EventMapper class to retrieve their events/states.

 

All the settings are saved in interface.xml and are quite straightforward to use. One thing I changed in comparison to the original GTKRadiant settings is the forward strafe behaviour of the camera view. I reversed the direction such that a mouse "up" movement actually moves the camera forward, as it was already suggested by SneaksieDave.

 

Code cleanup is still to come. :)

Link to post
Share on other sites

I'd call it input.xml just for clarity, but looking good.

 

How do I make a single-left-click to select mode? I tried changing both CycleSelection and ToggleSelection to a simple MOUSE_LEFT with no modifiers but all that happens is that the old modifiers stop working but left-click still only does a NewBrushDrag.

 

The new strafing is an improvement, but the up/down directions now seem to be reversed for the strafemode that uses only Control (rather than Control/Shift). Maybe they were always like this but I only notice because the Control/Shift mode is fixed.

Link to post
Share on other sites

Ah, I seem to have added one multiplier too much, I will fix this soon.

 

@single-left-click: I think you have to move the NewBrushDrag to something different like Alt-LMB, because this event gets catched and is not passed to the RadiantWindowObserver. Then you can change the ordinary selector to something different.

 

I also believe that it is not possible to set the CycleSelection to the same buttons/modifiers as ToggleSelection, but I may be wrong here. Would this make much sense to have them undistinguished?

Link to post
Share on other sites

Ah yes, it seems I have to change "Manipulate" to something different, which of course makes resizing inconvenient. I guess I am trying to do something more complicated than the system allows through simple reassignment -- using left-click to do CycleSelection AND NewBrushDrag AND Manipulate depending on context.

Link to post
Share on other sites

It's kind of tricky to determine for the system what the user actually wants to do, hence the massloads of different button/modifier combinations in vanilla GTKRadiant. A NewBrushDrag can be activated when 0 brushes are selected, but that can be the same circumstance in a Selection drag, so how would DarkRadiant know? Something similar goes for the manipulator/selector distinguishing.

 

I for myself will put NewBrushDrag to Alt-LMB, as in most of my mapping time I'm doing selections and manipulations, only a minimal percentage of my actions is creating new brushes (in later stages of my Bonehoard mapping I didn't create any brushes at all, mostly it's messing around with textures and grid alignments).

 

However, feel free to suggest something, I could have a look if it's somehow possible to implement it.

Link to post
Share on other sites

I think what I'd really like is the selection system that is used in drawing applications - left click to select or cycle through selectable objects, but once you select an object you can use left-drag to resize or move control points etc.

 

I am happy to use a modifier to drag out a new brush however.

Link to post
Share on other sites

I think I get the idea what you want to do. I could change the system such that if nothing is selected, the left click is interpreted as "selection", whereas if the selection count > 0, the click would be seen as "manipulate". How would you add more objects to your selection? Would you want to do it by Shift-LMB?

 

I could add such a "SelectionCount" condition to the XML file and have it checked by the EventMapper.

Link to post
Share on other sites

Shift-click is fine for adding more objects to a selection, this is what is used elsewhere.

 

Don't go adding too many special cases or wrappers just to implement this however -- if it can be done via the existing system through suitable abstraction then all well and good, but if not it is best to leave it unsupported until the system is properly overhauled.

Link to post
Share on other sites
I think what I'd really like is the selection system that is used in drawing applications - left click to select or cycle through selectable objects, but once you select an object you can use left-drag to resize or move control points etc.

 

I am happy to use a modifier to drag out a new brush however.

Changes committed. It wasn't too hard after all, I had to add a new minSelectionCount condition and the event "Select" to the XML file, that is evaluated by the EventMapper. Check out the file input_orbweaver.xml, where I stored the settings as you suggested:

 

ALT+Left-Click: NewBrushDrag

Left-Click (nothing selected): Select

Left-Click (anything selected): Manipulator

SHIFT-Left-Click: Toggle Selection (as in vanilla GtkRadiant)

 

Gtkradiant defaults are working as well of course, just leave the new event "Select" commented out.

Link to post
Share on other sites

I will also take a look at the camera movement shortcuts, which seem to be hardcoded. Perhaps I can make them use the shortcuts.ini file, so that the user can use the WASD keys instead of the arrow keys to navigate the camera. If this cannot be done easily, I will come up with something else.

 

edit: Just realised that it is already possible to define the free move shortcuts, so I guess there is nothing to do here.

 

I will now clean up some code and see if there is anything else left to do...

Link to post
Share on other sites

Does any of this facilitate the "drag-to-move" camera motion, rather than "right-click to toggle on/off" which is currently implemented? I think there were suggestions from a couple of people that drag-to-move would more intuitive.

Link to post
Share on other sites

I don't think so. It would take some alternative callbacks to implement this, which maybe tedious, but definitely feasible. I could try to implement it, if it is a priority.

Link to post
Share on other sites
  • 3 weeks later...

I will post this here, as it seems to fit here in some way: I rewrote the XYView management and moved it out of the MainFrame class into a newly written XYWndManager class, that takes care of all the window allocation stuff and calls to the currently active view.

 

As a nice side effect of this, it's now possible to switch the viewtype (XY, YZ, XZ) of any available view (in floating window layout), not just the default view of the three possible windows. This was a bit of a nuisance and is part of the past now :).

 

In theory it should even be possible to have two (or even more) XY views, but the methods aren't implemented yet, but I think this could be nice to have in some situations.

 

The whole thing is not finished yet, as I still have to move all the preference settings into the XMLRegistry, but this should be finished this afternoon.

Link to post
Share on other sites
In theory it should even be possible to have two (or even more) XY views, but the methods aren't implemented yet, but I think this could be nice to have in some situations.

 

That sounds like a nice Blender-like feature - being able to create new views and focus them on whatever you want, on demand. It should also alleviate one of the frequent complaints on the GtkRadiant mailing list, that of there being no Z window (like DoomEdit).

Link to post
Share on other sites

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:

 

xyviewsuy2.th.jpg

 

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.

Link to post
Share on other sites

Excellent. Mappers will like this, I'm sure (apart from those using the old splitpane view, but that's their choice).

 

One thing I need to look into is making the interface proper MDI, rather than this strange "SDI with hacks to make child windows disappear" that we have at the moment. With proper MDI, all of the child windows are within a "workspace" and cannot be positioned over the toolbar or menubar, as they can at present.

Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...