[Andrej N. Gritsenko <andrej@re...>]

    Hello!

PCMan has written on Friday,  8 November, at  0:52:
>On Thu, Nov 7, 2013 at 11:59 PM, Andrej N. Gritsenko <andrej@...>wrote:
>> The centralized storage has few drawbacks:
>> 1) it is application dependent - you cannot use setting made in pcmanfm
>>     even by pcmanfm-qt, no tell about other applications;

>This is not true. If you use a well-know format, such as tdb or sqlite,
>libraries are readily available for reading them. Also, it's not a problem
>for pcmanfm-qt.

    I should've explained it better it seems. Well, you have your storage
in ~/.config/pcmanfm/LXDE/dirs-config file (just an example). How do you
expect any other programs or non-LXDE environment to reach that storage?

>Ideally this implementation detail should be done in libfm core. So other
>programs using it should have access to the settings via APIs without
>touching the underlying storage.

    I heavily against putting GUI-related things into libfm core. And
that is exactly GUI-related, view mode has no relations to common file
manager operations. And since it is used only internally in pcmanfm, it
is simply should be done in pcmanfm itself.

>> 5) cannot set individual settings for two identical USB sticks, one of
>>     which has videos and other has backup data, even if user strictly
>>     wants to have them shown differently;

>This is partially true. If you also store uuid of the device, then it's
>solved.

    I've replied it already in other mail. We should add additional APIs
and stuff to retrieve and store uuids, that will bloat it a bit again.
And I don't want to extend libfm API at this point anymore.

>Creating unwanted hidden files in the folders behind our back automatically
>can be very annoying sometimes. It's a matter of taste. But I'm ok with
>this solution as well since creating in-folder hidden config files is a
>general practice and it's done by Mac and Windows for years.

    As I said already, I have no intentions to remember setting for each
folder visited. I know, many file managers do that but I would implement
that setting only by explicit user's request, and if user never requested
that operation then storage size is 0, no info will be saved at all.

>> Well, about dual-handle settings I would like then to use approaches (1)
>> and (3) together: if file .directory already exists then use it, if not
>> then use own settings storage to keep settings. The approach (2) is not
>> portable while (1) and (3) are, you know.

>Yes, after thinking about it more, I think adding xttr can be too
>complicated.
>The only real benefit of it is no additional files are created and it's
>fast to access without any db query. However, it's not easy to maintain and
>may make things more complicated than they should be.

>Try .directory first then fallback to our own cache just like dolphin seems
>to be reasonable. Since there is no perfect solution I'm ok with less
>optimized approaches given they work well.

    Thank you very much.

    Andriy.