Will Tracker finally have the ability to support user preferences like icon mode, etc. for all generally accessible folders no matter if they’re read only? This would include the blue folders that are linked to the Deskbar. I think it’s important to have feature parity with BeOS in this regard.
“Feature parity” isn’t quite the right word here. BeOS couldn’t save the state of a folder on a read-only medium either, which is what a mounted package fs amounts too.
I agree, there must be a solution for the issue eventually, but none has been proposed yet. See ticket #10094. +1 the ticket to up its importance. 
Well what I mean by feature parity is being able to view the Applications, Preferences, etc. folders in icon mode and persist that user preference, which BeOS supported.
2 Likes
The problem with the so-called “blue folders” (Applications, Preferences in the menu) is that they are not really folders.
In fact, they are query results shown as folders for convenience.
I would be possible to have an icon view but none came up with a patch to do it yet.
I really think those folders should be just listings of the actual folders themselves. It is extra work to add links to those folders, porting-wise, and they are not localisable.
Having the actual folders compliments the “simple” philosophy as well.
1 Like
They are not queries, they are a quick hack to have an editable Deskbar menu built from a merge of read-only and read-write data. The goal was to have some way to edit and organize the Deskbar entries while still having them auto-populated when adding and removing packages by default. The “simple” philosophy is nice and fine, but there was a strong requirement by users to be able to customize the deskbar AND also a strong requirement to have new apps automatically added to it.
It was not the plan to keep them, I think. This hack should be removed and Deskbar should work in some other way (mmu_man suggested to use queries).
The actual directory is still there (/system/data/deskbar/menu) and can be used in any view mode, but, being read-only, it is not possible to persist the view mode when showing it in Tracker. So even if we changed Deskbar and removed the “blue folders”, you still couldn’t use that.
The other thing to do is improve Tracker so that the queries and “blue folders” (they share mostly the same code on Tracker side) can be displayed in icon mode.
1 Like
Will Tracker prefs be fixed and blue folders be deprecated before the first stable release of R1?
As humdinger said:
Right now it has only 3 votes (including mine), that is not enough to make it a high priority thing.
(in case you missed it: when you are logged in Trac, the vote buttons are two arrows at the top right of the ticket view, which allow you to vote a ticket up or down)
You can see the tickets with highest score here: {9} Most Voted Tickets – Haiku
1 Like
I do intend to experiment with some options for this, once I get back into normal Haiku development. Lately I’ve been busy with working on things needed for Haiku, Inc. as well as just usual life business. Pretty much in the same state as I was 3 months ago in my last comment on that ticket. I definitely won’t work on it for the Beta 3 release but there should be something by R1.
Hopefully if I come up with something that works well enough it won’t be held up for not being totally perfect, like the idea of maintaining the state of read-only folders somewhere under ~/config. But I’ll keep thinking about it.
1 Like
That was my thinking as well for storing Tracker prefs for read-only directories in ~/config. It’d interesting to see how you could wire that up.
I haven’t looked at the relevant Tracker code in a while, but the general thought would be that when Tracker opens a read-only folder, it checks for a particular file associated with that folder, maybe something under ~/config/settings/Tracker/folder-attributes. The file in question is maybe named after the full folder path, with slashes replaced with some other character, or it is a hashed version. Either way the same folder path should always map to the same file here. That file then contains the attributes for the folder. When the attributes are changed the same process is used to find where to save them.
So we add some indirection in the Tracker code for where it loads and saves these settings, and some way to generate a file name from a folder path.
We implement that and see how it goes, if there are weird corner cases we can try to fix them.
Separating a folder from its attributes is not ideal and carries all the usual drawbacks of splitting things apart, and PulkoMandy made a list of them in the ticket linked above. But I think some are not that big of a deal and having something that works well most of the time is better than nothing.
1 Like