What    |Removed                     |Added
                 CC|                            |

--- Comment #1 from ---
(In reply to contact from comment #0)
> ... obj files are a legacy yet still commonly used File format to exchange 3D
> Models. As it is a plain text format, baloo will generate huge indexes of
> these files ...
For me, the .obj file is recognised as mime-type "model/obj"

    kmimetypefinder suzanna.obj

The section from the freedesktop definitions that identifies it is here (this
is from Fedora, this segment doesn't appear in Neon)

    <mime-type type="model/obj"> 
      <comment>OBJ 3D model</comment>
      <sub-class-of type="text/plain"/>
        <match type="string" value=" OBJ File: '" offset="0:64"/>
        <match type="string" value="mtllib " offset="0:256"/>
      <glob pattern="*.obj"/> 

The logic is pretty basic (the file contains "mtllib " in the first 256
characters). It seems to fit though although there definitely a chance of false
positives. I see there also another ".obj" with different "magic" that gives
"application/x-tgif". "model/obj' is flagged as a subclass of "text/plain" and
I'm guessing that's enough for Baloo to index it.

As Fedora and Neon have different versions of the freedesktop mime-type
definitions, the behaviour may be distro dependent. You'll need to see what
Nixos does.

Ways of fixing...

Baloo has a set of filename exclusions, files it does not index. That appears
in the ~/.config/baloofilerc file as an "exclude filters" line. I've checked a
couple of systems and they have ".obj" in the exclusions, but not "*.obj".

Maybe that's a bug or at least strange.

However Baloo can also exclude mime types, see Edit your ~/.config/baloofilerc
and add a line under [General]:

   exclude mimetypes=model/obj

Don't know doing this declaratively but you can script it with:

   balooctl config add excludeMimetypes model/obj

This seems to let baloo index the filename but not index the content,

> The file name, maybe the names of objects included in the files and some 
> metadata.
If you want to parse the files, that's a bigger job, a dedicated KFileMetadata

You are receiving this mail because:
You are watching all bug changes.

Reply via email to