Please make a new software for Haiku, not only a port

I don’t understand this at all, getting rid of file extensions is a good thing, our mime types for differentiation are much better (and actually allows you to remember the mime type of files you get from the web or mails)

Why would we want case insensitivity?

6 Likes

Exactly that’s the point. This is the current situation now, and the creator of this thread/post complained about that too little native apps are created. And I gave one idea, what could be done for developers to be more attracted to develop native apps.

Yes, the down side is: you need to set up an own server, making a secure connection, creating data bases, this is work that many are not very comfortable with, and the other disadvantage is: If I collect data, it’s only for me, the others don’t have access to it to use it. But if it is done system wide, by haiku, it could be public information accessible to everybody and the collection and evaluation would be done the haiku, which you trust more than a 3-rd party developer.

You know how annoying this is to users (and how many are just not answering to question, and even if they do, it is usually not very reliable information).

I meant more flagship applications, flecks (there are a lot of small apps). There are no applications that would, for example, interfere with the development of the Haiku toolbar and gui.

It’s a storm in a glass of water, I understand there are developers from Haiku who fix the bugs of the system. We need users who program and can think creatively while creating native apps.

If you want to be spied on,you can simply use Windows or Android.
Haiku is here to make things better,and violating the privacy of users is no improvement.
Yes,it would be cool to have more native applications,but if that is the price,then it’s too high and I’ll rather stay with ported stuff.

1 Like

we do not create reality, we copy it
a little bit sad

True, but our “User base” ist very smal.

The developers of the system can not be the same people making apps at same time.

There are some people around, making new stuff and other one try to port. I do not see a problem here.

Developers from outside, coming to haiku, want to make there available apps working in haiku too. So these are ports too. Ports are not a bad thing.

If you have an idea for a native app, you can try to do by yourself or found someone doing it. It is not the right way to say we need more native apps, without doing something by youself.

And many people do that they can do. If someone is good in porting apps and games, why he should do that not?

You can help making haiku more popular, so we get more users. More users, more ideal, more apps.

2 Likes

Tangentially related: Simulacra and Simulation - Wikipedia

1 Like

It really isn’t. Countless times I’ve had video files be detected as audio or text files in Haiku, even though I can open them in a video player and see that they are video files. A user also doesn’t necessarily want to open .txt, .ini and .cue files with the same program even though they are all technically text files.

So with MIME type based file type detection, you have to use workarounds like using a launcher or opening the program first and then opening the file that way. Simply double-clicking a file in the file manager becomes a lot less reliable and less flexible.

Case sensitivity is a major source of confusion and false bugs. To a lot of people, “A” and “a” are the same character and casing is often ignored entirely in casual conversations. With case sensitivity, you get situations like not being able to find a file because you searched for “door” instead of “Door”.

Or a program might expect a file with a certain name to be present, and then a user will report a “bug”, only to find out that the file had a capital letter somewhere. Search engines online also understand this problem and they are all case insensitive.

2 Likes

Or… you could just report a bug? I really don’t see the problem

As for case insensitivity you are arguing that search tools should be case insensitive… just like they already are.

Isn’t case-sensitivity more of a file-system feature than an OS one?

That’s not a solution. You can’t have a database of every single file type in existence and have it work 100% all the time. There are just too many different file types out there. It also takes away power from the user, because it turns an issue (wrong program associated with a file) that the user can otherwise easily solve himself in 2 seconds, into something that he needs to report to developers - who “might” fix it in a few days, weeks, months or years.

Right click the file and select the application to use, rather easy.

So I have to do that every single time?

If the application responsible for opening that file format didn´t register a type for it, so that the OS can open the file correctly, then one clicks with the right button, select Open With, and just mark a checkbox for “Always open with this software”.

If that process isn´t working, or lacks some better UI, that is something that can be improved without causing harm to other parts of the system .

As for extensions, they are nice, but nothing solves the problem of the user renaming files with the wrong extensions, or even without them, and later not being able to find their files because they do not remember the name of the file . And an extensionless file also couldn´t be opened automatically. That would be a case for having all software forcibly appending the correct extension for the file format when creating files. And that also would involve changing a lot of software for not so big a gain.

How is your prefered solution of changing the file extension for every file any better than setting the preffered app for each file?

The unix file utility does a great job of recognising files - in my experience much better than mime or file extensions, because it checks the actual format of the file instead of some extra record that can be set incorrectly. The database is not too large. file (command) - Wikipedia

As for case sensitive filesystems: they are a mess. Look at how many different options are needed to deal with the issue in mount for fat and vfat on open source operating systems. For one thing, case insensitive filesystems allow you to create mixed case file/directory/volume names, but then search on them is case insensitive… It’s far easier just to have very relaxed restrictions on naming and then have search tools with optional (and perhaps default) case insensitivity.

1 Like

We already sniff files to determine their mimetype, the only difference to file is that we cache the result, and allow for a priori knowledge, that is apps can just set the correct mimetype and not need to have to guess which it is.

In the end all sniffing is heuristics, and as such error prone, it is impossible to make it always have perfect results, but using only file extensions on an OS where most apps don’t care about setting them would massively degrade the quality of the matched types.

Edit: for reference, these are our sniffing rules: https://git.haiku-os.org/haiku/tree/src/data/mime_db

1 Like

I wonder how much effort it would be to add the types from the /etc/magic used by file…

It’s not too hard. Basically it’s a file with offsets and values mapped to a type name. Here’s the example for ELFs from the file command repo: https://github.com/file/file/blob/master/magic/Magdir/elf