If you think Haiku should do this or that, consider to help with contribution. Everything else is cheap talk.
2 Likes
Cheap talk is better than silence. But you do not understand that.
1 Like
You can read the corresponding package into my HPKGCreator and then change it and try to import it, but after the next update the previous package is back and it has to be adjusted manually again.
If you really want to change that, please post this as a suggestion on dev.haiku-os.org.
I don’t think so. Any organized activity in the community always begins with a discussion of the existing and desirable situation somewhere or for something. Of course, personal initiative also exists and is something to be encouraged, but it cannot replace the organized activity of a group of people. In addition, each person contributes as much as they can (or want). And creating Haiku isn’t just about writing code. I think any helpful opinion or comment is welcome.
3 Likes
In this case the annoyance probably comes from the blue folder thing beeing discussed for years with countless solutions proposed but nothing actually beeing implemented : )
That would only solve the Demos Deskbar menu items. What if the user wants to change something else?
I like the read-only file system idea that is populated by packages. I would like if packages was not allowed to write to the file system at all because it creates problems on package updates or removal. It simply leaves scattered files across the file system that is no longer needed. Just have a look at any “older” Windows or Linux installation, they are full of old orphaned files that was created by an application that is no longer installed.
Instead I would like support for making changes to the file system using some kind of “diff” functionality using rules. This way files that are in the write only part of the file system could be changed, moved or deleted, and changes can be reverted.
This could be utilized to freely make changes to the Deskbar “blue folders”. Another usage is editing of configuration files.
A stop-gap to identify orphaned files is to mark them with attributes so their source can be identified (what package created them etc).
Wouldn’t it be enough to create an uninstall info file in the package that is retrieved when a package is uninstalled. Of course, by asking the user, because they may not want to delete their saved data. Yes, and there would still be unused data on the computer that not everyone would stick to. I would also like to have a data folder in the home directory, which can be used as a storage folder for user-specific data (resulting from applications and games, not user files)
That would work for files created in the package installation process but nothing else. It is also a manual process that can be limited by human error.
The package manager could automatically assign attributes to any files created in the installation process. Native applications could also create similar attributes during operation so they can be identified later on via a query.
Files that should not be deleted should be marked as such via attributes.
Shared files should be marked by each package. In this way when uninstalling packages that shares data, shared files will not be deleted until the last package is uninstalled. I don’t know if such a situation exist in Haiku today.
What do you mean by this?
In this specific case, the situation has been debated already several dozen times over the past 10 years, and repeating the same arguments and reaching the same conclusion is just a waste of energy. Here is one from not even a year ago: Idea Standardization for categories for deskbar menu - #47 by apl , I don’t think anything happened since then, so, what was discussed there is up to date and there is no need to replay this discussion from the start, the outcome will be the same.
The ticket is here: #18250 (Better deskbar menu categorization) – Haiku
The proposed solutions are:
- Use queries instead of folders to populate deskbar. This would mean you can add and remove things by editing attributes, instead of using directories. This would not allow full customization, since you can’t edit attributes inside packages, however, we could provide several attributes in each package, and let user switch between different queries (or write their own) that would expose the apps in different ways,
- The current way DeskBar is managed is by “blue folders” which merge several directories into one. We could make it possible to delete these directories and replace them with normal directories for people who don’t want the package manager to add anything to their deskbar automatically. This is currently not possible because the “blue folders” themselves are in a packaged directory, it seems not difficult to move them to a writable directory
So, yes, now, someone who really cares about it should submit a patch. Or you can wait for people who are perfectly happy with the current situation to do it for you, but, I don’t see why they would.
1 Like