On Thu, Nov 21, 2013 at 5:12 AM, Andrej N. Gritsenko <and...@rep.kiev.ua>wrote:
> Hello!
>
> PCMan has written on Thursday, 21 November, at 1:17:
> >On Wed, Nov 20, 2013 at 11:21 PM, Andrej N. Gritsenko <and...@rep.kiev.ua
> >wrote:
> >> Jerome Leclanche has written on Monday, 18 November, at 12:33:
> >> >Is this available in pcmanfm-qt when rebuilding with latest libfm?
> >> >J. Leclanche
>
> >> Nope. This is in pcmanfm (gtk), because it touches only GUI-related
> >> settings so cannot be in libfm and therefore should be implemented in Qt
> >> separatedly. I'm sorry.
>
> >No, I don't completely agree with this idea.
> >A better approach is modifying fm_app_config_get_config_for_path() to make
> >it more generic. So it can return a GKeyFile instance or something similar
> >instead of hard-coded argument list.Then, this can be put in libfm core.
> >By making this generic, any GUI implementor can read/write some config
> >values associated with the folder easily. Libfm does not need to know the
> >meaning of the key-value pairs. It just provides APIs to access them.
>
> Not bad idea. Though the work with config file itself is only about
> 1/4 of the implementation, and 3/4 of implementation is retrieving of the
> values (config reader does not know meaning as you said) and applying of
> them to the widgets.
>
At least we save the 1/4 of the work which is not trivial.
File manager implementations do not need to know where the config values
are stored, in what format they're stored, what's the version of that
format, what's the encoding of the config files, if the config dir exists,
or other stuff.
Even better, if we come up with a better way to store these configs, the
applications won't be broken.
The same holds true when we need to add new config key/values. "It will not
break API or ABIs and things are still backward compatible." The
applications only needs to know keys to access the config, and how to apply
the values to the UI.
Applications only get key-value pairs and do not need to worry about other
stuff.
I really think that this is a more appropriate approach.
>
> >How to interpret the values is the job of pcmanfm and pcmanfm-qt.
> >The APIs may looks like the following:
>
> >FmFolderConfig* fm_path_dup_folder_config(FmPath* path);
> >char* fm_folder_config_get_value(FmFolderConfig*, const char* key);
> >void fm_folder_config_set_value(FmFolderConfig*, const char* key, const
> >char* value);
> >void fm_folder_config_save(FmFolderConfig* config);
> >void fm_folder_config_ref(FmFolderConfig* config);
> >void fm_folder_config_unref(FmFolderConfig* config);
>
> >FmFolderConfig is a key-value dictionary object representing folder
> >specific config values. Implementors of the GUIs can use this object to
> >access folder-specific config values by keys they defined.
> >Inside FmFolderConfig, this can be implemented easily using GKeyFile.
> >This is more extensible and flexible. Also, the APIs are still useful
> >outside pcmanfm.
>
> Well, it is possible to get any value as string. But we should to
> implement all the parsing and validation (which is implemented in the
> GKeyFile APIs) in the application, those parsers are static functions so
> cannot be reused outside of GKeyFile. That will be a lot much code than
> we move into such "optimization API". Yes, that approach will greatly
> increase volume of the code in pcmanfm instead of reducing it. :(
>
No, just wrap GKeyFile and use it whenever possible.
Internally it's implemented with a hash table. So key/value lookup is fast.
fm_folder_config_get_int(), fm_folder_config_get_bool(), and
fm_folder_config_get_strings() can be added.
The implementation is easy. GKeyFile is the first data member of the
FmFolderConfig object.
The APIs are just macros wrapping g_key_file_* APIs. This creates nice APIs
with nearly zero code bloat.
Real reduce (not a big though) will be if we implement all of that in
> the LibFM so that FmFolderConfig will be reimplementation of GKeyFile
> with all of the appropriate APIs (such as fm_folder_config_get_boolean(),
> fm_folder_config_set_strings_list() and so on) and with some required
> optimizations for flexibility. In fact, I already thought about GKeyFile
> replacement due to its limitations and low efficiency.
>
Please avoid doing that. You'll only introduce code bloat without improving
perceivable performance.
I did some profiling previously. This part is never the bottle neck.
So don't waste your time on micro-optimization. Please, I'm serious.
Reading the per-folder preferences is a once per folder visit operation.
Optimizing it too much won't improve the real performance since it's rarely
called.
Taking the time to optimize things called for every single file help more,
I guess.
> Unfortunately I have not enough time to write such implementation
> into LibFM right now, I want to make pcmanfm into beta before Christmas
> and let it possible to make a final release before freeze of Ubuntu LTS.
> Let make it later then. I'm sorry.
>
No, please don't waste your time to reimplement what's already provided by
glib.
Everytime we increase the code size, the locality of data decrease and we
have less cache hit and more page faults.
For a lib, this also means more work need to be done while the runtime
loader is doing relocation.
The overall effect to the performance is not always positive.
Besides, they're not the performance bottle necks. Other parts need much
more love.
So please take your time doing things with higher priorities.
Best regards.
>
> With best regards.
> Andriy.
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Pcmanfm-develop mailing list
> pcmanfm-deve...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
