Hello!
PCMan has written on Thursday, 7 November, at 11:22:
>On Thu, Nov 7, 2013 at 10:48 AM, Andrej N. Gritsenko <and...@rep.kiev.ua>wrote:
>> I'm currently working on implementation of next feature for PCManFM.
>> It is different sort and view mode for selected folders. I.e. user can
>> check an option 'Use these settings for this folder only' and sort (and
>> view mode) will be remembered for current folder independently from
>> common settings. The question is how to do that. I know two ways now:
>> 1. Use '.directory' file in folder in question.
>> Pros:
>> - can be used by other implementations and other file managers;
>> - settings persist if folder is renamed;
>> - settings persist if folder is accessed other way (via ssh, ftp, etc.).
>> Cons:
>> - can be used only if user can write into .directory file in folder.
>> 2. Use cache file somewhere.
>> Pros:
>> - can be used against system directories (/usr for example).
>> Cons:
>> - completely implementation-dependent and even environment-dependent;
>> - settings are lost when folder is renamed;
>> - it may be impossible to have different settings for removable media;
>> - cache will grow indefinitely, no sane cleaning heuristics exist.
>> I would appreciate all your opinions and I'm waiting for them until I
>> start implementing it. Thank you in advance.
>Well, I've been thinking about the issue for quite a long time but did not
>do it since I couldn't find a really satisfying solution.
>A cache is the most reliable, but it's hard to maintain and it's easy to
>break.
>Deleting dead entries in the cache periodically is needed. Otherwise the
>cache will be full of garbage after a period of time.
>Windows seems to use this approach and the info is in windows registry.
>Thunar uses similar way, and the info is stored in a tdb file.
>Tdb is the trivial key-value db developed by Samba and it's good enough for
>the task.
>Nautilus seems to use similar approach, but they use text-based meta-info
>files stored somewhere rather than a db, which is very inefficient.
>A key-value based binary db with periodic dead-entry clearance is
>reasonable.
>Good candidates are samba tdb and sqlite.
I really hate the cache solution - it is completely implementation
dependent and you even have to implement it exactly the same in each
application if you want them to be compatible. And yes, any cache is easy
to break if any crash happens in time of its rebuild.
>Another good stuff to use is xattr. Most modern filesystems support it.
>This is the best place to store this kind of info.
>Pros: widely-available, creates no junk, can be accessed by others easily.
>Will not be included when you try to tar a dir (this beats the .directory
>approach).
>Cons: not available on read-only FS, remote FS, and windows FS, such as
>ntfs and vfat.
>The last one is .directory approach. I like this one, too. Windows uses
>similar method to store other info, such as directory icon. It uses a
>hidden file "desktop.ini" in every folder for that.
>Pros: constant access speed. No db lookup, easy to implement, no other
>dependencies. Portable, easily managed, and can be preserved even when you
>create backup for the folder.
>Cons: When you create a tar file for the folder, it will be included. It's
>hard to delete them all if you want to uninstall pcmanfm. Also, remember to
>add it to .gitignore. This is quite annoying. It's also visible to the user
>if you turn on "show hidden files", which is really bad.
>So, the best way I can figure out:
>1. For local filesystems, check xattr first.
Well, that still have the same big limitation - when you go into the
folder via ssh or ftp, you get no setup for it.
>2. If xattr is not availble or it's not a local FS, try the key-value
>db-based cache.
>3. remove dead entries from the db periodically.
It is not possible really - you will remove all remembered data for
remote or removable media not currently connected. And since you have
proposed to use cache exactly for that purpose, that renders value of
that cache close to zero. In short - either not use cache, or accept its
unlimited growth, and other cons that I mentioned above.
>4. Add UI options for the user to turn off per-folder config.
That will be in config in any case, that was never a question.
>The .directory apprach is really bad for maintainance. For example, if the
>user want to turn off "per-folder" setting, it's not possible to search for
>all .desktop files and delete them. The drawbacks make this apprach less
>appealing.
It still have all that Pros that I mentioned above though. :)
Well, it seems both .directory and cache approaches have too many
Cons in eyes of you, people, so only acceptable one is to use xattr. It
has own drawbacks too but combine two (or more) approaches is worse as
that will bring problems when detection which approach to use fails by
false positive. So I would avoid double-approach as much as possible.
Thank you very much for all your opinions!
>Cheers!
Cheers!
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
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
