GNOME Bugzilla – Bug 681191
add g_key_file_{get,set}_modified()
Last modified: 2018-05-24 14:25:15 UTC
It can be useful to track if the keyfile has been modified, to check if it needs to be saved again. The API is similar to GtkTextBuffer. The user can manually set the modified flag. It could eventually be useful to have hook to be informed when the flag is modified.
Created attachment 220310 [details] [review] keyfile: add g_key_file_{get,set}_modified()
Created attachment 220311 [details] [review] tests/keyfile: add modified flag test
to be perfectly honest, I don't like this manual approach to mutability very much. I'd rather have a GKeyFile flag that loads the keyfile as 'immutable' - i.e. every set() operation will (more or less silently) fail - and if the flag is not set, the KeyFile will enter in a 'modified' state which will stay until the KeyFile is freed. saving to data won't change the 'modified' state, only loading again will. in other words: GKeyFile.modified can only be FALSE if the GKeyFile is immutable or it has just been created/loaded.
(In reply to comment #3) > to be perfectly honest, I don't like this manual approach to mutability very > much. I don't think it serves the same purpose here. keyfile is mutable, I am not trying to change that. That would be a seperate feature > I'd rather have a GKeyFile flag that loads the keyfile as 'immutable' - i.e. > every set() operation will (more or less silently) fail - and if the flag is > not set, the KeyFile will enter in a 'modified' state which will stay until the > KeyFile is freed. saving to data won't change the 'modified' state, only > loading again will. in other words: GKeyFile.modified can only be FALSE if the > GKeyFile is immutable or it has just been created/loaded. However I agree that after load, we can debate if modified should stay FALSE. Since the current API allows the same keyfile to be reloaded several time, I chose to set it as modified when this happens. If the flag you propose is not set, you said keyfile should stay in 'modified' state. Does that mean that there would be no way to know if it has actually been modified? That wouldn't be very helpful for the case I propose. I think adding an immutable flag and raising errors when modification are attempted could be a seperate feature that would combine well with this bug. No?
How much does this new API really buy you over just tracking the state manually outside of GKeyFile?
(In reply to comment #5) > How much does this new API really buy you over just tracking the state manually > outside of GKeyFile? Well, I don't have to wrap all the keyfile methods. But sure, I can do it outside. I thought it would make sense for others to have a modified flag as part of keyfile, and the change is fairly non-intrusive imho.
(je t'aime, un peu, beaucoup, passionnement, a la folie... pas du tout?)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/582.