GType typedef API/ABI break.
I sent this to gtk-list by mistake. Re-sending it to gtk-devel-list: I think the recent change to the GType definition is causing linker errors by changing the GType definition from gulong to gsize. We are left with the #else definition that was previously commented as "/* hm, shouldn't happen? */" This is the change: http://svn.gnome.org/viewcvs/glib/trunk/gobject/gtype.h?r1=5497&r2=5560 With this ChangeLog entry: http://svn.gnome.org/viewcvs/glib?view=revision&revision=5560 This is causing linker errors in almost everything that uses glib and C ++, such as gtkmm and Inkscape, because the parameter type in, e.g. void get_defs(GType) is part of the function signature. For instance, glibmm's library contains a void get_defs(unsigned long) But now, when building gtkmm, the linker is looking for void get_defs(unsigned int) and failing. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
> 1. User gets a crash in gnumeric-n.m, reports it. > > 2. Developer determines that the crash is in the theme engine. > > 3. Developer blacklists the theme engine; releases gnumeric-n.m+1 > > 4. User updates gnumeric, and can't run it anymore because it barfs on > that engine. He still risks crashes in other apps. > > I don't think blacklisting will work due to (4). If you require the > user to upgrade the app, then the user may as well update the theme > engine, too. > > It's better to tell the user "you should really update your theme > engine"; that will fix his problem and prevent crashes in other apps as > well. Well, but that still keeps the problem of countless dups in Bugzilla and bad reputation. I support the idea of blacklisting as this could be some efficient measure for quality control, but only if the blacklisting doesn't happen in the application, but in GTK+. Blacklisted themes would by detected by the MD5, SHA256, whatever hash over their gtkrc. Distributors would be encouraged to frequently backport our blacklist into their current GTK+ package. The blacklist even could be packaged separatly to make upgrades cheap. Just my 2 cents... Ciao, Mathias -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
Just realized that pygtk and gtk-devel-list subscribers may not be on d-d-l. So I'm forwarding this. See http://mail.gnome.org/archives/desktop-devel-list/2007-June/msg00109.html for the thread and discussion. Please jump in. -- Forwarded message -- From: Elijah Newren <[EMAIL PROTECTED]> Date: Jun 21, 2007 8:05 PM Subject: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?) To: Gnome Desktop Development List <[EMAIL PROTECTED]> Hi, As noted in bug http://bugzilla.gnome.org/show_bug.cgi?id=449318, there was a recent gtk+ API change. jdahlin just barely told me that the changed API has existed since 1998, long before gtk+-2.11.x (and pointed me to http://bugzilla.gnome.org/show_bug.cgi?id=447214). This API change breaks pygtk and means that much of GNOME cannot be compiled. But it doesn't seem clear who should fix this. Should gtk+ revert it or somehow fix the API break, or is this an API break we want and expect pygtk to adapt to? Elijah ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Tue, 2007-06-19 at 15:08 -0400, Morten Welinder wrote: > The application programmer has no choice in the matter and cannot > really test with > all kinds of themes and all kinds of versions of them. But the > resulting crashes are > still going to be blamed on the application and poor me. So the sequence goes: 1. User gets a crash in gnumeric-n.m, reports it. 2. Developer determines that the crash is in the theme engine. 3. Developer blacklists the theme engine; releases gnumeric-n.m+1 4. User updates gnumeric, and can't run it anymore because it barfs on that engine. He still risks crashes in other apps. I don't think blacklisting will work due to (4). If you require the user to upgrade the app, then the user may as well update the theme engine, too. It's better to tell the user "you should really update your theme engine"; that will fix his problem and prevent crashes in other apps as well. It would be better to capture the thing that caused this particular bug, and to make Manu Cornet's theme engine torturer replicate it. That way people can run their theme engines through the torturer before releasing them. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Automake requirements for gtk+, glib
On 6/16/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: > >No. automake versions are not compatible. >Simply changing the requirements is not an option. Following up to http://bugzilla.gnome.org/show_bug.cgi?id=448828 on-list because it's a developers'/multiproduct issue apparently, is there interest in getting gtk+ and glib clean for automake1.9? Should "we" (random contributors) consider submitting patches to bring things up to modern am standards, or is there some admin or policy or developers' reason/consensus to keep at the existing old am version? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
2007/6/19, Morten Welinder <[EMAIL PROTECTED]>: > The application programmer has no choice in the matter and cannot > really test with > all kinds of themes and all kinds of versions of them. But the > resulting crashes are > still going to be blamed on the application and poor me. The usual way to prevent this is to advocate fixed versions (or backported patches) to the distributions. I think it's the only valid way too, since as you note, the application programmer has no choice and should not have to care about the versions. It's really the distribution who has the responsibility to provide fixed versions of software. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
