Hi,
The way I've always thought about the floating flag is that when you
create a new object, *you* don't own a reference. Instead, there's a
floating reference with no owner, and anyone is allowed to remove that
floating reference since it's community property - the if floating
exists remove it
On Sat, 17 Dec 2005, Dave Benson wrote:
On Thu, Dec 15, 2005 at 05:07:34PM +0100, Tim Janik wrote:
On Thu, 15 Dec 2005, Dave Benson wrote:
[long discussion cut]
this thread never really addressed my concern,
which was that this makes it so that container classes
before 2.10 have one style,
On Tue, 2005-12-20 at 17:27 +0100, Tim Janik wrote:
GObject:
- created with ref_count=1
- not initially floating
This is the key I think. The point of my theoretical rant is that I
think it's really bad if I do:
obj = g_object_new(TYPE_WHATEVER);
and don't know whether I own a refcount or
On Tue, 2005-12-20 at 09:37 -0800, Dave Benson wrote:
why does one want GFloatingObject?
it seems like calling g_object_force_floating()
isn't too hard... and derivation is a somewhat
inflexible way to set flags (for example, it
can't be done in a subsubclass of object;
and to support N
Havoc Pennington wrote:
On Tue, 2005-12-20 at 17:27 +0100, Tim Janik wrote:
GObject:
- created with ref_count=1
- not initially floating
This is the key I think. The point of my theoretical rant is that I
think it's really bad if I do:
obj = g_object_new(TYPE_WHATEVER);
and don't
On Sat, 2005-12-17 at 05:21 -0600, Yevgen Muntyan wrote:
Tim Janik wrote:
On Fri, 16 Dec 2005, Murray Cumming wrote:
Thanks. But this is not completely clear to me yet.
Will applications built against gtk+ 2.6 work when gtk+ 2.10 is
installed, without rebuilding the applications?
Thanks. But this is not completely clear to me yet.
Will applications built against gtk+ 2.6 work when gtk+ 2.10 is
installed, without rebuilding the applications?
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
gtk-devel-list
On Fri, 16 Dec 2005, Murray Cumming wrote:
Thanks. But this is not completely clear to me yet.
Will applications built against gtk+ 2.6 work when gtk+ 2.10 is
installed, without rebuilding the applications?
yes.
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
---
Tim Janik wrote:
On Fri, 16 Dec 2005, Murray Cumming wrote:
Thanks. But this is not completely clear to me yet.
Will applications built against gtk+ 2.6 work when gtk+ 2.10 is
installed, without rebuilding the applications?
yes.
But old libgtkmm binary and applications that use it will
On Thu, 15 Dec 2005, Yevgen Muntyan wrote:
Tim Janik wrote:
ok so there is a reason. a desire (by multiple users and projects
actually) to implement that flag and a possibility (as was found out
in the original thread on this subject already).
Nobody so far said that objects with floating
Tim Janik wrote:
Nobody so far said that objects with floating reference in glib is
not needed.
But what about Murray idea, to create separate class; or, along same
lines,
that wouldn't change a thing. if you had a GFLoatableObject, you'd still
want to derive GtkObject from it, so you may
and API for g_object_ref_sink() (Re: GTK_FLOATING broken in 2.9?)
has the exact details on why/what the compat details are for particular gtk/glib
versions.
don't worry, be happy ;)
Yevgen
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list
),
will
be broken again, and in worse way. If not, well, I will sleep well :)
my initial email:
Subject: ABI and API for g_object_ref_sink() (Re: GTK_FLOATING broken
in 2.9?)
has the exact details on why/what the compat details are for
particular gtk/glib
versions.
It doesn't address issue
in CVS
doesn't adress this, which is why Murray Cumming started the GTK_FLOATING
broken in 2.9? thread.
the ABI and API for g_object_ref_sink() thread adresses this issue by
providing a proposed solution and an analysis of the impact on various
glib/gtk version combinations.
don't worry, be happy
On Wed, 14 Dec 2005, Federico Mena Quintero wrote:
On Tue, 2005-12-13 at 16:57 +0100, Tim Janik wrote:
right, since the floating flag is stored in GObject in 2.9, so altering
the GtkObject won't have any effect.
From the point of view of the release team, We Cannot Break Existing
Code(tm).
On Wed, 14 Dec 2005, Morten Welinder wrote:
before starting to investigate in ugly hacks to continue maintaining the
current GTK_FLOATING semantics with GtkObject, i'd really like to raise
the issue that people/langauge bnindings most probably never should be
setting GTK_FLOATING with
On Wed, 14 Dec 2005, Dave Benson wrote:
people who want floating flags could always derive from GtkObject if they
don't want to reimplement it...
this is not an option for glib-only programs.
- dave
---
ciaoTJ
___
gtk-devel-list mailing list
On Thu, 15 Dec 2005, Yevgen Muntyan wrote:
ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
When you are calling your own code, it is not that much to keep track of,
but when I write code that is used by 1000 developers it is much easier for
me to take care of the reference issues inside the API
Tim Janik wrote:
On Thu, 15 Dec 2005, Yevgen Muntyan wrote:
ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
When you are calling your own code, it is not that much to keep
track of, but when I write code that is used by 1000 developers it
is much easier for me to take care of the reference
Yevgen Muntyan wrote:
New code:
object = fancy_not_gtk_object_new();
g_object_ref_sink(object); /* because I don't know what will container do */
fancy_container_add(container, object);
g_object_unref(object);
What I want the container code to do is assert if an object is not floating, and
ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
What I want the container code to do is assert if an object is not floating, and
ref_sink internally. So the user's code will look like:
object = fancy_not_gtk_object_new();
fancy_container_add(container, object);
Exactly! Code of *your* users
On Dec 15, 2005, at 9:40 AM, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN
wrote:
What I want the container code to do is assert if an object is not
floating, and
ref_sink internally.
That would cause assertions on reparented objects, unless you added a
re-float capability (which i
On Thu, 15 Dec 2005, Murray Cumming wrote:
On Thu, 2005-12-15 at 12:47 +0100, Tim Janik wrote:
please read:
http://mail.gnome.org/archives/gtk-devel-list/2005-September/msg00165.html
and the associated thread which provides the original rationale.
So, it this feature is being added to
On Thu, Dec 15, 2005 at 12:49:45PM +0100, Tim Janik wrote:
On Wed, 14 Dec 2005, Morten Welinder wrote:
before starting to investigate in ugly hacks to continue maintaining the
current GTK_FLOATING semantics with GtkObject, i'd really like to raise
the issue that people/langauge bnindings
On Thu, 15 Dec 2005, Yevgen Muntyan wrote:
I apologize for junk-posting, I'll learn to use mozilla next time.
Tim Janik wrote:
it's language bindings and container implementations that do this.
the floating flag is actually meant to make it easier on the user as
outlined in:
Let me expand
On Thu, 15 Dec 2005, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
Yevgen Muntyan wrote:
New code:
object = fancy_not_gtk_object_new();
g_object_ref_sink(object); /* because I don't know what will container do */
fancy_container_add(container, object);
g_object_unref(object);
What I want
Could we at the type-level have a flag controlling whether the glib-
level should create a floating ref or a pre-sinked ref?
Anything derived from GtkObject could then set it to pre-sinked
and GTK+ could do its own floating ref handling. That ought to
ensure ABI compatibility, but would it do
On Thu, 15 Dec 2005, Morten Welinder wrote:
Could we at the type-level have a flag controlling whether the glib-
level should create a floating ref or a pre-sinked ref?
that wouldn't quite work out i think.
Anything derived from GtkObject could then set it to pre-sinked
and GTK+ could do
On Thu, 15 Dec 2005, Dave Benson wrote:
There is no problem in this combination. GTK+ 2.8 continues to use the
GtkObject floating flag,
and does not care about the GObject floating flag at all. We decided to
allow finalizing floating GObjects,
so there is no problem.
as long as no-one
On Thu, 15 Dec 2005, Dave Benson wrote:
On Fri, Dec 16, 2005 at 12:29:18AM +0100, Tim Janik wrote:
i think this is a good enough compromise. we'll allow potential breakage
if applications/libraries don't care to implement their dependencies
properly. i hope that is weak enough to not occour or
Tim Janik wrote:
ok so there is a reason. a desire (by multiple users and projects
actually) to implement that flag and a possibility (as was found out
in the original thread on this subject already).
Nobody so far said that objects with floating reference in glib is not
needed.
But what
Murray Cumming wrote:
Murray Cumming wrote:
On Tue, 13 Dec 2005, Murray Cumming wrote:
In GTK+ 2.9, GTK_FLOATING is deprecated and README.in states that it
can
no longer be used to detect floating objects. I hope nobody is using
that. I assume that effort was made to avoid
On Wed, 14 Dec 2005, Murray Cumming wrote:
Murray Cumming wrote:
On Tue, 13 Dec 2005, Murray Cumming wrote:
In GTK+ 2.9, GTK_FLOATING is deprecated and README.in states that it
can
no longer be used to detect floating objects. I hope nobody is using
that. I assume that effort was made
could you please outline why you need this in GtkMM
By default, gtkmm _Widgets_ are not owned by their containers, because
that would not allow regular C++ memory management. For instance:
Gtk::VBox* box1 = new Gtk::VBox;
Gtk::Button button(Hello);
box1.pack_start(button); //The button is in
On 12/14/05, Tim Janik [EMAIL PROTECTED] wrote:
On Tue, 13 Dec 2005, Matthias Clasen wrote: On 12/13/05, Murray Cumming [EMAIL PROTECTED] wrote: gtkmm
2.8 depends on glib/gtk 2.8, right? then you don't have g_object_force_floating() there. would it be of any help to you if glib 2.8 had
Tim Janik said:
so, could you please outline why you need this in GtkMM (especially
considering that james gets along without it in python)?
metooThe perl bindings also sink all GtkObjects that get a perl wrapper
attached, as the perl wrapper holds a real reference in all cases, and owns
the
On Wed, 2005-12-14 at 13:42 -0600, Federico Mena Quintero wrote:
From the point of view of the release team, We Cannot Break Existing
Code(tm).
By corollary, we need to avoid doing interesting stuff in macros, since
they essentially embed parts of the ABI in compiled code. We already
had one
The problem you are thinking about is probably the fact that g_return_if_fail is a very widely used macro that started to use a new symbol at some point,g_return_if_fail_warning(), thus immediately making everything compiled against the new glib depend on the new ABI.
Matthias
On Wed, 2005-12-14 at 14:51 -0500, Matthias Clasen wrote:
The problem you are thinking about is probably the fact that
g_return_if_fail is a very widely used macro that started to use a new
symbol at some point,
g_return_if_fail_warning(), thus immediately making everything
compiled against
On Wed, 2005-12-14 at 14:56 -0500, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN
wrote:
Yes, we do really need the floating reference. There is no reason to
discourage
the code you mentioned when you want to make reusable container objects that
have a sane API without requiring the caller to do a
On 12/14/05, Federico Mena Quintero [EMAIL PROTECTED] wrote:
Okay.So how do we do it without breaking the ABI?The fact that this ABI is so low down in the stack means that thingsbecome *really hard* in the upper layers.How do we build applications against a new Glib (without using new
APIs),
ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
When you are calling your own code, it is not that
much to keep track of, but when I write code that is used by 1000 developers it
is much easier for me to take care of the reference issues inside the API and
make the large group of unknown
In GTK+ 2.9, GTK_FLOATING is deprecated and README.in states that it can
no longer be used to detect floating objects. I hope nobody is using
that. I assume that effort was made to avoid this ABI breakage.
But does this also mean that setting GTK_FLOATING has no effect with
2.9? We do use this in
On Tue, 13 Dec 2005, Murray Cumming wrote:
In GTK+ 2.9, GTK_FLOATING is deprecated and README.in states that it can
no longer be used to detect floating objects. I hope nobody is using
that. I assume that effort was made to avoid this ABI breakage.
But does this also mean that setting
Le mardi 13 décembre 2005 à 11:44 -0500, Matthias Clasen a écrit :
On 12/13/05, Murray Cumming [EMAIL PROTECTED] wrote:
gtkmm 2.8 depends on glib/gtk 2.8, right? then you don't
have
g_object_force_floating() there. would it be of any help to
45 matches
Mail list logo
