On Thu, Nov 7, 2013 at 10:48 AM, Andrej N. Gritsenko <and...@rep.kiev.ua>wrote:
> Hello!
>
> 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.
>
> Cheers!
> Andriy.
>
>
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.
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.
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.
4. Add UI options for the user to turn off per-folder config.
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.
Cheers!
------------------------------------------------------------------------------
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
