Re: Using By-Value Compound Getters (Re: gtk_widget_get_allocation)
Havoc Pennington wrote: Not sure we need to block merge of get_allocation() on this major other patch to change the entire guideline. Changing the entire guideline will be a giant change and giant patch anyhow, so changing get_allocation() again will be a drop in the bucket. Can't such big repetitive changes be addressed through some user script the way 2to3.py does for python2 - python3 constructs for, say, the planned 3.0 ABI breakage ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using By-Value Compound Getters (Re: gtk_widget_get_allocation)
On Wed, 2009-04-22 at 11:37 +0200, Steve Frécinaux wrote: Can't such big repetitive changes be addressed through some user script the way 2to3.py does for python2 - python3 constructs for, say, the planned 3.0 ABI breakage ? Yes, I talked about this in my last email. There's a rewriter that will attempt to fix up C code for the transition. http://github.com/bratsche/clang/tree/gtkrewriter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using By-Value Compound Getters (Re: gtk_widget_get_allocation)
I think that using pass-by-value struct will bring more headache for language bindings developers, because this complicates ABI and not every language's foreign function interface supports passing structs by value. (I think that passing structs by value is not part of C language, but of C++ (or am I wrong?), so it is problematic to support) I would support having both kinds of accessors: simple ones (option a) and convenient for C (option b). Just the same as with other kinds of functions, e.g., g_object_get and g_object_get_property. One part of interface for convenience of C programming, one part for convenience of other languages. 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: Using By-Value Compound Getters (Re: gtk_widget_get_allocation)
On 04/21/2009 04:11 PM, Kalyanov Dmitry wrote: I think that using pass-by-value struct will bring more headache for language bindings developers, because this complicates ABI and not every language's foreign function interface supports passing structs by value. (I think that passing structs by value is not part of C language, but of C++ (or am I wrong?), I think you are wrong. behdad so it is problematic to support) I would support having both kinds of accessors: simple ones (option a) and convenient for C (option b). Just the same as with other kinds of functions, e.g., g_object_get and g_object_get_property. One part of interface for convenience of C programming, one part for convenience of other languages. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using By-Value Compound Getters (Re: gtk_widget_get_allocation)
On Tue, 2009-04-21 at 20:00 +0200, Tim Janik wrote: To sum up our getter options: a) /* force adding lots of helper variables into user code */ void gtk_widget_get_allocation (GtkWidget *widget, GtkAllocation *allocation); b) /* convenient access, no garbage collection problem */ GtkAllocation gtk_widget_get_allocation (GtkWidget *widget); c) /* tie ourselves into always keeping the handed out GtkAllocation * allocated in the widget, which can be different from the * actual widget-allocation. */ const GtkAllocation* gtk_widget_get_allocation (GtkWidget *widget); d) /* force caller to free returned allocation, most often forces * an extra GtkAllocation *helper; variable. */ GtkAllocation* /*freeme*/ gtk_widget_get_allocation (GtkWidget *widget); Thanks Tim, I don't have a strong opinion on this between options A and B. But I am trying to push forward with getting things in shape for a 3.0 branch, and this is a blocker so I'm hoping this thread can lead to a decision. Whichever option is chosen, I can prepare a patch that includes it as well as fixing all instances of foo-allocation to use the new style API. Same applies to GtkRequisition, so once some consensus can be made then I'll prepare branches to fix up all of gtk+ to use the new API. fwiw, I'm not a fan of options C or D. In the past few days I've been doing some work on enhancing Richard Hult's code rewriter. It was capable of rewriting code using option B already, and I've since improved it so that if option A is chosen it can work with that by injecting new variables to the top of the function and calling the get-by-reference accessor. As I go through more of the GSEAL deprecations I can continue to improve the code rewriter to fit new patterns in the API. Right now there are still issues with nested macros, and after an email with Richard he says he believes this is fixable using the latest llvm/clang (which I'm using now, I just need to figure out how to fix this issue using it). So far I've held off really blogging about my improvements to the rewriter until I can solve the nested macro issues, but for anyone interested I have posted my repo to github [1]. I believe we'll also need a gtk_widget_set_allocation() to be used in size_allocate() implementations; I guess the two options are a: set_allocation(GtkWidget*, GtkAllocation*) or b: set_allocation(GtkWidget*, GtkAllocation) So while we're discussing the get method, please consider the set method as well. Thanks everyone, Cody [1]. http://github.com/bratsche/clang/tree/gtkrewriter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_get_allocation
Cody Russell wrote: * gtk_widget_get_allocation Removed in 2.14.1 The prototype of this function was not agreed upon among the core developers. So the decision was deferred to the next Gtk version. It had to be removed before final API freeze, otherwise it could not have been changed anymore. This is rather old, but it never came up again after this so I'd like to see what thoughts are about how to implement this in C. It was in 2.13 but removed before 2.14 because of disagreement, but I can't find any public record of the disagreement in gtk-devel-list. Can anyone comment on what was not liked, or how a better implementation could be made? Here's the old discussion: http://bugzilla.gnome.org/show_bug.cgi?id=548052. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_widget_get_allocation
On Thu, 2008-09-25 at 02:02 +0200, Christian Dywan wrote:
* gtk_widget_get_allocation
Removed in 2.14.1
The prototype of this function was not agreed upon among the core
developers. So the decision was deferred to the next Gtk version.
It had to be removed before final API freeze, otherwise it could not
have been changed anymore.
This is rather old, but it never came up again after this so I'd like to
see what thoughts are about how to implement this in C. It was in 2.13
but removed before 2.14 because of disagreement, but I can't find any
public record of the disagreement in gtk-devel-list. Can anyone comment
on what was not liked, or how a better implementation could be made?
For reference, this is the previous implementation:
GtkAllocation
gtk_widget_get_allocation (GtkWidget *widget)
{
static GtkAllocation allocation = { 0 };
g_return_val_if_fail (GTK_IS_WIDGET (widget), allocation);
return widget-allocation;
}
/ Cody
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_get_allocation
Cody Russell wrote:
On Thu, 2008-09-25 at 02:02 +0200, Christian Dywan wrote:
* gtk_widget_get_allocation
Removed in 2.14.1
The prototype of this function was not agreed upon among the core
developers. So the decision was deferred to the next Gtk version.
It had to be removed before final API freeze, otherwise it could not
have been changed anymore.
This is rather old, but it never came up again after this so I'd like to
see what thoughts are about how to implement this in C. It was in 2.13
but removed before 2.14 because of disagreement, but I can't find any
public record of the disagreement in gtk-devel-list. Can anyone comment
on what was not liked, or how a better implementation could be made?
For reference, this is the previous implementation:
GtkAllocation
gtk_widget_get_allocation (GtkWidget *widget)
{
static GtkAllocation allocation = { 0 };
g_return_val_if_fail (GTK_IS_WIDGET (widget), allocation);
return widget-allocation;
}
I assume the issue was with returning a non-primitive type by-value and
not as a pointer. For modern compilers this isn't a big deal, I don't
think (but might be inefficient on some arches), but I imagine people
want to compile gtk on all sorts of systems. An implementation like
this avoids that problem, though perhaps isn't as nice to use[1]:
void
gtk_widget_get_allocation (GtkWidget *widget,
GtkAllocation *allocation)
{
g_return_if_fail (GTK_IS_WIDGET (widget) allocation);
memcpy (allocation, widget-allocation, sizeof(*allocation));
}
(Could also have it return gboolean, but I tend to think it's
unnecessary to have a success/fail return value when the only reason it
would fail is if the programmer is using the function incorrectly.)
This seems to be a similar pattern to how other things like this are
done in gtk...
-brian
[1] I guess part of the motivation for the original (rejected)
implementation is so that you can do things like this:
gint width = gtk_widget_get_allocation (widget).width;
Oh well.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_get_allocation
Hi,
On Fri, Apr 17, 2009 at 9:38 PM, Brian J. Tarricone bj...@cornell.edu wrote:
I assume the issue was with returning a non-primitive type by-value and not
as a pointer.
Right. The normal way in glib/gtk would definitely be as you say.
void
gtk_widget_get_allocation (GtkWidget *widget,
GtkAllocation *allocation)
{
g_return_if_fail (GTK_IS_WIDGET (widget) allocation);
but this should be two separate checks
memcpy (allocation, widget-allocation, sizeof(*allocation));
and just:
*allocation = widget-allocation;
should be fine.
Presumably some core gtk dev was arguing for the weird way though or
someone would have just fixed it ;-)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_get_allocation
On 04/17/2009 09:38 PM, Brian J. Tarricone wrote:
void
gtk_widget_get_allocation (GtkWidget *widget,
GtkAllocation *allocation)
{
g_return_if_fail (GTK_IS_WIDGET (widget) allocation);
memcpy (allocation, widget-allocation, sizeof(*allocation));
}
(Could also have it return gboolean, but I tend to think it's
unnecessary to have a success/fail return value when the only reason it
would fail is if the programmer is using the function incorrectly.)
I don't think it needs a boolean given the condition. Previously it was
being accessed by dereferencing the struct field.
So as you say the only it would fail it because it is used incorrectly.
In that case, it wouldn't crash, unlike before when accessing the struct
fields.
Hub
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_get_allocation
On 04/17/2009 09:02 PM, Cody Russell wrote: This is rather old, but it never came up again after this so I'd like to see what thoughts are about how to implement this in C. It was in 2.13 but removed before 2.14 because of disagreement, but I can't find any public record of the disagreement in gtk-devel-list. Can anyone comment on what was not liked, or how a better implementation could be made? It should be noted that this one was a major showstopper for me to build AbiWord with GSEAL enabled. And the more we wait to have this implement, the more it will be a problem. Currently some basic accessor (gtk_widget_get_window() for example) are only in Gtk 2.14. This is already a big issue to write code that work with GSEAL and still work with earlier version of Gtk. Gtk 2.14 is still not that common even more on Enterprise distributions. I know there are some hack that can be done (been there, done that), but still. And today everything that touch flags or allocation is a no go. Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
