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 rewri
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 rep
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 *a
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 va
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
;s just one,
pointers and primitive types as out param if the function returns
multiple values. ("int get_x()" but "get_coords(int *x, int *y)")
Proposed way to move forward:
* if there's a sane path to fix all the current existing functions,
there must be a sane path to fix gtk_
reement in gtk-devel-list. Can anyone comment
on what was not liked, or how a better implementation could be made?
There was a lengthy #gtk+ discussion about this that could be dug out of
the archives. But I'll better summarize the original API motivation here:
GtkAllocation gtk_widget
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
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 g
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, siz
Hi,
On Fri, Apr 17, 2009 at 9:38 PM, Brian J. Tarricone 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
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
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
13 matches
Mail list logo
