Hello!
PCMan has written on Friday, 8 November, at 0:52:
>On Thu, Nov 7, 2013 at 11:59 PM, Andrej N. Gritsenko <and...@rep.kiev.ua>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.
------------------------------------------------------------------------------
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
