Tested just for you - WIP toolbar editing šŸ˜¬

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.

1 Like

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ā€¦ :sleeping:

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.

2 Likes

Ok, here comes my rant response, ā€˜kids these daysā€™ style.

what you just mentioned Mitch is a great example of the many jobs, trades, industries where Rhino plays so well, and it requires both: customizations created by nerds that are also trade experts, and those customized tools being used by also expert craftspeople that are not necessarily advanced computer users.

At Fresco, my design company, over the last 3 years, we have grown slowly whatā€™s now a full industrial design modelshop, and just as we have very advanced programmers and 3D modelers in our team, we also have amazing master model makers that struggle a bit with computer use. The role that Rhino plays there is crucial: we use it extensively for a lot of doctoring, fixing, completing, remodeling and modifying customersā€™ files. Letā€™s just say that the typical industrial designer/engineerā€™s 3D file these days is less than ideal to do any real work with it. So to make physical models thereā€™s tons of expert CAD work needed first. This is beyond all the work for fasteners, fixtures, paint offsets, glue traps, magnets rails and sockets, thin part reinforcements, etc.

This is all possible with scripts and plugins by folks like you Mitch, and Pascal, Dale, Dan Byan, HĆølger, Willem, Peter Harris, Rolf, Nathan, Gijs, Jarek, Daniel Piker, David Rutten, and many others.

All these amazing tools, some created now over 20 years ago, are making, an otherwise kind of ok 3D package, into one of the most powerful tools of work Iā€™ve ever used.

This style of work. This body of collective wisdom shared here over decades. This ability to make a difference and perfect a craft, needs a lot more of respect, care and focus by McNeel. You canā€™t just bury all this greatness just because thereā€™s a ton of children out there now, running Rhino on Macbooks and with no intelectual curiosity or understanding for 3D things, and want everything simpler and default.

This issue needs a serious rethink, rebuild, and re-prioritization, as soon as the ā€˜Basics for the MacBook Generationā€™ is taken care of.

Thanks for listening,

Gustavo

10 Likes

I completely agree !

2 Likes

6 posts were split to a new topic: OSnaps do not stay put

@clement I canā€™t repeat both of your issues here, I will if anyone has a clue what might be causing this.

1 Like

Donā€™t do this. It will eat your changes.

@Helvetosaur
You once promised to never try to edit a button again, must have been in early V3 or V4 times.
Good you broke your promise :laughing:
However the system works in the background, the user shouldnā€™t have to hassle with macros and delta files.

I remember this macro thing was once visible in V3 or V4.
But then it disappeared, and from then on it was possible to play with buttons, and it worked quite easy.

I said that? Really? :rofl:

I honestly donā€™t remember that, but it most likely was at the introduction of the whole concept of the linked macro library and workspace editor - I guess with V4?

I guess that was (and still is) because I am in the habit of copying buttons and then modifying the copies - which was already the source of a bunch of problems, some of which persist in V7, but now has become a complete nightmare in the WIP.

I started just making new buttons from scratch and importing the bitmaps which worked better, but even that is now monstrously complicated.

1 Like

I just had a similar experience, The toolbar was looking good this morning, and I saved it so it would look the same on my other computer (rui on dropbox) and then when I reopened the wip it looks like this:

(X)'s over a few of the ā€œmacrosā€ and the macros has been deleted from the library.
EDIT: It seems the macros are OK, but the svg icons are gone. Those are saved IN the toolbar/library right???

image

I hope this illustrates how terrible this is working and how counter intuitive it all is.

EDIT, is this the library? This is where I saved: (Itā€™s difficult to understand since you use words like toolbar and library on what seems to be multiple and overlapping things)

There we need a ā€œsave asā€ also, so we donā€™t have to go the OS to make duplicates and rename the copies.

2 Likes

Yeahā€¦ I relinked the svg to one of the buttons and saved the toolbar/library thingo and reopened V8 and now the icon that was lost is there, but the other one is lostā€¦ (the one that was working fine on that toolbar after the previous save)
image

image

And the strangest thing is that the one icon on ā€œMake Toolsā€ that still is intact is the same one that now got lost on the LARK v8ā€¦ (Same macro linked to both toolbars, both toolbars are in the HoloHolo-v8.rui library.

And one more thing, button tooltip text doesnā€™t get updated unless you restart Rhino. At least thatā€™s what happened now.

I canā€™t believe there is no way to sync toolbars between teams or even yourself like that anymore. Every step of this new system prevents it. Copy-by-ref means quick edits are applied to the default, not your RUI. Rhino doesnā€™t save your RUI on exit. And if you manually save the RUI, it nukes the file.

But since Rhino isnā€™t saving the RUI, you can do some edits in V7 with the comparatively-easier-to-use workspace editor, then relaunch the WIP. Thatā€™s been working so far. It keeps all my SVGs associated with their macros.

And a next thing.
I configured the middle mouse button for showing the MRU toolbar.
Strange resultsā€¦


And no, I didnā€™t modify the toolbars at all.
Plain Rhino 8 default.


BTW, I like the auto pop out when only moving the mouse over a button with a triangle.
While a bit delay would be better.
And perhaps auto close on mouse leave.

Is it possible to activate the behavior for the standard toolbars as well?

1 Like

@wim and @gijs, can you give some insight in when we can rely on the toolbar save issue? That is the most pressing part.

Itā€™s kind of OK that it is difficult to do something, at least for the time being, but it is critical that we canā€™t save the toolbar in a way that gives results with out messing up previous work. Thanks!

1 Like

OK, a small update.
I just added some buttons to my toolbar and saved, and then reopened WIP. Now all other toolbar icons are gone, but the last added ones are there. So it seems the save feature just deletes the existing ones and saves only the new ones. So a bug that should be easy to fix.

you donā€™t know who JD Hill is?!

I know heā€™s a very talented rendering software creator and programmer. But I donā€™t know if he spends much of his working hours modeling, for a living, and where are his expectations when it comes to modeling efficiency l, productivity and design exploration requirements.

G

1 Like

sorry, for some reason I missed this @ mention. John is working right now on this part of the UI. I canā€™t however give you an estimate of when that will be ready.

1 Like

@Helvetosaur yesterdayā€™s WIP has some significant changes in the realm of button editing. The whole workflow of creating toolbars and workspaces is still just as bad as always, but copying, editing, and creating a new button should be much better. What do you think?