Button gets the .PNG image size wrong

Eto is WPF on Windows Rhino.

Hi Steve, did you have a look at the crash log ?

:shushing_face: Yes But I suppose @osuire wants to mix them, a.k.a, use them together?

Ok, so you get the swollen icons too, right ?

That’s fine as long as you are only developing for Windows. You can mix WPF with Eto. Look at the crash that was posted here; you can see that it is just WPF.

@curtisw can you take a look at this? I’m having trouble deciphering what is happening. It may be the reason Olivier has had problems with WPF for so long… or maybe not.

@osuire the crash is happening because human-ui includes an old version of Xceed.Wpf.Toolkit.dll (3.0), which is incompatible with the version that is shipped with Rhino (3.6). Due to the way we handle assemblies in Rhino, this causes a conflict if the human-ui version loads before the one shipped with Rhino.

If you remove (or rename) that assembly from the human-ui plugin it shouldn’t crash. I’ve created RH-62909 to look into a way to get around that if possible without causing other issues.

As for your issue with image sizes, your source image appears to be saved with 16 Pixels Per Inch. WPF looks at this to determine what size to show it at. Windows is by default 96 PPI, so 32 pixels * 96 / 16 = 192 logical pixels. If you edit the image and re-save it at 96 PPI, then it should show at the expected size.

Hope this helps!

Hi Curtis,

I renamed the dll, restarted Rhino, and still got the crash.
I deleted the dll, restarted Rhino, and still got the crash.
The Human UI interface works though.

I checked the source images, and they are saved with 96 ppi

Maybe Human UI “thinks” they are 16 ppi…

saved with 96 ppi

Hm, I extracted the image from your .gh, loaded in Gimp and this is what I get:

Perhaps something in the way your are saving it is causing that issue, or the tool… Removing the resolution info from the image also is another way to get things working. Try the 96dpi image from here and see if that works for you: someimage.zip (2.7 KB)

Hm, odd. How did you install human-ui, and what .dll did you remove exactly (full path)? I installed it automatically when loading your .gh definition (via yak), then deleted this file:


If you installed it differently then you need to delete it from wherever it was installed to. Also another thing to look for is perhaps you have other plugins that include that same file.

Original vs 96

Indeed !
It’s strange that Windows doesn’t give the ppi detail on png files.
Even stranger : for the jpg version, the file details said 96 ppi, but somehow, it was something else.
What a mess.

It was installed long ago ; I can’t remember how exactly. The file was here : C:\Users\osuir\AppData\Roaming\Grasshopper\Libraries\HumanUI\ , and it was indeed the XCeed.Wpf.Toolkit.dll
I find this folder with GH using Files \ Special folders \ Component folder.

An extensive search on my drive for this file yielded this result :
So there’s another set of files here … but why ???

There’s been a whole lot of confusion with GH plugins , going through V5, V6, and V7 with sub-directories, and even the “lazy load” folder (is that from some tired porn star ?) ; and now there’s also stuff in a “packages” folder ?
Lazy load

Isn’t it time to tidy-up all that stuff ?
How can I get a clean slate ?

I’m not even sure I can find the latest versions on Food4Rhino anymore, since the avent of the “packageManager”…

Headache rising. Better go to sleep.

*LazyLoad is created by Pancake. It’s to allow loading libraries when needed, to improve GH’s startup time. However this feature isn’t public yet and those two folders are dummy folders. They would not be created in the following releases.

You can go through Pancake’s addon manager to see what library (HumanUI & Xpf) is used:

1 Like

I suppose it can be done by referencing strong-named assembly?

OK folks, what’s the deal with this folder ? Libraries were already mangled together between V5, V6 and V7-compatible versions, and now there’s another folder, not even listed in GH’s “special folders” ?

After a scan on my laptop at work, I realize that I have six XCeed.Wpf.Toolkit.dll files !!!

So are these the “new official” folders for GH plugins ? :

IIs the old “Components” folder obsolete ?
I still have a Human UI there as well , and all my other plugins…

Really, I’m lost, and it’s no wonder there are crashes and funny behaviors with the interfaces in the middle of this mess.

The packages are new official folders for plugins installed through Package Manager. I suppose manually-installed plugins are still expected to be in the Components folder.

I’d recommend to try deleteing all Human-related Xpf files first (dont forget to make a backup).

Well, I heard by complete chance about the package manager, but I wasn’t aware it installed stuff in another folder.

Why is it not listed in the “Special folders” then ?
Special folders

And how about Food4Rhino ? Should it be avoided because some important plugins like Human or Elefront are no longer up to date there ?

So what happens exactly when we update a plugin through that package manager ?
It creates a duplicate of the files instead of deleting the old ones, thus creating bugs and headaches…?

And what about the plugins that can’t be gotten through the “Package manager” ? Should we move them to the “Packages” folder to have everything in one place, or should we leave the plugins scattered all over the place ?

I realize that this is way more fu**ed-up than I thought !!!

food4rhino is now, sort of, integrated with the package system (yak). You may see some plugins providing GHA and YAK files at the same time. GHA files are for manual installation while the YAK is an installer, which results in the same thing as you install it from the package manager.

If you update a plugin through the package manager, the plugin will be updated, if the previous version is installed as a package (aka not manually copied).

I believe they’d be in the current Libraries folder. Yes the files are scattered.

My opinion is that a bad system is better than two systems.

Where’s “YAK” anyways ?
Take Pancake for instance, all I see on Food4Rhino is a “Download” button and after that, it’s the good old manual install with the silly Windows “unblock” procedure, and opening the GH components folder and dumping all the stuff there.

As a guy more focused on doing stuff with plugins rather than following McNeel’s latest fantasies, I find myself completely lost between all these install / update procedures.

We rely on a bunch of plugins, and we have many Rhino seats to maintain, so all this crap is really making our lives harder.

I’m afraid the new PackageManager (YAK is the name of package system) is what McNeel is promoting. It’s slightly easier for new-installations/new-updates. You launch the package manager, find what you need, click Install, done; and click Update when there’s new version. Though it’s very confusing when a plugin is previously manually-installed.

They could start by adding the /package/ folder to the “Special folders” GH list !
I knew about the package manager because you mentionned it, but that was by complete chance, and up to now, I had NO IDEA that it installed the files elsewhere than the “Components folder”…

Also, there should be a warning when newer versions of plugins can only be installed through YAK, and the Food4Rhino version is obsolete !

Hi Curtis,

I followed your instructions, and now the crash is gone.
Human UI manages to work without the file ; maybe it grabs the one used by Rhino , I don’t know ; this is way above my head.

I also figured what was going on when I exported from Xara Designer X : when I set the dimensions in pixels, it would automatically change the dpi setting, and I never noticed that.
Now I have setup my “icon forge” page so that the size of my vectors matches the page’s resolution, and it’s all smooth.

Thank you very much !

1 Like

That’s great! I’m glad it’s working. Yes, it’ll grab the copy from Rhino now, which should work with anything that was built with an older version. I’ll see what I can do to make it so you won’t have to worry about this in the future.

Ah! glad you figured that out, it was certainly a head scratcher.

1 Like