BJörn Lindqvist wrote:
> On 10/12/07, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
>
>> On Fri, 2007-10-12 at 14:40 +0200, Mathias Hasselmann wrote:
>>
>>
>>> So I guess what you really want is some kind of "g_soft_assert" or some
>>> "g_warn_if_fail".
>>>
>> +1 on a g_warn_if_fail() A
On 10/12/07, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-10-12 at 14:40 +0200, Mathias Hasselmann wrote:
>
> > So I guess what you really want is some kind of "g_soft_assert" or some
> > "g_warn_if_fail".
>
> +1 on a g_warn_if_fail() API addition.
What is wrong with:
if (!everything
Hello!
On 10 Oct 2007 21:46:38 +0200, Soeren Sandmann <[EMAIL PROTECTED]> wrote:
> "BJörn Lindqvist" <[EMAIL PROTECTED]> writes:
>
> > Incidentally, blitting pixbufs is slower than it has to be because its
> > format rarely matches the X11 server which uses either xRGB32 or
> > ARGB32.
>
> I don't
On 10/8/07, Havoc Pennington <[EMAIL PROTECTED]> wrote:
> BJörn Lindqvist wrote:
> > So how about replacing gdk-pixbuf with something cairo compatible that
> > is also modern? 16 bits per sample is common these days. Support for
> > digital camera RAW images would also be nice. Is a completely new
On 10/8/07, Kalle Vahlman <[EMAIL PROTECTED]> wrote:
> 2007/10/8, BJörn Lindqvist <[EMAIL PROTECTED]>:
> > It feels like Cairo doesn't fit in. For example, GDK uses GdkColor to
> > represent colors but Cairo has no equivalent.
>
> There is gdk_cairo_set_source_color() though, which bridges the gap.
I've been thninking about this issue for some while now as well, and I've
written (in gtkmm straight, so i didn't attempt to provide patches yet) a
CairoImageSurface cellrenderer, and a few miscellaneous widgets which render
directly a Cairo ImageSurface to a drawable instead of doing roundtrips. T
Tim Janik wrote:
> hey All.
>
> i'd like to propose to turn g_assert and friends like g_assert_not_reached
> into warnings instead of errors. i'll give a bit of background before the
> details though.
Like Mathias, I was in a bit of "hell no!" mode when I first read this.
After reading your ra
On Fri, 12 Oct 2007, Owen Taylor wrote:
> On Fri, 2007-10-12 at 11:52 +0200, Tim Janik wrote:
>
>> i'd like to propose to turn g_assert and friends like g_assert_not_reached
>> into warnings instead of errors. i'll give a bit of background before the
>> details though.
>
> This is an incompatible
On Fri, 2007-10-12 at 11:52 +0200, Tim Janik wrote:
> i'd like to propose to turn g_assert and friends like g_assert_not_reached
> into warnings instead of errors. i'll give a bit of background before the
> details though.
This is an incompatible change. The contract now is that unless you
compil
2007/10/12, Tim Janik <[EMAIL PROTECTED]>:
>
> hey All.
>
> i'd like to propose to turn g_assert and friends like g_assert_not_reached
> into warnings instead of errors. i'll give a bit of background before the
> details though.
[snip]
While the reasoning to make programs seem less crashy sounds
c
On Fri, 12 Oct 2007, Mathias Hasselmann wrote:
> Am Freitag, den 12.10.2007, 11:52 +0200 schrieb Tim Janik:
>> note that in practice, this shouldn't change anything for programmers
>> (except for the ability to write better code ;)
>> because of G_DISABLE_ASSERT, programmers can already not rely o
Il giorno ven, 12/10/2007 alle 15.16 +0200, Tim Janik ha scritto:
> please reread my reasoning about G_DISABLE_ASSERT, there already is no
> behavior
> of g_assert() you could rely on. (and some distributions do build their
> binaries with G_DISABLE_ASSERT and/or G_DISABLE_CHECKS defined).
What d
Il giorno ven, 12/10/2007 alle 14.40 +0200, Mathias Hasselmann ha
scritto:
> I was in strict "HELL, NO!" mode until I read this reasoning. Still I am
> not sure if G_DISABLE_ASSERT is a misfeature, since when using g_assert*
> instead of g_return* or g_warning you usually really have no good
> fal
hi..
how to get information regarding opened windows using libwnck library..
and another thing..how to log mouse events and keyboard events..
is there any package is there..
--
Thanks & Regards
sridhar gupta yerram
M.Tech(A.I)
University of Hyderabad
__
That's pretty much a no-go.
g_assert_warning is marked G_GNUC_NORETURN.
If you return from such a function, there is no telling what incorrect
assumption the
following code was compiled with, i.e., things that the compiler thought were in
registers all of a sudden are not. Crash. Burn. Toast.
> c) programs that aren't 100% bug free could possibly trigger these warnings
> during production. aborting would take all the end user data with it,
> created/modified images, text documents, etc.
> issuing just a warnig preserves the possibility to still save crucial
> data if the
On Fri, 12 Oct 2007, Yevgen Muntyan wrote:
> Hey,
>
> Why not introduce a new check, some g_check_stuff() which would
> do what you propose? And let g_assert() be what it is, a glib analog
> of C assert(). When an assertion fails, you can't possibly expect the
> code to function in any meaningful
On Fri, 2007-10-12 at 14:40 +0200, Mathias Hasselmann wrote:
> So I guess what you really want is some kind of "g_soft_assert" or some
> "g_warn_if_fail".
+1 on a g_warn_if_fail() API addition.
ciao,
Emmanuele.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.
Am Freitag, den 12.10.2007, 11:52 +0200 schrieb Tim Janik:
> note that in practice, this shouldn't change anything for programmers
> (except for the ability to write better code ;)
> because of G_DISABLE_ASSERT, programmers can already not rely on
> failing assertions to abort their programs (only
Hey,
Why not introduce a new check, some g_check_stuff() which would
do what you propose? And let g_assert() be what it is, a glib analog
of C assert(). When an assertion fails, you can't possibly expect the
code to function in any meaningful way, e.g.
int idx;
g_assert (idx >= 0);
array[idx
hey All.
i'd like to propose to turn g_assert and friends like g_assert_not_reached
into warnings instead of errors. i'll give a bit of background before the
details though.
the main reasons we use g_return_if_fail massively throughout the glib and
gtk+ code base is that it catches API misuses v
21 matches
Mail list logo
