You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree, this sounds useful. Adding a way to attach files to a bag together with a widget for viewing them would probably also make it easy to implement #102 . I'll have to think a bit about a good way to implement actually storing the files; off the top of my head, I think it'd be useful to be able to attach files through the GUI, add them via a script, or read them from disk at the same time a bag file is added to the filesystem.
In the meantime, technically a script can return anything you want and it will be saved, although binary data might break the result viewer, and anything that's not JSON won't have pretty formatting. A workaround for storing binary data might be to base64-encode it and then store it as a string in JSON output...
That would be a good addition indeed. Currently our workaround for this and #123 (reported by my colleague) is to save files in a parallel file tree and viewing them manually (and optionally tagging with the path to that data), and it would be very useful to be able to e.g. return a file path or URL or even b64-encoded data and have the GUI recognize it in the bag info, allowing downloading or viewing (for images).
We have a topic that publishes data (position, acceleration, ...) and we want to extract this data to a csv file.
It would be nice if we could add file attachments to a bag through scripts, which can then be downloaded via the bag information window.
The text was updated successfully, but these errors were encountered: