path= (or not) in GSettings schemas
hi, One of the big design mistakes I made with GSettings is that this is really weird: schema id=org.a11y.atspi path=/org/a11y/atspi/ The requirement to specify a separate path is confusing. It causes people to think that maybe the path should have a prefix like /apps/. If you manage to avoid this trap and do it properly then it is completely redundant. Of course, it is possible to omit the path to create a relocatable schema. schema id=org.a11y.atspi That's the crux of the mistake. Relocatable schemas are somewhat rare in their use. The non-relocatable case is the 'ordinary one'. Ideally, the syntax (immediately) above should have been reserved to that common case. Changing this now is a no-go, of course. There are existing applications that use the above syntax to define relocatable schemas. I propose that we could bail ourselves out of this mess with a two-step process, as follows: 1) Start looking for a relocatable='' attribute on schema. If a schema has no path and has not been marked as relocatable='yes' then emit a warning (similar to what we do for path='/apps/*' already). 2) After a year or so, assume that schemas without relocatable='yes' and with no path='' are schemas that wish to have a path automatically assigned using the expected '.' to '/' mapping. In this way we turn: schema id='a.b.c' path='/a/b/c/' !-- common case -- schema id='x.y.z' !-- uncommon case -- to: schema id='a.b.c' !-- common case -- schema id='x.y.z' relocatable='yes'!-- uncommon case -- Even if we don't do #2, I think doing #1 might be useful. I don't have any evidence (even anecdotal) to support the idea that the current situation is confusing but it seems that a helpful warning explaining to the user that schema id='a.b.c' doesn't mean what they think may be useful... Thoughts? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: path= (or not) in GSettings schemas
On Wed, Oct 17, 2012 at 12:02 PM, Ryan Lortie de...@desrt.ca wrote: In this way we turn: schema id='a.b.c' path='/a/b/c/' !-- common case -- schema id='x.y.z' !-- uncommon case -- to: schema id='a.b.c' !-- common case -- schema id='x.y.z' relocatable='yes'!-- uncommon case -- Even if we don't do #2, I think doing #1 might be useful. I don't have any evidence (even anecdotal) to support the idea that the current situation is confusing but it seems that a helpful warning explaining to the user that schema id='a.b.c' doesn't mean what they think may be useful... Thoughts? I mostly agree with the analysis of the mess we're in, but I think there may be some other options out that don't require a two-step: One alternative would be to go from schema id='a.b.c' path='/a/b/c/' !-- common case -- schema id='x.y.z' !-- uncommon case -- to fixedschema id='a.b.c' relocatableschema id='x.y.z' or whatever alternative element names you can come up with. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: path= (or not) in GSettings schemas
On 12-10-17 12:17 PM, Matthias Clasen wrote: to fixedschema id='a.b.c' relocatableschema id='x.y.z' Seb mentioned a variation on this theme focusing on attribute names instead: schema pathid=... !-- same as fixedschema above -- My problem with these proposals is that schema and id are the natural names to use here and that people will find a lot of online help instructing them about that. It's also problematic from the standpoint of not wanting the entire world to have to change over to the 'new way' and not wanting to have two separate element/attribute names around forever. From a purely aesthetic standpoint I guess I could accept schema name=''... Then we could have schema name='a.b.c'/ schema name='x.y.z' relocatable='yes'/ and throw warnings if we ever see id=''... We could keep the warnings forever (ie: never have an incompatible change). I could see a lot of people being annoyed about that, though. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: path= (or not) in GSettings schemas
Le 17/10/2012 18:02, Ryan Lortie a écrit : Even if we don't do #2, I think doing #1 might be useful. I don't have any evidence (even anecdotal) to support the idea that the current situation is confusing but it seems that a helpful warning explaining to the user that schema id='a.b.c' doesn't mean what they think may be useful... Hey Ryan, I'm not a big fan of let's warn and do the semantic change anyway after some time, you have no good way to check that the message went through to everyone and that you are not going to break something... One thing which seems to confuse some people, in the current documentation, is that the path format is detailed but there are no explanations of what the path is used for in the application (if you write a standard gsettings client you will end up using the schemas id only and wonder what you should have done with the path or if you are missing something). Some suggestions on things I could see as potential improvement: * add a path=id which would build the path from the id and recommend in the API to use that * update the API documentation to specificy that for most applications the path is an implementation detail and should just follow the id naming * deprecate id and path and add a new pathid with the new semantic. This way you never break the compat but you can update the documentation and hopefully phase out the use of the old arguments over time... Cheers, Sebastien Bacher ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: path= (or not) in GSettings schemas
On 17/10/12 18:02, Ryan Lortie wrote: hi, One of the big design mistakes I made with GSettings is that this is really weird: schema id=org.a11y.atspi path=/org/a11y/atspi/ The requirement to specify a separate path is confusing. It causes people to think that maybe the path should have a prefix like /apps/. If you manage to avoid this trap and do it properly then it is completely redundant. Of course, it is possible to omit the path to create a relocatable schema. schema id=org.a11y.atspi That's the crux of the mistake. Relocatable schemas are somewhat rare in their use. The non-relocatable case is the 'ordinary one'. Ideally, the syntax (immediately) above should have been reserved to that common case. Changing this now is a no-go, of course. There are existing applications that use the above syntax to define relocatable schemas. I propose that we could bail ourselves out of this mess with a two-step process, as follows: 1) Start looking for a relocatable='' attribute on schema. If a schema has no path and has not been marked as relocatable='yes' then emit a warning (similar to what we do for path='/apps/*' already). 2) After a year or so, assume that schemas without relocatable='yes' and with no path='' are schemas that wish to have a path automatically assigned using the expected '.' to '/' mapping. In this way we turn: schema id='a.b.c' path='/a/b/c/' !-- common case -- schema id='x.y.z' !-- uncommon case -- to: schema id='a.b.c' !-- common case -- schema id='x.y.z' relocatable='yes'!-- uncommon case -- Even if we don't do #2, I think doing #1 might be useful. I don't have any evidence (even anecdotal) to support the idea that the current situation is confusing but it seems that a helpful warning explaining to the user that schema id='a.b.c' doesn't mean what they think may be useful... I remember one time when I was writing an applet and I forgot to set the path and then as a result my settings were not being saved. This cost me quite a big amount of time to figure out that the path was necessary in my specific case. So I think this is a nice proposal if it makes thing easier to use. Thoughts? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
