> Date: Tue, 16 Mar 2010 17:20:41 +0200
> From: Mikhail Zabaluev
> To: gtk-devel-list@gnome.org
> Subject: Faster UTF-8 decoding in GLib
> Message-ID:
> <9d78c8b41003160820p5fad00afjaa8ec4772162c...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
>
> I've made a glib b
Hi,
Am Mittwoch, den 17.03.2010, 00:17 +0200 schrieb Mikhail Zabaluev:
> Yes, though we are already in the buffer overflow territory with all
> implementations of g_utf8_get_char considered so far.
Only read past the end, thus no security implications beyond a potential
for DoS in the unlikely e
Hi,
Am Dienstag, den 16.03.2010, 23:51 +0100 schrieb Mathieu Lacage:
> loading offsets are usually randomized once in a while and the whole
> system is prelinked with these randomized offsets so that all further
> loads do use the same 'random' (per-machine) offset until the next
> offset randomi
On Tue, 16 Mar 2010, Marty Jack wrote:
> I confirm this. LFS, glib-2.22.4, gtk-2.18.8, firefox 3.6 and
> thunderbird 3.0.3 both fail on startup with that or a similar
> backtrace. Every other GTK application I tried worked before I
> reverted to 2.18.7.
Same here (firefox 3.6 was the only GTK
This has the same general feel as
https://bugzilla.gnome.org/show_bug.cgi?id=601922
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi;
recently there's been a flood of changes in gtk+ where *internal* uses
of GTK_WIDGET_* macros accessing the widget flags were replaced by the
new public accessors. Why is that? I thought the GSEAL work was intended
to only seal *outside* access to the flags, while library-internal code
could c
Hi,
Why is gtk_widget_real_unrealize() calling gtk_widget_real_unmap()
directly instead of calling gtk_widget_unmap()?
Unless I'm missing the obvious, this seems to have the consecuence of
not executing the unmap method when implemented by subclasses.
Attached horrid example shows the issue wit
Fix confirmed. Good work on the bisect. Patch below.
diff -Naur gtk+-2.18.8.orig/gtk/gtkentry.c gtk+-2.18.8/gtk/gtkentry.c
--- gtk+-2.18.8.orig/gtk/gtkentry.c 2010-03-15 18:36:16.0 -0400
+++ gtk+-2.18.8/gtk/gtkentry.c 2010-03-17 11:31:42.0 -0400
@@ -6668,8 +6668,11 @@
g_o
hi everyone;
it's been a while since the last one, so let's get the ball rolling once
again.
next tuesday I'll be offline, until the 25th included, but it would
still be good to have an irc meeting; the 26th is friday so I can
understand if people will just laugh at a proposal for holding the
mee
GTK+ 2.18.9 is now available for download at:
ftp://ftp.gtk.org/pub/gtk/2.18/
http://download.gnome.org/sources/gtk+/2.18/
sha256 sums:
5dcd8c406acbb8779c0b081a089fa87dfd7ab4d7d4c6075db478997ce96aa9b4 gtk
+-2.18.9.tar.bz2
9645fbeaba1eb0ed6bebeaa94d87ecdc1c4d881ff19931085bf363d32338cd6c gtk
+-2.
Am Wed, 17 Mar 2010 15:55:23 +0100
schrieb Christian Persch :
> Hi;
>
> recently there's been a flood of changes in gtk+ where *internal* uses
> of GTK_WIDGET_* macros accessing the widget flags were replaced by the
> new public accessors. Why is that? I thought the GSEAL work was
> intended to o
On Wed, 2010-03-17 at 17:49 +0100, Christian Dywan wrote:
> > recently there's been a flood of changes in gtk+ where *internal* uses
> > of GTK_WIDGET_* macros accessing the widget flags were replaced by the
> > new public accessors. Why is that? I thought the GSEAL work was
> > intended to only s
Am Wed, 17 Mar 2010 17:10:02 +
schrieb Emmanuele Bassi :
> On Wed, 2010-03-17 at 17:49 +0100, Christian Dywan wrote:
>
> > > recently there's been a flood of changes in gtk+ where *internal*
> > > uses of GTK_WIDGET_* macros accessing the widget flags were
> > > replaced by the new public acc
In a previous thread about sealing accessors and how that means more
type checking,
On Wed, 2010-03-17 at 17:10 +, Emmanuele Bassi wrote:
> this might be the kick in the arse needed to get type checking down to a
> minimal cost
We have observed in the past that the type checking calls are 2-
On 17/03/10 22:03, Andrew Cowie wrote:
in gtk/gtkbutton.c which after wading through several macros ends up as
a call to g_type_check_instance() in glib/gtype.c with some if/else
blocks around it.
[snip]
So I'm wondering: can we [C, GTK] do away with one of the code paths
entirely? It'd be ni
On Thu, 2010-03-18 at 09:03 +1100, Andrew Cowie wrote:
> I've often wondered about it, because on the one hand we have
>
> void
> gtk_button_set_label (GtkButton *button,
> const gchar *label)
> {
> g_return_if_fail (GTK_IS_BUTTON (
Martyn Russell a écrit :
> On 17/03/10 22:03, Andrew Cowie wrote:
>> in gtk/gtkbutton.c which after wading through several macros ends up as
>> a call to g_type_check_instance() in glib/gtype.c with some if/else
>> blocks around it.
>
> [snip]
>
>> So I'm wondering: can we [C, GTK] do away with o
2010/3/17 Emmanuele Bassi :
> hi everyone;
>
> it's been a while since the last one, so let's get the ball rolling once
> again.
>
> next tuesday I'll be offline, until the 25th included, but it would
> still be good to have an irc meeting; the 26th is friday so I can
> understand if people will ju
2010/3/18 Emmanuele Bassi :
> On Thu, 2010-03-18 at 09:03 +1100, Andrew Cowie wrote:
>
>> I've often wondered about it, because on the one hand we have
>>
>> void
>> gtk_button_set_label (GtkButton *button,
>> const gchar *label)
>> {
>>
19 matches
Mail list logo
