Make a tab for Usertext UI, please

The new UI for Usertext in Rh6 is great.
But it would be even better if it had its own tab so that I can see an object’s Name and Usertext at once.
Now I always have to click to swap the UI display.
Or is there a way I can do this already?

1 Like

HI -

I’ve looked through the YouTrack items but couldn’t find an earlier request for this.
I do get what you mean, though. On Layouts, I find myself constantly switching between the UserText panel and the Detail properties.

It might not be limited to the UserText panel, though.
-wim

So the properties tab shows the properties of “something” and the various sub-property icons at the top of the tab contents all show a sub-grouping of assorted properties of the same “something” that the main property tab shows.

It seems like it makes considerable sense for the identifying info (ie: type, name, layer) to be dis[played “above” the sub-icons and stay with the properties tab while the sub-property panels are shown “below” the sub-icons. The sub-panels needn’t repeat the identity info.

I think I would find this arrangement more satisfying than the current one.

1 Like

@wim here is a YOUTRACK issue that addresses the same problem:
https://mcneel.myjetbrains.com/youtrack/issue/RH-39315#u=1494831427088

here is another request for this:


And here it is in my discussion with @Trav. I believe he originally implement the UI for Usertext:

Hi -

Thanks for finding that! I’ve added this thread to that report.

I’m not so sure about that. Most users (we don’t collect statistics so my guess is as good as yours) don’t name their objects. Layer information for the selected object is always visible in the status bar.
-wim

1 Like

You are, of course, absolutely right about that, but the main point was that the ID info, such as it is, that is now shown on the object tab should instead reside on the properties tab and stay there no matter which of the sub-property tabs is currently showing.

And my guess (mostly from observing posts here on discourse) is “more than you might think”. Anyone who is working on projects with a lot of objects eventually figures out that naming objects - at least the important ones that get a lot of action or look a lot like one another - helps a lot when selecting, etc.

Many users apparently find naming so helpful that they have written scripts or plugins to do automatic naming for them.

Type and layer can be very useful in many situations even when there is no name, although the improvements in filtering have made a big difference too. It’s just the difference between having the info available at a glance or having to make some clicks or button presses to find out what you need to know.

1 Like

A few questions for yourself as well as @Goswin

Are there any sub panels other than Attribute User Text that need access to those properties? EG do the Material / Displacement / Curve Piping panels need access to Object Name?

Beyond Object Name and Object Layer what other object attributes would you suggest be persistent?

I have pondered the addition of a 2 way binding text field operator in the Attribute User Text panel that would give you the ability to not only see the Object Name but also be able to change the Object Name by setting the value in this field. The 2 way binding fields get a little more complex on things like Layer Name were a misspelling or predefined list selection needs to be adhered to but I think it could work if we constrain the UI properly.

My fear here is that by loading every possible panel and option, 3rd party plugins included, into a persistent state the performance during object selections could be severely impacted as most of those panels don’t do any computations until they are the active panels. The other issue is the sheer size of the panel UI and the scrolling nightmare that it could become trying to find something.

1 Like

My posts were directed at the “common factors” of a hierarchy of tabs. Much like an equation with a common factor which can be pulled out or the idea of inheritance in OOP, I’m suggesting that information that is (or should be, based on frequent tab switching to find it where it is) common to the sub-tabs should be placed on the main tab and remain visible while a sub-tab is selected and displaying it’s unique information.

As I mentioned earlier I think the type should be part of the properties display in addition to name and layer.

I defer to Goswin on the other aspects as I have never had a reason to need Usertext.

Thanks @Trav for looking into this.
I can think of several ways to solve this, here with increasing complexity:

  1. I think the simplest solution would be to just give the user text its own tab, collapsed or hidden by default.

  2. Give every nested window under properties its own tab, collapsed or hidden by default: image
    These Icons could even stay her under properties, but clicking on them would open the respective new tab.

Here is a nice example of why Usertext makes Rhino so useful. These guys even build their own user text viewer and user text tools:


video here