It’s worth noting: the main Haiku CI is currently offline as the developer who was hosting the build machine moved to a location with much slower internet. A new build machine and home for the CI has already been selected, but isn’t fully online yet, so the nightly builds are a bit behind at the moment.
I’m just curious why a mail message draft should have its own file type, since it’s semantically still a normal mail message, just with unfinished text. So why not just use the MAIL:flags attribute or a separate attribute MAIL:draft (boolean)? @humdinger
If there are 2 separate types, you cannot simply search for mail message, but always have to include the draft type, which is cumbersome and error prone.
What’s the rationale behind this? Was it the same in BeOS?
Hmmm I see, for the icon…
Afaik mails have the mime type 'text/rfc822’ (at least they should imho😏) but I’m not at my Haiku laptop right now to check…
In that case using the super type would over-generalize.
But it’s not a big deal, just a bit suboptimal from a semantics point of view.
Would be cool to allow dynamic icons based on attribute values😏
On the topic of hierarchical mime-typing… some form of sub-typing for text/x-source-code for different languages would also be cool (so, for example, sorting by Kind on Tracker wouldn’t lump .h, cpp, .sh, and .py files all together).
You can already create your own mime types inside of the FileTypes application, like text/x-c-header or something, but there are some bugs with the file extensions and sniffer rules used for identifying files. You’d have to set the mime type of the files manually or with some other tool.