Button gets the .PNG image size wrong

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:

C:\Users\[me]\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\human-ui\0.8.6\XCeed.Wpf.Toolkit.dll.

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 :
C:\Users\osuir\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\human-ui\0.8.6
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 ? :
C:\USER[me]\AppData\Roaming\McNeel\Rhinoceros\packages\6.0\human-ui
C:\USER[me]\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\human-ui

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

Just set the image on the size you need and upload it once again. I mean, you can change the photo size and upload it to the size it is required. Photo editing is a very common problem nowadays, and while there are thousands of paid applications, I use a free site when I need to improve a photo’s quality or to change its size. So when I need to edit a photo, I just access https://imglarger.com/enhancer and make all the changes I need. I hope you will find this information helpful, stay safe, and have a wonderful day!

Hi Bernadette.

I use Xara Designer X.
Now that I have scaled my images to the page layout, they export fine in 96dpi.

Cheers !

newest version on yak uses xceed.toolkit.wpf.dll v 3.6, hope that helps

I’ve been using Human UI intensively for the past months without this dll, and it’s been working just fine.
It probably uses that of Rhino… Are you sure it’s better that Human UI has it’s own ?

By the way, is there anything new to look for ? Some features related to the Data Table component perhaps ?

I can’t build it without the dll. To maintain compatibility with versions of rhino that don’t ship with it, I have to package it. It won’t be a problem as long as the versions are compatible.
The only other new change in this release is a compatibility fix with grasshopper player submitted by @stevebaer, no new features otherwise.

What versions of Rhino are you trying to support? We can probably create Rhino version specific yak packages.

(edit) I guess the yak packages could just always not include this dll as those packages are really for V7 and beyond

Just to be a bit of a stickler here : please use the term “Package manager” from now on.
It took me a while to figure out that this was the new “official” name of the “Yak” thing because this term is still randomly used around here.
It’s already confusing enough to have two different sources (Package manager + Food4Rhino) and two different install folders.