[SUGGESTION] Room Explorer: a tree-like control for navigating room contents.

[Crimson Wizard]

Many years ago, when the open source stage of AGS has just began, people were discussing means to improve it. Perhaps I was not the only one, but once I suggested to make a room contents explorer panel, similar to the Project Explorer, with a tree-like structure. I had Project Explorer as an example, but I recall that others also were suggesting art software as a reference (like Photoshop, with its groups and layers).

Unfortunately, tzachs, who was intending to work on this, had an opinion that another explorer-like panel would take too much extra space on screen. Somehow his idea was that the AGS UI is already too clogged. This is why he went the direction of Navigation bar, that we have today.

But this navigation bar turned to have a number of usability issues, and is difficult to customize too.

My suggestion is to revive the topic of a proper room explorer, and design one at least "on paper", defining which would be more convenient.

[Alan v.Drake]

I remember we ventured the idea some time ago. IMO, a tree panel akin to painting apps is the most convenient option for users.
Besides, if it were done as a dockpanel panel it could be positioned on the side of the room panel as click-to-expand, so it doesn't waste space.

I can't think of any other way to make it more intuitive.
As a tree panel it would be immediate to switch bewtween modes. Visibility and lock could be implemented by adding clickable icons.

There isn't much else to say, I think.
A tree view with the same node structure as the navigation bar is all one could need.


- Alan

[Snarky]

This sounds like a good idea to me. I've always found the editing tools in the room editor unintuitive and fiddly to use.

I'm not quite sure I understand or can envision exactly how it's meant to work. The analogy with painting apps is good (after all, a lot of it is essentially a painting app), but in the ones I'm familiar with, like Photoshop, there are two panels: a tool panel and a layer panel. But for the AGS editor, the relevant tools may very depending on the layer type (drawing tools aren't relevant for objects, for example), so the UI needs to be a bit different, no?

Also, there is a natural connection between the "layer" (e.g. a walkable area or an object) and the properties of that layer, so will the properties pane and the layer panel be linked somehow?

[Crimson Wizard]

The point of this suggestion is to have a tree-like object explorer, everything else stays the same.
But if you think the toolbar should be changed to something else, that would be a different task. I believe these two panels may be replaced separately and not depend on each others looks.

The properties pane is linked to the "selected" object. How the object is marked "selected" is a question of UI. Right now it's selected if it's clicked upon in a room with a selection tool, or selected in a navigation bar. If there's a tree explorer, then it will get selected by selecting an item in the tree. That's essentially same thing, except command comes from another kind of gui.

[Radiant]

CW pointed me to this thread...

Speaking for myself, I find the current "ToolStrip" (the navigation bar that lets you see and edit walkbehinds/regions/walkables/etc) very impractical: it looks unintuitive, contains too many buttons or button-likes, doesn't support mousewheel or keyboard shortcuts, and generally requires multiple clicks for a simple task. I've been informed that it works that way so as to make all objects/walkables/edges/etc in a room work in the exact same way, but I don't think this is helpful; they are different classes of things, they don't combine well into a one-size-fits-all interface.

I'd say that the easiest step from here would be to revert to the menus used back in AGS 3.4.3, which let the user perform the same tasks with fewer mouse clicks; and has a less cluttered interface. And then talk about adding functionality to this.

I like the idea of a tree as well, as described above. But I'd prefer to first step back to a proven-and-true interface, and then expand or experiment.

[Crimson Wizard]

I'd say that the easiest step from here would be to revert to the menus used back in AGS 3.4.3, which let the user perform the same tasks with fewer mouse clicks; and has a less cluttered interface.

You may ignore the subitems in this navigation bar and only use it for selecting a layer.
Everything else stayed the same, and you may still perform all other actions the way you did in 3.4.3: individual items may be still selected by clicking in the room or using a drop-down list on property grid. The only difference compared to 3.4.3 is layer selection: where you have to open a drop-down menu by clicking on "..." after "Room" word, instead of opening a combobox in front of "Show this room's:" label.

I cannot tell what do you mean exactly when you suggest to "revert". Whether you are talking about planning & experimentation stage, or about reverting this in a public version. If the latter, then I will refuse to do this, because current control, as imperfect as it is, contains few functions that users were asking about, such as:
- displaying multiple layers simultaneosly;
- hiding individual objects in the editor.

The old interface did not let to do either of that.

If you find it difficult to select layers with this control, we might consider some kind of a hotfix, some quick solution, such as keyboard shortcuts, for example.

[Alan v.Drake]

I agree with Crimson. Reverting is not the way.
Though the current implementation might not be perfect, it solves even more aggravating issues. Hiding big objects and locking some elements has come in handy more than once.

Once we'll find time to traspose it to a tree view format it should be perfect.

In the meanwhile, the only addition worth the effort to the current system could be some keyboard shortcuts to quickly switch from edges/characters/objects/etc. Like CTRL+1 or ALT+1.


- Alan

[eri0o]

I made this other keyboard navigation by shortcut too...

https://github.com/ericoporto/ags-old/commit/9ec388e2b397049bb9a218b63b6c45531137b867

Which was meant to pair with something like you mention. But my take after going this route is

• Remembering the shortcuts is hard
• You almost instantly want to be able to remap shortcuts in this case

Which is why I abandoned and made the arrow navigation way. But while it works fine, I ended up feeling that it was better to not waste much time on that and instead go for the TreeView approach.

[Crimson Wizard]

I suppose that regardless which controls are there, someone eventually will like to have keyboard navigation with shortcuts.

[eri0o]

One other thing to note is a different road for the room Editor that could be more interesting is to have the Engine have a state that is a room Editor and then it could render the room while editing through the same pipeline that it already has. There are ways to shove an arbitrary exe into a Winforms panel, or alternatively the engine could be built as a library (like it's done in Android). It could reuse the same interface to pass messages as the debugger.

I think this road may be a lot more painful than switching the controls in the current room editor - but note the room editor has lots of little things to improve too.

[Crimson Wizard]

Which is why I abandoned and made the arrow navigation way. But while it works fine, I ended up feeling that it was better to not waste much time on that and instead go for the TreeView approach.

I actually think that this may be worth adding. The code is relatively small, and keyboard navigation may be convenient for some people. So this is going to be useful in a short term.
(One thing to remember is that users tend to stick to older versions years later, so fixing existing control may be still worth it, so long as it's a reliable fix and you do not spend unproportionally lot time on it.)

Although, I would not be adding this to RoomSettings, but rather to AddressBarExt, to keep this contained withing the control itself.

The only thing necessary for RoomSettings would be a key which sets focus to the navigation bar, similar to how Alt key sets focus to the Main Menu.

[eri0o]

Although, I would not be adding this to RoomSettings, but rather to AddressBarExt, to keep this contained withing the control itself

I don't know how to do that but if you do feel free to copy the code or idea.

About the address bar focus shortcut perhaps copying from the web browsers, I think alt+d is the common one - it works in the Windows File Explorer too I think. Alternatively Ctrl+L, which I think works in File Explorer and in the File Explorer from Gnome.