It would be good to allow the creator of a definition know what plugin is needed for a definition when sharing it. even have a package feature to include those plugins.
Also when I manually manage to find Human (I think Grasshopper should have found it, instead of telling me “Better luck next time!”) when I drag n’ drop it to my Grasshopper window it makes it dissappear from my folder. Which means now I cannot even manage manually my plugins to share with my team, when you are telling us: “Better luck next time!”)
hahaha! This month I’ve been using a lot or Rhino and Grasshopper, and the more I use it, the more I shake my head with all these hiccups that don;t seem to be a major technical limitation, but rather not enough empathy for users. All these issues become real apparent when you are working with different people, sharing files, switching computers, or having to use Rhino V5, V6 and V7 wip for different things. There’s soooo much friction all over the place that gets in the way of having a good user experience.
Complains about the ‘wrong shade of gold’ aside, we are pretty happy with what we can achieve with these programs. I can’t wait for the Fall 2018 SubD update!
The issue of opening Grasshopper definitions from collaborators with third-party plug-ins has been around for a while. I’ve been in your shoes and that’s why I started the Package Manager (Yak) project and added the “Download and Install” button (a.k.a. Package Restore). Even though there aren’t many plug-ins available this way yet, we thought that it would be a good way to expose this project to users (and indeed it’s currently the only way); if it doesn’t work then users are in the same boat as they’ve always been, having to manually download and install Grasshopper plug-ins. However I can appreciate now that for users who aren’t used to the current manual method of installing Grasshopper plug-ins it could be frustrating when the Package Restore doesn’t work. I’ll try to improve the messaging around this (instead of “Better luck next time!”).
When you drag and drop .gha files they’re being moved to %appdata%\Grasshopper\Libraries\.
Yes. I save my files where I think makes sense for me to manage them. In our case we maintain a shared network folder where we can all go and look from he files we need. It makes no sense that the first time one person goes to install a plugin Grasshopper steals the file. It should copy it’s own duplicate, never move what a human already decided to place somewhere. This behaviors is not consistent with any behavior in Windows. It should be fixed.
Sorry, but if you drag and drop anything from one folder to another in windows it gets moved, not copied. Same when drag and drop into gh (move to component folder).
In my opinion, this is right the same behavior as windows…
It should copy it’s own duplicate, never move what a human already decided to place somewhere. This behaviors is not consistent with any behavior in Windows
as @tim.stark mentioned, That is a windows behavior, nothing to do with Rhino/Gh. You can change default behavior:
" * If you drag and drop a file/folder from a location to another on the same drive, then the default action will be to move the file/folder to the drop location."
I think Grasshopper should have found it, instead of telling me “Better luck next time!
This is a new feature via Yak. However it only works if the plug-in author adds the correct code in their plug-in for gh to find it. Many devs have yet to adapt it (myself included) and since most plugin authors are not employed by McNeel, they are not really obligated to do so (or they simply don’t even know about it yet) and it is not in McNeels control. I believe you will see it catch on more as it becomes more popular.
I’d hate for software to move my files when I drop them onto them. My .txt, .cs, .py, .3dm, etc files nicely stay where they are when I drop the on gVim, Visual Studio, Rhino etc. Windows explorer is a separate case.Besides a drag and drop between two Windows Explorer instances with one on a network location also just copies, not moves, you have to hold SHIFT to get a move.
What you do not understand is you are describing softwares file types as a drag drop which of course won’t move because there is nothing to move. You are just launching the “open” function.
A gha is an assembly (plug-in) not a openable file type. So the operation you trigger in that case is “move” because what you are doing (behind the scenes) is actually moving the plugin to the plugin folder where gh can find it. This folder is found at File>Special folders>components folder.
This falls under windows “drag and drop a file/folder from a location to another on the same drive” which by default windows sets to move. Not that this is a great default, I’ve changed it long ago.
The .rhp file doesn’t get moved anywhere when droppes on Rhino. I’d be upset if it did, to be honest. And it’d be nicer if the move didn’t happen because it is not communicated anywhere and just plain confusing.
It is annoying sometimes for sure. Maybe there is some override McNeel can do. I just know what Windows default it but as you said, seems .rhp ignores default.
You’re not dropping gha files in an opened explorer instance nor folder manager, like when you’re opening files with file->open.
You’re dropping on the canvas. The move operation is unnatural it is made especially for files with .gha in the end from inside the code. This cannot possibly be the same behavior as in WindowsExplorer if it was then right-click drag would result in an drop-down context menu for you to choose what to do Move/Copy/Shortcut. Same goes for when holding Shift or Alt or Ctrl.
You’re not dropping gha files in an opened explorer instance
You are, it is just hidden from you. Haven’t seen the code but I imagine that is all it is doing. Why do I think that? Because when I changed my windows behavior for “drag and drop a file/folder from a location to another on the same drive” to always copy rather than move, the behavior of dropping .gha’s now also copies rather than moves.
The move operation is unnatural it is made especially for files with .gha in the end from inside the code.
Have you seen the code? If so then ok, you solved it. I imagine it is the opposite that there was no special protocol added which is why this behavior. That is not to say that “copy” behavior couldn’t be added, But again - I’ve never seen the code.
