On Thu, Nov 7, 2013 at 11:59 PM, Andrej N. Gritsenko <andrej@rep.kiev.ua> wrote:
    Hello!

u-cxif@aetey.se has written on Thursday,  7 November, at 14:23:
>Having in mind the goal of keeping Lxde small I would suggest
>considering a compact one without any redundant features.

    Well, we've completely lost point of discussion I've started. It is
not about implementation of data storage. It is about where to store data
about directory-related settings of pcmanfm. So far there are 3 variants:

1) the file '.directory' in the target folder;
2) the extended FS attributes of target folder;
3) the centralized storage somewhere inside homedir.

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.
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.
 
2) it is environment dependent (due to different paths for different
    environments) - settings made in LXDE are not known for LXDE-Qt;

Yes, they'll be known by lxde-qt. The problem is the uris are not known by kde. Other gio/gvfs using DEs should all know the paths/uris generated by gio.
I don't see any problems here.
 
3) settings are specific to the machine, you cannot share settings for
    the same folder over your office or whatever;
This is true. It's a limitation. Xattr has the same problem. Only .directory approach solves this.
 
4) settings will be reset after folder is renamed;
Indeed, but if the renaming is done by libfm, we can handle it. If it's not, then there is no way to update the data.
 
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.
 
6) centralized storage will slowly grow in size.

Distributed storage will grow as well, but you just don't know where they are and how to clean them.
 

Yes, it has bright sides too:

1) it can be used for read-only folders as well;
2) it isn't OS dependent;
3) it does not create any files in target folder.

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

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.
 

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.

Regards
 

    With best regards.
    Andriy.

------------------------------------------------------------------------------
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
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Pcmanfm-develop mailing list
Pcmanfm-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop