The non centralized storage has another one drawback:
If multiple users have write permission on the directory (for example it's mounted nfs or smb share) then the one user will overwrite the settings of another.

2013/11/7 Andrej N. Gritsenko <>
    Hello! has written on Thursday,  7 November, at 17:38:
>On Thu, Nov 07, 2013 at 05:59:16PM +0200, Andrej N. Gritsenko 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;
>> 2) it is environment dependent (due to different paths for different
>>     environments) - settings made in LXDE are not known for LXDE-Qt;

>I guess #2 is due to the fact that it is different programs who potentially
>use it, thus the same as #1.

>> 3) settings are specific to the machine, you cannot share settings for
>>     the same folder over your office or whatever;

>Unclear what you mean here. My (and many others') home directory is
>available on all machines I am using, with the same shared contents. A
>file-based storage somewhere under $HOME/.something would be working fine
>(as long as the implementation does not do something innapropriate,
>i.e. specifically incompatible with shareability). That's why I would
>dismiss #3 as well.

Well, you have folder ~/Video available on machine A and you set it to
use Thumbnails View mode. On machine B you have default view mode as
Detailed List View. You can get that folder opened on the machine B as
sftp://A/home/user/Video. Guess how it will be shown on machine B? If you
think it will be in Thumbnails View mode then you've failed. It will be
shown in Detailed List View mode. User may expect it to be shown in the
Thumbnails View on machine B, C, etc. That can be achieved though with
.directory approach only.

>> 4) settings will be reset after folder is renamed;

>Not if the rename is done via the same file manager (otherwise yes).

Well, we should put hooks everywhere to handle that, that will bloat the
file manager (who dare to call it lightweight after that?). And also you
wrote yourself, that is only if you rename via the same file manager and
that isn't always the case, a lot of users use a lot of different tools.
So we shouldn't do it in the file manager either, for consistency and to
keep it still lightweight.

>> 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;

>Why? As long as the settings refer to the sticks' hardware (and unique)
>identifier they will be separate. I tried already to explain this.
>Thus #5 is not valid either.

Unfortunately, we never refer to sticks' hardware, we don't work with the
hardware directly but we use GVFS, and the same stick will have generic
name such as 'USB Dongle 16GB'. Trying to retrieve hardware identifier
and use it back and forth means we should add few hooks, bloating the
code again. I'm heavily against any code bloating as I said, I stay on
the KISS principle - if that cannot be done simply then it should not be
done at all.

>> 6) centralized storage will slowly grow in size.

>But not indefinitely, mostly as large as to correspond to the user's needs,
>even with a simplistic garbage collector.
>The information storage volume would be roughly the same for all of
>the approaches.

Well, it will be a bit bigger for some folders that were gone but file
manager does not know yet about it. Though it is very little difference
so I should agree with you, it may be safely ignored.

>Thus I can not agree with #6.

>This leaves us:

>1) it is application dependent
>2) if the user renames a folder by a different program or from a separate
>   $HOME then the setting for the folder get lost

>> Do you think those drawbacks aren't important for our users?

>Talking as a system administrator for quite a few computers and users:
>I believe that this would be better for my users than properties of the
>other two approaches.

Thank you very much for sharing your opinion!

>Thanks for working on this Andriy!

>(I guess this is the spelling of your name which you prefer, I didn't
>think about it when I used the one from the mail header, sorry for that)

Nothing to be sorry for. In fact, both those names are right, just in
different languages (Russian and Ukrainian) that I communicate the most.
I just like the Ukrainian language a bit more, that's all. :)


    With best regards.

November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
Lxde-list mailing list

Best regards,