1997-11-24 22:37:52 +00:00
|
|
|
/* GTK - The GIMP Toolkit
|
|
|
|
* Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Library General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Library General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Library General Public
|
|
|
|
* License along with this library; if not, write to the Free
|
|
|
|
* Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
*/
|
|
|
|
#include <stdarg.h>
|
|
|
|
#include "gtksignal.h"
|
|
|
|
|
|
|
|
|
|
|
|
#define MAX_PARAMS 20
|
|
|
|
#define DONE 1
|
|
|
|
#define RESTART 2
|
|
|
|
|
|
|
|
#define GTK_RUN_TYPE(x) ((x) & GTK_RUN_MASK)
|
|
|
|
|
|
|
|
|
|
|
|
typedef struct _GtkSignal GtkSignal;
|
|
|
|
typedef struct _GtkSignalInfo GtkSignalInfo;
|
1998-02-10 23:49:15 +00:00
|
|
|
typedef struct _GtkHandler GtkHandler;
|
1997-11-24 22:37:52 +00:00
|
|
|
typedef struct _GtkHandlerInfo GtkHandlerInfo;
|
|
|
|
typedef struct _GtkEmission GtkEmission;
|
|
|
|
|
|
|
|
typedef void (*GtkSignalMarshaller0) (GtkObject *object,
|
|
|
|
gpointer data);
|
|
|
|
|
|
|
|
struct _GtkSignalInfo
|
|
|
|
{
|
|
|
|
gchar *name;
|
1998-03-09 15:16:28 +00:00
|
|
|
GtkType object_type;
|
|
|
|
guint signal_type;
|
1997-11-24 22:37:52 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct _GtkSignal
|
|
|
|
{
|
|
|
|
GtkSignalInfo info;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint function_offset;
|
1997-11-24 22:37:52 +00:00
|
|
|
GtkSignalRunType run_type;
|
|
|
|
GtkSignalMarshaller marshaller;
|
|
|
|
GtkType return_val;
|
|
|
|
GtkType *params;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint nparams;
|
1997-11-24 22:37:52 +00:00
|
|
|
};
|
|
|
|
|
1998-02-10 23:49:15 +00:00
|
|
|
struct _GtkHandler
|
|
|
|
{
|
|
|
|
guint id : 28;
|
|
|
|
guint blocked : 1;
|
|
|
|
guint object_signal : 1;
|
|
|
|
guint after : 1;
|
|
|
|
guint no_marshal : 1;
|
|
|
|
guint16 ref_count;
|
|
|
|
guint16 signal_type;
|
|
|
|
GtkSignalFunc func;
|
|
|
|
gpointer func_data;
|
|
|
|
GtkSignalDestroy destroy_func;
|
|
|
|
GtkHandler *prev;
|
|
|
|
GtkHandler *next;
|
|
|
|
};
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
struct _GtkHandlerInfo
|
|
|
|
{
|
|
|
|
GtkObject *object;
|
|
|
|
GtkSignalMarshaller marshaller;
|
|
|
|
GtkArg *params;
|
|
|
|
GtkType *param_types;
|
|
|
|
GtkType return_val;
|
|
|
|
GtkSignalRunType run_type;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint nparams;
|
|
|
|
guint signal_type;
|
1997-11-24 22:37:52 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct _GtkEmission
|
|
|
|
{
|
|
|
|
GtkObject *object;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type;
|
1997-11-24 22:37:52 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
static void gtk_signal_init (void);
|
1998-03-09 15:16:28 +00:00
|
|
|
static guint gtk_signal_hash (guint *key);
|
|
|
|
static gint gtk_signal_compare (guint *a,
|
|
|
|
guint *b);
|
1997-11-24 22:37:52 +00:00
|
|
|
static guint gtk_signal_info_hash (GtkSignalInfo *a);
|
|
|
|
static gint gtk_signal_info_compare (GtkSignalInfo *a,
|
|
|
|
GtkSignalInfo *b);
|
|
|
|
static GtkHandler* gtk_signal_handler_new (void);
|
1998-01-30 23:47:09 +00:00
|
|
|
static void gtk_signal_handler_ref (GtkHandler *handler);
|
|
|
|
static void gtk_signal_handler_unref (GtkHandler *handler,
|
|
|
|
GtkObject *object);
|
1997-11-24 22:37:52 +00:00
|
|
|
static void gtk_signal_handler_insert (GtkObject *object,
|
|
|
|
GtkHandler *handler);
|
1998-01-30 23:47:09 +00:00
|
|
|
static void gtk_signal_real_emit (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type,
|
1997-11-24 22:37:52 +00:00
|
|
|
va_list args);
|
1998-02-10 23:49:15 +00:00
|
|
|
static GtkHandler* gtk_signal_get_handlers (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type);
|
|
|
|
static guint gtk_signal_connect_by_type (GtkObject *object,
|
|
|
|
guint signal_type,
|
1997-11-24 22:37:52 +00:00
|
|
|
GtkSignalFunc func,
|
|
|
|
gpointer func_data,
|
|
|
|
GtkSignalDestroy destroy_func,
|
1998-02-13 05:19:06 +00:00
|
|
|
gint object_signal,
|
1997-11-24 22:37:52 +00:00
|
|
|
gint after,
|
|
|
|
gint no_marshal);
|
|
|
|
static GtkEmission* gtk_emission_new (void);
|
|
|
|
static void gtk_emission_destroy (GtkEmission *emission);
|
|
|
|
static void gtk_emission_add (GList **emissions,
|
|
|
|
GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type);
|
1997-11-24 22:37:52 +00:00
|
|
|
static void gtk_emission_remove (GList **emissions,
|
|
|
|
GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type);
|
1997-11-24 22:37:52 +00:00
|
|
|
static gint gtk_emission_check (GList *emissions,
|
|
|
|
GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type);
|
1997-11-24 22:37:52 +00:00
|
|
|
static gint gtk_handlers_run (GtkHandler *handlers,
|
|
|
|
GtkHandlerInfo *info,
|
|
|
|
gint after);
|
|
|
|
static void gtk_params_get (GtkArg *params,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint nparams,
|
1997-11-24 22:37:52 +00:00
|
|
|
GtkType *param_types,
|
|
|
|
GtkType return_val,
|
|
|
|
va_list args);
|
|
|
|
|
|
|
|
|
|
|
|
static gint initialize = TRUE;
|
|
|
|
static GHashTable *signal_hash_table = NULL;
|
|
|
|
static GHashTable *signal_info_hash_table = NULL;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
static guint next_signal = 1;
|
|
|
|
static guint next_handler_id = 1;
|
1997-11-24 22:37:52 +00:00
|
|
|
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
static const gchar *handler_key = "gtk-signal-handlers";
|
1998-03-14 04:43:14 +00:00
|
|
|
static guint handler_key_id = 0;
|
1997-11-24 22:37:52 +00:00
|
|
|
|
|
|
|
static GMemChunk *handler_mem_chunk = NULL;
|
|
|
|
static GMemChunk *emission_mem_chunk = NULL;
|
|
|
|
|
|
|
|
static GList *current_emissions = NULL;
|
|
|
|
static GList *stop_emissions = NULL;
|
|
|
|
static GList *restart_emissions = NULL;
|
|
|
|
|
|
|
|
static GtkSignalMarshal marshal = NULL;
|
|
|
|
static GtkSignalDestroy destroy = NULL;
|
|
|
|
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_new (const gchar *name,
|
|
|
|
GtkSignalRunType run_type,
|
1998-03-09 15:16:28 +00:00
|
|
|
GtkType object_type,
|
|
|
|
guint function_offset,
|
1997-11-24 22:37:52 +00:00
|
|
|
GtkSignalMarshaller marshaller,
|
|
|
|
GtkType return_val,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint nparams,
|
1997-11-24 22:37:52 +00:00
|
|
|
...)
|
|
|
|
{
|
|
|
|
GtkType *params;
|
1998-01-29 20:44:14 +00:00
|
|
|
guint i;
|
|
|
|
va_list args;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint return_id;
|
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
g_return_val_if_fail (nparams < 16, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
if (nparams > 0)
|
|
|
|
{
|
|
|
|
params = g_new (GtkType, nparams);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
va_start (args, nparams);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
for (i = 0; i < nparams; i++)
|
|
|
|
params[i] = va_arg (args, GtkType);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
va_end (args);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
params = NULL;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
return_id = gtk_signal_newv (name,
|
|
|
|
run_type,
|
|
|
|
object_type,
|
|
|
|
function_offset,
|
|
|
|
marshaller,
|
|
|
|
return_val,
|
|
|
|
nparams,
|
|
|
|
params);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
g_free (params);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
return return_id;
|
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1998-01-29 20:44:14 +00:00
|
|
|
gtk_signal_newv (const gchar *name,
|
|
|
|
GtkSignalRunType run_type,
|
1998-03-09 15:16:28 +00:00
|
|
|
GtkType object_type,
|
|
|
|
guint function_offset,
|
1998-01-29 20:44:14 +00:00
|
|
|
GtkSignalMarshaller marshaller,
|
|
|
|
GtkType return_val,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint nparams,
|
1998-01-29 20:44:14 +00:00
|
|
|
GtkType *params)
|
|
|
|
{
|
1997-11-24 22:37:52 +00:00
|
|
|
GtkSignal *signal;
|
|
|
|
GtkSignalInfo info;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint *type;
|
1998-01-29 20:44:14 +00:00
|
|
|
guint i;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (name != NULL, 0);
|
|
|
|
g_return_val_if_fail (marshaller != NULL, 0);
|
1998-01-29 20:44:14 +00:00
|
|
|
g_return_val_if_fail (nparams < 16, 0);
|
|
|
|
if (nparams)
|
|
|
|
g_return_val_if_fail (params != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
info.name = (char*)name;
|
|
|
|
info.object_type = object_type;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = g_hash_table_lookup (signal_info_hash_table, &info);
|
|
|
|
if (type)
|
|
|
|
{
|
1998-03-08 10:41:48 +00:00
|
|
|
g_warning ("gtk_signal_newv(): signal \"%s\" already exists in the `%s' class ancestry\n",
|
1997-11-24 22:37:52 +00:00
|
|
|
name, gtk_type_name (object_type));
|
|
|
|
return 0;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
signal = g_new (GtkSignal, 1);
|
1998-01-29 20:44:14 +00:00
|
|
|
signal->info.name = g_strdup (name);
|
1997-11-24 22:37:52 +00:00
|
|
|
signal->info.object_type = object_type;
|
|
|
|
signal->info.signal_type = next_signal++;
|
|
|
|
signal->function_offset = function_offset;
|
|
|
|
signal->run_type = run_type;
|
|
|
|
signal->marshaller = marshaller;
|
|
|
|
signal->return_val = return_val;
|
|
|
|
signal->nparams = nparams;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (nparams > 0)
|
|
|
|
{
|
|
|
|
signal->params = g_new (GtkType, nparams);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
for (i = 0; i < nparams; i++)
|
1998-01-29 20:44:14 +00:00
|
|
|
signal->params[i] = params[i];
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-01-29 20:44:14 +00:00
|
|
|
else
|
|
|
|
signal->params = NULL;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
g_hash_table_insert (signal_hash_table, &signal->info.signal_type, signal);
|
|
|
|
g_hash_table_insert (signal_info_hash_table, &signal->info, &signal->info.signal_type);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
return signal->info.signal_type;
|
|
|
|
}
|
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
GtkSignalQuery*
|
1998-03-09 15:16:28 +00:00
|
|
|
gtk_signal_query (guint signal_id)
|
1998-01-29 20:44:14 +00:00
|
|
|
{
|
|
|
|
GtkSignalQuery *query;
|
|
|
|
GtkSignal *signal;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
g_return_val_if_fail (signal_id >= 1, NULL);
|
|
|
|
|
|
|
|
signal = g_hash_table_lookup (signal_hash_table, &signal_id);
|
1998-01-29 20:44:14 +00:00
|
|
|
if (signal)
|
|
|
|
{
|
|
|
|
query = g_new (GtkSignalQuery, 1);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
query->object_type = signal->info.object_type;
|
1998-03-09 15:16:28 +00:00
|
|
|
query->signal_id = signal_id;
|
1998-01-29 20:44:14 +00:00
|
|
|
query->signal_name = signal->info.name;
|
|
|
|
query->is_user_signal = signal->function_offset == 0;
|
|
|
|
query->run_type = signal->run_type;
|
|
|
|
query->return_val = signal->return_val;
|
|
|
|
query->nparams = signal->nparams;
|
|
|
|
query->params = signal->params;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
query = NULL;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-29 20:44:14 +00:00
|
|
|
return query;
|
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_lookup (const gchar *name,
|
1998-03-09 15:16:28 +00:00
|
|
|
GtkType object_type)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
GtkSignalInfo info;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (name != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
g_return_val_if_fail (gtk_type_is_a (object_type, GTK_TYPE_OBJECT), 0);
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
info.name = (char*)name;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
while (object_type)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
guint *type;
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
info.object_type = object_type;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = g_hash_table_lookup (signal_info_hash_table, &info);
|
|
|
|
if (type)
|
|
|
|
return *type;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
object_type = gtk_type_parent (object_type);
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
gchar*
|
1998-03-09 15:16:28 +00:00
|
|
|
gtk_signal_name (guint signal_id)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
GtkSignal *signal;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
g_return_val_if_fail (signal_id >= 1, NULL);
|
|
|
|
|
|
|
|
signal = g_hash_table_lookup (signal_hash_table, &signal_id);
|
1997-11-24 22:37:52 +00:00
|
|
|
if (signal)
|
|
|
|
return signal->info.name;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
void
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_emit (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_id,
|
1997-11-24 22:37:52 +00:00
|
|
|
...)
|
|
|
|
{
|
|
|
|
va_list args;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
g_return_if_fail (signal_id >= 1);
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
va_start (args, signal_id);
|
|
|
|
|
|
|
|
gtk_signal_real_emit (object, signal_id, args);
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
va_end (args);
|
|
|
|
}
|
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
void
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_emit_by_name (GtkObject *object,
|
|
|
|
const gchar *name,
|
|
|
|
...)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
guint type;
|
1997-11-24 22:37:52 +00:00
|
|
|
va_list args;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
g_return_if_fail (name != NULL);
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = gtk_signal_lookup (name, GTK_OBJECT_TYPE (object));
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
if (type >= 1)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
va_start (args, name);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
gtk_signal_real_emit (object, type, args);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
va_end (args);
|
|
|
|
}
|
1998-03-08 10:41:48 +00:00
|
|
|
else
|
|
|
|
{
|
|
|
|
g_warning ("gtk_signal_emit_by_name(): could not find signal \"%s\" in the `%s' class ancestry",
|
|
|
|
name, gtk_type_name (GTK_OBJECT_TYPE (object)));
|
|
|
|
}
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_emit_stop (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_id)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
g_return_if_fail (signal_id >= 1);
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
if (gtk_emission_check (current_emissions, object, signal_id))
|
|
|
|
gtk_emission_add (&stop_emissions, object, signal_id);
|
1998-03-08 10:41:48 +00:00
|
|
|
else
|
1998-03-09 15:16:28 +00:00
|
|
|
g_warning ("gtk_signal_emit_stop(): no current emission (%u) for object `%s'",
|
|
|
|
signal_id, gtk_type_name (GTK_OBJECT_TYPE (object)));
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_emit_stop_by_name (GtkObject *object,
|
|
|
|
const gchar *name)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
guint type;
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
|
|
|
g_return_if_fail (name != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = gtk_signal_lookup (name, GTK_OBJECT_TYPE (object));
|
|
|
|
if (type)
|
|
|
|
gtk_signal_emit_stop (object, type);
|
1998-03-08 10:41:48 +00:00
|
|
|
else
|
|
|
|
g_warning ("gtk_signal_emit_stop_by_name(): could not find signal \"%s\" in the `%s' class ancestry",
|
|
|
|
name, gtk_type_name (GTK_OBJECT_TYPE (object)));
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_connect (GtkObject *object,
|
|
|
|
const gchar *name,
|
|
|
|
GtkSignalFunc func,
|
|
|
|
gpointer func_data)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
guint type;
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (object != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = gtk_signal_lookup (name, GTK_OBJECT_TYPE (object));
|
|
|
|
if (!type)
|
|
|
|
{
|
1998-03-08 10:41:48 +00:00
|
|
|
g_warning ("gtk_signal_connect(): could not find signal \"%s\" in the `%s' class ancestry",
|
1997-11-24 22:37:52 +00:00
|
|
|
name, gtk_type_name (GTK_OBJECT_TYPE (object)));
|
|
|
|
return 0;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-02-13 05:19:06 +00:00
|
|
|
return gtk_signal_connect_by_type (object, type,
|
1997-11-24 22:37:52 +00:00
|
|
|
func, func_data, NULL,
|
1998-02-13 05:19:06 +00:00
|
|
|
FALSE, FALSE, FALSE);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_connect_after (GtkObject *object,
|
|
|
|
const gchar *name,
|
|
|
|
GtkSignalFunc func,
|
|
|
|
gpointer func_data)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
guint type;
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (object != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = gtk_signal_lookup (name, GTK_OBJECT_TYPE (object));
|
|
|
|
if (!type)
|
|
|
|
{
|
1998-03-08 10:41:48 +00:00
|
|
|
g_warning ("gtk_signal_connect_after(): could not find signal \"%s\" in the `%s' class ancestry",
|
1997-11-24 22:37:52 +00:00
|
|
|
name, gtk_type_name (GTK_OBJECT_TYPE (object)));
|
|
|
|
return 0;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-02-13 05:19:06 +00:00
|
|
|
return gtk_signal_connect_by_type (object, type,
|
1997-11-24 22:37:52 +00:00
|
|
|
func, func_data, NULL,
|
1998-02-13 05:19:06 +00:00
|
|
|
FALSE, TRUE, FALSE);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1998-02-13 05:19:06 +00:00
|
|
|
gtk_signal_connect_full (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
const gchar *name,
|
1998-02-13 05:19:06 +00:00
|
|
|
GtkSignalFunc func,
|
|
|
|
GtkCallbackMarshal marshal,
|
|
|
|
gpointer func_data,
|
|
|
|
GtkDestroyNotify destroy_func,
|
|
|
|
gint object_signal,
|
|
|
|
gint after)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
guint type;
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (object != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = gtk_signal_lookup (name, GTK_OBJECT_TYPE (object));
|
|
|
|
if (!type)
|
|
|
|
{
|
1998-03-08 10:41:48 +00:00
|
|
|
g_warning ("gtk_signal_connect_full(): could not find signal \"%s\" in the `%s' class ancestry",
|
1997-11-24 22:37:52 +00:00
|
|
|
name, gtk_type_name (GTK_OBJECT_TYPE (object)));
|
|
|
|
return 0;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-02-13 05:19:06 +00:00
|
|
|
if (marshal)
|
|
|
|
return gtk_signal_connect_by_type (object, type, (GtkSignalFunc) marshal,
|
|
|
|
func_data, destroy_func,
|
|
|
|
object_signal, after, TRUE);
|
|
|
|
else
|
|
|
|
return gtk_signal_connect_by_type (object, type, func,
|
|
|
|
func_data, destroy_func,
|
|
|
|
object_signal, after, FALSE);
|
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1998-02-13 05:19:06 +00:00
|
|
|
gtk_signal_connect_interp (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
const gchar *name,
|
1998-02-13 05:19:06 +00:00
|
|
|
GtkCallbackMarshal func,
|
|
|
|
gpointer func_data,
|
|
|
|
GtkDestroyNotify destroy_func,
|
|
|
|
gint after)
|
|
|
|
{
|
|
|
|
return gtk_signal_connect_full (object, name, NULL, func,
|
|
|
|
func_data, destroy_func, FALSE, after);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_connect_object (GtkObject *object,
|
|
|
|
const gchar *name,
|
|
|
|
GtkSignalFunc func,
|
|
|
|
GtkObject *slot_object)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
guint type;
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (object != NULL, 0);
|
1998-01-25 18:45:56 +00:00
|
|
|
/* slot_object needs to be treated as ordinary pointer */
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = gtk_signal_lookup (name, GTK_OBJECT_TYPE (object));
|
|
|
|
if (!type)
|
|
|
|
{
|
1998-03-08 10:41:48 +00:00
|
|
|
g_warning ("gtk_signal_connect_object(): could not find signal \"%s\" in the `%s' class ancestry",
|
1997-11-24 22:37:52 +00:00
|
|
|
name, gtk_type_name (GTK_OBJECT_TYPE (object)));
|
|
|
|
return 0;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-02-13 05:19:06 +00:00
|
|
|
return gtk_signal_connect_by_type (object, type,
|
1997-11-24 22:37:52 +00:00
|
|
|
func, slot_object, NULL,
|
1998-02-13 05:19:06 +00:00
|
|
|
TRUE, FALSE, FALSE);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
guint
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_connect_object_after (GtkObject *object,
|
|
|
|
const gchar *name,
|
|
|
|
GtkSignalFunc func,
|
|
|
|
GtkObject *slot_object)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
guint type;
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (object != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
type = gtk_signal_lookup (name, GTK_OBJECT_TYPE (object));
|
|
|
|
if (!type)
|
|
|
|
{
|
1998-03-08 10:41:48 +00:00
|
|
|
g_warning ("gtk_signal_connect_object_after(): could not find signal \"%s\" in the `%s' class ancestry",
|
1997-11-24 22:37:52 +00:00
|
|
|
name, gtk_type_name (GTK_OBJECT_TYPE (object)));
|
|
|
|
return 0;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-02-13 05:19:06 +00:00
|
|
|
return gtk_signal_connect_by_type (object, type,
|
1997-11-24 22:37:52 +00:00
|
|
|
func, slot_object, NULL,
|
1998-02-13 05:19:06 +00:00
|
|
|
TRUE, TRUE, FALSE);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
typedef struct _GtkDisconnectInfo GtkDisconnectInfo;
|
|
|
|
struct _GtkDisconnectInfo
|
|
|
|
{
|
|
|
|
GtkObject *object1;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint disconnect_handler1;
|
|
|
|
guint signal_handler;
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
GtkObject *object2;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint disconnect_handler2;
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
};
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
static guint
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
gtk_alive_disconnecter (GtkDisconnectInfo *info)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (info != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
gtk_signal_disconnect (info->object1, info->disconnect_handler1);
|
|
|
|
gtk_signal_disconnect (info->object1, info->signal_handler);
|
|
|
|
gtk_signal_disconnect (info->object2, info->disconnect_handler2);
|
|
|
|
g_free (info);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1998-02-03 21:36:06 +00:00
|
|
|
void
|
|
|
|
gtk_signal_connect_while_alive (GtkObject *object,
|
|
|
|
const gchar *signal,
|
|
|
|
GtkSignalFunc func,
|
|
|
|
gpointer func_data,
|
|
|
|
GtkObject *alive_object)
|
|
|
|
{
|
|
|
|
GtkDisconnectInfo *info;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-02-03 21:36:06 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
|
|
|
g_return_if_fail (GTK_IS_OBJECT (object));
|
|
|
|
g_return_if_fail (signal != NULL);
|
|
|
|
g_return_if_fail (func != NULL);
|
|
|
|
g_return_if_fail (alive_object != NULL);
|
|
|
|
g_return_if_fail (GTK_IS_OBJECT (alive_object));
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-02-03 21:36:06 +00:00
|
|
|
info = g_new (GtkDisconnectInfo, 1);
|
|
|
|
info->object1 = object;
|
|
|
|
info->object2 = alive_object;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-02-03 21:36:06 +00:00
|
|
|
info->signal_handler = gtk_signal_connect (object, signal, func, func_data);
|
|
|
|
info->disconnect_handler1 = gtk_signal_connect_object (info->object1,
|
|
|
|
"destroy",
|
|
|
|
GTK_SIGNAL_FUNC (gtk_alive_disconnecter),
|
|
|
|
(GtkObject*) info);
|
|
|
|
info->disconnect_handler2 = gtk_signal_connect_object (info->object2,
|
|
|
|
"destroy",
|
|
|
|
GTK_SIGNAL_FUNC (gtk_alive_disconnecter),
|
|
|
|
(GtkObject*) info);
|
|
|
|
}
|
|
|
|
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
void
|
|
|
|
gtk_signal_connect_object_while_alive (GtkObject *object,
|
|
|
|
const gchar *signal,
|
|
|
|
GtkSignalFunc func,
|
|
|
|
GtkObject *alive_object)
|
|
|
|
{
|
|
|
|
GtkDisconnectInfo *info;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
|
|
|
g_return_if_fail (GTK_IS_OBJECT (object));
|
|
|
|
g_return_if_fail (signal != NULL);
|
|
|
|
g_return_if_fail (func != NULL);
|
|
|
|
g_return_if_fail (alive_object != NULL);
|
|
|
|
g_return_if_fail (GTK_IS_OBJECT (alive_object));
|
1998-03-09 15:16:28 +00:00
|
|
|
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
info = g_new (GtkDisconnectInfo, 1);
|
|
|
|
info->object1 = object;
|
|
|
|
info->object2 = alive_object;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
info->signal_handler = gtk_signal_connect_object (object, signal, func, alive_object);
|
|
|
|
info->disconnect_handler1 = gtk_signal_connect_object (info->object1,
|
|
|
|
"destroy",
|
|
|
|
GTK_SIGNAL_FUNC (gtk_alive_disconnecter),
|
|
|
|
(GtkObject*) info);
|
|
|
|
info->disconnect_handler2 = gtk_signal_connect_object (info->object2,
|
|
|
|
"destroy",
|
|
|
|
GTK_SIGNAL_FUNC (gtk_alive_disconnecter),
|
|
|
|
(GtkObject*) info);
|
|
|
|
}
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
void
|
|
|
|
gtk_signal_disconnect (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint handler_id)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
GtkHandler *handler;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
g_return_if_fail (handler_id > 0);
|
|
|
|
|
1998-03-14 04:43:14 +00:00
|
|
|
handler = gtk_object_get_data_by_id (object, handler_key_id);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
while (handler)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
if (handler->id == handler_id)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler->id = 0;
|
|
|
|
handler->blocked = TRUE;
|
|
|
|
gtk_signal_handler_unref (handler, object);
|
1997-11-24 22:37:52 +00:00
|
|
|
return;
|
|
|
|
}
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler = handler->next;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
g_warning ("gtk_signal_disconnect(): could not find handler (%u)", handler_id);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_disconnect_by_data (GtkObject *object,
|
|
|
|
gpointer data)
|
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
GtkHandler *handler;
|
1997-11-24 22:37:52 +00:00
|
|
|
gint found_one;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
found_one = FALSE;
|
1998-03-14 04:43:14 +00:00
|
|
|
handler = gtk_object_get_data_by_id (object, handler_key_id);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
while (handler)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
GtkHandler *handler_next;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler_next = handler->next;
|
|
|
|
if (handler->func_data == data &&
|
|
|
|
handler->id > 0)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
found_one = TRUE;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler->id = 0;
|
|
|
|
handler->blocked = TRUE;
|
|
|
|
gtk_signal_handler_unref (handler, object);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler = handler_next;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (!found_one)
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
g_warning ("gtk_signal_disconnect_by_data(): could not find handler containing data (0x%0lX)", (long) data);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_handler_block (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint handler_id)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
GtkHandler *tmp;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
g_return_if_fail (handler_id > 0);
|
|
|
|
|
1998-03-14 04:43:14 +00:00
|
|
|
tmp = gtk_object_get_data_by_id (object, handler_key_id);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
while (tmp)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
if (tmp->id == handler_id)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
tmp->blocked = TRUE;
|
|
|
|
return;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
tmp = tmp->next;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
g_warning ("gtk_signal_handler_block(): could not find handler (%u)", handler_id);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_handler_block_by_data (GtkObject *object,
|
|
|
|
gpointer data)
|
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
GtkHandler *handler;
|
1997-11-24 22:37:52 +00:00
|
|
|
gint found_one;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
found_one = FALSE;
|
1998-03-14 04:43:14 +00:00
|
|
|
handler = gtk_object_get_data_by_id (object, handler_key_id);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
while (handler)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
if (handler->func_data == data &&
|
|
|
|
handler->id > 0)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
found_one = TRUE;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler->blocked = TRUE;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler = handler->next;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (!found_one)
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
g_warning ("gtk_signal_handler_block_by_data(): could not find handler containing data (0x%0lX)", (long) data);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_handler_unblock (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint handler_id)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
GtkHandler *handler;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
g_return_if_fail (handler_id > 0);
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-03-14 04:43:14 +00:00
|
|
|
handler = gtk_object_get_data_by_id (object, handler_key_id);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
while (handler)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
if (handler->id == handler_id)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler->blocked = FALSE;
|
1997-11-24 22:37:52 +00:00
|
|
|
return;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler = handler->next;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
g_warning ("gtk_signal_handler_unblock(): could not find handler (%u)", handler_id);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_handler_unblock_by_data (GtkObject *object,
|
|
|
|
gpointer data)
|
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
GtkHandler *handler;
|
1997-11-24 22:37:52 +00:00
|
|
|
gint found_one;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (initialize)
|
|
|
|
gtk_signal_init ();
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
found_one = FALSE;
|
1998-03-14 04:43:14 +00:00
|
|
|
handler = gtk_object_get_data_by_id (object, handler_key_id);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
while (handler)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
if (handler->func_data == data &&
|
|
|
|
handler->id > 0)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
found_one = TRUE;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler->blocked = FALSE;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler = handler->next;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (!found_one)
|
GTK_RESIZE_NEEDED is a private flag now.
Mon Feb 2 04:15:08 1998 Tim Janik <timj@gimp.org>
* gtk/gtkcontainer.h:
* gtk/gtkcontainer.c: GTK_RESIZE_NEEDED is a private flag now.
(gtk_container_register_toplevel): new function.
(gtk_container_unregister_toplevel): new function.
* gtk/gtkmain.c: GTK_LEAVE_PENDING is a private flag now.
* gtk/gtkmenu.c: call gtk_container_register_toplevel in
gtk_menu_class_init instead of this dirty gtk_widget_set_parent(,NULL)
hack. new default handler gtk_menu_destroy for calling
gtk_container_unregister_toplevel. removed GTK_ANCHORED, GTK_UNMAPPED.
* gtk/gtkobject.h: macro cleanups, added GTK_DESTROYED flag.
* gtk/gtkobject.c: only emit DESTROY signal if !GTK_OBJECT_DESTROYED
(object).
* gtk/gtkprivate.h: new file that will not be automatically included.
it holds the private flags for GtkWidget along with it's SET/UNSET
and examination macros.
* gtk/gtkwidget.c: private flags: GTK_RESIZE_NEEDED, GTK_REDRAW_PENDING,
GTK_RESIZE_PENDING, GTK_IN_REPARENT, GTK_USER_STYLE. GTK_ANCHORED is
replaced by GTK_TOPLEVEL. added missing UNSET for GTK_IN_REPARENT.
removed the gtk_widget_set_parent(, NULL) hack for toplevels.
upon destroy free memory for widgets with GTK_WIDGET_HAS_SHAPE_MASK.
* gtk/gtkwidget.h: split up the widget flags into a public and a private
portion. added an extra field private_flags to GtkWidget without making
it bigger by using an alignment gap of 16 bit. macro cleanups.
* gtk/gtkwindow.c: removed GTK_ANCHORED. new function gtk_window_destroy
for calling gtk_container_unregister_toplevel. removed the
gtk_widget_set_parent(,NULL), call gtk_container_register_toplevel
instead. remove GTK_UNMAPPED. GTK_RESIZE_NEEDED is private now.
* gtk/gtksignal.c (gtk_signal_disconnect): removed a bug on
removal that cut off the handler list -> living_objects == 0
with testgtk. made some warnings more descriptive.
new function gtk_signal_connect_object_while_alive, which
will automatically destroy the connection once one of the objects
is destroyed. didn't include this before removal of the above
mentioned bug.
* reflected refcounting revolution in ChangeLog
1998-02-02 04:54:25 +00:00
|
|
|
g_warning ("gtk_signal_handler_unblock_by_data(): could not find handler containing data (0x%0lX)", (long) data);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_handlers_destroy (GtkObject *object)
|
|
|
|
{
|
|
|
|
GtkHandler *handler;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
/* we make the "optimization" of destroying the first handler in the last
|
|
|
|
* place, since we don't want gtk_signal_handler_unref() to reset the objects
|
|
|
|
* handler_key data on each removal
|
|
|
|
*/
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-03-14 04:43:14 +00:00
|
|
|
handler = gtk_object_get_data_by_id (object, handler_key_id);
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
if (handler)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler = handler->next;
|
|
|
|
while (handler)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
GtkHandler *next;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
next = handler->next;
|
|
|
|
gtk_signal_handler_unref (handler, object);
|
|
|
|
handler = next;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-03-14 04:43:14 +00:00
|
|
|
handler = gtk_object_get_data_by_id (object, handler_key_id);
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
gtk_signal_handler_unref (handler, object);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_default_marshaller (GtkObject *object,
|
|
|
|
GtkSignalFunc func,
|
|
|
|
gpointer func_data,
|
|
|
|
GtkArg *params)
|
|
|
|
{
|
|
|
|
GtkSignalMarshaller0 rfunc;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
rfunc = (GtkSignalMarshaller0) func;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
(* rfunc) (object, func_data);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gtk_signal_set_funcs (GtkSignalMarshal marshal_func,
|
|
|
|
GtkSignalDestroy destroy_func)
|
|
|
|
{
|
|
|
|
marshal = marshal_func;
|
|
|
|
destroy = destroy_func;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
gtk_signal_init ()
|
|
|
|
{
|
|
|
|
if (initialize)
|
|
|
|
{
|
|
|
|
initialize = FALSE;
|
|
|
|
signal_hash_table = g_hash_table_new ((GHashFunc) gtk_signal_hash,
|
|
|
|
(GCompareFunc) gtk_signal_compare);
|
|
|
|
signal_info_hash_table = g_hash_table_new ((GHashFunc) gtk_signal_info_hash,
|
|
|
|
(GCompareFunc) gtk_signal_info_compare);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static guint
|
1998-03-09 15:16:28 +00:00
|
|
|
gtk_signal_hash (guint *key)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
return *key;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static gint
|
1998-03-09 15:16:28 +00:00
|
|
|
gtk_signal_compare (guint *a,
|
|
|
|
guint *b)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
return (*a == *b);
|
|
|
|
}
|
|
|
|
|
|
|
|
static guint
|
|
|
|
gtk_signal_info_hash (GtkSignalInfo *a)
|
|
|
|
{
|
1998-01-18 18:15:46 +00:00
|
|
|
return (g_str_hash (a->name) + a->object_type);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static gint
|
|
|
|
gtk_signal_info_compare (GtkSignalInfo *a,
|
|
|
|
GtkSignalInfo *b)
|
|
|
|
{
|
|
|
|
return ((a->object_type == b->object_type) &&
|
1998-01-18 18:15:46 +00:00
|
|
|
g_str_equal (a->name, b->name));
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static GtkHandler*
|
|
|
|
gtk_signal_handler_new ()
|
|
|
|
{
|
|
|
|
GtkHandler *handler;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (!handler_mem_chunk)
|
|
|
|
handler_mem_chunk = g_mem_chunk_new ("handler mem chunk", sizeof (GtkHandler),
|
|
|
|
1024, G_ALLOC_AND_FREE);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
handler = g_chunk_new (GtkHandler, handler_mem_chunk);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
handler->id = 0;
|
1998-01-30 23:47:09 +00:00
|
|
|
handler->ref_count = 1;
|
1997-11-24 22:37:52 +00:00
|
|
|
handler->signal_type = 0;
|
|
|
|
handler->blocked = FALSE;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler->object_signal = FALSE;
|
1997-11-24 22:37:52 +00:00
|
|
|
handler->after = FALSE;
|
|
|
|
handler->no_marshal = FALSE;
|
|
|
|
handler->func = NULL;
|
|
|
|
handler->func_data = NULL;
|
|
|
|
handler->destroy_func = NULL;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler->prev = NULL;
|
1997-11-24 22:37:52 +00:00
|
|
|
handler->next = NULL;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
return handler;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
1998-01-30 23:47:09 +00:00
|
|
|
gtk_signal_handler_ref (GtkHandler *handler)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-01-30 23:47:09 +00:00
|
|
|
handler->ref_count += 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gtk_signal_handler_unref (GtkHandler *handler,
|
|
|
|
GtkObject *object)
|
|
|
|
{
|
1998-02-03 21:36:06 +00:00
|
|
|
if (!handler->ref_count)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
/* FIXME: i wanna get removed some when */
|
1998-02-03 21:36:06 +00:00
|
|
|
g_warning ("gtk_signal_handler_unref(): handler with ref_count==0!");
|
|
|
|
return;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
handler->ref_count -= 1;
|
|
|
|
if (handler->ref_count == 0)
|
|
|
|
{
|
|
|
|
if (!handler->func && destroy)
|
|
|
|
(* destroy) (handler->func_data);
|
|
|
|
else if (handler->destroy_func)
|
|
|
|
(* handler->destroy_func) (handler->func_data);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
if (handler->prev)
|
|
|
|
handler->prev->next = handler->next;
|
1998-01-30 23:47:09 +00:00
|
|
|
else
|
1998-03-14 04:43:14 +00:00
|
|
|
gtk_object_set_data_by_id (object, handler_key_id, handler->next);
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
if (handler->next)
|
|
|
|
handler->next->prev = handler->prev;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
g_mem_chunk_free (handler_mem_chunk, handler);
|
|
|
|
}
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gtk_signal_handler_insert (GtkObject *object,
|
|
|
|
GtkHandler *handler)
|
|
|
|
{
|
|
|
|
GtkHandler *tmp;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
|
|
|
|
/* FIXME: remove */ g_assert (handler->next == NULL);
|
|
|
|
/* FIXME: remove */ g_assert (handler->prev == NULL);
|
|
|
|
|
1998-03-14 04:43:14 +00:00
|
|
|
tmp = gtk_object_get_data_by_id (object, handler_key_id);
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
if (!tmp)
|
1998-03-14 04:43:14 +00:00
|
|
|
{
|
|
|
|
if (!handler_key_id)
|
|
|
|
handler_key_id = gtk_object_data_force_id (handler_key);
|
|
|
|
gtk_object_set_data_by_id (object, handler_key_id, handler);
|
|
|
|
}
|
1997-11-24 22:37:52 +00:00
|
|
|
else
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
while (tmp)
|
|
|
|
{
|
|
|
|
if (tmp->signal_type < handler->signal_type)
|
|
|
|
{
|
|
|
|
if (tmp->prev)
|
|
|
|
{
|
|
|
|
tmp->prev->next = handler;
|
|
|
|
handler->prev = tmp->prev;
|
|
|
|
}
|
|
|
|
else
|
1998-03-14 04:43:14 +00:00
|
|
|
gtk_object_set_data_by_id (object, handler_key_id, handler);
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
tmp->prev = handler;
|
|
|
|
handler->next = tmp;
|
|
|
|
break;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
if (!tmp->next)
|
|
|
|
{
|
|
|
|
tmp->next = handler;
|
|
|
|
handler->prev = tmp;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
tmp = tmp->next;
|
|
|
|
}
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
static void
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_real_emit (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type,
|
1997-11-24 22:37:52 +00:00
|
|
|
va_list args)
|
|
|
|
{
|
|
|
|
GtkSignal *signal;
|
|
|
|
GtkHandler *handlers;
|
|
|
|
GtkHandlerInfo info;
|
|
|
|
guchar **signal_func_offset;
|
|
|
|
GtkArg params[MAX_PARAMS];
|
1998-01-30 23:47:09 +00:00
|
|
|
|
|
|
|
signal = g_hash_table_lookup (signal_hash_table, &signal_type);
|
|
|
|
g_return_if_fail (signal != NULL);
|
|
|
|
g_return_if_fail (gtk_type_is_a (GTK_OBJECT_TYPE (object),
|
|
|
|
signal->info.object_type));
|
|
|
|
|
|
|
|
if ((signal->run_type & GTK_RUN_NO_RECURSE) &&
|
|
|
|
gtk_emission_check (current_emissions, object, signal_type))
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-01-30 23:47:09 +00:00
|
|
|
gtk_emission_add (&restart_emissions, object, signal_type);
|
|
|
|
return;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-01-30 23:47:09 +00:00
|
|
|
|
|
|
|
gtk_params_get (params, signal->nparams, signal->params,
|
|
|
|
signal->return_val, args);
|
|
|
|
|
|
|
|
gtk_emission_add (¤t_emissions, object, signal_type);
|
|
|
|
|
|
|
|
gtk_object_ref (object);
|
|
|
|
|
|
|
|
restart:
|
|
|
|
if (GTK_RUN_TYPE (signal->run_type) != GTK_RUN_LAST && signal->function_offset != 0)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-01-30 23:47:09 +00:00
|
|
|
signal_func_offset = (guchar**) ((guchar*) object->klass +
|
|
|
|
signal->function_offset);
|
|
|
|
if (*signal_func_offset)
|
|
|
|
(* signal->marshaller) (object, (GtkSignalFunc) *signal_func_offset,
|
|
|
|
NULL, params);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
1998-01-30 23:47:09 +00:00
|
|
|
|
|
|
|
info.object = object;
|
|
|
|
info.marshaller = signal->marshaller;
|
|
|
|
info.params = params;
|
|
|
|
info.param_types = signal->params;
|
|
|
|
info.return_val = signal->return_val;
|
|
|
|
info.nparams = signal->nparams;
|
|
|
|
info.run_type = signal->run_type;
|
|
|
|
info.signal_type = signal_type;
|
|
|
|
|
|
|
|
handlers = gtk_signal_get_handlers (object, signal_type);
|
|
|
|
switch (gtk_handlers_run (handlers, &info, FALSE))
|
|
|
|
{
|
|
|
|
case DONE:
|
|
|
|
goto done;
|
|
|
|
case RESTART:
|
|
|
|
goto restart;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (GTK_RUN_TYPE (signal->run_type) != GTK_RUN_FIRST && signal->function_offset != 0)
|
|
|
|
{
|
|
|
|
signal_func_offset = (guchar**) ((guchar*) object->klass +
|
|
|
|
signal->function_offset);
|
|
|
|
if (*signal_func_offset)
|
|
|
|
(* signal->marshaller) (object, (GtkSignalFunc) *signal_func_offset,
|
|
|
|
NULL, params);
|
|
|
|
}
|
|
|
|
|
1998-02-03 21:36:06 +00:00
|
|
|
handlers = gtk_signal_get_handlers (object, signal_type);
|
1998-01-30 23:47:09 +00:00
|
|
|
switch (gtk_handlers_run (handlers, &info, TRUE))
|
|
|
|
{
|
|
|
|
case DONE:
|
|
|
|
goto done;
|
|
|
|
case RESTART:
|
|
|
|
goto restart;
|
|
|
|
}
|
|
|
|
|
|
|
|
done:
|
|
|
|
|
|
|
|
gtk_emission_remove (¤t_emissions, object, signal_type);
|
|
|
|
|
|
|
|
if (signal->run_type & GTK_RUN_NO_RECURSE)
|
|
|
|
gtk_emission_remove (&restart_emissions, object, signal_type);
|
|
|
|
|
|
|
|
gtk_object_unref (object);
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
|
|
|
|
1998-02-10 23:49:15 +00:00
|
|
|
static GtkHandler*
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_get_handlers (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
GtkHandler *handlers;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (object != NULL, NULL);
|
|
|
|
g_return_val_if_fail (signal_type >= 1, NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1998-03-14 04:43:14 +00:00
|
|
|
handlers = gtk_object_get_data_by_id (object, handler_key_id);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
while (handlers)
|
|
|
|
{
|
|
|
|
if (handlers->signal_type == signal_type)
|
|
|
|
return handlers;
|
|
|
|
handlers = handlers->next;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
1998-02-10 23:49:15 +00:00
|
|
|
guint
|
|
|
|
gtk_signal_handler_pending (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_id,
|
1998-02-10 23:49:15 +00:00
|
|
|
gboolean may_be_blocked)
|
|
|
|
{
|
|
|
|
GtkHandler *handlers;
|
|
|
|
guint handler_id;
|
|
|
|
|
|
|
|
g_return_val_if_fail (object != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
g_return_val_if_fail (signal_id >= 1, 0);
|
1998-02-10 23:49:15 +00:00
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
handlers = gtk_signal_get_handlers (object, signal_id);
|
1998-02-10 23:49:15 +00:00
|
|
|
|
|
|
|
handler_id = 0;
|
1998-03-09 15:16:28 +00:00
|
|
|
while (handlers && handlers->signal_type == signal_id)
|
1998-02-10 23:49:15 +00:00
|
|
|
{
|
|
|
|
if (handlers->id > 0 &&
|
|
|
|
(may_be_blocked ||
|
|
|
|
!handlers->blocked))
|
|
|
|
{
|
|
|
|
handler_id = handlers->id;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
handlers = handlers->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
return handler_id;
|
|
|
|
}
|
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
static guint
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_connect_by_type (GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type,
|
1997-11-24 22:37:52 +00:00
|
|
|
GtkSignalFunc func,
|
|
|
|
gpointer func_data,
|
|
|
|
GtkSignalDestroy destroy_func,
|
1998-02-13 05:19:06 +00:00
|
|
|
gint object_signal,
|
1997-11-24 22:37:52 +00:00
|
|
|
gint after,
|
|
|
|
gint no_marshal)
|
|
|
|
{
|
1998-01-29 20:44:14 +00:00
|
|
|
GtkObjectClass *class;
|
1997-11-24 22:37:52 +00:00
|
|
|
GtkHandler *handler;
|
|
|
|
gint found_it;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_val_if_fail (object != NULL, 0);
|
|
|
|
g_return_val_if_fail (object->klass != NULL, 0);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
/* Search through the signals for this object and make
|
1998-01-29 20:44:14 +00:00
|
|
|
* sure the one we are adding is valid. We need to perform
|
|
|
|
* the lookup on the objects parents as well. If it isn't
|
|
|
|
* valid then issue a warning and return.
|
1997-11-24 22:37:52 +00:00
|
|
|
*/
|
|
|
|
found_it = FALSE;
|
1998-01-29 20:44:14 +00:00
|
|
|
class = object->klass;
|
|
|
|
while (class)
|
|
|
|
{
|
|
|
|
GtkType parent;
|
1998-03-11 22:49:40 +00:00
|
|
|
guint *object_signals;
|
1998-03-09 15:16:28 +00:00
|
|
|
guint nsignals;
|
1998-01-29 20:44:14 +00:00
|
|
|
guint i;
|
|
|
|
|
|
|
|
object_signals = class->signals;
|
|
|
|
nsignals = class->nsignals;
|
|
|
|
|
|
|
|
for (i = 0; i < nsignals; i++)
|
|
|
|
if (object_signals[i] == signal_type)
|
|
|
|
{
|
|
|
|
found_it = TRUE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
parent = gtk_type_parent (class->type);
|
|
|
|
if (parent)
|
|
|
|
class = gtk_type_class (parent);
|
|
|
|
else
|
|
|
|
class = NULL;
|
|
|
|
}
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (!found_it)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
g_warning ("gtk_signal_connect_by_type(): could not find signal id (%u) in the `%s' class ancestry",
|
1998-03-08 10:41:48 +00:00
|
|
|
signal_type,
|
|
|
|
gtk_type_name (class->type));
|
1997-11-24 22:37:52 +00:00
|
|
|
return 0;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
handler = gtk_signal_handler_new ();
|
|
|
|
handler->id = next_handler_id++;
|
|
|
|
handler->signal_type = signal_type;
|
|
|
|
handler->object_signal = object_signal;
|
|
|
|
handler->func = func;
|
|
|
|
handler->func_data = func_data;
|
|
|
|
handler->destroy_func = destroy_func;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
handler->after = after != FALSE;
|
1997-11-24 22:37:52 +00:00
|
|
|
handler->no_marshal = no_marshal;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_signal_handler_insert (object, handler);
|
|
|
|
return handler->id;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GtkEmission*
|
|
|
|
gtk_emission_new ()
|
|
|
|
{
|
|
|
|
GtkEmission *emission;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (!emission_mem_chunk)
|
|
|
|
emission_mem_chunk = g_mem_chunk_new ("emission mem chunk", sizeof (GtkEmission),
|
|
|
|
1024, G_ALLOC_AND_FREE);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
emission = g_chunk_new (GtkEmission, emission_mem_chunk);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
emission->object = NULL;
|
|
|
|
emission->signal_type = 0;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
return emission;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gtk_emission_destroy (GtkEmission *emission)
|
|
|
|
{
|
|
|
|
g_mem_chunk_free (emission_mem_chunk, emission);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gtk_emission_add (GList **emissions,
|
|
|
|
GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
GtkEmission *emission;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (emissions != NULL);
|
|
|
|
g_return_if_fail (object != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
emission = gtk_emission_new ();
|
|
|
|
emission->object = object;
|
|
|
|
emission->signal_type = signal_type;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
*emissions = g_list_prepend (*emissions, emission);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gtk_emission_remove (GList **emissions,
|
|
|
|
GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
GtkEmission *emission;
|
|
|
|
GList *tmp;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
g_return_if_fail (emissions != NULL);
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
tmp = *emissions;
|
|
|
|
while (tmp)
|
|
|
|
{
|
|
|
|
emission = tmp->data;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if ((emission->object == object) &&
|
|
|
|
(emission->signal_type == signal_type))
|
|
|
|
{
|
|
|
|
gtk_emission_destroy (emission);
|
|
|
|
*emissions = g_list_remove_link (*emissions, tmp);
|
|
|
|
g_list_free (tmp);
|
|
|
|
break;
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
tmp = tmp->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static gint
|
|
|
|
gtk_emission_check (GList *emissions,
|
|
|
|
GtkObject *object,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint signal_type)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
|
|
|
GtkEmission *emission;
|
|
|
|
GList *tmp;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
tmp = emissions;
|
|
|
|
while (tmp)
|
|
|
|
{
|
|
|
|
emission = tmp->data;
|
|
|
|
tmp = tmp->next;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if ((emission->object == object) &&
|
|
|
|
(emission->signal_type == signal_type))
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static gint
|
|
|
|
gtk_handlers_run (GtkHandler *handlers,
|
|
|
|
GtkHandlerInfo *info,
|
|
|
|
gint after)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
while (handlers && handlers->signal_type == info->signal_type)
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
GtkHandler *handlers_next;
|
1998-01-30 23:47:09 +00:00
|
|
|
|
1998-03-09 15:16:28 +00:00
|
|
|
gtk_signal_handler_ref (handlers);
|
1998-01-30 23:47:09 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (!handlers->blocked && (handlers->after == after))
|
|
|
|
{
|
|
|
|
if (handlers->func)
|
|
|
|
{
|
|
|
|
if (handlers->no_marshal)
|
|
|
|
(* (GtkCallbackMarshal)handlers->func) (info->object,
|
|
|
|
handlers->func_data,
|
|
|
|
info->nparams,
|
|
|
|
info->params);
|
|
|
|
else if (handlers->object_signal)
|
1998-01-15 03:49:51 +00:00
|
|
|
(* info->marshaller) ((GtkObject*) handlers->func_data, /* don't GTK_OBJECT() cast */
|
1997-11-24 22:37:52 +00:00
|
|
|
handlers->func,
|
|
|
|
handlers->func_data,
|
|
|
|
info->params);
|
|
|
|
else
|
|
|
|
(* info->marshaller) (info->object,
|
|
|
|
handlers->func,
|
|
|
|
handlers->func_data,
|
|
|
|
info->params);
|
|
|
|
}
|
|
|
|
else if (marshal)
|
|
|
|
(* marshal) (info->object,
|
|
|
|
handlers->func_data,
|
|
|
|
info->nparams,
|
|
|
|
info->params,
|
|
|
|
info->param_types,
|
|
|
|
info->return_val);
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
if (gtk_emission_check (stop_emissions, info->object,
|
|
|
|
info->signal_type))
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-01-30 23:47:09 +00:00
|
|
|
gtk_emission_remove (&stop_emissions, info->object,
|
|
|
|
info->signal_type);
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
if (info->run_type & GTK_RUN_NO_RECURSE)
|
1998-01-30 23:47:09 +00:00
|
|
|
gtk_emission_remove (&restart_emissions, info->object,
|
|
|
|
info->signal_type);
|
1998-02-03 21:36:06 +00:00
|
|
|
gtk_signal_handler_unref (handlers, info->object);
|
1997-11-24 22:37:52 +00:00
|
|
|
return DONE;
|
|
|
|
}
|
|
|
|
else if ((info->run_type & GTK_RUN_NO_RECURSE) &&
|
1998-01-30 23:47:09 +00:00
|
|
|
gtk_emission_check (restart_emissions, info->object,
|
|
|
|
info->signal_type))
|
1997-11-24 22:37:52 +00:00
|
|
|
{
|
1998-01-30 23:47:09 +00:00
|
|
|
gtk_emission_remove (&restart_emissions, info->object,
|
|
|
|
info->signal_type);
|
1998-02-03 21:36:06 +00:00
|
|
|
gtk_signal_handler_unref (handlers, info->object);
|
1997-11-24 22:37:52 +00:00
|
|
|
return RESTART;
|
|
|
|
}
|
|
|
|
}
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
|
1998-01-30 23:47:09 +00:00
|
|
|
handlers_next = handlers->next;
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
gtk_signal_handler_unref (handlers, info->object);
|
1998-01-30 23:47:09 +00:00
|
|
|
handlers = handlers_next;
|
1997-11-24 22:37:52 +00:00
|
|
|
}
|
ok, there have been several severe bugs in the signal handler referencing
Tue Feb 10 07:12:07 1998 Tim Janik <timj@gimp.org>
* gtk/gtksignal.h:
* gtk/gtksignal.c:
ok, there have been several severe bugs in the signal handler
referencing and ->next connection stuff. these bugs caused
invokations of handlers that are disconnected and - worse -
destroyed already. invokation of *destroyd* handlers mean:
anything can be executed , because the handler structure can just
as well be realocated.
at the cost of an extra ->prev field per handler we should have a
reasonable stable system now, because of the various places that
can cause a handler to be disconnected (*any* handler invokation can
cause *any* or *all* handlers to be disconnected, there is no way
around a doubly linked list, actually handler disconnection has never
worked correctly because of this.
handlers are connected together via a *doubly* linked list now, and it
is *not* valid to remove a handler out of this list untill all its
references have been droped, i.e. handler->ref_count==0.
to prevent emissions of disconnected but still referenced handlers,
disconnected handlers are simply marked as blocked and get an id of 0
which is an invalid signal handler id.
the handler->id has been changed to have 28 significant bits (using
alignment gaps), since 65536 (old range: guint16) signal connections
(as a total) can easily be reached by complex applications.
this whole handler thingy is at least as tedious as writing doubly
linked list implementations ;)
1998-02-10 06:53:08 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gtk_params_get (GtkArg *params,
|
1998-03-09 15:16:28 +00:00
|
|
|
guint nparams,
|
1997-11-24 22:37:52 +00:00
|
|
|
GtkType *param_types,
|
|
|
|
GtkType return_val,
|
|
|
|
va_list args)
|
|
|
|
{
|
1998-03-09 15:16:28 +00:00
|
|
|
gint i;
|
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
for (i = 0; i < nparams; i++)
|
|
|
|
{
|
1997-12-18 02:17:14 +00:00
|
|
|
params[i].type = param_types[i];
|
|
|
|
params[i].name = NULL;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
switch (GTK_FUNDAMENTAL_TYPE (param_types[i]))
|
|
|
|
{
|
|
|
|
case GTK_TYPE_INVALID:
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_NONE:
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_CHAR:
|
|
|
|
GTK_VALUE_CHAR(params[i]) = va_arg (args, gint);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_BOOL:
|
|
|
|
GTK_VALUE_BOOL(params[i]) = va_arg (args, gint);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_INT:
|
|
|
|
GTK_VALUE_INT(params[i]) = va_arg (args, gint);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_UINT:
|
|
|
|
GTK_VALUE_UINT(params[i]) = va_arg (args, guint);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_ENUM:
|
|
|
|
GTK_VALUE_ENUM(params[i]) = va_arg (args, gint);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_FLAGS:
|
|
|
|
GTK_VALUE_FLAGS(params[i]) = va_arg (args, gint);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_LONG:
|
|
|
|
GTK_VALUE_LONG(params[i]) = va_arg (args, glong);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_ULONG:
|
|
|
|
GTK_VALUE_ULONG(params[i]) = va_arg (args, gulong);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_FLOAT:
|
|
|
|
GTK_VALUE_FLOAT(params[i]) = va_arg (args, gfloat);
|
|
|
|
break;
|
1998-01-18 11:09:04 +00:00
|
|
|
case GTK_TYPE_DOUBLE:
|
|
|
|
GTK_VALUE_DOUBLE(params[i]) = va_arg (args, gdouble);
|
|
|
|
break;
|
1997-11-24 22:37:52 +00:00
|
|
|
case GTK_TYPE_STRING:
|
|
|
|
GTK_VALUE_STRING(params[i]) = va_arg (args, gchar*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_POINTER:
|
|
|
|
GTK_VALUE_POINTER(params[i]) = va_arg (args, gpointer);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_BOXED:
|
|
|
|
GTK_VALUE_BOXED(params[i]) = va_arg (args, gpointer);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_SIGNAL:
|
|
|
|
GTK_VALUE_SIGNAL(params[i]).f = va_arg (args, GtkFunction);
|
|
|
|
GTK_VALUE_SIGNAL(params[i]).d = va_arg (args, gpointer);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_FOREIGN:
|
|
|
|
GTK_VALUE_FOREIGN(params[i]).data = va_arg (args, gpointer);
|
|
|
|
GTK_VALUE_FOREIGN(params[i]).notify =
|
|
|
|
va_arg (args, GtkDestroyNotify);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_CALLBACK:
|
|
|
|
GTK_VALUE_CALLBACK(params[i]).marshal =
|
|
|
|
va_arg (args, GtkCallbackMarshal);
|
|
|
|
GTK_VALUE_CALLBACK(params[i]).data = va_arg (args, gpointer);
|
|
|
|
GTK_VALUE_CALLBACK(params[i]).notify =
|
|
|
|
va_arg (args, GtkDestroyNotify);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_C_CALLBACK:
|
|
|
|
GTK_VALUE_C_CALLBACK(params[i]).func = va_arg (args, GtkFunction);
|
|
|
|
GTK_VALUE_C_CALLBACK(params[i]).func_data = va_arg (args, gpointer);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_ARGS:
|
1998-03-09 15:16:28 +00:00
|
|
|
GTK_VALUE_ARGS(params[i]).n_args = va_arg (args, gint);
|
1997-11-24 22:37:52 +00:00
|
|
|
GTK_VALUE_ARGS(params[i]).args = va_arg (args, GtkArg*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_OBJECT:
|
|
|
|
GTK_VALUE_OBJECT(params[i]) = va_arg (args, GtkObject*);
|
1998-03-09 15:16:28 +00:00
|
|
|
if (GTK_VALUE_OBJECT(params[i]) != NULL &&
|
|
|
|
!GTK_CHECK_TYPE (GTK_VALUE_OBJECT(params[i]), params[i].type))
|
|
|
|
g_warning ("signal arg `%s' is not of type `%s'",
|
|
|
|
gtk_type_name (GTK_OBJECT_TYPE (GTK_VALUE_OBJECT(params[i]))),
|
|
|
|
gtk_type_name (params[i].type));
|
1997-11-24 22:37:52 +00:00
|
|
|
break;
|
|
|
|
default:
|
1998-03-09 15:16:28 +00:00
|
|
|
g_error ("unsupported type `%s' in signal arg",
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_type_name (params[i].type));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-12-18 02:17:14 +00:00
|
|
|
params[i].type = return_val;
|
|
|
|
params[i].name = NULL;
|
1998-03-09 15:16:28 +00:00
|
|
|
|
1997-11-24 22:37:52 +00:00
|
|
|
switch (GTK_FUNDAMENTAL_TYPE (return_val))
|
|
|
|
{
|
|
|
|
case GTK_TYPE_INVALID:
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_NONE:
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_CHAR:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gchar*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_BOOL:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gint*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_INT:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gint*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_UINT:
|
|
|
|
params[i].d.pointer_data = va_arg (args, guint*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_ENUM:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gint*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_FLAGS:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gint*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_LONG:
|
|
|
|
params[i].d.pointer_data = va_arg (args, glong*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_ULONG:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gulong*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_FLOAT:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gfloat*);
|
|
|
|
break;
|
1998-01-18 11:09:04 +00:00
|
|
|
case GTK_TYPE_DOUBLE:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gdouble*);
|
|
|
|
break;
|
1997-11-24 22:37:52 +00:00
|
|
|
case GTK_TYPE_STRING:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gchar**);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_POINTER:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gpointer*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_BOXED:
|
|
|
|
params[i].d.pointer_data = va_arg (args, gpointer*);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_OBJECT:
|
|
|
|
params[i].d.pointer_data = va_arg (args, GtkObject**);
|
|
|
|
break;
|
|
|
|
case GTK_TYPE_SIGNAL:
|
|
|
|
case GTK_TYPE_FOREIGN:
|
|
|
|
case GTK_TYPE_CALLBACK:
|
|
|
|
case GTK_TYPE_C_CALLBACK:
|
|
|
|
case GTK_TYPE_ARGS:
|
|
|
|
default:
|
1998-03-09 15:16:28 +00:00
|
|
|
g_error ("unsupported type `%s' in signal return",
|
1997-11-24 22:37:52 +00:00
|
|
|
gtk_type_name (return_val));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|