G_TYPE_<unterminated-string> (was: Re: Status of 2.0 API freeze bugs)
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: G_TYPE_<unterminated-string> (was: Re: Status of 2.0 API freeze bugs)
- Date: Tue, 3 Apr 2001 12:37:21 +0200 (CEST)
On 3 Apr 2001, Owen Taylor wrote:
> 50209 gobject glib Need a G_TYPE_ for non-nul-terminated strings
>
> Patch from otaylor needs to be fixed-up / applied by timj
there are basically two issues i have with that patch.
1) the way in wich it special cases G_TYPE_BYTES in glib-genmarshal.c,
2) the argument order, which is (guint8 *bytes, guint n_bytes) in your
patch
for (1), i need to extend glib-genmarshal.c to generically deal with in value
types that get passed as multiple args (marshalling of out value types with multiple
args are not going to be supported for 2.0).
for (2), we definitely need to change that to (guint n_bytes, guint8 *bytes),
and people have to be aware of this as these args are passed through a varargs
interface.
on why the number of elements should be passed as first arg by general
convention:
a) for varargs interfaces there's often no other way to handle this, e.g.
old API:
guint gtk_signal_new (const gchar *name,
[snip]
guint n_args,
...);
void gtk_binding_entry_add_signal (GtkBindingSet *binding_set,
[snip]
guint n_args,
...);
new API:
GtkListStore *gtk_list_store_new_with_types (gint n_columns,
...);
b) gtk has in the past pretty consistently been doing this:
typedef void (*GtkCallbackMarshal) (GtkObject *object,
gpointer data,
guint n_args,
GtkArg *args);
guint gtk_signal_newv (const gchar *name,
[...]
guint n_args,
GtkType *args);
void gtk_container_addv (GtkContainer *container,
GtkWidget *widget,
guint n_args,
GtkArg *args);
void gtk_item_factory_delete_entries (GtkItemFactory *ifactory,
guint n_entries,
GtkItemFactoryEntry *entries);
c) intuitivity. i usually expect args of equal contextual relevance to be
passed in order of significance. for a (n_elements, elements) tuple that's
clearly n_elements, since for n_elements==0, elements can be passed as NULL
in most APIs, we often even add checks like:
if (n_elements)
g_return_if_fail (elements != NULL);
(a) definitely isn't disputable, (c) i could imagine owen disagreeing on,
though i'd hope not. for (b) we even have some counter examples in gtk,
though that's mostly old API added by owen:
void gtk_drag_dest_set (GtkWidget *widget,
GtkDestDefaults flags,
const GtkTargetEntry *targets,
gint n_targets,
GdkDragAction actions);
and new API which should be fixed for consistency:
void gtk_tree_view_set_rows_drag_dest (GtkTreeView *tree_view,
const GtkTargetEntry *targets,
gint n_targets,
GdkDragAction actions,
GtkTreeViewDroppableFunc location_droppable_func,
gpointer user_data);
void gtk_tree_view_set_rows_drag_source (GtkTreeView *tree_view,
GdkModifierType start_button_mask,
const GtkTargetEntry *targets,
gint n_targets,
GdkDragAction actions,
GtkTreeViewDraggableFunc row_draggable_func,
gpointer user_data);
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]