Hi,
The reference that is returned by gtk_invisible_new is not owned by the
caller. If one tries to unref it, it's an immediate memory corruption.
When a toplevel widget is concerned, the things go like the following:
* New floating GtkWidget is created (not owned by anyone).
* GTK library tak
(This is a bit better suited to gtk-app-devel-list, but...)
Brian Lu wrote:
> Thanks a lot for your explanation. But look at following snippet from
> firefox latest code base:
> void InitWidget() {
> mWidget = gtk_invisible_new();
> gtk_object_ref(GTK_OBJECT(mWidget));
>
On Fri, 2008-01-11 at 12:01 -0600, Cody Russell wrote:
>
> Other widgets are SexySpellEntry, but that would involve new
> dependencies that I think gtk+ doesn't want,
We do want to solve the spell-checking-everywhere issue at some point
though. There was talks about having gspell in glib. The s
On Fri, 2008-01-11 at 12:01 -0600, Cody Russell wrote:
> So as you suggested I'm filing bug reports for widgets that seem
> merge-worthy:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=508809
> http://bugzilla.gnome.org/show_bug.cgi?id=508810
>
> Other widgets are SexySpellEntry, but that would
On Fri, 2008-01-11 at 14:38 +, Bastien Nocera wrote:
> > I don't think we need to discuss libsexy in a meeting, let alone a
> > hackfest. Libsexy IIUC is a staging area for widgets, similar to
> > libegg. If that's the case, it cannot be "merged" at once and needs
> to
> > be done for each wi
On Fri, 2007-12-28 at 14:45 -0500, Behdad Esfahbod wrote:
> Hi,
>
> On my Berlin GTK+ Hackfest blog post [1] I got two comments about adding
> libsexy to the agenda.
>
> I don't think we need to discuss libsexy in a meeting, let alone a
> hackfest. Libsexy IIUC is a staging area for widgets, si
On Jan 10, 2008 5:16 AM, Alexander Larsson <[EMAIL PROTECTED]> wrote:
>
> > GdkPixbuf *
> > gtk_icon_info_load_at_size (GtkIconInfo *info,
> > gint pixel_size);
> >
>
> Since this does I/O it would be nice if it took a GCancellable argument.
> However, that might
Thanks a lot for your explanation. But look at following snippet from
firefox latest code base:
void InitWidget() {
mWidget = gtk_invisible_new();
gtk_object_ref(GTK_OBJECT(mWidget));
gtk_object_sink(GTK_OBJECT(mWidget));
gtk_widget_ensure_style(mWidget);
On Sun, 6 Jan 2008, Mikkel Kamstrup Erlandsen wrote:
> On 05/01/2008, Tim Janik <[EMAIL PROTECTED]> wrote:
> test would look like the below pseudo code:
>
> -
>
> setup (fix) {
> fix->search = create_search_on_search_engine()
> }
>
> test_run (fix) {
> Hits hits;
>
> start_search(fix->sea
On Wed, 2 Jan 2008, Asbjørn wrote:
I'm checking out the Test Framework and here is my first test program:
glib/glib/tests/testingbase64.c
Output:
TEST: testingbase64... (pid=15393)
/misc/base64/encode: OK
/misc/base64/decode:
On Wed, 9 Jan 2008, Tommi Komulainen wrote:
> Hi,
> make -k test probably shouldn't abort gtester on first failing assertion
hm, currently, we have these test framework makefile rules:
test: run all tests recursively, abort on first error
test-report:run tests in subdirs, generate
On Wed, 9 Jan 2008, Tommi Komulainen wrote:
> Hi,
>
> Here's a quick guide for setting up GLib testing framework for your own
> project. It is the result of some trial and error when integrating for
> hildon widgets the test framework from current trunk. There are some
> autotools related details
On Wed, 9 Jan 2008, Shawn Amundson wrote:
> Olav Vitters wrote:
>> On Wed, Jan 09, 2008 at 09:25:16AM +, Martyn Russell wrote:
>>> I must confess, I have quite limited knowledge when it comes to our
>>> hosting services for GNOME and GTK+ (i.e. where machines are hosted
>>> physically and who
13 matches
Mail list logo
