Open BergenSoft opened 3 years ago
I think the problem is also related to the header. There are also some more scriptable settings which disapear, when using ScriptDude.
Generally I like the idea to write the information in the head of the file. But its conflicting with the Scriptable header.
I took a look into the code and was confused, why you create also a scriptable header at the beginning of the file. Even when the script has its own header.
I think there are several ways to solve that:
Always look for a Scriptable header and place your header below. If there is no Scriptable header, you could do it the way you do it right now and add one.
Use a separate ScriptDude.json file to save the information that are in the header right now.
I would prefer the second one because if scriptable will implement any new features or settings it won't affect your script. But I'm also fine with the first one, but here you really have to take care what you do with the headers.
What do you think?
I do not like the approach of having an external file to store information about a script within the Scriptable folder, as it quickly messes up the file system if you have multiple scripts doing that.
I did ignore the header (or always add another header) because of the way ScriptDudede identifies updates - through hashes. I do always get the hash of the code below the ScriptDude header and compare it with the hash of the remote file. If I was about to implement your suggested changes, this would be much more difficult. In addition to that, I want the color and icon of a script to be user-definable. Nevertheless I agree that the header handling needs to become more robust than it currently is.
For me it wouldn't be bad to have one more file in the system. But ok, the second is also fine. I forked your repo and fixed that problems.
Please take a look to the pull request. It should solve the header problems.
I was thinking about looking into this one! I'd suggest avoiding any subsequent additional files in the users file system, just in case it accidentally get's removed and causes an issue with ScriptDude randomly resetting the icons/colours on an update because it couldn't find the data.
What about initially using the original script header data the first time the script installs, then ignoring it on subsequent updates - this would allow the script developer to have the icon and colour preserved when installing for the first time, but allow for customisation by the user without affecting ScriptDude's update process?
When installing a script with scriptdude, than the color and glyph-icon of the script is not recognized by scriptable. I think that the scriptable header should always comes first and after that the script dude header.