i've done enough work on this that i'm quite confident that it can be implemented without further incompatible changes to the API.

we'll punt this to 2.28 since it's coming so soon anyway (and that way we can avoid last-minute mistakes)

 didn't make 2.28 either :-(

Will it be implemented soon ?

I want to help on this. I have a lot of free time during the next 6 weeks.

I'm reading the code of GSettings, and it's not too hard to understand. I have a lot of things to learn, since I've never contributed to GLib/GIO. But I'm motivated!

The code I'm reading is the one in the master branch. I'll also read what has been done in the wip/gsettings-list branch, since I suppose it's a good base.

The last discussion I found is this thread:
http://www.mail-archive.com/gtk-devel-list@gnome.org/msg11753.html

Is there other discussions or other code that worth the reading?

Hi,

is there any progress with this? Can I help somehow?

Regards

Marek

I made some really basic stuff here (to see how it works):

https://github.com/swilmet/glib
https://github.com/swilmet/dconf

I wanted to write a mail to the gtk-devel-list explaining my plans, and ask some questions, but I was busy with other projects.

Anyway, my idea was to create a subclass of GSettings called GSettingsList. The previous implementation added some functions directly in the GSettings class if I recall correctly.

I explain more in depth what was my ideas here:

http://mail.gnome.org/archives/gtk-devel-list/2012-February/msg00060.html

*** Bug 694800 has been marked as a duplicate of this bug. ***

2015, any news?

As a side note, I'm quite impressed Gnome made this huge effort to migrate all apps to gsettings when it still lacks a key value type from gconf.

Some apps that used List have migrated with downgraded features, such as Gnome Terminal that currently does not support multiple profiles anymore.

gnome-terminal supports multiple profiles just fine.

If anybody is still blocking a gsettings port for lack of this feature, it is time to move on. I don't expect GSettingsList will ever happen.

(In reply to comment #10)
> gnome-terminal supports multiple profiles just fine.

It didn't according to https://bugzilla.gnome.org/show_bug.cgi?id=624856 .Perhaps they found out a way to implement profiles without List? Speaking of that...

> If anybody is still blocking a gsettings port for lack of this feature, it is
> time to move on. I don't expect GSettingsList will ever happen.

What would be recommended GSettings way of creating a list? If not as a native type, is there any equivalent idiom?

(In reply to comment #11)
> What would be recommended GSettings way of creating a list? If not as a native
> type, is there any equivalent idiom?

This bug has never been about storing list types in GSettings, but rather having a list of GSettings objects.

You can store any valid GVariant type in GSettings and that includes lists (lists of strings, lists of ints, etc.)  You can even store lists of lists and lists of lists of lists or lists of tuples containing lists (...and so on).  It's fully recursive.

See https://developer.gnome.org/glib/stable/glib-GVariantType.html for a full (*cough*) list of the possible types.

Created attachment 301064 [details] [review]
GSettingsList implementation (unfinished)

Hi,

I walked through the Ryan's post about GSettingsList (https://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00065.html) and tried to implement something working.
Attached is a patch which implements the basic API of GSettingsList mentioned there:

gchar *g_settings_list_add_item (GSettings *settings)
void g_settings_list_remove_item (GSettings *settings, const gchar *name)
GSettings *g_settings_list_get_item (GSettings *settings, const gchar *name)
gchar **g_settings_list_get_items (GSettings *settings)

All those functions are part of gsettings.h.

The implementation uses the '.exists' key to store list of items of the gsettings list. It also uses existence of the '.anti-Default' key to specify that the list in '.exists' contains all items of the list.

I used the 'list-of' attribute to specify which schema is used for items of the list.

I haven't found another way to specify default items than using 'override' element together with 'extends' attribute without changing the DTD file.
Getting of the default items lists all schemas and finds all extending schemas of the schema used as schema of the list items. This is very inefficient. An improvement here would probably need a change in the DTD file (an <instance> element with <override>s in it?).

It doesn't emit signals (added, removed, changed?) or lock anything yet.

This is just a proposal to start with. Please let me know if there is anything I got wrong about the ideas (e.g. I wasn't sure about whether to add new DTD elements or try to use just the existing ones).

I'll attach a small example of such a schema soon.

Created attachment 301066 [details]
Sample schema + little demo of the API

Here is a small schema which contains gsettings list schema 'org.test.data.profiles', schema 'org.test.data.profile' for its items and 2 schemas used as default items of the list: {org.test.data.profile-1, org.test.data.profile-2}.

(In reply to Matthias Clasen from comment #10)
> gnome-terminal supports multiple profiles just fine.
> 
> If anybody is still blocking a gsettings port for lack of this feature, it
> is time to move on. I don't expect GSettingsList will ever happen.

My understanding is gnome-terminal drops the multiple profiles?
I cannot find profiles on gnome-terminal menus in 3.16.
The profiles had worked with dconf.

'File -> New Profile' exists here in gnome-terminal, on Fedora 22.

For some apps, a profile feature is/would be useful IMO. And GSettingsList would simplify the implementation. For example it would be nice to have profiles in gedit: one profile for the C language, one profile for Python, or even different profiles for different C projects (with different indentation settings, for example).

We can even imagine creating profiles from the desktop, for several apps at once, so that we can clearly separate _tasks_. Coming back to a task would be just a matter of launching a certain profile.

(In reply to Sébastien Wilmet from comment #16)
> 'File -> New Profile' exists here in gnome-terminal, on Fedora 22.

You're right. I looked at a different terminal by mistake.
I will look at the implementation.

When I see the code of gnome-terminal, my understanding is gnome-terminal still uses dconf APIs for the new profiles.
I guess gnome-terminal/src/terminal-settings-list.c:clone_child() generates the profile and it runs dconf_client_new().
It means both dconf and gsettings is used.
Should we migrate dconf to gsettings?

-- 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/312.