About gsettings aborting on unkown schemas

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

About gsettings aborting on unkown schemas

ecyrbe
I just filled this bug : https://bugzilla.gnome.org/show_bug.cgi?id=651225
Mathias closed it as wontfix, this is by "design".. i'm told that it's not a bug it's a feature!

So if my desktop is crashing it's a feature and nobody is willing to fix it?I really would like to have another answer than this one.

Can't we make gsettings return a null parameter? aborting a program for not loading the right schemas is not right.
The gnome shell is currently  aborted if you make a small mistaping mistake because in an extension.
And when i say aborted, your only choice is to reboot your desktop because all your desktop is freezed. And you loose everything you where doing ...

Am i the only one that think this is silly? can't we change this behaviour?

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Emmanuele Bassi
On 2011-05-27 at 13:42, ecyrbe wrote:
> I just filled this bug : https://bugzilla.gnome.org/show_bug.cgi?id=651225
> Mathias closed it as wontfix, this is by "design".. i'm told that it's not a
> bug it's a feature!

it's not a bug.

the rationale is: schemas are an integral part of an application or a
library exposing settings. it's like the .ui file for applications
creating their user interface through GtkBuilder. there is no amount of
magic in the world that can save you from a missing .ui file. without
the schema, the settings system cannot identify default values, key
names or *anything* else about the settings.

> So if my desktop is crashing it's a feature and nobody is willing to fix
> it?I really would like to have another answer than this one.

if your desktop is crashing then it means that some part of it is
relying on a file that is not there. try randomly removing a shared
library from your system, and you'll obtain the same behaviour.

> Can't we make gsettings return a null parameter?

and then what? abort the application? gracefully terminate with a
warning on the console?

> The gnome shell is currently  aborted if you make a small mistaping mistake
> because in an extension.

you're messing with extensions, and you're messing with custom schemas.
you only notice it more because the shell is the compositor.

we can have fallbacks in place, and the system should fall back and not
load the extension that caused it to abort in the first place; but that
is an issue of GNOME Shell, not of GSettings.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Emmanuele Bassi
On 2011-05-27 at 14:59, ecyrbe wrote:

> > I just filled this bug : https://bugzilla.gnome.org/show_bug.cgi?id=651225
>
> > > Mathias closed it as wontfix, this is by "design".. i'm told that it's
> > not a
> > > bug it's a feature!
> >
> > it's not a bug.
> >
> >
> of course it's a bug, you can't abort like that a program.

you can say that all you want, but it's absolutely *not* a bug.

aborting a program is done all over the place in glib and gtk+.

> > and then what? abort the application? gracefully terminate with a
> > warning on the console?
> >
>
>
> No, you can gracefully show a popup to the user that something is broken and
> to the right direction. It's better than crashing.

and what would a popup solve from the user's perspective? a missing
schema is a missing file, which means an installation problem. there is
*no* graceful way to handle that.

and how can gsettings, in GIO, pop up a window?

> > you're messing with extensions, and you're messing with custom schemas.
> > you only notice it more because the shell is the compositor.
> >
> >
> I'm not messing with anything. I'm a free software developper like you and
> i have the right to develop anything i want without having my desktop
> crashing for silly mistakes.

[citation needed]

> > we can have fallbacks in place, and the system should fall back and not
> > load the extension that caused it to abort in the first place; but that
> > is an issue of GNOME Shell, not of GSettings.
> >
> >
> No, it's easier to not abort in gsettings than add a workaround to this bad
> behaviour.

no, it's not easier.

> You can't make decisions for the developper about how HIS program should
> behave,

we do take decisions like that *all the time*.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Shaun McCance-2
On Fri, 2011-05-27 at 15:34 +0100, Emmanuele Bassi wrote:

> On 2011-05-27 at 14:59, ecyrbe wrote:
> > > and then what? abort the application? gracefully terminate with a
> > > warning on the console?
> > >
> >
> >
> > No, you can gracefully show a popup to the user that something is broken and
> > to the right direction. It's better than crashing.
>
> and what would a popup solve from the user's perspective? a missing
> schema is a missing file, which means an installation problem. there is
> *no* graceful way to handle that.

If the application itself is missing files it needs (schemas,
ui files, .la files, whatever), then yeah. If it's some plugin
that's busted, this is how I'd write my application code in a
language with real exception handling:

try:
    load_some_extension()
except:
    warn("This extension sucks. I'm disabling it and moving on.")

Of course, GLib is C. We don't have exceptions. We have GError,
which is a decent foundation for exceptions in language bindings.
But if we don't use it, then languages that could otherwise do
the right thing are screwed.

--
Shaun


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Morten Welinder-2
In reply to this post by Emmanuele Bassi
> you can say that all you want, but it's absolutely *not* a bug.

Of course it is.  With this bug, programs crash where they other-
wise could limp on.  It's like changing all g_return_if_fail calls
into asserts -- after all, any time one of those hits it represents
a bug somewhere.  My log files suggest that "all the time" is
a good approximation of how often that happens.

It is absolutely not like missing your main ui file.  You can't limp
on from that in a meaningful way.

And note, that in the gconf age handling this was not a problem
at all.

This bug makes it hard to keep multiple versions of a program
installed without making settings per-version which has its own
problems.  If a setting is ever removed, the old version won't
run.

Morten
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Hub Figuière-2
In reply to this post by Emmanuele Bassi
On 11-05-27 5:43 AM, Emmanuele Bassi wrote:
> On 2011-05-27 at 13:42, ecyrbe wrote:
>> I just filled this bug : https://bugzilla.gnome.org/show_bug.cgi?id=651225
>> Mathias closed it as wontfix, this is by "design".. i'm told that it's not a
>> bug it's a feature!
>
> it's not a bug.

It is a bug.

>
> the rationale is: schemas are an integral part of an application or a
> library exposing settings. it's like the .ui file for applications
> creating their user interface through GtkBuilder. there is no amount of
> magic in the world that can save you from a missing .ui file. without
> the schema, the settings system cannot identify default values, key
> names or *anything* else about the settings.

First, if the UI file is missing the application does not abort. There
is an error but it can be handled by the application, and eventually
recovered gracefuly. I deleted all the UI files and my app didn't crash.
Sure it was not very functional but I actually had the opportunity to
show a proper error message to the user. Not a crash.

Second the actual requirement of the schemas is part of the problem,
even though that's not the original complain. Even more so that it does
not seems to be possible to load a schema at runtime or to have it in a
specific prefix... unlike in gconf. GSettings is a huge regression in
gconf: read my words. It is WORSE.

Third, passing a NULL widget to gtk_widget_(), or the wrong type does
not cause an abort. And this is likely a programmer error with barely no
external side effect, unlike the gsettings schemas.

>
>> So if my desktop is crashing it's a feature and nobody is willing to fix
>> it?I really would like to have another answer than this one.
>
> if your desktop is crashing then it means that some part of it is
> relying on a file that is not there. try randomly removing a shared
> library from your system, and you'll obtain the same behaviour.

Wow. So basically you are saying that instead of having a SOLID
foundation we should have a fragile system with so many component?

Weren't you complaining about the lack of MacOS-style bundles you seem
to be pretty inconsistent: one of the thing that MacOS-style bundles
permit is it actually install an application by copying ONE SINGLE item.
But with gsettings this is just impossible. The dicatorship of
distributions like you call it is right here[1].

[ screenshot of the tweet by use @ebassi ]

>
>> Can't we make gsettings return a null parameter?
>
> and then what? abort the application? gracefully terminate with a
> warning on the console?

The application should gracefuly deal with it, but isn't currently left
with a chance to do so. I mean come in if it is a bool saying "reload my
last document" then it is false.

Hub

[1] https://twitter.com/ebassi/status/72990226313777152
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Matthias Clasen-2
In reply to this post by ecyrbe
On Fri, May 27, 2011 at 7:42 AM, ecyrbe <[hidden email]> wrote:
> I just filled this bug : https://bugzilla.gnome.org/show_bug.cgi?id=651225
> Mathias closed it as wontfix, this is by "design".. i'm told that it's not a
> bug it's a feature!
>
> So if my desktop is crashing it's a feature and nobody is willing to fix
> it?I really would like to have another answer than this one.

The fix is to install the missing schema.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Emmanuele Bassi
In reply to this post by Shaun McCance-2
On 2011-05-27 at 10:57, Shaun McCance wrote:

> On Fri, 2011-05-27 at 15:34 +0100, Emmanuele Bassi wrote:
> > On 2011-05-27 at 14:59, ecyrbe wrote:
> > > > and then what? abort the application? gracefully terminate with a
> > > > warning on the console?
> > > >
> > >
> > >
> > > No, you can gracefully show a popup to the user that something is broken and
> > > to the right direction. It's better than crashing.
> >
> > and what would a popup solve from the user's perspective? a missing
> > schema is a missing file, which means an installation problem. there is
> > *no* graceful way to handle that.
>
> If the application itself is missing files it needs (schemas,
> ui files, .la files, whatever), then yeah. If it's some plugin
> that's busted

how do you propose to define the difference between a plugin running in
the application space and an application? from a library perspective,
and from an application perspective, application + plugin and
application are exactly the same thing.

> this is how I'd write my application code in a
> language with real exception handling:
>
> try:
>     load_some_extension()
> except:
>     warn("This extension sucks. I'm disabling it and moving on.")

load_some_extension() *should* check if a schema exists in the current
path, and raise an exception if not found. Ryan is working on being able
to define custom search paths as well.

but once you reached g_settings_new() then there's nothing you can do
because anything after that assumes that the GSettings returned exist
and maps to a valid settings backend, with valid values.

> Of course, GLib is C. We don't have exceptions. We have GError,
> which is a decent foundation for exceptions in language bindings.
> But if we don't use it, then languages that could otherwise do
> the right thing are screwed.

GError is for recoverable run-time errors, not for installation errors; a
missing schema is an installation error.

by the way, GError, as it is implemented and used currently, is *not* an
exception-like system. I'm not against creating a GException, but that's
another thing, and the two should not be confused.

we don't have g_malloc(size_t, GError**) for OOM cases as well, I just
hope you're not honestly asking for that.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Emmanuele Bassi
In reply to this post by Morten Welinder-2
On 2011-05-27 at 11:04, Morten Welinder wrote:
> > you can say that all you want, but it's absolutely *not* a bug.
>
> Of course it is.  With this bug, programs crash where they other-
> wise could limp on.

potentially eating away data? without schema you don't have a default to
fall back to for application preferences and for state. it might end up
deleting existing account data, for instance. or eating your files.

> It's like changing all g_return_if_fail calls into asserts

no, it's nothing like that.

> It is absolutely not like missing your main ui file.  You can't limp
> on from that in a meaningful way.

no, it's even *worse*, because a missing UI will not eat your data.

> And note, that in the gconf age handling this was not a problem
> at all.

yes, and it was one of the major design issues identified by the gconf
authors years ago, and one of the pre-conditions for a new settings
system.

> This bug makes it hard to keep multiple versions of a program
> installed without making settings per-version which has its own
> problems.

it doesn't have any more problems than using two different libraries, or
using two different prefixes, or using two different UI files.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

ecyrbe
2011/5/27 Emmanuele Bassi <[hidden email]>
On 2011-05-27 at 11:04, Morten Welinder wrote:
> > you can say that all you want, but it's absolutely *not* a bug.
>
> Of course it is.  With this bug, programs crash where they other-
> wise could limp on.

potentially eating away data? without schema you don't have a default to
fall back to for application preferences and for state. it might end up
deleting existing account data, for instance. or eating your files.


nope, what you don't seems to understand is that you don't let the calling program deal with it. With this behavviour
you now have to protect your code from crashing by checking everytime that the schemas (or even the key) exists.
No data is eaten if the calling application show a gracefull message and exit from itself.

> It's like changing all g_return_if_fail calls into asserts

no, it's nothing like that.


And it's like what? your argumentation is empty.
 


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Emmanuele Bassi
In reply to this post by Hub Figuière-2
On 2011-05-27 at 08:51, Hubert Figuiere wrote:
> On 11-05-27 5:43 AM, Emmanuele Bassi wrote:
> > On 2011-05-27 at 13:42, ecyrbe wrote:
> >> I just filled this bug : https://bugzilla.gnome.org/show_bug.cgi?id=651225
> >> Mathias closed it as wontfix, this is by "design".. i'm told that it's not a
> >> bug it's a feature!
> >
> > it's not a bug.
>
> It is a bug.

where were you people in 2004 when Havoc outlined all the issues of
GConf and this was the one thing to fix? :-p

> > the rationale is: schemas are an integral part of an application or a
> > library exposing settings. it's like the .ui file for applications
> > creating their user interface through GtkBuilder. there is no amount of
> > magic in the world that can save you from a missing .ui file. without
> > the schema, the settings system cannot identify default values, key
> > names or *anything* else about the settings.
>
> First, if the UI file is missing the application does not abort.

yes, a UI is actually (barely) recoverable. you just die with an error
message, to which the user will have absolutely no idea how to respond
to.

> Second the actual requirement of the schemas is part of the problem,
> even though that's not the original complain. Even more so that it does
> not seems to be possible to load a schema at runtime or to have it in a
> specific prefix... unlike in gconf. GSettings is a huge regression in
> gconf: read my words. It is WORSE.

read my words: it's definitely not. because when I use GConf I have to
add three times the amount of code to handle the default values in case
the schema is missing or broken or the daemon simply decides to go
insane. with GSettings if I depend on a schema, I don't have to second
guess every call to settings.get(): I'll either get the default or get
the stored value, and it will have the correct type.

> Third, passing a NULL widget to gtk_widget_(), or the wrong type does
> not cause an abort. And this is likely a programmer error with barely no
> external side effect, unlike the gsettings schemas.

invalidating the internal state in every library from glib up to
whatever will hit g_assert() as some point or other.

> >
> >> So if my desktop is crashing it's a feature and nobody is willing to fix
> >> it?I really would like to have another answer than this one.
> >
> > if your desktop is crashing then it means that some part of it is
> > relying on a file that is not there. try randomly removing a shared
> > library from your system, and you'll obtain the same behaviour.
>
> Wow. So basically you are saying that instead of having a SOLID
> foundation we should have a fragile system with so many component?

oh, please. let's complain that g_malloc() will abort(), then. I haven't
heard about that for a while.

> Weren't you complaining about the lack of MacOS-style bundles you seem
> to be pretty inconsistent: one of the thing that MacOS-style bundles
> permit is it actually install an application by copying ONE SINGLE item.
> But with gsettings this is just impossible. The dicatorship of
> distributions like you call it is right here[1].
>
> [ screenshot of the tweet by use @ebassi ]

setting different search paths, which is how bundles work, should work
for GSettings; it is a currently pending issue, one that Ryan intends to
solve with the minimal impact on the API entry points.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Emmanuele Bassi
In reply to this post by ecyrbe
On 2011-05-27 at 18:17, ecyrbe wrote:

> > > Of course it is.  With this bug, programs crash where they other-
> > > wise could limp on.
> >
> > potentially eating away data? without schema you don't have a default to
> > fall back to for application preferences and for state. it might end up
> > deleting existing account data, for instance. or eating your files.
> >
>
>
> nope, what you don't seems to understand is that you don't let the calling
> program deal with it.

and how do you propose to deal with that? if you allow the application
code to run then *anything* can happen, by definition. what's to say
that an app developer or a plugin developer decides to still go on and
not write sensible code? or tested code: a missing schema is an
installation issue, and people barely test error paths.

this might be acceptable for application developers and their own code,
but this sort of carelessness in designing a platform API is simply
not acceptable.

> With this behavviour
> you now have to protect your code from crashing by checking everytime that
> the schemas (or even the key) exists.

no, because the schema *has* to exists. why would you want to protect
from an abort()? don't you use g_assert() to protect internal state? you
might certainly not do that, but gtk+ does in multiple places. do you want
to have a callback for gracefully showing an error dialog?

> No data is eaten if the calling application show a gracefull message and
> exit from itself.

you cannot guarantee that for every application, unless the library
itself shows that error dialog — an error dialog that will essentially
be useless for the user ("Schema not installed. Reinstall the
application"; well, what now?). GIO cannot show error dialogs, so it
does the next best thing: abort() with an error message meaningful for
the developer in the error log, which will be caught by the desktop-wide
system service for application crashes, and will send a bug report.

what we need is a way for the Shell and for applications to be able to
validate the existence of a schema for their plugins.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Milan Bouchet-Valat
In reply to this post by Hub Figuière-2
Le vendredi 27 mai 2011 à 08:51 -0700, Hubert Figuiere a écrit :
> First, if the UI file is missing the application does not abort. There
> is an error but it can be handled by the application, and eventually
> recovered gracefuly. I deleted all the UI files and my app didn't crash.
> Sure it was not very functional but I actually had the opportunity to
> show a proper error message to the user. Not a crash.
That's already what you get:
    g_error ("Settings schema '%s' is not installed\n", name);

I really can't imagine what you could do from a program missing its
schemas, except if you hardcode (i.e. duplicate) all default values in
the code to handle this broken case, which we actually want to avoid.
You could probably show a GTK error dialog, but people that don't know
to look at the console output wouldn't understand the settings issue
anyway...

The only place where it makes sense not to exit is for an application
that loads extensions. Maybe it's worth having a convenience function
around g_settings_list() to check the schema is present before loading
it...


Cheers


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Shaun McCance-2
In reply to this post by Emmanuele Bassi
On Fri, 2011-05-27 at 17:02 +0100, Emmanuele Bassi wrote:

> On 2011-05-27 at 10:57, Shaun McCance wrote:
> > On Fri, 2011-05-27 at 15:34 +0100, Emmanuele Bassi wrote:
> > > On 2011-05-27 at 14:59, ecyrbe wrote:
> > > > > and then what? abort the application? gracefully terminate with a
> > > > > warning on the console?
> > > > >
> > > >
> > > >
> > > > No, you can gracefully show a popup to the user that something is broken and
> > > > to the right direction. It's better than crashing.
> > >
> > > and what would a popup solve from the user's perspective? a missing
> > > schema is a missing file, which means an installation problem. there is
> > > *no* graceful way to handle that.
> >
> > If the application itself is missing files it needs (schemas,
> > ui files, .la files, whatever), then yeah. If it's some plugin
> > that's busted
>
> how do you propose to define the difference between a plugin running in
> the application space and an application? from a library perspective,
> and from an application perspective, application + plugin and
> application are exactly the same thing.

If I were writing a native Python library, I would never
sys.exit on errors. I would always throw exceptions. The
library wouldn't distinguish between core and plugin, but
throwing exceptions allows the core to be written in such
a way that it can manage bad plugins.

Of course, GLib is not a native Python library. But when
underlying libraries do things like this, it makes it hard
for bindings to behave the way they should.

> > this is how I'd write my application code in a
> > language with real exception handling:
> >
> > try:
> >     load_some_extension()
> > except:
> >     warn("This extension sucks. I'm disabling it and moving on.")
>
> load_some_extension() *should* check if a schema exists in the current
> path, and raise an exception if not found. Ryan is working on being able
> to define custom search paths as well.

Then load_some_extension has to know the schemas that each
extension uses ahead of time, or it has to rely on each
plugin being good about checking its schemas. And the ui
files. And its data files. And $deity knows what else.

The point is to be able to write an application that can
continue to work in the presence of a piece-of-shit plugin.

(BTW, how does one check a schema? I don't see any API for that.)

> but once you reached g_settings_new() then there's nothing you can do
> because anything after that assumes that the GSettings returned exist
> and maps to a valid settings backend, with valid values.
>
> > Of course, GLib is C. We don't have exceptions. We have GError,
> > which is a decent foundation for exceptions in language bindings.
> > But if we don't use it, then languages that could otherwise do
> > the right thing are screwed.
>
> GError is for recoverable run-time errors, not for installation errors; a
> missing schema is an installation error.

So is a missing ui file, but gtk_ui_manager_add_ui_from_file
takes a GError**.

> by the way, GError, as it is implemented and used currently, is *not* an
> exception-like system. I'm not against creating a GException, but that's
> another thing, and the two should not be confused.

I don't even see how you could create an exception system in C,
short of adding a reference argument to every single function,
and rewriting everything to always check and propagate errors
after every function call. Not worth it.

Just make sure bindings can exercise their exception systems
correctly.

> we don't have g_malloc(size_t, GError**) for OOM cases as well, I just
> hope you're not honestly asking for that.

That would be overkill. And malloc failing is not an installation
problem. It's a your-system-can't-handle-this problem.

We do have g_try_malloc though, because in some situations, there
are actually things you can do. We don't have g_settings_try_new.

--
Shaun


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

ecyrbe
In reply to this post by Emmanuele Bassi
2011/5/27 Emmanuele Bassi <[hidden email]>
On 2011-05-27 at 18:17, ecyrbe wrote:
> > > Of course it is.  With this bug, programs crash where they other-
> > > wise could limp on.
> >
> > potentially eating away data? without schema you don't have a default to
> > fall back to for application preferences and for state. it might end up
> > deleting existing account data, for instance. or eating your files.
> >
>
>
> nope, what you don't seems to understand is that you don't let the calling
> program deal with it.

and how do you propose to deal with that? if you allow the application
code to run then *anything* can happen, by definition. what's to say
that an app developer or a plugin developer decides to still go on and
not write sensible code? or tested code: a missing schema is an
installation issue, and people barely test error paths.

this might be acceptable for application developers and their own code,
but this sort of carelessness in designing a platform API is simply
not acceptable.

This is not dconf decision to make, it's the developper one. this where we are disageeing.


> With this behavviour
> you now have to protect your code from crashing by checking everytime that
> the schemas (or even the key) exists.

no, because the schema *has* to exists. why would you want to protect
from an abort()? don't you use g_assert() to protect internal state? you
might certainly not do that, but gtk+ does in multiple places.

Because it can happen?
if you are using a plugin hierarchy you will want to protect yourself
from crashing the entire application because of a single plugin.

imagine an anjuta plugin that is badly installed and that uses gsettings.
Then only one plugin can make anjuta crash (imagine a dynamic loading plugin hierarchy)
So now how can Anjuta protect itself from crashing? there is no way but adding workaround code on the plugin...
But the right way to do it should be for Anjuta to recover from some exception mecanism.
But C has no exception mecanism, so you need to make one or let the developpers deal with the error themselves.

do you want
to have a callback for gracefully showing an error dialog?

this is not going to work for the plugin hierarchy i explained.


> No data is eaten if the calling application show a gracefull message and
> exit from itself.

you cannot guarantee that for every application, unless the library
itself shows that error dialog — an error dialog that will essentially
be useless for the user ("Schema not installed. Reinstall the
application"; well, what now?). GIO cannot show error dialogs, so it
does the next best thing: abort() with an error message meaningful for
the developer in the error log, which will be caught by the desktop-wide
system service for application crashes, and will send a bug report.

what we need is a way for the Shell and for applications to be able to
validate the existence of a schema for their plugins.


Yes we need a way to validate schema existence for ANY plugin hierarchy system.
You can't seriously ask that every plugin system in gnome applications to reinvent this feature. (Gedit, Anjuta,Evolution, Gnome-shell etc)
 you have to provide a way to allow them to deal with the error. And the simplest one is to not abort,
 but if you have another suggestion, i'm all ears open.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

ecyrbe
In reply to this post by Milan Bouchet-Valat
2011/5/27 Milan Bouchet-Valat <[hidden email]>
Le vendredi 27 mai 2011 à 08:51 -0700, Hubert Figuiere a écrit :
> First, if the UI file is missing the application does not abort. There
> is an error but it can be handled by the application, and eventually
> recovered gracefuly. I deleted all the UI files and my app didn't crash.
> Sure it was not very functional but I actually had the opportunity to
> show a proper error message to the user. Not a crash.
That's already what you get:
   g_error ("Settings schema '%s' is not installed\n", name);

I really can't imagine what you could do from a program missing its
schemas, except if you hardcode (i.e. duplicate) all default values in
the code to handle this broken case

This is true for a single application with no plugin (crappy plugins?) hierarchy.
But with plugins, you need to prevent youself from crashing because plugins
do not make the whole application unusable!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Ignacio Casal Quinteiro
IMHO it is a problem in gnome shell, it should provide some api to 
create the settings for the plugins and in this api check that the
settings really exists and do not enable the plugin in that case.
But as said in some comment this is under development to provide
dynamic place for setting on plugins etc.

Regards.

On Fri, May 27, 2011 at 7:23 PM, ecyrbe <[hidden email]> wrote:
2011/5/27 Milan Bouchet-Valat <[hidden email]>
Le vendredi 27 mai 2011 à 08:51 -0700, Hubert Figuiere a écrit :
> First, if the UI file is missing the application does not abort. There
> is an error but it can be handled by the application, and eventually
> recovered gracefuly. I deleted all the UI files and my app didn't crash.
> Sure it was not very functional but I actually had the opportunity to
> show a proper error message to the user. Not a crash.
That's already what you get:
   g_error ("Settings schema '%s' is not installed\n", name);

I really can't imagine what you could do from a program missing its
schemas, except if you hardcode (i.e. duplicate) all default values in
the code to handle this broken case

This is true for a single application with no plugin (crappy plugins?) hierarchy.
But with plugins, you need to prevent youself from crashing because plugins
do not make the whole application unusable!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list



_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Havoc Pennington-2
In reply to this post by Shaun McCance-2
Hi,

Man, how many times has this thread happened? At least fifty.

On Fri, May 27, 2011 at 10:57 AM, Shaun McCance <[hidden email]> wrote:
> try:
>    load_some_extension()
> except:
>    warn("This extension sucks. I'm disabling it and moving on.")
>
> Of course, GLib is C. We don't have exceptions. We have GError,
> which is a decent foundation for exceptions in language bindings.
> But if we don't use it, then languages that could otherwise do
> the right thing are screwed.

This is the core thing. People who expect no g_error/abort are used to
languages with exceptions.

The thing that's different about C is that an "exception" (think
GError) changes the function signature of that function... _and_ *all
callers* in any library or app!

One of the very foundational design decisions of GLib, back in the
90s, was to not have an error code from every single function.
(Contrast with some other utility libraries.) And this decision has
been continued in GTK+ and all the other family of GLib-based
libraries. Some might like to change it, but people, it's too late to
paint this bikeshed another color with thousands and thousands of
existing API calls relying on it. It does, you have to admit, make the
C API a lot nicer.

The core principle that allows most functions to "always succeed" is
that programming bugs are not "thrown," they just terminate the
program.

Config schemas that contain type checking and default values are part
of the program; the program is either incorrect, or redundant in a way
likely to create bugs, without the schemas. If schemas were just docs
or something, it would be a different situation.

If you really want to "handle" this, make it impossible to be missing
the schema, by embedding the schema in the binary at compile time,
perhaps. I don't know.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Hub Figuière-2
In reply to this post by Milan Bouchet-Valat
On 11-05-27 9:46 AM, Milan Bouchet-Valat wrote:

> Le vendredi 27 mai 2011 à 08:51 -0700, Hubert Figuiere a écrit :
>> First, if the UI file is missing the application does not abort. There
>> is an error but it can be handled by the application, and eventually
>> recovered gracefuly. I deleted all the UI files and my app didn't crash.
>> Sure it was not very functional but I actually had the opportunity to
>> show a proper error message to the user. Not a crash.
> That's already what you get:
>     g_error ("Settings schema '%s' is not installed\n", name);
>
> I really can't imagine what you could do from a program missing its
> schemas, except if you hardcode (i.e. duplicate) all default values in
> the code to handle this broken case, which we actually want to avoid.

I can't really imagine GSettings knowing about MY use case and HOW I
manage my settings.

That GSettings wants to offer mechanism to enforce a schemas, fine.
That GSettings crash because a schema is missing, not so much. After all
Gtk not crash when you pass NULL to a gtk_widget_*() function, it does
not crash if the GtkBuilder file ain't found.
That GSettings does not allow me to use it in a RELAXED way, not fine.

> You could probably show a GTK error dialog, but people that don't know
> to look at the console output wouldn't understand the settings issue
> anyway...

Or not. My code is *designed* to actually manage default value. Like UI
has default that people whine about. This is just good programing practice.

But the consensus seems to be clear for me. Glad that I abstracted
preference management already thinking at the time that gconf would go away.

The only reason I jumped into the thread is because I encountered the
problem. I even filed a bug thinking that eventually things would settle
and actually get fixed. But reading all for this it end up being
horribly disappointing.


Hub
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: About gsettings aborting on unkown schemas

Krzysztof Kosiński
In reply to this post by Havoc Pennington-2
2011/5/27 Havoc Pennington <[hidden email]>:
> Config schemas that contain type checking and default values are part
> of the program; the program is either incorrect, or redundant in a way
> likely to create bugs, without the schemas. If schemas were just docs
> or something, it would be a different situation.

I think it's OK for schemas to be mandatory for programs, but problems
start when the program has several optional modules or plugins with
each having their own schemas, and the main program does not require
any of those optional modules to meaningfully work. So g_settings_new
unconditionally aborting might not be a bug, but it is very
inconvenient for the programmer.

I think the following could be done to fix this problem:
a) provide a function called g_settings_schema_exists that would check
whether creation of GSettings for a given schema name would succeed
b) provide g_settings_try_new as suggested before

Regards, Krzysztof
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
12