Is this as expected? As you mention yourselves, none of other softwares on the toolbar create a new icon when launching it.
I’m used to it but I would prefer that Rhino behave the same as other software and not create a new copy of an icon if the icon is already on the tool bar.
No.
It still is a total mess.
This won’t be fixed. I tried several different ways, and it was a mess regardless of the fix.
But why is this a problem with Rhino?
I have never seen another program showing this annoying behavior.
I am sure you have good reason to come to the conclusion that this won’t be fixed.
It would just be nice to hear your reasoning (in layman’s terms of course)
My guess this behavior is related to the usage management system which was introduced with Rhino 6 and expanded with Rhino 7. That system allows a single Rhino 7 license to be used for a combination of Rhino 6, Rhino 7 and Rhino WIP on a single system, but does not allow a single license to be used simultaneously on multiple systems.
I think it’s because Rhino 6 and Rhino 7 and Rhino 8 all use the same program name - rhino.exe. This is done to make it so plug-ins continue to load in newer versions.
There are some parts of the Windows API that key off of the application full path, others registry keys, and yet others the application name. The dock bar uses the application name, but can be tricked with some additional data in a manifest file embedded in the application. When I tried using that, people complained that the icon in the task bar would get deleted or abandoned whenever they installed an update to Rhino.
The details, with attempts over several years are here:
https://mcneel.myjetbrains.com/youtrack/issue/RH-60614
That is what happens with other software I use, and I’m used to it. But it is a bit annoying.
Thanks Brian!
Much appreciated.
Hello @brian
For me it’s not really a big deal, but in some cases it’s still annoying.
For the moment my approach leads me to load the same model in version 6 and 7 (and maybe 8 for the tests)
I don’t want Rhino7 (or 8) to be used for certain tasks on this model.
The icons and interfaces of the Rhino versions look very similar.
I am not the only user who works on the same computer.
I try to limit user errors as much as possible.
A workaround that seems simple to me would be to change the Rhino window title.
Currently you have <FILENAME> - Rhino <VERSION>
change it to <VERSION> - <FILENAME>
(I think “Rhino” in the title doesn’t give more information than we already see)
This would make it possible, regardless of the size of the file name, to immediately identify the version.
Another solution, perhaps less relevant (because it depends on the theme chosen by the user), is to integrate a color code in the icons of Rhino.
here is a visual of what these solutions could be:
jmv
Thanks for those suggestions. I think we’re in a situation here where we can’t make everyone happy. You clearly want to know the version number more than you want to know the name of the file you’re working on. I can see just as much confusion for people that weren’t part of this conversation wondering why the titlebar starts with a number. As for colors, you can make your own icons and associate them with applications in Windows. Perhaps you could make big bright “6” and “7” and “8” icons that help you distinguish what’s running?
Hello @brian
You are right, I had not thought of it. Unfortunately it does not work.
If I change the icons of C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Rhino ...\Rhino ...
, only the icon in the taskbar changes.
(unsurprisingly, the version 6 icon is used for all versions).
The icons above the thumbnails (the one I surrounded with colored squares) don’t change.
I did not find how to change the executable icon (C:\Program Files\Rhino 6\System\Rhino.exe
)
In this installation folder, I saw that there was an icon C:\Program Files\Rhino 6\System\rhino.ico
I changed it, deleted all caches, restarted the PC. I did not observe any change.
No, I am looking for solutions to identify the applications.
C:\Program Files\Rhino 6\System\Rhino.exe
is not the same application as C:\Program Files\Rhino 7\System\Rhino.exe
Maybe I’ll take another run at this for V8… I wasn’t very successful in Rhino 7, though.
On my Win 10 install, I have the tabs separated - 5,6,7, WIP - no problem. On Win 11 (ugh) 5 is still separate but 6, 7 and WIP are now all together on one icon. The one that wins (shows) is the one that was open first.
Win 11 in any case is a mess in this regard, I used to have a separate tab for each open file in the taskbar in Win 8.1 and 10, but this option was removed from Windows 11, so everything is always combined.
I wanted to understand why other apps don’t have this problem.
So I watched the work of the blender team.
I assumed the solution could be found here blender/source/creator at master · blender/blender · GitHub
I didn’t find it, but it gave me an idea.
When you start blender, you actually start blender_launcher.exe
, which in turn will start blender.exe
.
So maybe if I create three rhino_launcher_<6/7/8>.exe
apps that start as a child process
C:\Program Files\Rhino <6/7/8>\System\Rhino.exe
the task bar will group the rhino_launcher_6.exe
together
and rhino_launcher_7.exe
in another group.
I don’t know how to program in C, so I tried in C#. It didn’t work.
I looked a little bit more and I could understand that the only thing that interests the Windows task bar is a property named “AppUserModelID” which must be defined before creating the window.
I also understood that there are two methods to define it; SetCurrentProcessExplicitAppUserModelID and SHGetPropertyStoreForWindow.
We cannot compile Rhino and the methods must be called in the main function of Rhino.exe,
We are dependent on you.
I found on Stackoverflow a small example which allowed me to make a functional demonstration.
The code is really simple.
using System;
using System.Runtime.InteropServices;
using System.Security;
namespace RhinoLauncher
{
[SuppressUnmanagedCodeSecurity]
internal static class SafeNativeMethods
{
[DllImport ("shell32.dll")]
public static extern int SetCurrentProcessExplicitAppUserModelID ([MarshalAs (UnmanagedType.LPWStr)] string AppID);
[DllImport ("kernel32.dll")]
public static extern bool AllocConsole ();
[DllImport ("kernel32.dll")]
public static extern bool FreeConsole ();
}
class Program
{
[STAThread]
static void Main(string[] args) {
string ID = args.Length > 0 ? args[0] : "Demo.AppUserModelID";
int result = SafeNativeMethods.SetCurrentProcessExplicitAppUserModelID (ID);
SafeNativeMethods.AllocConsole ();
Console.ReadLine ();
SafeNativeMethods.FreeConsole ();
}
}
}
You can have any icons, any title, the same application is correctly grouped in the group of its choice.
In conclusion, despite all my efforts, I have no solutions to resolve this.
Of all the software I have installed, Rhino is the only one that has this problem.
@brian , this is not an optional feature request,
It’s a bug.
I admit that I was a little to read this:
This implies that we have to wait and pay for a new license to,
possibly,
fix the problem.
Think UX.
This is exactly the fix I attempted for Rhino 7. And it caused other problems (I think the shortcut that you pin to your taskbar gets orphaned and ugly after installing an update). Maybe that symptom is better for you than having all the icons clumped together, I don’t know. The trouble is that I have to pick something that stays broken. And when I do that, I also pick someone to hate that I don’t fix it. If I leave things, you can hate me. If I change it, someone else can. Someone wins - but it’s not me .
I admit, I was direct in my previous message.
And the next day I found a stupid solution that worked for me.
I change the color theme of the interface.
I understand the problem (without really understanding, because it goes beyond my knowledge).
But maybe developing Rhino as a portable application could solve this problem and possibly others.
Like no longer using the registry for windows.
I worked with an error message every time I started Rhino until I found the right key to delete in the registry.
Allow Rhino to run in different contexts.
In my case, CNC (Rhino 6), modeling (Rhino 7), development (All)
Avoid sharing plugins and configurations
I don’t know, I guess if Rhino becomes portable with the ability to set ANY path
pluginS (Rh, Gh, Yak), configurationS. that might solve your problem of having to make the choice.
It would only be a question of configuration and when Rhino8 is released you will have messages like this on this forum:
“How do I use my previous plugins?”
(I hope I understood your message correctly and not made a message out of context.)
jmv
Don’t worry - I can take it. It’s just that I can’t make everybody happy
Yes, there would be advantages to this, for sure. Being able to install Rhino and plug-ins without needing admin rights would be pretty great. Sadly, it also adds complexity for larger organizations that want to deploy Rhino simultaneously on hundreds of computers. Per-user installs don’t work for that, and need to be configured separately to work for all users on a computer.
When Google Chrome first launched it was brilliant in its simplicity. You could install for just yourself with no admin rights on Windows. You still can, kind of, but they’ve come toward what we do, probably to support large organizations.
We could store the same data somewhere else (a JSON file? XML? some other data storage technique) and the bug that caused your slow startup would persist. It would just have data stored somewhere else. Figuring out which reigstry key caused the slowdown and reproducing it here is the only way to fix that bug.
I appreciate your persistence in this problem.
Indeed I had not thought of automation and deployment.
You know better than I do on this subject.
but while reading you, I thought of Visual Studio, UnrealEngine or even the Nvidia drivers.
These apps use third-party software to install and update their apps. (Visual Studio installer, Epic Games Launcher, GeForce Experience)
Perhaps this is a solution to have an entry point for deployment without overly constraining the configuration for each platform / user.
I know this topic indirectly depends on the “No V7 in Toolbar” issue, but yes:
All of my previous links are the same problem:
I don’t have full control over configurations and paths.
I’m curious, on MacOs there is no ToolBar but a DockBar, there is no registry (I guess).
How does the DockBar work with different versions of Rhino and where are the configuration / plugins located?
Is MacOs more flexible for both strategies: deployment / per user?
For people who want it, I create a plugin to fix this: