[SUG][EDITOR] Level Arranger Window / Open All Tabs

[GigaLem]

I noticed I can't seperate the tabs into showing all of them at once, It's been my way of using the new format editor to have all the tabs be viewable instead of one at the time, the NLEditor has that feature. Why doesn't this cross compatible editor have it too?

[WillLem]

I noticed I can't seperate the tabs into showing all of them at once

Separate tabs were removed a while ago due to other updates which necessarily changed the shape and layout of the UI.

I could look at adding it back in for the next update, but it might look slightly different than previously (i.e. the tabs are now significantly wider).

Also, there have been requests for floating panels rather than tabs (I think you yourself requested this?). Would that be better than all-tabs-open-at-once? If you have a preference one way or the other, let me know and I'll have a look at what's possible.

[WillLem]

Here's a mockup of how the Editor would look with all tabs open:



As you can see, the SLX Editor has significantly wider tabs for easier reading/navigation, and to fit the additional skills & features. Having all of them open at once leaves basically no room for the level itself, hence the decision to remove this option.

Floating panels would most likely cause a similar issue. And if we made these individually closable/openable then that's not much different from the status quo of individually tabbed properties, so the benefits of this aren't particularly clear.

The answer (for either option) would be to manually resize and reposition the controls and then have smaller tabs/windows, but then we're reverting to the problem of a less readable and more cluttered-looking interface. Tabbed properties is the solution to this.

I'd need to get more feedback about this before taking any action. Does anyone else prefer all property tabs to be available at once? Would people prefer pinnable floating property windows as opposed to tabs? What problem does this solve that individually tabbed properties doesn't solve?

And, in particular: Can you give tabbed properties a try first and see if you can integrate it into your workflow? Besides a few extra mouse clicks, what problems arise from tabbed properties that can only be solved by untabbed properties? Could those problems be solved some other way?

For example, if it's that the skillset should always be visible, there are other ways to solve that problem:

1) For talisman purposes, only show the skills that have already been added to the level when browsing talisman requirements (already implemented in 2.8.4)

2) Add an option to show the skillset in the status bar (do-able, and much less real estate than a tab/window)

3) Add an option to show the skillset in a floating window (getting closer to UI clutter, but preferable to a popout window of the entire "Skills" tab)

Another problem might be that piece editing should require less mouse-clicks in order to aid workflow. A possible solution could be that clicking a piece could (optionally) auto-focus the "pieces" tab; I'll probably add this functionality anyway, since it makes a lot of sense.

Feedback is needed.

[GigaLem]

The tabs are much thinner in NLEditor, while I get widening the tabs for readability, I feel for a "View all at once" option, that the tabs be made thinner.

Suggestions I could think about is being able to resize the tabs by choice, like if you want resize the the tabs to get more viewability of the level canvas itself.

Or, this one is a bit more ambitious per say but say the ability to pop out the tabs like widgets in a paint program, have them be able to snap to each other or back to the editor

If there is a better way to condense the tabs so you can see all you need to know without sacrificing view real estate of the level canvas, im open to hear it. I've gave my two cents about it and that's if we assume the average NL or SLX user is using a single monitor set up.

[WillLem]

The tabs are much thinner in NLEditor, while I get widening the tabs for readability, I feel for a "View all at once" option, that the tabs be made thinner.

This could be done for "Global" and "Misc", but not for "Pieces" or "Skills", because these necessarily require the extra width to fit all 26 (there may soon be 28) skills on.

Also, you haven't answered the question I was hoping you'd answer: what's the reason for wanting all properties available all at once, all the time? I ask because there might be a better way to meet your requirements than exploding the entire UI.

Or, this one is a bit more ambitious per say but say the ability to pop out the tabs like widgets in a paint program, have them be able to snap to each other or back to the editor

This is a good idea in principle. It's occured to me that the reason it works in a paint program is because they tend to rely on symbols (i.e. paintbrush, magnifying glass, etc) rather than text.

It may be possible to update the Editor to also rely on symbols, which could considerably reduce the real estate needed for controls. However, that's a significant overhaul which would require a lot of time and effort, particularly with regards to designing said symbols. I wouldn't want to take that on unless the idea had a lot of vocal and practical support (including help with the graphic design) from people who intend to use the SLX Editor as their main (or only) level editor.

If there is a better way to condense the tabs so you can see all you need to know without sacrificing view real estate of the level canvas, im open to hear it.

One idea would be a custom tab into which the user can place any control they wish - I can imagine this filling up pretty quickly though, and not proving to be all that useful vs. what's already there, so this perhaps doesn't justify the amount of work it would be to implement. Another simpler idea (that would definitely work for pieces, at least) would be a RMB context menu with all the most common piece editing stuff: draw sooner/later, make an eraser, make no overwrite, etc. With this update, we can even add "load style" to this menu, to load that piece's style into the piece browser.

To come up with more specific ideas, I still need to know what the potential gains are with "all controls available all at once all the time", hence the questions:

• Other than immediate access to every control, what problem does widgets solve that individually tabbed properties doesn't solve? Please be as specific as you can here.
• What controls in particular do you need constant access to?

Bear in mind also that, whilst "all controls available..." may be an ideal of sorts, there is no way to achieve it without sacrificing some level-area real estate, other than on a multi-monitor setup. So, we need to assume that the majority of users will be using single-monitor setups and tailor accordingly.

The level area is arguably the most important element, since that's where all the piece placement and fine editing happens. The level properties tend to be set and left as they are, and updated only incidentally. The exception here is the "Pieces" tab, which I admit needs more regular access. For the next update, I've implemented "clicking on a piece automatically opens the Pieces tab", which should hopefully prove useful enough not to require widgets or exploded tabs.

[GigaLem]

Pop out Stage viewer

Not sure what you mean by this one

Pop out the stage canvas from the editor for larger displays and customizability with the editor so you have the two parts separated and the ability to move them around however you want. Like you could have the level tabs on one screen, the stage canvas of piece selector on the other

[WillLem]

Pop out the stage canvas from the editor for larger displays

This is a good idea, I'll see if it's possible.

If it is, then I'll add the "open all tabs at once" logic back in; the two would be mutually dependent anyway. I'd probably implement it as a single option which opens a detached window in the secondary display and opens all tabs. That way, if no secondary display is detected, the option simply becomes unavailable.

This should also offset any need for pop-out control windows; one screen for controls, the other to view the level.

I've added it to the to-do list.

[namida]

I don't think there's any reason to disable it if the user only has a single display. It may not be as practical - though this depends, it might be very practical for a user running an ultrawide monitor for example - but there's no reason to block it. You could still give a warning / advice to the user that it may not be ideal on a single normal-size monitor.

[WillLem]

I don't think there's any reason to disable it if the user only has a single display.

I guess making the option available separately is OK. I'm perhaps thinking that users might complain that it's not useable on small single displays (likely to account for most users), to which I could only agree and then not do very much about.

Maybe the Editor could detect the screen size/scaling and only make the option available for screens that would allow some reasonably usable amount of level area.

Thoughts?

[namida]

Don't block the functionality under any circumstances. Up to you what circumstances you feel justify showing a warning to the user before activating the feature.

[WillLem]

Made some progress with this today. We can re-parent the level view to a separate window (and even cast mouse and key events to it so that all hotkeys remain functional) with a minimum of extra code, which is great.

Zooming in and out works, although scrollbars haven't been added yet and there is some quite distracting flickering between zooms which I haven't yet found the cause of.

Other than that, this feature works a treat and will most likely go ahead if these kinks can be ironed out.

Don't block the functionality under any circumstances. Up to you what circumstances you feel justify showing a warning to the user before activating the feature.

OK, fair enough. If this feature is added, all users will get a warning on first use of this feature informing them that it's intended for large displays and/or multi-monitor setups unless a large display or multi-monitor setup is detected, in which case the warning will be postponed until the same user attempts to use the feature on a small display and/or single-monitor setup.

[WillLem]

The pop-out Level Viewer (which from now on I'll refer to as the Level Arranger Window as that's what it's been titled in the Editor code) is basically done!

Figured out what was causing the flickering between zooms, that's now been fixed. Added a hotkey and menu button to open the Window, and its open/closed state is remembered when closing the Editor.

By default, the window opens maximized and in the primary display. An eventual next step is to also remember whether or not the window was open in an external display. If it was, open it there (if it's detected), if not then open it in the primary display as normal. We also want to remember the size of the window, and automatically resize it accordingly (i.e. assuming that the last-used size is the user's preference).

The scrollbars have also still yet to be added. Unfortunately with those, it isn't a simple case of re-parenting the existing scrollbars. It probably can be done that way, but there's already quite a bit of very verbose size-calculating and screen-respositioning code related to the scrollbars which doen't play nicely with the floating window and which would have to be somewhat re-written to account for this. The alternative is just to give the window its own scrollbars; I imagine this will be much easier.

Here's a screenshot of what it looks like so far:

Level Arranger Prevew

[GigaLem]

this looks good, like real good, a level window you can move anywhere and resize how you want. I do wish to see more demonstrations with this.

[WillLem]

I do wish to see more demonstrations with this.

Here's a quick video demo. Bear in mind that scrollbars haven't been implemented yet, and I also forgot to zoom in and out in the demo (it can be done, promise! )

It's essentially the exact level view image re-parented to a floating window, so it does everything the level view can already do: respond to hotkeys, group pieces, erase pieces, show skill icons, etc.

I've yet to test it in an external display but I can't see any reason it wouldn't work as expected. Once I've done that and confirmed it's usable, I'll go ahead and implement the scrollbars, external display detection, and "Open All Tabs" option.

[WillLem]

Working scrollbars implemented!