From: Andrej N. G. <an...@re...> - 2013-11-17 22:15:55
|
Hello everyone! I've pushed new branch 'per-folder-modes' into pcmanfm GIT right away. The branch is implementation of per-folder setting save. Settings that are to be saved: - sort mode and attributes (direction, case-sensitivity, etc.) - the "show hidden" flag - view mode for the folder The settings will be loaded and saved in the file .directory if it exists, otherwise the file ~/.config/pcmanfm/<profile>/dir-settings.conf will be used to save all settings. The settings will be saved only if 'View'->'Save for This Folder' checkbox in the main menu is checked, and will be forgotten when it's unchecked. No big volume of data is expected therefore. The format of the file is selected the same as format of pcmanfm's common settings for the same data (in the file pcmanfm.conf) for few very obvious reasons: - not add another format, all existing data are in key file format; - not add additional dependencies for pcmanfm. Data are cached in pcmanfm so no impact on performance is expected. Yes, I remember the suggestions about database, but that will not make it faster in any way but it will make it more fat (due to additional library for database). And since search in the implementation is very fast (it is linked list and check is done by simple pointers comparison) and save of that data is implemented by safe way, I believe it is still better than any database. Everyone is encouraged to test it thoroughly and I want yours test results, opinions, suggestions, etc. It should build with LibFM either 1.0.1, 1.1.x, or 1.2.0, I believe. Thank you in advance. Andriy. |
From: Jerome L. <ad...@gm...> - 2013-11-18 12:33:31
|
Is this available in pcmanfm-qt when rebuilding with latest libfm? J. Leclanche On Sun, Nov 17, 2013 at 9:54 PM, Andrej N. Gritsenko <an...@re...> wrote: > Hello everyone! > > I've pushed new branch 'per-folder-modes' into pcmanfm GIT right > away. The branch is implementation of per-folder setting save. Settings > that are to be saved: > - sort mode and attributes (direction, case-sensitivity, etc.) > - the "show hidden" flag > - view mode for the folder > > The settings will be loaded and saved in the file .directory if it > exists, otherwise the file ~/.config/pcmanfm/<profile>/dir-settings.conf > will be used to save all settings. > > The settings will be saved only if 'View'->'Save for This Folder' > checkbox in the main menu is checked, and will be forgotten when it's > unchecked. No big volume of data is expected therefore. > > The format of the file is selected the same as format of pcmanfm's > common settings for the same data (in the file pcmanfm.conf) for few very > obvious reasons: > - not add another format, all existing data are in key file format; > - not add additional dependencies for pcmanfm. > Data are cached in pcmanfm so no impact on performance is expected. Yes, > I remember the suggestions about database, but that will not make it > faster in any way but it will make it more fat (due to additional library > for database). And since search in the implementation is very fast (it is > linked list and check is done by simple pointers comparison) and save of > that data is implemented by safe way, I believe it is still better than > any database. > > Everyone is encouraged to test it thoroughly and I want yours test > results, opinions, suggestions, etc. It should build with LibFM either > 1.0.1, 1.1.x, or 1.2.0, I believe. > > Thank you in advance. > Andriy. > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list |
From: Andrej N. G. <an...@re...> - 2013-11-20 15:21:13
|
Hello! 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. With best regards. Andriy. |
From: PCMan <pcm...@gm...> - 2013-11-20 17:17:44
|
On Wed, Nov 20, 2013 at 11:21 PM, Andrej N. Gritsenko <an...@re...>wrote: > Hello! > > 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. 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. Regards > > With best regards. > Andriy. > |
From: Andrej N. G. <an...@re...> - 2013-11-20 21:12:33
|
Hello! PCMan has written on Thursday, 21 November, at 1:17: >On Wed, Nov 20, 2013 at 11:21 PM, Andrej N. Gritsenko <an...@re...>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. >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. :( 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. 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. With best regards. Andriy. |
From: PCMan <pcm...@gm...> - 2013-11-21 02:23:33
|
On Thu, Nov 21, 2013 at 5:12 AM, Andrej N. Gritsenko <an...@re...>wrote: > Hello! > > PCMan has written on Thursday, 21 November, at 1:17: > >On Wed, Nov 20, 2013 at 11:21 PM, Andrej N. Gritsenko <an...@re... > >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 > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop > |
From: Andrej N. G. <an...@re...> - 2013-11-21 10:39:30
|
Hello! PCMan has written on Thursday, 21 November, at 10:23: >The APIs are just macros wrapping g_key_file_* APIs. This creates nice APIs >with nearly zero code bloat. [.......] >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. Thank you for your ideas. I wanted to not add new APIs to LibFM at this point but may be adding a little bunch of such wrappers will not hurt. I'll try to make it when time permits, it's still a lot of text (for documentations at least). Cheers! Andriy. |
From: Andrej N. G. <an...@re...> - 2013-11-22 00:38:08
|
Hello! I have written on Thursday, 21 November, at 12:39: > Thank you for your ideas. I wanted to not add new APIs to LibFM at >this point but may be adding a little bunch of such wrappers will not >hurt. I'll try to make it when time permits, it's still a lot of text >(for documentations at least). I've pushed a branch 'per-folder-modes' into libfm. Also I've pushed a branch 'per-folder-modes2' into pcmanfm. The latter has some enclosures (#if !FM_CHECK_VERSION(1, 2, 1) ... #endif) that set to 1.2.1 just to let it be built with unmodified libfm, I'll change them to 1.2.0 when I merge all into libfm and pcmanfm master. Please, review it as soon as you can. I believe you are right that in this case convenience is better than some CPU and memory consumption increase. Thank you very much. Cheers! Andriy. |