Is that a feature? It’s rather annoying one I would say. I just created a .xrnx package, tried to test it before uploading and renoise just deleted it.
Deleted or MOVED it? I noticed that too, they’re moved from the download directory to the “Tools” folder when dropped onto Renoise.
Deleted, moved, I don’t care. I don’t think it should do it anyway. Or can anyone argue with me on that?
Found this behaviour weird too and it killed basically my own backup of the tool package and i had to create a new one. I like the idea, that it keeps the download folder clean though, so maybe Renoise should ask, if you want to have it removed maybe.
It moves them to the new location (user script folder) when the installtion was successful. I don’t see a problem with this.
For me that obviously makes sense, but lets discuss.
Should Renoise then delete samples and xrns files which are dropped on the Renoise window too?
Also as far as I understood, the drag-and-drop approach is temporary solution anyway. Normal behaviour would be to assign .xrnx extension to renoise and you can directly choose from firefox (or any browser) to “open with renoise” instead of downloading it. Then firefox will handle deleting the file later itself.
I think this behaviour is inconsistent with other programs on Windows and Linux for at least.
- When dropping a file into a program, program should “open” the file, whatever that means in current context.
- When moving files, you should clearly see where the file went (like in file manager), in renoise you can’t see the icon appearing.
- Firefox does not delete .xpi file when you drop it on firefox window. Neither should Renoise.
well I don’t, since when I download and install something I might poke around in it, break it, and then I have to go back to the original I downloaded. so right now I have to manually make a backup of everything before I install… which is more “work” than deleting the downloaded files, it could be argued ^^
and suva really is right in that it’s generally not the expected behaviour, and good point about registering the file extension, too (you could use that wonderful icon from tools.renoise.com!)
The reason why the file-extension has not yet be registered is that Linux seems to be willing to reopen another copy of Renoise all the time.
If some veteran Linux coder has an idea how to tell Linux to use the already opened instance of Renoise and allow it to install the script, this extension registration can be made live.
You need to create a pid file in /var/run or something and acquire lock on it, when renoise starts, it checks if there are no already locked pid files in the directory. If it find one it passes the XRNX file to the running instance of renoise and exits itself. If it doesn’t find locked pid file then it starts up normally.
How to pass the message to running instance? Unix sockets? dbus? (If you are using dbus, I don’t think the pid file stuff is even neccesary).
Alright. Will change this for the next beta.
You might be able to use libunique for this, depending on your policy regarding LGPL libraries.
I thought that this was strange behaviour too, usually when I install something my download doesn’t disappear!