Itches, Glitches & Anything Else...

[greebo]

Is this better? This is already committed.

 

[OrbWeaver]

Yup, that's what I was thinking.

[OrbWeaver]

1. There's a slight problem with the Find/Replace dialog -- when I click to browse for textures, the browser window appears behind the main dialog and cannot be brought in front (modality problem). This may be Linux-specific if you haven't seen it already.

2. The texture browser in the Light Inspector no longer displays any details for the selected texture, although the preview is OK.

3. What happened to the buttons in the Light Inspector? There used to be OK/Cancel, now there is just Apply. Is this a stop-gap measure for Dave's request to have real-time updates in the Light Inspector?

[greebo]

1. There's a slight problem with the Find/Replace dialog -- when I click to browse for textures, the browser window appears behind the main dialog and cannot be brought in front (modality problem). This may be Linux-specific if you haven't seen it already.

Haven't seen this, must be linux-specific, but it could be possible that I set the modality to MainFrame instead of the parent window. I'll check that.

 

2. The texture browser in the Light Inspector no longer displays any details for the selected texture, although the preview is OK.

Argh, I knew I forgot something, I'll have to copy over the old infostore population code from the LightTextureSelector.

 

3. What happened to the buttons in the Light Inspector? There used to be OK/Cancel, now there is just Apply. Is this a stop-gap measure for Dave's request to have real-time updates in the Light Inspector?

The dialog is behaving now as the Surface Inspector and the Patch Inspector does, they can be floating around while working on the actual map. OK is suggesting that the dialog is closed after clicking, which isn't the case.

 

Similarly, I thought Cancel is not appropriate anymore, but I could re-add it calling it "Reset" instead, triggering a reload of the information from the currently selected light. Should I do that?

[OrbWeaver]

The dialog is behaving now as the Surface Inspector and the Patch Inspector does, they can be floating around while working on the actual map. OK is suggesting that the dialog is closed after clicking, which isn't the case.

Similarly, I thought Cancel is not appropriate anymore, but I could re-add it calling it "Reset" instead, triggering a reload of the information from the currently selected light. Should I do that?

 

That's fair enough, but we should stick to the HIG.

 

http://developer.gnome.org/projects/gup/hi...ws-utility.html

 

What we have here is an Explicit Apply Window, but it is missing two buttons - OK (to apply and close the dialog) and Cancel (to undo all changes from the time the dialog was first displayed) along with the Apply button that already exists.

 

It might be appropriate to use an Instant Apply Window here, where each control would apply its changes immediately (the DoomEdit light inspector does this IIRC), the OK button would just close the dialog and leave all changes intact, and the Cancel button would revert to the initial status. This is what I think Dave's suggestion was about, and I can see the value in this approach.

[greebo]

This could pose some problems with saving the light state though. How are the changes written to the selected entity? Are these merely key/value changes? If yes, it would be possible to save the current keyvalue set and revert it on Cancel, although this information would be immediately lost when clicking on another light. The Cancel button would be not doing the expected job.

[OrbWeaver]

That's why I went for a modal dialog in the first place -- for a non-modal dialog, you have to take into account things like the user selecting a different light, or changing a keyvalue on the existing light (by dragging its box or using the Entity Inspector). It would be necessary to capture these events and update the widgets accordingly in order to maintain consistency.

 

If a non-modal dialog is desired, it might be necessary to use the Entity Inspector's model of instant apply, and have a single Close button to dismiss the dialog. If this is the case, it will be necessary to make sure all of the changes are properly captured by the Undo system so that they can be reverted.

[greebo]

I just noticed that the current light inspector actions don't use the UndoSystem at all, so this has definitely to be changed. I'll open an issue for this.

[greebo]

I've replaced the ArbitraryRotation and ArbitraryScale stuff by this dialog:

 

 

The widget sensitivity is reflecting the current selection. If any entity is selected, the scale manipulation gets disabled. Removal of the old code is nearly done, afterwards I can look into the LightInspector undo stuff.

[sparhawk]

HAH! That was the must stupid dialog IMO. Nice that you changed that. Does it now also update the screen in realtime? Not sure if this was the case in GTKRadiant, but in Doomedit you always had to close the dialog, because the changes were only activated when you pressed OK, which is IMO a really braindead design for such a dialog.

[greebo]

Yes, what you click is what you get. Undoable, of course.

[sparhawk]

Maybe you could add textboxes, that displays the current values, so that you can not it down if you want to go back to a previous setting?

[greebo]

The only thing that I could possibly make editable would be the dimensions of the AAAB of the entire selection, everything else would be ambiguous, I'm afraid.

[greebo]

If a non-modal dialog is desired, it might be necessary to use the Entity Inspector's model of instant apply, and have a single Close button to dismiss the dialog. If this is the case, it will be necessary to make sure all of the changes are properly captured by the Undo system so that they can be reverted.

The LightInspector changes when clicking on "Apply" are undoable now. Should I go further and make all changes instantly applied? This is of course harder to implement, but from working on the Surface and Patch Inspectors I think I know what to watch out for.

[OrbWeaver]

The LightInspector changes when clicking on "Apply" are undoable now. Should I go further and make all changes instantly applied? This is of course harder to implement, but from working on the Surface and Patch Inspectors I think I know what to watch out for.

 

That's probably the best solution from a usability perspective. If all changes are applied instantly, then OK can simply close the dialog, whilst the Cancel button can just invoke the Undo function to restore all previous changes.

[greebo]

That's probably the best solution from a usability perspective. If all changes are applied instantly, then OK can simply close the dialog

This is no problem,

whilst the Cancel button can just invoke the Undo function to restore all previous changes.

although this will be one. The Light Inspector can't keep track of any other undoable actions that might happen while it's open. Imagine a change from a point to a projected light and the user dragging the vertices around. It could never know how "far" to go back to revert the changes since the time it was first displayed.

 

In my opinion the gnome HIG are nice and clean for most applications, but can't be easily applied 1:1 in an application like DarkRadiant, especially when it comes to using the inspectors. If it was up to me, I'd make all changes in the Light Inspector instantly applied and undoable, and ditch the apply button completely (the Surface Inspector and Patch Inspector) don't have one either.

 

That said, I'm all for making the UI as predictable and easy-to-use as possible, but in the end we can't (and shouldn't) turn it in an Office application.

 

(I guess I got dragged away, sorry.)

 

I'll try to look into the instant-apply stuff first.

[OrbWeaver]

Fine, just have a Close button and don't bother with Cancel. The user can then dismiss the dialog and manually use Ctrl-Z to revert the changes.

[greebo]

Sorry, if I sounded uneasy or non-constructive, I don't mean to.

[OrbWeaver]

No problem, there is nothing wrong with trying to maximise the flexibility of the workflow, even if it means more implementation effort. The HIG is only a guideline, so it shouldn't be employed rigidly if doing so would get in the way of user tasks.

[greebo]

1. There's a slight problem with the Find/Replace dialog -- when I click to browse for textures, the browser window appears behind the main dialog and cannot be brought in front (modality problem). This may be Linux-specific if you haven't seen it already.

I just checked, the parent window is set correctly. The ShaderChooser dialog (the one you select the texture) has gtk_window_set_transient_for() such that it's transient for the Find/Replace dialog.

 

Should I set the modal to false?

 

2. The texture browser in the Light Inspector no longer displays any details for the selected texture, although the preview is OK.

This is fixed now.

 

edit: One more thing: The LightInspector actions are instantly applied now. I've added a XMLRegistry key to disable this behaviour. If the instant-apply stuff is disabled, the "Apply" button is added to the dialog, otherwise it behaves as the other Inspector windows (toggle-able by clicking the X or hitting the shortcut).

 

Is this a desirable compromise or should the Apply button be always there (I'd rather have the dialog slimmed down, but this is a personal preference).

[OrbWeaver]

I checked out the new Light Inspector, it seems to work fine without an Apply button except that the "Use start/end planes" checkbox no longer has any effect.

[greebo]

I checked out the new Light Inspector, it seems to work fine without an Apply button except that the "Use start/end planes" checkbox no longer has any effect.

Ok, will check that.

 

edit: Fixed. Forgot to connect the signal.

[greebo]

To post this here: The old menu population code and all the legacy gtkutil/menu stuff is gone now and has been replaced by the MenuManager class (a helper class of the UIManager). Interface: see iuimanager.h. This means a few hundred lines of legacy code less.

 

I already migrated the MRU and the FiltersMenu classes to use the new MenuManager. In order to make the filters compatible with this system, I had to integrate them into the EventManager system. As a result all filters have their own command name (e.g. "FilterWorldGeometry", is automatically generated), which means that they can be assigned shortcuts in the shortcut editor from now on - a nice side-effect for those who make heavy use of filters.

 

Additionally, the Save Region issues are resolved now; all regioned objects are included into the saved file, regardless of the displayed size of the region. The wall brushes don't clip into the light volumes anymore and the brush walls are of finite height.

 

I also fixed the filtered brush faces from being selectable, so it's no longer possible to select them even if they are filtered.

 

And the ShaderChooser dialog is remembering its position now.

[OrbWeaver]

Wow, great progress. This thing will be done soon at this rate.

 

I'm very pleased about the UIManager, this means I can look into the new plugin system for the Objectives Editor. In theory the Radiant plugin system would need to do nothing more than search for and load the DLLs, beyond that the plugins themselves could add their own menu items and callbacks.

[sparhawk]

Speeking of Menus, how about that extension that I mentioned earlier, where def objects can be grouped into a menu hierarchy, instead of having a flat menu whenever you want to assign an entity?

 

BTW: Do you mean svn on the server, or on the client? It means I have to install a commandline client as well?