After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 403728 - Legacy INI interface for key-value file parser
Legacy INI interface for key-value file parser
Status: RESOLVED WONTFIX
Product: glib
Classification: Platform
Component: gkeyfile
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2007-02-02 21:17 UTC by Robert Millan
Modified: 2018-02-02 09:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Robert Millan 2007-02-02 21:17:41 UTC 
How would you feel about adding a legacy INI interface for the key-value file parser?

  http://developer.gnome.org/doc/API/2.2/glib/glib-Key-value-file-parser.html

I've been discussing with gnome-volume-manager maintainer the possibility of adding support for parsing autorun.ini files.  There's a working patch, but Jeffrey would prefer if we could use the file parser in glib for that.  See:

  http://bugzilla.gnome.org/show_bug.cgi?id=397796

However, it doesn't seem to be fully .INI compliant:

  "This syntax is obviously inspired by the .ini files commonly met on Windows,
but there are some important differences"

The most important of them seems to be the last one (about case sensitiveness).

I'd like to propose to add some flag that would enable legacy compatibility with Microsoft format of INI.

Would you like a patch for that?
Comment 1 Philip Withnall 2018-02-02 09:22:43 UTC 
Sorry for the delay in replying.

The policy for GKeyFile is that it only supports desktop file syntax which, as you’ve found, is not INI file syntax. If you want to support INI files, please use a separate INI file parser.

If we added support for relaxed parsing of INI-style files, we’d become non-compliant with the desktop file specification, which could reduce interoperability with other implementations of the spec.