It would be nice if we had an STL thumbnailer. macOS has this and I find it *really* useful when I'm doing some 3D printing since I can see what a model looks like using the file manager rather than tediously open it in a viewer app.
Git commit a5ded8f01e60948e58aa7ee109a65514208ef873 by David Edmundson. Committed on 04/04/2020 at 22:20. Pushed by davidedmundson into branch 'master'. Add 3mf thumbnail support Summary: 3D Modelling Format is based on "Open Packaging Conventions" which is already supported by the opendocumentthumbnail spec, we just need to add the relevant mime type so our thumbnailer gets used. Test Plan: Registed mime type from glob. (I should submit this to fd-shared-mime spec) Opened dolphin with a 3mf file with a thumbnail. It "just worked" Reviewers: broulik Reviewed By: broulik Subscribers: kde-frameworks-devel, kfm-devel Tags: #dolphin, #frameworks Differential Revision: https://phabricator.kde.org/D28570 M +1 -1 thumbnail/opendocumentthumbnail.desktop https://commits.kde.org/kio-extras/a5ded8f01e60948e58aa7ee109a65514208ef873
The more I look into this the more I think we shouldn't try and focus on making N thumbnailers but instead create and support a better cross desktop thumbnail system. Gnome works by having a registry of mime types and then an executable line to run that takes a file name in, a size and a filename out. KDE code is running a binary that passes a filename in, a size gets a file out. We just happen to have the one binary(kioslave) that in turn loads a plugin than in turn loads a plugin. Migrating KDE code to do the same thing as gnome in a way that doesn't change any of the existing plugins would be absolutely doable, even within KF5. That just leaves the task of a common format for storing the metadata...and bam! Then a 3rd party STL thumbnail author wouldn't target any particular desktop.
(In reply to David Edmundson from comment #2) > The more I look into this the more I think we shouldn't try and focus on > making N thumbnailers but instead create and support a better cross desktop > thumbnail system. > > Gnome works by having a registry of mime types and then an executable line > to run that takes a file name in, a size and a filename out. > > KDE code is running a binary that passes a filename in, a size gets a file > out. We just happen to have the one binary(kioslave) that in turn loads a > plugin than in turn loads a plugin. > > Migrating KDE code to do the same thing as gnome in a way that doesn't > change any of the existing plugins would be absolutely doable, even within > KF5. > That just leaves the task of a common format for storing the metadata...and > bam! > > Then a 3rd party STL thumbnail author wouldn't target any particular desktop. It's a bit more complicated than that, with live previews and whatnot. If you've tried to use e. g. chromium with the default gtk dialog (which you need to be able to select save format) you quickly see why it's a bad design. There's a reason bigger gtk apps like gimp have to basically reimplement the file dialogs themselves.
Perhaps this can be added https://github.com/krepa098/stl2thumbnail?