On Wed, 2009-09-02 at 14:28 -0400, David Zeuthen wrote:
> Unfortunately there's a lot of const incorrectness in the GLib and GTK
> +
> stack - maybe we should fix this in GLib3/GTK3 since it's going to be
> a
> new ABI.
Just a very minor correction, but at the moment there are no plans for
GLib 3.
Hello,
Sorry if this message does not thread properly, I just subscribed to the
list to avoid this issue in the future.
I'm an Inkscape developer and had noticed strange behavior in Ubuntu
Karmic when attempting to use my tablet. I can definitely confirm the
issues which result in the input coord
2009/9/2 Morten Welinder :
> void (*f1) (char *) = foo;
Why would you ever do that for g_simple_async_result_set_from_error?
If you're doing things like that with
g_simple_async_result_set_from_error then you're doing it wrong...
Richard.
___
gtk-devel
On Thu, 20 Aug 2009 at 22:09:21 -0400, Yu Feng wrote:
> However, because
> GError is always accessed by pointers and no GLib program is supposed to
> statically allocate memory for GError
Er, is nobody supposed to allocate GErrors statically? That's the first I'd
heard of it...
In code using dbus
Richard Hughes wrote:
2009/9/2 Steve Frécinaux :
I don't think it would make the ABI change...
No, it won't If anything it makes the ABI more permissive, not less
permissive, as "const GError" will accept either a "GError" or "const
GError" parameter.
Well this doesn't change the ABI, it onl
> With this change, it won't break (or add warnings) to any program. It
> just removes a warning for programs that do not do the explicit cast,
> and get given a const GError.
Really?
Take the program below and notice that the constified prototype
introduces a warning. If used from C++, that wou
2009/9/2 Steve Frécinaux :
> I don't think it would make the ABI change...
No, it won't If anything it makes the ABI more permissive, not less
permissive, as "const GError" will accept either a "GError" or "const
GError" parameter.
Richard.
___
gtk-deve
On Wed, 2009-09-02 at 20:42 +0200, Sven Neumann wrote:
> On Wed, 2009-09-02 at 14:28 -0400, David Zeuthen wrote:
>
> > Mmmm, wouldn't this break the API? E.g. cause compilation of existing
> > apps to spew warnings. If so, we can't do it.
>
> How is the introduction of a compiler warning an API b
2009/9/2 David Zeuthen :
> Mmmm, wouldn't this break the API? E.g. cause compilation of existing
> apps to spew warnings. If so, we can't do it.
No, the API doesn't change. g_simple_async_result_set_from_error
doesn't ever free the passed error, and the only function that
g_simple_async_result_set
David Zeuthen wrote:
On Wed, 2009-09-02 at 19:17 +0100, Richard Hughes wrote:
In PackageKit, I have to explicitly cast in my finish function:
static void
pk_package_sack_merge_state_finish (PkPackageSackState *state, const
GError *error)
{
...
g_simple_async_result_set_from_erro
On Wed, 2009-09-02 at 14:28 -0400, David Zeuthen wrote:
> Mmmm, wouldn't this break the API? E.g. cause compilation of existing
> apps to spew warnings. If so, we can't do it.
How is the introduction of a compiler warning an API break? Every gcc
update introduces some more compiler warnings in co
On Wed, 2009-09-02 at 19:17 +0100, Richard Hughes wrote:
> In PackageKit, I have to explicitly cast in my finish function:
>
> static void
> pk_package_sack_merge_state_finish (PkPackageSackState *state, const
> GError *error)
> {
> ...
> g_simple_async_result_set_from_error (state->
In PackageKit, I have to explicitly cast in my finish function:
static void
pk_package_sack_merge_state_finish (PkPackageSackState *state, const
GError *error)
{
...
g_simple_async_result_set_from_error (state->res, (GError*)
error);
...
}
The finish function is passed a const GE
13 matches
Mail list logo
