FileTypes: visible hint when "editing" a read-only file

[-Meanwhile-]

The FileType add-on window shows the icon of an application (in what I think is called the 'icon-well'). It used to be possible to right click on that icon, choose 'Edit icon...' and edit it through I-O-M that opened as a result. This effectively doesn't work anymore, since the icon can still be edited but saving the result doesn't work anymore. Similarly, replacing an icon doesn't work either; this used to work by drag-dropping a replacement icon from the application type window that has the replacement icon to the application type window that has the icon to be replaced.

[pulkomandy]

Are you sure you are editing writable files? If your application is in a package, it is not possible to write to it. Have you tried with an application that is not packaged?

[-Meanwhile-]

I assumed that was the reason. Maybe then the ticket could be named 'Icons from packaged files can't be edited or replaced by the end user', but the fact remains that currently there's functionality offered/suggested by FileType that in practice doesn't work in many cases.

[dcatt]

Packaged applications should allow such user changes. I tried to update the icon for MailNews sometime back to the one HaikuDepot offers but obviously with the read-only nature of packaged apps crushed the hopes of my desired change.

[mmlr]

In cases where it'd benefit other users as well, it would be nice to get such changes into the packages by adjusting their HaikuPorts recipe.

As for the read-only part: Please note that this is also a feature. Recently more operating systems are moving towards read-only packages for their much easier handling.

Introducing writeability (for example through a persistence feature in the already existing write_overlay or through the packagefs itself that already presents merged views anyway) would certainly be technically possible. But from a user perspective it could get messy very quickly. You lose the self-containedness and simple upgrades if you have to consider what user modified content may be present, as there is no 1:1 relation on what package such changes belong to and on what events they may need to be removed/updated.

That being said, packages aren't all that magic. They are basically just archives. Extracting a package using the package tool, modifying some content and creating a new package from that isn't terribly complicated. It also keeps the changes within that package, so an upgrade will consistently overwrite them, instead of some changes remaining and possibly breaking things.

[-Meanwhile-]

What I think is bad is that right now the FileType add-on has now become inconsistent, as it may sometimes work and sometimes not. The end user/ Joe User will get confused because of that, and can't be expected to know about any of the technicalities explained above.

BeOS was an OS for both developers and end users/Joe Users and -in my understanding at least- Haiku was supposed to be an improved recreation of it. Maybe this has changed along the way, but then I wonder how deliberate that change was and if it was ever announced.

Every major OS (and even most smaller ones) has always let the end user replace and often adapt its stock icons, BeOS included.

Haiku now lacks this sympathetic option, thereby reducing the status of Icon-O-Matic from an application that both developers and end users/Joe users can use to a purely developers tool.

[dcatt]

The read-only nature of the random parts of the system directory (packagefs included) has certainly been annoying and taken some fun and flexibility out of the OS. I should be able to do simple things like change app icons, set Tracker preferences, etc... to any file or directory so I can have the OS look and behave the way I see fit (within reason) and with this package management implementation since it was introduced (after the A4 release), has obviously taken some of that ability away.

There has got to be a way to have your cake and eat it too. Like -Meanwhile- said above, inconsistent behavior between like things will be both confusing and frustrating for end-users.

One of the reasons for me using Haiku (beyond the simple yet powerful ala BeOS) is to escape the inflexible/insensible changes that other OSes (like Windows, Mac, and sometimes GNU/Linux) have forced upon end-users making them little less enjoyable to use these days.

[pulkomandy]

Ok guys, if this ticket turns into yet another "read-only package sucks" rant, we'll just close it and ignore the issue. We are bored of this now.

So, let's try to fix the problem instead: FileType should somehow let the user see that the file you opened is read-only and cannot be modified. This applies in the case of package-managed files, and in all other cases where the files are read-only. For example, you hit the same problem if you mount a data partition read-only and try to edit files in it. Or when the permissions are set to not allow a write.

As for customization of the operating system, well, for me this never was the goal of Haiku. On the contrary, providing a well-defined and recognizable user interface is one of the things that make Haiku what it is. If you want endless customization and tweaking, Linux (probably with KDE) sounds like a good choice. Or you can just contribute your changes to Haiku itself, if they are really good. Why keep them for yourself?

Icon-O-Matic can still be used for customizing icons for your own directories and documents. We don't want "joe the user" messing with system files directly. This is something that I learnt even on my old 8 bit machines: "always work on a copy of your system disks, and keep the original floppies write-protected". Going any other way opens the path for virusses and other bad things happening to your system.

[-Meanwhile-]

Replying to PulkoMandy:

Ok guys, if this ticket turns into yet another "read-only package sucks" rant, we'll just close it and ignore the issue. We are bored of this now.

It's kinda unprofessional to put ego(s) above the project itself, or even to threaten to do so based on your own hyper-personal perception of the moment... but let's blame the moment rather than you.

So, let's try to fix the problem instead: FileType should somehow let the user see that the file you opened is read-only and cannot be modified.

That's one approach to "fix the problem". It would surely take away the confusion/annoyance of the uninformed end user, but at the same time it would leave Haiku as an OS that forms the exception among OS'es in that most of its relevant icons would be un-editable by the end user, contrary to the OS it's meant to recreate: BeOS.

As for customization of the operating system, well, for me this never was the goal of Haiku.

Neither was it to BeOS and neither is it to me.

As I said, allowing end users to replace icons with their own designs or with icons from icon packs is common practice with both closed-source and open source OS'es and this has been the case since their early versions, so that means for at least two decades.

You could say it's a tradition and something users will expect to be able to do in Haiku.

On the contrary, providing a well-defined and recognizable user interface is one of the things that make Haiku what it is.

Exactly, just like it was with BeOS.

If you want endless customization and tweaking, Linux (probably with KDE) sounds like a good choice.

Maybe you're talking to commenter DCatt here, but I'm not talking at all about endless customization and tweaking, I'm talking about the same limited, well-dosed, useful and pleasant level of customization and tweaking that BeOS offered, indicating my assumption that Haiku is supposed to be an improved recreation of that OS.

Or you can just contribute your changes to Haiku itself, if they are really good. Why keep them for yourself?

Again talking for myself: I'm not a developer/coder.

Icon-O-Matic can still be used for customizing icons for your own directories and documents.

Sure, but custom icons are generally made for applications, preferences, everything in the blue folders and anything but own directories and documents.

[pulkomandy]

As it was pointed out, if you want to change the icons in the system packages, you can extract the package, make your changes, and repack. There could be a tool to make this easier for end-users (maybe the feature could be added to ThemeManager for example). But manual tweaking of the icons with FileTypes is just not the right way to do this.

As for blue folders, these were created specifically to allow some customization of the deskbar organization, so, in principle you could replace your "blue folders" with regular folders and customize those. However we did not finish work on this yet, so you will lose the automatic insertion of entries in the DeskBar by pkgman if you do so.

Anyway, first let's fix the problem that FileType leaves you clueless when the FS is read-only, and let's stay focused on this here. Discussions on the best way to customize icons and wether we want to allow it at all do not belong in the bugtracker.

[-Meanwhile-]

Okay, interesting. Hoping for that tool (after the FileType issue is fixed).

[-Meanwhile-]

As for the milestone label of this ticket: there's talk of first fixing the FileType bug, but tickets that are bugs can be fixed up until the release of R1 (or even later, but I think this is an R1 bug), that means they can be fixed after the beta. Problem is that the upcoming beta is defined by having 'all features present', so if a small application/tool (that can unpack and re-pack) is to be added in the main distro, it should be already present in the beta (by that definition). Also, I don't see a need for discussion now on whether Haiku wants to allow users to customize icons, as the project started with this option available to the user. So it's clearly a regression.

[-Meanwhile-]

I can't modify this ticket to change the milestone to R1/beta1, so if somebody could do that for me, thanks.