SU16 - new "trays" feature

I’m not sure that the trays UI are as polished as I would expect:
(*I’m using the term “element” below to refer to what was a rollup docker/window in previous versions)

  • can’t position tray elements or trays themselves while managing which to show or adding new ones
  • if a tray has only one element in it, the double title is unnecessary
  • “New Tray” as a menu item isn’t needed since it’s accessible through the manage trays and r-click
  • adding in a new tray messes up the existing tray layout (maybe it should attach to the mouse until clicked in place?)
  • Would like to be able to drag an element’s header off a tray (to blank screen real-estate) and have it create a new single element tray
  • If an element is expanded, it’s easy to miss that extra information is hidden below the lower edge of the tray’s border (I would expect the tray to scroll down to line up the bottoms, and if rolled up then the tray would scroll up to line up the tops)
  • the height of the elements within the tray should change to suit the tray’s bottom edge if there is nothing more to display (eg the materials element with only one or two materials in the list will still show space for 9 or 10)
  • I don’t like that an element can only be on one tray at a time
  • I would like to be able to roll trays in/out to the edge of the screen (depending on where they are docked) {Note}
  • I would like the ‘pin’ on a tray to have an additional “auto hide” function that would roll up if it looses focus for (eg) 3 seconds and auto expand if the mouse hovers for (eg) 1 second.
  • After setting up the trays and toolbars I would like to be able to save this workspace (so that I can import it to other machines - alternatively, have my login save it to the cloud so that if I ever log in to any other machine it will pull down my preferences.)

{Note} edit - reading up, it looks like they should be; every release note I read about them says “completely collapsible trays” … am I missing something?

They are generally “panels”, or more specifically “inspector panels,” and could be SketchUply called just “inspectors.”

They could use some tweaking. I have a request filed for right-click context menu for individual panels (ie, expand, collapse, maximize, minimize, etc.)

As Dan says there are a lot of similar feature requests to your items that beta testers submitted. Well continue to make improvements where we can. Thanks for the detailed feedback!

In general the Window’s tray system that we are using leaves a lot to be desired. As a result things like having a dialog (element) in more than one tray isn’t possible. Focus support is also pretty bad so we can’t keep and un-pinned tray open while a tool is active (such as the paint tool). There’s also a fine line between being helpful and being annoying when it comes to auto sizing dialogs or showing them. As a result we opted not to make dialogs change size based on selections or shift a dialog into full visibility when it has focus.


When I minimize the (things formerly known as) Windows in a tray, or only have one of the Windows expanded, there is still a lot of empty space underneath in the tray, blocking the view to my model when there is no need. It would be awesome if the tray would shrink up dynamically so as to not have white space in it, and then expand with the expanding Windows, but not so much that it covers up the Measurements box or goes off-screen.

I like the button for “New Tray” because I wouldn’t have guessed that right-clicking anything would give me a new tray. Having two trays that don’t dynamically shrink up does halve my usable screen size, though, when I’m in low-res mode for teaching.

I know they say “Why re-invent the wheel” (especially programmers), but when the only way to get the dialog on-screen is to wrap it in a tray and the tray no longer rolls up?.. this almost feels like a step backwards.

With regard to auto-sizing, I’m only talking about setting the size of the dialogue to fit the wrapper -the way it sits you get scroll bars inside scroll bars. When is this ever a good, desirable or even aesthetically pleasing thing? I admire SU for giving you a sleek tool set and intuitive commands (the improvements to the inference system are really cool) however this “tray” thing is the opposite. Personally I would advise that if the current system leaves a lot to be desired then you need to re-invent the wheel.

1 Like

Dock (“pin”) the tray on the side you wish it to slide in/out (ie, “autohide”) and then “unpin” it and it slides to side out of sight, and becomes a tab on the side margin.

You can have any number of custom trays with whatever panel configuration you need in auto-hidden trays.

For example I have the Outliner in it’s own autohidden tray called “Object Tree”, and the Instructor in another called “Help”, still another tray called “Properties” with EntityInfo, Layers and Scenes inspectors,… etc., etc.

The tray system is multi-paradigm. You can have some trays floating and sized however you want (especially vertically.) You can have some docked (“pinned”) and always visible. Other trays pinned but autohidden that slide into view only when you need them. You can assign inspector panels to any of your trays, and re-assign them as needed (via the menu or Manage Trays dialog.)



Only thing is that the docked trays span the whole height of the screen - when pinned I can split them, stack them and size them.

I do like the ‘auto hide’, but if I have one main panel showing, then the secondary ones hide the first one when they pop out. The order you pin things also has an effect on their position as docked to the side - I would have hoped you could drag them up & down.

Perhaps not exactly doable. The nature of drag and drop in most UIs is that objects can only be dropped into acceptable containers. For example a toolbar command button can only be dropped into a toolbar. So an inspector dialog panel can only be dropped into a tray (either another position in the current tray, or another existing tray.)

So currently create the new tray first via Window > New Tray…

OR a new feature could add a “Move to New Tray…” menu item to the right click captionbar menu that I’ve already suggested, that would combine the two operations. Choosing it would popup the tray naming inputbox, then create the tray as a floating tray in the default position, and move the right-clicked inspector panel into the new tray.

That has already been logged as a feature request.

(My choice would be to have them always auto-arranged alphabetically.)

Whoops! Thats not on the what’s new list :wink:

Corrected to Paint tool
~B )

Well you can hide the hidden ones on the other side or dock the pinned one on the side opposite the hidden ones.

Despite the limitations of the new tray system its still a huge improvement over the old snappy dialogs.

Its much more reliable. Previously, expanding dialogs would push things off the screen and the dialogs would sometimes un-dock from each other.

It works great for managing tall stacks of dialogs. Now, you can set up a stack of dialogs and scroll the entire stack without having to collapse others to find what you’re looking for. Right now I have all my dialogs in two trays (pinned with tabs at the bottom). It’s pretty quick to scroll when you can’t see what you need so I almost never collapse the individual dialogs.

In addition, the new tray support working with several maximized dialogs at once. For example, its nice to be able to make the component browser or outliner the full height of the screen and then un-pin them so they only show when you need to access them.

In general Un-pinned trays are also really nice for users who want the modeling window to fill their screen while still being able to easily access all their dialogs.

I like this suggestion. L think you should post this on SketchUcation. I think others would like it too and it would add a positive tone to some of the comments.

Thanks for sharing.

With the old dialogs it also took time to get comfortable with them. They seemed to float all over the place at will and most times. My Outliner box would open the length of the screen into my task bar. No matter how few items I had in it, I could not get it to stay minimized. We are creatures of habit.

I have two trays docked to the right side of my screen. Default has Materials, Scenes, Shadows, Soften and Styles. Then Tray 1 with Comps, Entity, Outliner and Layers. When pinned and open, a single click on the pin icon will hold it open. Re-click it will auto-close it. A right click will allow you to select and manage them without going to the Window tab. It also will allow you to sort/stack your selected elements of each tray alphabetically. Or arranging them in the order most used by clicking and dragging them~each one up or down.

I DID NOT like them at first as it took me a lot of time to get used to the old ones. In another week I will have adjusted to it. It is like anything else that takes you from your comfort zone, or just use the 2015 edition or your previous edition. That you spent time setting up and GROWN accustom to, if you dont wont to take the time and re-apply it.

If I may join the discussion… the new trays could use some fine-tuning to work for me (arguments = all personal opinion).

  1. The autohide side-UI together with a keypress toggle could work for me if it were a real toggle.
    Sometimes, you just want to look at some entity info data (surface area etc) or look at the layers or the hierarchy in the outliner. You have an object selected, press the toggle key, before you can actually read the info the side tray is hidden again.
    Being forced to move the mouse over the panel just to read is kind of a waste in mouse movements. You want to keep the mouse in the workarea, at your 3d object - selecting faces and looking at the individual surface areas.
    Also, the mouse pointer jump in this mode when doing a right-click soften/smooth edges is not nice (but of course needed to bypass the auto hide).
    Being able to set the auto-hide time in the preferences would be nice although I would prefer a real toggle in this mode by far.

  2. The unhidden docked single tray with all the panels in it don’t work for me doing projects with a big hierarchy, lots of layers and scenes etc etc. You want to spend time in the actual workspace and not collapsing panels, scrolling in the UI etc etc. Also, if you want a large workspace and again use a keypress toggle, the workspace view jumps around due to the toggling of the UI tray.

  3. The floating combined trays could work fine for me but the double-toggle to switch between one tray to another and the lack of a master toggle to show/hide them all together is making it a hard to love.
    By making several trays you’re limiting the need to scroll to find what you need. You can leave most of the panels open. But, to get to the tray you want you need to use the keypress toggle twice. Also, to hide all trays you need to press the toggle for your trays all once.
    A single toggle to get to your tray in this mode and a master key to toggle them altogether would be very welcome. If these individual tray actions and flags to check if a tray is open or not just would just be available for ruby I would be happy as well. That way, you could customize it yourself.

At the moment I’m testing option 3 but just with just one tray visible at all times to quickly toggle to maximum workspace.

I’m struggling with the UI changes and still prefer V15. That’s also due to some small changes (Entity info doesn’t auto-size like in V15 = wasted space, time until Entity info is displayed seems to take more time?) , and a bug (renaming an object in the EntityInfo forces you to click in the workspace and not in the white space of the outliner or the new name isn’t applied AND renaming an object in the EntityInfo and immediately selecting another object in the Outliner renames the wrong object).

I hope the bugs get fixed very soon and the discussion about the trays will continue and the UI can be fine tuned a bit more.


One small thing I’ve just encountered: the drawing space does not actually extend under the trays

  • If you select objects with a marquee from left to right, it selects everything fully enclosed by the marquee.
  • If the object extends so that it just goes under the tray, then the marquee selection will not select it.

I understand why it’s happening (the marquee won’t select anything you can’t see), but I’m not convinced that it’s the correct way to work.

There are a few drawing packages that get round this by scrolling the view as you drag off-screen: should this be adopted? (I don’t believe that anything can be dragged to a tray, but I may be wrong)

Found an annoying inconsistency with tray positioning and dual monitors.

I haven’t seen the default tray since I rearranged my desk and moved the second monitor to the right instead of the left. Presumably, it’s still hanging somewhere off in imaginary display space that no longer exists. No biggie, since I made two other trays that now should reside on the second monitor to the right.

Here’s the inconsistency, though; if my second monitor gets turned off, the trays move back to the main monitor. I want them to stay put so I don’t have to move them again, especially when I have 3-4 SU instances running and someone bumps the power button on the monitor, but they react to the monitor “going away.” Why then, does the default tray stay gone?

IMO, this is default behavior controlled by the Windows operating system. Ie, child window objects should be positioned somewhere on the desktop, although perhaps not on top of other child windows. (I’m not sure it can be or should be overridden by applications.) When this does NOT happen, it is considered a bug, if the monitor and desktop settings for the operating system are correct.

Q1: After physically moving the secondary monitor from the left of the primary monitor, to the right of the primary monitor,… did you reorder the placement of monitors, in the Control Panel ?
ie: Control Panel\All Control Panel Items\Display\Screen Resolution
(… so that Windows knows you’ve moved the secondary display.)

Q2: And are they both still set as “Extend these displays” ?

Yes to both questions. I’m just still at a loss as to why the default tray acts differently from the two I’ve created.

1 Like