Re: g_spawn_async_with_pipes and WIN32
Alan M. Evans writes: The process being called simply prints a short message and returns. I see the message if I execute the program from a command prompt under Windows. The linux version works, In the Windows version, _read() always returns -1, errno=EBADF. Does your code use the same C runtime library as GLib does, msvcrt.dll, which is part of the operating system? If not, the file handles returned have no meaning in your code. File handles are basically indexes into a table in the C library. Microsoft in their infinite wisdom provides so many C runtimes libraries, and their newer tools for some reason don't allow building code against msvcrt.dll... If you want to use msvcrt.dll, you should either use the older, but for plain C still perfectly usable, Visual C 6.0. Or use gcc, i.e. mingw. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn_async_with_pipes and WIN32
Alan M. Evans writes: This is being compiled with VC6, and does depend (indirectly) on msvcrt.dll. OK, good. Are you saying that my method should work in this circumstance? In principle, yes. In practice, if it doesn't, file a bug report at bugzilla.gnome.org and include a complete but minimal sample program source code as an attachment. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn_async_with_pipes and WIN32
On Fri, 2007-06-22 at 11:37 +0300, Tor Lillqvist wrote: Alan M. Evans writes: The process being called simply prints a short message and returns. I see the message if I execute the program from a command prompt under Windows. The linux version works, In the Windows version, _read() always returns -1, errno=EBADF. Does your code use the same C runtime library as GLib does, msvcrt.dll, which is part of the operating system? If not, the file handles returned have no meaning in your code. File handles are basically indexes into a table in the C library. Microsoft in their infinite wisdom provides so many C runtimes libraries, and their newer tools for some reason don't allow building code against msvcrt.dll... If you want to use msvcrt.dll, you should either use the older, but for plain C still perfectly usable, Visual C 6.0. Or use gcc, i.e. mingw. This is being compiled with VC6, and does depend (indirectly) on msvcrt.dll. Are you saying that my method should work in this circumstance? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Proper Handling of GtkTreeModelFilters
I have an underlying model for a TreeView in my application that I am
filtering based on certain user selections. I maintain a global reference
to the base TreeModel (which is sometimes attached to the TreeView used to
display the information.) The mechanism I am using goes something like
this:
1. User selects a new filter criteria
2. (Depending on the selection) Either a) gtk_tree_model_filter_new to
create a new filter based on the user's criteria from the global base
model or b) use the base model.
3. gtk_tree_view_set_model( [selected model])
I was thinking this is probably leaving a bunch of filtered tree models
around that aren't doing anything but taking up space...do I need to be
g_object_unref'ing the old filter models? I attempted a replace function
that looks something like:
void replaceTreeModel(GtkTreeModel *model)
{
GtkTreeView *treeview = [get the widget];
GtkTreeModel *currentModel = gtk_tree_view_get_model(treeview);
gtk_tree_view_set_model( treeview, model );
// The following makes the application unstable and crash in the filter
function so I've commented it out for now
//if (GTK_IS_TREE_MODEL_FILTER( currentModel))
//{
// g_object_unref( G_OBJECT(currentModel));
//}
}
What is the best/proven way of doing something like this?
Thanks,
Matt
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Proper Handling of GtkTreeModelFilters
On Fri, Jun 22, 2007 at 02:47:30PM -0400, Matthew Yaconis wrote:
I have an underlying model for a TreeView in my application that I am
filtering based on certain user selections. I maintain a global reference
to the base TreeModel (which is sometimes attached to the TreeView used to
display the information.) The mechanism I am using goes something like
this:
1. User selects a new filter criteria
2. (Depending on the selection) Either a) gtk_tree_model_filter_new to
create a new filter based on the user's criteria from the global base
model or b) use the base model.
3. gtk_tree_view_set_model( [selected model])
GtkTreeModelFilter does not contain much data to preserve.
So, to get a different filter, just take the current
filter and call gtk_tree_model_filter_set_visible_func() or
gtk_tree_model_filter_set_modify_func() on it -- or change
the private data the filter uses and call
gtk_tree_model_filter_refilter().
And instead of switching to the base model you can set the
visible func to one that always returns TRUE (for some
reason it is not possible to set the filter functions back
to NULL). This saves you testing whether to convert iters
and paths or not as you convert them always.
I only physically replace the filter if the virtual root has
to change as it is construction only property. Sometimes
one has a handful of well-defined (semi)fixed filters that
it makes sense to keep around, but usually not.
I was thinking this is probably leaving a bunch of filtered tree models
around that aren't doing anything but taking up space...do I need to be
g_object_unref'ing the old filter models? I attempted a replace function
that looks something like:
void replaceTreeModel(GtkTreeModel *model)
{
GtkTreeView *treeview = [get the widget];
GtkTreeModel *currentModel = gtk_tree_view_get_model(treeview);
gtk_tree_view_set_model( treeview, model );
// The following makes the application unstable and crash in the filter
function so I've commented it out for now
//if (GTK_IS_TREE_MODEL_FILTER( currentModel))
//{
// g_object_unref( G_OBJECT(currentModel));
//}
}
What holds references to currentModel after the
gtk_tree_view_set_model() call? GtkTreeModelFilter is
created with reference count 1, so you should be left with
this inital reference at the end -- but only if you didn't
released it earlier. And if you did, then currentModel is
already destroyed when you try GTK_IS_TREE_MODEL_FILTER().
It's hard to deduce anything from such code fragment.
If you don't need to keep the filters around, it's probably
easiest to release the inital reference immediately after
you do gtk_tree_view_set_model() and do not care about them
any more as they will be destroyed automatically once
nothing needs them.
Yeti
--
http://gwyddion.net/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Proper Handling of GtkTreeModelFilters
Yeti, What holds references to currentModel after the gtk_tree_view_set_model() call? If it is a filter model, then nothing. If it was the base model then I was maintaining my own global pointer to it. I apologize for the difficult code snippet but regardless you have helped me tremendously. I'll be re-working my framework to align more closely with what you've described. (Makes way more sense.) Thanks so much! Matt ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-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
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=5497r2=5560 With this ChangeLog entry: http://svn.gnome.org/viewcvs/glib?view=revisionrevision=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: GType typedef API/ABI break.
On Fri, 22 Jun 2007, Murray Cumming wrote: 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=5497r2=5560 With this ChangeLog entry: http://svn.gnome.org/viewcvs/glib?view=revisionrevision=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. hm, just to clarify explicitely, actual C ABI wasn't broken by this change. i guess we can workaround the C++ linking issues by reintroducing typedef gulong GType; if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T defined __cplusplus. that'll just leave C++ with bogus warnings about %zu again. -- Murray Cumming --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Thu, 21 Jun 2007, Elijah Newren wrote: 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? so far, my take on the issue is that PyGtk should adapt to that change by not using tooltips-tips_data_list, because: a) i haven't seen a single argument yet about why giving up using tips_data_list would be bad for PyGtk or any other application for that matter; b) GtkTooltips is going to be deprecated in 2.12 anyways, so there is little use in continuing to use it anyway. c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. Elijah --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GType typedef API/ABI break.
On Fri, 2007-06-22 at 10:05 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: 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=5497r2=5560 With this ChangeLog entry: http://svn.gnome.org/viewcvs/glib?view=revisionrevision=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. hm, just to clarify explicitely, actual C ABI wasn't broken by this change. I think that's debatable. I'd prefer to be careful than have to argue over every possible thing this could break. i guess we can workaround the C++ linking issues by reintroducing typedef gulong GType; if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T defined __cplusplus. that'll just leave C++ with bogus warnings about %zu again. I really don't like the idea of a typedef having one definition for C and another for C++. It seems destined to break something sometime in strange and obscure ways. What does %zu do? What bug does this solve? -- 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: Automake requirements for gtk+, glib
On Thu, 21 Jun 2007, Daniel Macks wrote: 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? no, i'm not aware of a consensus against automake-1.9, and that can probably be reasonably be expected by most developer systems these days. the same cannot be said of atuomake-1.10 though, so submitting patches that either upgrade our Makefiles to 1.9 or better yet, make them work with 1.7 *and* 1.9 would probably be the right way to go abnout such a change. in any case, note that an automake upgrade is rather unlikely to happen soon without patch submissions. dan --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: 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? so far, my take on the issue is that PyGtk should adapt to that change by not using tooltips-tips_data_list, because: a) i haven't seen a single argument yet about why giving up using tips_data_list would be bad for PyGtk or any other application for that matter; b) GtkTooltips is going to be deprecated in 2.12 anyways, so there is little use in continuing to use it anyway. c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. When was GtkTooltips::tips_data_list deprecated, if it was every public API? -- 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: GType typedef API/ABI break.
On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:05 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: 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. hm, just to clarify explicitely, actual C ABI wasn't broken by this change. I think that's debatable. I'd prefer to be careful than have to argue over every possible thing this could break. i guess we can workaround the C++ linking issues by reintroducing typedef gulong GType; if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T defined __cplusplus. that'll just leave C++ with bogus warnings about %zu again. I really don't like the idea of a typedef having one definition for C and another for C++. well, we've always had two definitions there (using long, allthough the effective GType width was always made sure to match GLIB_SIZEOF_SIZE_T). It seems destined to break something sometime in strange and obscure ways. aparently, at least for C++ (which of course wasn't intended by the change). What does %zu do? What bug does this solve? printf-ing a GType. so far, the correct way to print it would have been to use %lu if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T, and %zu (prints size_t) otherwise, allthough sizeof (GType) is guaranteed to always match sizeof (size_t) (not neccessarily sizeof (long)). -- Murray Cumming --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: b) GtkTooltips is going to be deprecated in 2.12 anyways, so there is little use in continuing to use it anyway. c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. When was GtkTooltips::tips_data_list deprecated, if it was every public API? reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 in favour of GtkTooltip. Murray Cumming --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GType typedef API/ABI break.
On Fri, 2007-06-22 at 10:40 +0200, Tim Janik wrote: What does %zu do? What bug does this solve? printf-ing a GType. so far, the correct way to print it would have been to use %lu if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T, and %zu (prints size_t) otherwise, allthough sizeof (GType) is guaranteed to always match sizeof (size_t) (not neccessarily sizeof (long)). This doesn't seem worth the risk. printfing a GType as a number isn't very useful or common, and people are used to typedefs having different definitions on different platforms. -- 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: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: b) GtkTooltips is going to be deprecated in 2.12 anyways, so there is little use in continuing to use it anyway. c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. When was GtkTooltips::tips_data_list deprecated, if it was every public API? reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 in favour of GtkTooltip. So, this is deprecation with a break. Breaking normally follows deprecation after a delay. Deprecation with a break is just a break. -- 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: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 11:03 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: b) GtkTooltips is going to be deprecated in 2.12 anyways, so there is little use in continuing to use it anyway. c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. When was GtkTooltips::tips_data_list deprecated, if it was every public API? reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 in favour of GtkTooltip. So, this is deprecation with a break. Breaking normally follows deprecation after a delay. Deprecation with a break is just a break. every change is a break in some sense. the question is whether the change actually affect applications badly or not (not what name is given to it). so far, no case has been made for tips_data_list=NULL badly affecting applications or LBs, i'm still waiting. I was talking about the renaming of the struct field, which breaks builds. If the rename is going to be reverted, and the change of behavior has no bad effect then that's fine. -- 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: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: b) GtkTooltips is going to be deprecated in 2.12 anyways, so there is little use in continuing to use it anyway. c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. When was GtkTooltips::tips_data_list deprecated, if it was every public API? reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 in favour of GtkTooltip. So, this is deprecation with a break. Breaking normally follows deprecation after a delay. Deprecation with a break is just a break. every change is a break in some sense. the question is whether the change actually affect applications badly or not (not what name is given to it). so far, no case has been made for tips_data_list=NULL badly affecting applications or LBs, i'm still waiting. Murray Cumming --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 11:03 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: b) GtkTooltips is going to be deprecated in 2.12 anyways, so there is little use in continuing to use it anyway. c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. When was GtkTooltips::tips_data_list deprecated, if it was every public API? reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 in favour of GtkTooltip. So, this is deprecation with a break. Breaking normally follows deprecation after a delay. Deprecation with a break is just a break. every change is a break in some sense. the question is whether the change actually affect applications badly or not (not what name is given to it). so far, no case has been made for tips_data_list=NULL badly affecting applications or LBs, i'm still waiting. I was talking about the renaming of the struct field, which breaks builds. If the rename is going to be reverted, and the change of behavior has no bad effect then that's fine. the structure field renaming is there to catch current third-party uses. that way we can gather feedback on field usage and figure if there are cases where the behavior change has bad effects. as for reverting the structure field rename, i don't think that is really necessary for 2.12. Gtk+ 2.x stable branches are supposed to be ABI and API compatible, however not neccessarily source compatible. when 2.12 deprecates GtkTooltips, the field is not anymore part of the API, ABI is maintained by its NULL assignment, and the source incompatibility is covered by README.in (as all source/API changes have to be). Murray Cumming --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 11:20 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 11:03 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote: On Fri, 22 Jun 2007, Murray Cumming wrote: On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: b) GtkTooltips is going to be deprecated in 2.12 anyways, so there is little use in continuing to use it anyway. c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. When was GtkTooltips::tips_data_list deprecated, if it was every public API? reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 in favour of GtkTooltip. So, this is deprecation with a break. Breaking normally follows deprecation after a delay. Deprecation with a break is just a break. every change is a break in some sense. the question is whether the change actually affect applications badly or not (not what name is given to it). so far, no case has been made for tips_data_list=NULL badly affecting applications or LBs, i'm still waiting. I was talking about the renaming of the struct field, which breaks builds. If the rename is going to be reverted, and the change of behavior has no bad effect then that's fine. the structure field renaming is there to catch current third-party uses. that way we can gather feedback on field usage and figure if there are cases where the behavior change has bad effects. as for reverting the structure field rename, i don't think that is really necessary for 2.12. Gtk+ 2.x stable branches are supposed to be ABI and API compatible, however not neccessarily source compatible. This is news to me, though similar things have been done before. I thought we had got better. when 2.12 deprecates GtkTooltips, the field is not anymore part of the API, ABI is maintained by its NULL assignment, and the source incompatibility is covered by README.in (as all source/API changes have to be). -- 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?
On Thu, 2007-21-06 at 20:25 -0500, Federico Mena Quintero wrote: 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. I agree with Federico here. It is impractical to black list engines, or certain engine and theme combinations. eg. there are a lot of engines affected by this particular bug (think of all the Clearlooks forks out there), but most themes do not set the style property so nothing happens. You would either end up blacklisting engines, or a large amount of engine/theme combinations. At the same time, it is not practical to push fixes made in gtk-engines to all the forks. (I don't even know what is out there.) 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. The gtk-engines make check torture test tests for this since some time now (which is loosely based on Manu Cornet's theme engine torturer). Benjamin signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Qui, 2007-06-21 at 23:39 -0300, Johan Dahlin wrote:
Joseph Sacco wrote:
The currently available version of pygtk is the stable branch. I would
expect the development branchof pygtk to adapt.
I'm ready to adapt but only if the general consent is that API changes
are okay.
My personal opinion is that the API shouldn't be allowed to change, once
an API is added it should stay stable until the major version is bumped
(3.0 in the case of gtk+).
I'm 100% with Johan on this one. Gtk+ 2.11.x broke API and ABI.
Before 2.11.x, the structure is:
struct _GtkTooltips
{
GtkObject parent_instance;
GtkWidget *tip_window;
GtkWidget *tip_label;
GtkTooltipsData *active_tips_data;
GList *tips_data_list;
guint delay : 30;
guint enabled : 1;
guint have_grab : 1;
guint use_sticky_delay : 1;
ginttimer_tag;
GTimeVal last_popdown;
};
None of these fields is marked private, therefore they are public.
Public fields are part of the API and cannot be changed as per GNOME
Developer Platform. Probably there is a way to introduce the new
tooltips without having to break the old tooltips API!
Just because pygtk _can_ adapt doesn't mean that it _should_.
In fact there are at least a couple of other changes in gtk+ 2.11.x that
break the API; we should really be more careful about these things...
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
The universe is always one step beyond logic. -- Frank Herbert
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Fri, Jun 22, 2007 at 02:04:17PM +0200, Benjamin Berg wrote: On Thu, 2007-21-06 at 20:25 -0500, Federico Mena Quintero wrote: 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. I don't think Morten's intent was to handle the blacklist at the application level. A more practical approach would be a bugbuddy extension that would compare the current theme engine and version against a central collection of known bad engines, aka a black list. Then a user could be notified at the time of the crash that the right solution is to stop using that theme. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
Gustavo J. A. M. Carneiro wrote:
On Qui, 2007-06-21 at 23:39 -0300, Johan Dahlin wrote:
Joseph Sacco wrote:
The currently available version of pygtk is the stable branch. I would
expect the development branchof pygtk to adapt.
I'm ready to adapt but only if the general consent is that API changes
are okay.
My personal opinion is that the API shouldn't be allowed to change, once
an API is added it should stay stable until the major version is bumped
(3.0 in the case of gtk+).
I'm 100% with Johan on this one. Gtk+ 2.11.x broke API and ABI.
The real test for this is if some one who has developed a GTK+ based
on GNOME 2.0
and now copy over the binary to GNOME 2.20, will it run?
If not, it is breaking ABI. Breaking ABI at GTK+ is not good.
You can fix the API by recompiling, but you can fix ABI if the user
doesn't have the code
to recompile or too complex to recompile which is likely to happen in
the real world.
-Ghee
Before 2.11.x, the structure is:
struct _GtkTooltips
{
GtkObject parent_instance;
GtkWidget *tip_window;
GtkWidget *tip_label;
GtkTooltipsData *active_tips_data;
GList *tips_data_list;
guint delay : 30;
guint enabled : 1;
guint have_grab : 1;
guint use_sticky_delay : 1;
gint timer_tag;
GTimeVal last_popdown;
};
None of these fields is marked private, therefore they are public.
Public fields are part of the API and cannot be changed as per GNOME
Developer Platform. Probably there is a way to introduce the new
tooltips without having to break the old tooltips API!
Just because pygtk _can_ adapt doesn't mean that it _should_.
In fact there are at least a couple of other changes in gtk+ 2.11.x that
break the API; we should really be more careful about these things...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 13:58 +0100, Gustavo J. A. M. Carneiro wrote:
On Qui, 2007-06-21 at 23:39 -0300, Johan Dahlin wrote:
Joseph Sacco wrote:
The currently available version of pygtk is the stable branch. I would
expect the development branchof pygtk to adapt.
I'm ready to adapt but only if the general consent is that API changes
are okay.
My personal opinion is that the API shouldn't be allowed to change, once
an API is added it should stay stable until the major version is bumped
(3.0 in the case of gtk+).
I'm 100% with Johan on this one. Gtk+ 2.11.x broke API and ABI.
Before 2.11.x, the structure is:
struct _GtkTooltips
{
GtkObject parent_instance;
GtkWidget *tip_window;
GtkWidget *tip_label;
GtkTooltipsData *active_tips_data;
GList *tips_data_list;
guint delay : 30;
guint enabled : 1;
guint have_grab : 1;
guint use_sticky_delay : 1;
gint timer_tag;
GTimeVal last_popdown;
};
None of these fields is marked private, therefore they are public.
Actually, that's not the convention in GTK+, though I doubt that it's
written down anywhere official. struct fields are private unless marked
as public. It's obviously difficult to know, and easy to make the
mistake.
But even if an app did something wrong, we should still avoid breaking
that app unnecessarily.
Public fields are part of the API and cannot be changed as per GNOME
Developer Platform. Probably there is a way to introduce the new
tooltips without having to break the old tooltips API!
Just because pygtk _can_ adapt doesn't mean that it _should_.
In fact there are at least a couple of other changes in gtk+ 2.11.x that
break the API; we should really be more careful about these things...
--
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: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On 6/22/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: so far, my take on the issue is that PyGtk should adapt to that change by not using tooltips-tips_data_list I have attached a patch to http://bugzilla.gnome.org/show_bug.cgi?id=449318 that removes access to private GtkTooltips struct members from the pygtk bindings. I can't tell if this will break any PyGTK apps but I guess that these bindings have only been added for the sake of completeness. Thats fine. Can we still please revert the field name change to make existing pygtk versions compile against 2.11.x ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
Hi, On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: so far, my take on the issue is that PyGtk should adapt to that change by not using tooltips-tips_data_list I have attached a patch to http://bugzilla.gnome.org/show_bug.cgi?id=449318 that removes access to private GtkTooltips struct members from the pygtk bindings. I can't tell if this will break any PyGTK apps but I guess that these bindings have only been added for the sake of completeness. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 22 Jun 2007, Tommi Komulainen wrote: On 6/22/07, Tim Janik [EMAIL PROTECTED] wrote: c) note that the actual compilation changes could easily be ironed out by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced deliberately, to catch remaining tips_data_list uses in third-party code which should be removed now, since tips_data_list became a mere alias for NULL for future Gtk+ versions. The real killer I suppose is the change in semantics. Otherwise you would've used tips_data_list vs. _tips_data_list depending on GTK_DISABLE_DEPRECATED ? yeah, additionally, *all* of GtkTooltips is going to be DEPRECTAED in 2.12, so we don't have the option deprecate uses of this one field only. -- Tommi Komulainen [EMAIL PROTECTED] --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Fri, 2007-06-22 at 09:20 -0400, Jody Goldberg wrote: I don't think Morten's intent was to handle the blacklist at the application level. A more practical approach would be a bugbuddy extension that would compare the current theme engine and version against a central collection of known bad engines, aka a black list. Then a user could be notified at the time of the crash that the right solution is to stop using that theme. This is certainly a nice idea --- although then people would need a newer version of BugBuddy ;) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Windows runtime and package Dev-Cpp for GTK+ 2.10.8
Dear all, I released a Windows runtime and a package for Dev-Cpp based on GTK+ 2.10.8. You can find this on : gtk.alkia.org Regards, Benoît Carpentier, GTKool - Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
