Tested just for you - WIP toolbar editing 😬

[inju]

Example:

UI Rhino 8 WIP -2

[inju]

example:

[DanBayn]

The other important factor for me at least, is that whatever UI that I eventually come up with has to be portable. I’ve got to be able to copy it into many more computers.

[seltzdesign (Armin Seltz)]

Yes, the whole toolbar system is completely messy. Not just in V8 but even before. Plugins create their toolbars that will just appear when starting Rhino. The amount of times I had to manually close all 10! of V-Rays toolbars because they decided to show up again. Other toolbars will disappear even though I have added them many times.

Why does this have to be so complicated, while being so static? If I spend all this time customizing Rhino I want to be able to at least use it on several machines easily or restore a previous setup that was working.

Hmpf…

[jeremy5 (Jeremy)]

I had a similar idea to you, Mitch, and created my own version of the default menu and swapped it in, replacing the McNeel one, added a button, created a dropdown toolbar to display sub buttons when the button is clicked and, while it was hard to work out how to do all that, and the random distribution of tools didn’t help, and there were numerous false starts, I felt I was getting somewhere, even if half an hour seemed like a long time to get to one new button (heaven knows how long if I’d got into the icon editor!).

But then I went to look at what McNeel put in a typical macro to display such a dropdown toolbar and… …Rhino froze. At that point I shrugged philosophically (a.k.a. swore) and walked away. It’s a WIP and it just isn’t ready to explore this part.

I look forward to trying again after McNeel have created (or received) a collection of scenarios that illustrate real-world use cases and written a cohesive set of tools that facilitate those scenarios.

Incidentally, I would hope that, if any of the disparate maze of tools I wandered through were legacy items and not intended for use in R8, they can be disabled or removed to avoid confusing the landscape.

Regards
Jeremy

[brian (Brian Gillespie)]

@Helvetosaur

Warning - long post…

Thanks for taking the time to write this. It deserves an equally long response, so here goes.

But first, a bit about where we are with this project. There’s a lot of new code here, and the UI for it is not yet done. As you’ve discovered, it’s gross.

First, our intentions

There are a few new features coming to Rhino 8 that are designed to fix a few very painful long-standing problems in Rhino.

1. Cross Platform: This new toolbar and window management system works on both Windows and Mac. On Mac, you didn’t have much if any customization available in Rhino 7 and older.

2. Toolbars Stay Put: This change makes it so that all the dockable stuff in Rhino can live in any of the containers. It also is stored in a way that when you close Rhino and re-open it, you get what you had. For some people, Rhino 5, 6, and 7, never really worked this way.

3. Delivering Updates, Not Trashing Customization: Another thing we’re trying to fix is the ability to add new tools to Rhino without trashing everyone’s custom RUI files. This is actually a big deal. Let’s say we find a bug in the Circle button: we shipped with a macro -_Coircle and it just didn’t work. And you built a new custom layout of your own based on our default RUI. In the past, if you wanted the fix, you had to know to look for it and update your RUI. Now, because your changes to the RUI are stored locally as a set of changes (rather than a whole RUI file), we can modify -_Coircle to be -_Circle and both the default and all your changes will be updated.

4. Combining Tools: It used to be that if you had the VRay plugin loaded and you wanted your own new toolbar that had some Rhino tools and some VRay tools, you’d get a bunch of copies of those tools in your new toolbar. Now, Rhino will save links back to the original RUI files (for much the same reason as above) so that the original authors can update and change their RUIs.

And finally, if you’re one of the very rare people who design whole new layouts for Rhino (and, I know, you are) there are tools for un-linking everything and embedding it in the RUI.

Second, Our priorities

I got my hands on this set of new tools about six months ago. At that point, just opening Rhino felt foreign. All the styling was confused, things didn’t line up, there was a waste of pixel space, etc. Dark mode didn’t work (and still kinda doesn’t).

There were a bunch of things that didn’t work when you simply opened Rhino and tried to use it. We are very nearly done cleaning all of that up. And it’s our top priority - because using Rhino is way more important than customizing it for most of our users. I’m not saying customization isn’t important - but I think it’s not controversial to say that using Rhino is more important than customization.

I intentionally pulled people’s focus away from toolbar button creation, workspace creation, and layout editing in favor of straight-up default user experience.

And now, we’re turning toward some of those more subtle things like what you’ve described. And yes, it’s far from being done.

@Helvetosaur

“Create new file and link”

I was just talking to John about this, and wondered what on earth “and link” means? Why isn’t this just “New…”? Logged as RH-73818

@Helvetosaur

Why isn’t there an access button from Options>Appearance>Toolbars?

Maybe there should be. I’m not sold on that idea yet… doing so means you have a modal options dialog with another Toolbars dialog on top, and then all the editing you do happens on top of those two windows, pretty well obscuring what you’re working on? Or am I missing something here?

@Helvetosaur

Funny thing, in default, even though the top and left sidebars are showing, NONE of the toolbars in Toolbar Layout are actually checked in the list…

That looks like a bug. I’m not sure those checkboxes actually are hooked to anything. Since toolbars can belong to multiple containers now, a checkbox is kinda nonsensical. It looks like you can cause toolbars to appear with those checkboxes, but they don’t seem to have a visibility correspondence: RH-73819

@Helvetosaur

I’m going to add a new toolbar – I call it MyFirstToolbar. Then I get to this window:

The intention here, which clearly didn’t work very well, was to help guide you through the process of creating a toolbar and adding buttons to it. If you were doing this in the context of the default RUI, I think it’d make more sense. But since you started with nothing (an empty RUI) it’s less sensible.

@Helvetosaur

And just hit Finish to hopefully get my toolbar. Miracle of miracles, I actually get the toolbar. Not so miraculous, you can’t make it a single row, what you see below is as small as it gets vertically.

Logged as RH-73820

@Helvetosaur

So now, I have a button in Recon1.rui that links to a toolbar in default. Hard to wrap my head around that.

Yep, that’s by design. So that we can update that linked toolbar and you don’t have to care. Glad you love it

@Helvetosaur

As has been mentioned in other threads, the commands in buttons can no longer be edited directly.

This is currently in the category of internal conflict. Some of us agree with you. Some of us don’t. I’m not sure where we’ll land ultimately - but even if we keep the “buttons reference macros” concept, we’ll streamline the UI so that it’s not so many clicks to do things.

All the rest, I just agree with, and we have bugs logged for them.

@Helvetosaur

The only way to have two different scripts LMB/RMB is to DUPLICATE the macro you made with the first script and then edit the duplicate and put the second script. This is beyond crazy.

Thanks: RH-73821

@Helvetosaur

PLEASE UNLINK EVERYTHING !!!

I refer you to Rhino 7. Everything is unlinked there. But seriously, we’re going to continue to fix bugs and make it better - it might be a few months yet, however.

[gustojunk (Gustavo Fontana)]

Hey Brian, Thanks for explaining all this. I think the priorities you listed on your post are the right ones. I read about the issue that Mitch and Dan and others have been having with linked toolbars, and I was feeling really guilty, because I know I’ve lobbied for linked toolbars pretty hard. I still believe they are necessary.

I know is really hard work to get this right. Actually, I probably have no idea how insanely hard this must really be. But I really look forward to a future when I can maintain a set of custom tools that people in my team can use, linked to their source file, and that I can update them on my end and they see those updates (our .RUI files live in synched Dropbox folders). And none of that conflicts with you guys at McNeel also updating your own toolbars/defaults and we all also get to see those updates. And noting break anything.

Also having everything look the same on every machine that I use, every time I launch Rhino is really needed. Currently, every time I start Rhino 7 my first thing to do is rea-ranging toolbars. Every, single, time I launch Rhino. So thanks for fixing all that!

Thanks again, and keep it up!

G

[EricM (Eric Paul Marvets)]

@brian

Now, because your changes to the RUI are stored locally as a set of changes (rather than a whole RUI file), we can modify -_Coircle to be -_Circle

@brian

Rhino will save links back to the original RUI files (for much the same reason as above) so that the original authors can update and change their RUIs.

I can understand your thinking for copy-by-ref between RUIs, but you’ve got a whole mess of people thinking they are tweaking their copy of a button while overwriting the default version. That’s not how it’s ever been, and there is nothing to alert the user that they are editing the default macro in a custom RUI.

You have to make default macros read-only. If someone tries to edit it, you silently spawn a new instance of the macro in the RUI that owns the parent toolbar. No need for a duplicate button. You edit, and you get something new. That way Rhino updates the read-only defaults and never touches someone’s customization, no matter what RUI they live in.

@brian

This is currently in the category of internal conflict. Some of us agree with you. Some of us don’t.

This conflict does not exist amongst users who’ve tried to make their toolbars in v8.

[Helvetosaur]

Hi Brian,

Since we’re doing point-counterpoint here…

@brian

1. Cross Platform:

Of course, agreed.

@brian

2. Toolbars Stay Put:

Yes, a very good improvement. But for me containers and how they are arranged/docked etc. are separate from the contents of those containers. The container system is fine. What it contains is what I am questioning.

@brian

Delivering Updates, Not Trashing Customization:

I’ve never really been affected by this, but OK, not a problem.

@brian

4. Combining Tools:

Never really experienced this either but hey, maybe I’m the exception.

@brian

And finally, if you’re one of the very rare people who design whole new layouts for Rhino (and, I know, you are) there are tools for un-linking everything and embedding it in the RUI.

Please elaborate on how to unlink stuff… I would like to test.

@Helvetosaur

Why isn’t there an access button from Options>Appearance>Toolbars?

@brian

Or am I missing something here?

Just the expectation that if one goes into Options looking for toolbar options, one should somehow have access to the editing system…

@Helvetosaur

PLEASE UNLINK EVERYTHING !!!

@brian

Rhino 7. Everything is unlinked there.

Well, not exactly - you might find some of my and other’s previous posts concerning concerning copying buttons and having macros, tooltips etc. come with them - in V7.

@brian

I refer you to Rhino 7… But seriously,

I’m glad that’s not a serious response. Well, maybe it is finally time for me to quit mucking about with this stuff and really finally retire along with Rhino 7.

I simply want to state that if you end up tailoring the system to a collection of high-end users at the detriment of lots of the lower-end ones, I will be very sad.

If you have a way to export the default toolset so that it is completely unlinked from the totally interconnected dialog box jungle world it currently lives in, and in those unlinked tools I can simply open a button editor, type or paste in macros, scripts and the like, choose from a library of svg images and OK to finish, I will be fine with that. (hmm, sounds about like V4 doesn’t it…).

[jdhill]

if I can shift-click a button I just copied, type a macro, and click ok, then I don’t care how the rest of it works

besides doing that, I have not sunk a second of time into customizing rhino toolbars since I did it in v2 or v3, only for the next version to come along and not support the workspace I had spent so much time making, and become dependent upon; that sucked, but it was also good, because it was what taught me to never customize software

sidenote on the point about needing to link so you can fix things without disturbing user customizations – you know what string was wrong, and what string is right, so you don’t need to replace the toolbar, just fix the known bad button macro

[brian (Brian Gillespie)]

@Helvetosaur

Please elaborate on how to unlink stuff… I would like to test.

It’s in the Tools > Options > Appearance > Toolbar Layout > Gear > Save Changes to Linked File.

(I have no idea why it’s called this, makes no sense to me)

@Helvetosaur

I’m glad that’s not a serious response. Well, maybe it is finally time for me to quit mucking about with this stuff and really finally retire along with Rhino 7.

That will be a sad day, indeed.

@Helvetosaur

If you have a way to export the default toolset so that it is completely unlinked from the totally interconnected dialog box jungle world it currently lives in, and in those unlinked tools I can simply open a button editor, type or paste in macros, scripts and the like, choose from a library of svg images and OK to finish, I will be fine with that. (hmm, sounds about like V4 doesn’t it…).

I know, I’m with you. I don’t want you to need to be a database wizard to manage these things, either. I hope we can make it better in the coming months.

@jdhill

sidenote on the point about needing to link so you can fix things without disturbing user customizations – you know what string was wrong, and what string is right, so you don’t need to replace the toolbar, just fix the known bad button macro

Sure, and also the bitmaps. Oh and add a new button. Oh, and delete one. If only it were easy! Maybe we could just overwrite everyone’s customizations

[gustojunk (Gustavo Fontana)]

@jdhill

because it was what taught me to never customize software

Do you do 3D design and 3D modeling for a living?

I do. And I can tell you that without custom tools, workflows, scripts and plugging I’d be a lot slower at what I do. And my days would be a lot more repetitive and boring AF.

Bad for me. Bad for my customers.

I see Rhino mostly as a 3D operating system that allows people like me grow businesses with a lot of custom tools and workflows. I really hope Rhino continues to nurture and support this type of work going forward, because no one else does. The world does not need yet another defaultware 3D package. That’s a crowded market.

G

[brian (Brian Gillespie)]

@EricM

I can understand your thinking for copy-by-ref between RUIs, but you’ve got a whole mess of people thinking they are tweaking their copy of a button while overwriting the default version. That’s not how it’s ever been, and there is nothing to alert the user that they are editing the default macro in a custom RUI.

That’s actually not how it works, either. Unfortunately this whole system is rather complicated, and may almost be impossible to get a sane mental model of.

When you edit a button, you are actually editing a small “delta file” that records the differences between our defaults and your changes. When you start Rhino, that “delta file” is read and applied to the defaults. So the core, unmodified macro is still there for you.

@EricM

This conflict does not exist amongst users who’ve tried to make their toolbars in v8.

If only we could have all of you type on the code at the same time, all our disagreements would be solved.

[jdhill]

@gustojunk

Do you do 3D design and 3D modeling for a living?

I do. And I can tell you that without custom tools, workflows, scripts and plugging I’d be a lot slower at what I do. And my days would be a lot more repetitive and boring AF.

no (but I have to use about a billion tools to do development), and I’m not saying what works for me has to work for anyone else, let alone someone like you, who is creating custom workflows for entire teams

[EricM (Eric Paul Marvets)]

@brian

When you edit a button, you are actually editing a small “delta file” that records the differences between our defaults and your changes. When you start Rhino, that “delta file” is read and applied to the defaults. So the core, unmodified macro is still there for you.

It is how it works. After spending a day filling a delta file with stuff that should have gone into a custom toolbar, I finally understand it. And I’m ready to rage quit.

There is no way V8 can launch if editing a copy of a button in a custom RUI replaces the stock button in the default RUI.

Just remove the duplicate button. If someone edits the macro, silently duplicate that macro in the RUI hosting the toolbar. That way, you create a new command on that button without overwriting the existing macro on every other button.

If it’s an edited macro, Rhino shouldn’t update it. And if it’s unedited, it remains a by-ref you can update at will.

[AlW]

@brian

Unfortunately this whole system is rather complicated, and may almost be impossible to get a sane mental model of.

This is a really fundamental flaw in anything designed for users. It’s also a serious obstacle to practical intuitively usable design when it’s true for developers.

BTW: I personally think that unless Mitch is already getting incredibly rich as a Rhino reseller you really need to send him a generous check for the billable hours he spent on this!

[Helvetosaur]

@gustojunk

And I can tell you that without custom tools, workflows, scripts and plugging I’d be a lot slower at what I do. And my days would be a lot more repetitive and boring AF.

Bad for me. Bad for my customers.

Yep. Let me give you another small case in point. Being an (ex)modelmaker as well as a Rhino reseller, I am in touch with virtually all the model shops in this country - there aren’t all that many, maybe 20 or so and the largest of them has maybe 7-8 people and the smallest is just one person. They pretty much all use Rhino now (I’m still trying to wean a few off of AutoCAD) and we use Rhino to teach CAD to our apprentices.

I have created quite a number of scripts over the years to streamline some of their workflows. I need to be able to hand out those scripts with some simple installation instructions. Right now that’s easy enough, it’s the same instructions as we give out here on the forum when someone posts a script - make a new button, open the editor, paste the script in there, done. It needs to be simple. The audience is not computer programmers, they are just craftspeople who use computer aided design and manufacturing to allow them to do their work efficiently and stay competitive in today’s world.

Oh, and by the way - now that I mentioned “Forum”… The same goes for the dozens of requests we get here weekly for macros, scripts etc. to solve specific problems. Oftentimes the requesters are students, relative beginners or simply not Rhino masters and thus again, the install procedure needs to be SIMPLE. I would hate to see that stuff get so complicated that most people won’t even try.

Edit -
I guess one other thing I could add here is that when a group of very experienced users on this forum - Jørgen, Gustavo, Eric, Bobi, Dan, JD, etc. (OK, I’ll include myself here as well) - all start voicing their doubts about something, there is definitely a problem…

[Helvetosaur]

@AlW

BTW: I personally think that unless Mitch is already getting incredibly rich as a Rhino reseller you really need to send him a generous check for the billable hours he spent on this

Naah, not necessary… No, I’m not getting incredibly rich, but sales are good, I have great friends and clients, so I really can’t complain. I also do this simply because I love Rhino and the community around it, so when I think something major is wrong, I will put in the time to document it.

[Helvetosaur]

Not being one to start tearing down stuff without offering at least some suggestions as to how it could be made better…

I’m trying to imagine how to reconcile the perceived need to to have a base set of tools that can be remotely restored, modified, updated etc. and at the same time accommodate user customizations in an easy and reliable way. I’m sure this has been the subject of extensive discussions @ McNeel already, so I’m probably covering old, old ground.

@brian mentioned this “Delta” file. That’s exactly how I see it working. Simply the implementation would be different and transparent to the user.

Let’s imagine first off that the user is allowed to edit an existing toolbar button as they can now in V7 - edit the ‘macro’, the image, the tooltip, etc. - i.e. the system is completely unlocked as it is now.

We have the following scenarios:

• The following are all without creating a “linked” file -

1. Editing an existing toolbar button:
   The edits go in the Delta file, it just makes a whole new button using the edits. The edited button is no longer linked automatically to the original macro or image. The edited button contains a pointer to the original (untouched) base tool button it replaced. When Rhino is updated, the original button may be updated - and then the changes from the Delta file are applied over that, i.e. the original button is replaced by the edited one again. The edited button is not affected by an update, it can only be changed by the user.

2. Making a new button from scratch:
   The edits go in the Delta file, it just makes a whole new button. There is no link necessary to an original. There is a pointer to the toolbar in which the new button resides. The new button is not affected by an update, it can only be changed by the user.

3. Making a new button by copying an original button:
   If no edits to the button are made, it acts as a copy of the original - macros/images are still linked and updated. If an edit is made to the copy, it automatically becomes like scenario 1 - independent.

4. The Delta file is automatically backed up in at least two places, plus it is accessible to the user so that it can be backed up elsewhere. Maybe the Delta file is like the other linked files.

5. New toolbars:
   Two possible scenarios here, with or without a linked file.
   Without a linked file, new toolbars go into the Delta file. They can contain buttons that are either edited (independent) or not (updatable/linked)
   With a “linked” file, new toolbars can go into the linked file. They can contain buttons that are either edited (independent) or not (updatable/linked)

That’s one way of doing it (maybe). I’m sure there are plenty of other things to consider that I haven’t thought of. The other way of doing it… well, it would take something from the Mac side.

1. The default set of tools is not modifiable in any way.
2. In order to modify or add to the toolset you need to make a copy of it.
3. Making a copy is as simple as saving it under a name (as we do with .rui files now)
4. Once copied, two possibilities:
   A - everything becomes independent and editable, and is no longer affected by any updates. Therefore the user does this at their own risk.
   B - The copy works like the first scenario above, edited stuff becomes independent, unedited stuff remains linked/updatable.

Well, anyway, that’s about as much logic as my brain can manage on this Saturday morning…

[AlW]

@Helvetosaur

I guess one other thing I could add here is that when a group of very experienced users on this forum - Jørgen, Gustavo, Eric, Bobi, Dan, JD, etc. (OK, I’ll include myself here as well) - all start voicing their doubts about something, there is definitely a problem…

Just to make sure this is seen where it needs to be: @bobmcneel @brian

There must be something amiss in the development process that allowed this to get so far off the right track.