Re: About gsettings aborting on unkown schemas
Le lundi 30 mai 2011 à 20:17 -0400, Morten Welinder a écrit : Doing a g_return_val_if_fail is fine here. That will give the user a chance of saving his work. This is in contrast to g_error which is a sure way of eating data. There's no work of data here. Programs load GSettings on start, and OTC it's far better for users' data to ensure a program won't start without schemas. If it pretends to work, it might crash at any point because the code paths run when schemas are not present are poorly tested (if at all), and do nasty things to the data it works with. Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Am Mon, 30 May 2011 21:13:16 -0400 schrieb Havoc Pennington: Hi, On Mon, May 30, 2011 at 8:37 PM, Shaun McCance sha...@gnome.org wrote: But I want to point out that my point was never that GLib should behave like a language with exceptions. Just that it should let bindings in those languages behave like they should. I agree that would be ideal if you were optimizing for non-C. But the only way to do that is to replicate the entire API currently lacking an error indicator, with a second _with_error version of every function. Some functions may happen to have some other ad hoc way to do an error (like returning NULL) but it'd just be some subset without rhyme or reason. If you aren't prepared to do the _with_error() replication of the API, then doing it here and there at random is kinda weird. Either it's needed or not, it isn't needed here and there at random. This is a great argument. There was a mistake. It made you notice the API is inconsistent, so you suddenly insist that GLib can't be improved further without rewriting all the functions I would personally prefer it if you were honest and would say that your opinion is set, instead of giving bogus arguments. Including the one about g_error. Then nobody would continue wasting time on trying to explain his point of view to deaf ears. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Mon, May 30, 2011 at 8:17 PM, Morten Welinder mort...@gnome.org wrote:
The core principle that allows most functions to always succeed is
that programming bugs are not thrown, they just terminate the
program.
Havoc, the data doesn't agree with that assertion.
Let's look at numbers:
glib, number of not-crashing on programmer errors:
# find glib -type f -name '*.c' -print | xargs -n100 grep -E
'g_return_(val_)?if_fail' | wc -l
1509
glib, number of crashing on programmer errors:
# find glib '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
213
gtk+, number of not-crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_return_(val_)?if_fail' |
wc -l
5637
gtk+, number of crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
693
So the overwhelming conclusion is that glib and gtk+ handle programmer
errors by issuing a critical and returning. Not by crashing.
It tips even more in that direction when you realize that a good
fraction of the crashing calls do not actually catch (library user)
programmer errors, but problems more in the memory-corruption
department.
We know that not having the schema around is not good. Going postal
and killing the program is not the solution.
Doing a g_return_val_if_fail is fine here. That will give the user a
chance of saving his work. This is in contrast to g_error which is a
sure way of eating data.
This is getting very tiresome. Your statistics don't make any sense. A
programming error is a programming error, and the fact that we
indicate some of them with g_return_if_fail instead
of g_assert is a mere convention, not an invitation to handle them at runtime.
How about everybody who wants their programs to stumble along when
installed incorrectly just use g_settings_list_schemas() to determine
the presence of their schemas, instead of prolonging this discussion
even further ?
Thanks,
Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Hi, On Tue, May 31, 2011 at 5:47 AM, Christian Dywan christ...@lanedo.com wrote: This is a great argument. There was a mistake. It made you notice the API is inconsistent, so you suddenly insist that GLib can't be improved further without rewriting all the functions It didn't make me notice - I've known about this issue for many years, including in all the other threads about it. I also wrote the GError API docs 11 years ago, which explain the issue. You can find years-old emails with me making the same duplicate error-throwing API for bindings point about libdbus, if you do some googling. This is a 15-year-old issue, or so. It's a tradeoff. We could redo thousands of functions with duplicate functions to be used only from language bindings, or we could live with this design decision. I personally think 15 years of experience show that we can survive without a major API redo. I agree that g_warning/critical can be nicer than g_error in a certain way, fwiw, though when it's up to me I make both abort and consider them the same. Anyway, I don't make the decision on this. I'm just trying to tell you why it is how it is and just how long it's been that way. This thread is hardly the first one to suddenly realize this is how GLib works and get upset about it. But GLib has always worked this way. There are other people you'd have to convince if you wanted to change anything. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Fri, 2011-05-27 at 11:57 -0400, Matthias Clasen wrote: On Fri, May 27, 2011 at 7:42 AM, ecyrbe ecy...@gmail.com 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. Sorry to pick on Matthias, by responding to his mail, but I think that general-purpose thinking is preventing people from realizing that there is a real problem that needs to be fixed here. Yes, programs should not be written to run with missing schemas. Yes, we don't have ways clean ways of raising exceptions for programmer or system configuration errors. But that doesn't change the fact that if from some interactive environment (GNOME Shell looking glass console, python command line, etc), I try to use GSettings and typo the name of a schema, it should not; _should not_ make the entire environment go boom. So, let's add alternate API that allows for failure without going boom and blowing up the world, and let's figure out how to get that hooked up to languages with exceptions automatically. Yes, this is made harder by the fact that it's a constructor, not a normal function, but it's certainly doable; we just have to come up with a convention. (The idea that comes t mind is that we add a construct-only property that means construct in an error state, and and a getter to check for and retrieve the GError.) - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On 05/31/2011 03:12 PM, Owen Taylor wrote: So, let's add alternate API that allows for failure without going boom and blowing up the world, and let's figure out how to get that hooked up to languages with exceptions automatically. Yes, this is made harder by the fact that it's a constructor, not a normal function, but it's certainly doable; we just have to come up with a convention. We already have it; GInitable. -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
The core principle that allows most functions to always succeed is
that programming bugs are not thrown, they just terminate the
program.
Havoc, the data doesn't agree with that assertion.
Let's look at numbers:
glib, number of not-crashing on programmer errors:
# find glib -type f -name '*.c' -print | xargs -n100 grep -E
'g_return_(val_)?if_fail' | wc -l
1509
glib, number of crashing on programmer errors:
# find glib '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
213
gtk+, number of not-crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_return_(val_)?if_fail' |
wc -l
5637
gtk+, number of crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
693
So the overwhelming conclusion is that glib and gtk+ handle programmer
errors by issuing a critical and returning. Not by crashing.
It tips even more in that direction when you realize that a good
fraction of the crashing calls do not actually catch (library user)
programmer errors, but problems more in the memory-corruption
department.
We know that not having the schema around is not good. Going postal
and killing the program is not the solution.
Doing a g_return_val_if_fail is fine here. That will give the user a
chance of saving his work. This is in contrast to g_error which is a
sure way of eating data.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Fri, 2011-05-27 at 17:09 -0400, Havoc Pennington wrote: Hi, Man, how many times has this thread happened? At least fifty. On Fri, May 27, 2011 at 10:57 AM, Shaun McCance sha...@gnome.org 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! I really don't want to carry this thread much further. It is getting bike-sheddy. We disagree. I'm not the one making the decisions. Life goes on. But I want to point out that my point was never that GLib should behave like a language with exceptions. Just that it should let bindings in those languages behave like they should. What I would do (take it or leave it, and let's move on with our lives) is make the constructor return NULL if there's a problem and make all consumers of GSettings abort if passed NULL. Same effect, just perhaps delayed. I don't think it risks any more data loss than the current behavior. The advantage is that bindings could do a NULL check and raise an exception. With introspection-based bindings, this kind of NULL-check-and-raise can even be done automatically, perhaps with a flag like raise-on-null. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Hi, On Mon, May 30, 2011 at 8:17 PM, Morten Welinder mort...@gnome.org wrote: Doing a g_return_val_if_fail is fine here. That will give the user a chance of saving his work. This is in contrast to g_error which is a sure way of eating data. If that's the argument it's fine. I treat return_if_fail and g_error the same (often setting the env variable to make return_if_fail crash). Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Le vendredi 27 mai 2011 à 19:04 -0700, Hubert Figuiere a écrit : My code is *designed* to actually manage default value. Like UI has default that people whine about. This is just good programing practice. While I can perfectly conceive we might need a way to avoid crashing when a schema is missing (e.g. when loading broken plugins), I really think code designed to manage default values is wrong. And that's exactly what GSettings's behavior is meant to prevent. What the point of duplicating information in the schemas and in the code? In the good GConf times, you had to create several code paths every time you read a key in case the setting wasn't valid, or had no default. And then you had to keep the hardcoded default in sync with the schemas to avoid a big mess. With GSettings, that's easy: you're guaranteed to get a correct value, and in the worst case the default. You don't need any if() in your code, and you can change the default just by editing the schema. GSettings was designed with the idea that settings can't be missing in mind. As Havoc said, consider them as being part of the code (at least as a metaphor). There's no good reason a program should have missing schemas - except maybe in the case of plugins. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Here is a patch for this for those who want it. https://bugzilla.gnome.org/show_bug.cgi?id=651366 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Fri, May 27, 2011 at 7:42 AM, ecyrbe ecy...@gmail.com 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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
2011/5/27 Emmanuele Bassi eba...@gmail.com 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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
2011/5/27 Milan Bouchet-Valat nalimi...@club.fr 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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 ecy...@gmail.com wrote: 2011/5/27 Milan Bouchet-Valat nalimi...@club.fr 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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Hi, Man, how many times has this thread happened? At least fifty. On Fri, May 27, 2011 at 10:57 AM, Shaun McCance sha...@gnome.org 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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
2011/5/27 Havoc Pennington h...@pobox.com: 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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
