CODEWITHSUNDEEP
cgtksignals
Zimzalabim
Zimzalabim

Reputation: 1137

Gtk signal with multiple arguments

Context

After writing a simple application using a GtkEntry widget to process textual commands from user I would like to do some design changes.

As of now I use signal hook on key-press. If key(s) are a specified value, then show command line and process various actions on entry widget. Like e.g.

As well as parsing commands and saving/loading history.

I am not satisfied with how this is stitched together. The command parsing becomes a subset of:

main_window -> mode_check -> command_line_act -> parse_cmd+execute

As I see it one good approach would be to write a new widget using GtkEntry as base – and send signals on command enter. All of the internals like Ctrl+... and history handled by the new widget.

Signals emitted from new widget being e.g.:

Status

Have written the base for this but I am at a hault when it comes to emitting signals with more then one argument.

I have:

gtk_signal_emit(obj, sig, 0, command)
                                 |
                                 +---- string.

but would like, (for now at least, most likely more/other down the line.):

gtk_signal_emit(obj, sig, 0, command, length)

gtk_emit_signal Typo fixed. Thanks to jku.. Also, now using g_signal_

In widget code:

static void
cmdline_class_init(CmdlineClass *klass)
{

With one argument I am using g_signal_new() as:

cmdline_signals[CMDLINE_CMD] = g_signal_new(
                "cmdline-cmd",
                G_TYPE_FROM_CLASS(klass),
                G_SIGNAL_RUN_LAST | G_SIGNAL_ACTION,
                G_STRUCT_OFFSET(CmdlineClass, cmdline),
                NULL,
                NULL,
                g_cclosure_marshal_VOID__VOID,
                G_TYPE_NONE,
                1,
                G_TYPE_STRING
);

And as I see it, for two arguments, should change it to something like:

cmdline_signals[CMDLINE_CMD] = g_signal_new(
                "cmdline-cmd",
                G_TYPE_FROM_CLASS(klass),
                G_SIGNAL_RUN_LAST | G_SIGNAL_ACTION,
                G_STRUCT_OFFSET(CmdlineClass, cmdline),
                NULL,
                NULL,
                g_cclosure_user_marshal_VOID__STRING_INT,
                G_TYPE_NONE,
                2,
                G_TYPE_STRING,
                G_TYPE_INT
);

Trouble in the garden

Using glib-genmarshal to generate marshals with marshal.list holding:

VOID:STRING,INT

This works, but gives me a warning upon compile time as:

warning: ISO C forbids conversion of object pointer to function pointer type

Caused by this code generated by glib-genmarshal:

  typedef void (*GMarshalFunc_VOID__STRING_INT) (gpointer     data1,
                                                 gpointer     arg_1,
                                                 gint         arg_2,
                                                 gpointer     data2);

  register GMarshalFunc_VOID__STRING_INT callback;

  /* GCC Warnig: conversion of object pointer to function => */
  callback = (GMarshalFunc_VOID__STRING_INT) ( 
                    marshal_data ? 
                    marshal_data : 
                    cc->callback
  );

Question

Is this the wrong approach? Is there some way to fix the conversion error? Etc.

As a note: I am fairly new to Gtk, and Gui programming in general.

Side point

There are some deprecations I also wonder if could affect the code / should be avoided:

Upvotes: 1

Views: 1516

Answers (1)

Jussi Kukkonen
Jussi Kukkonen

Reputation: 14577

This warning does appear (with -pedantic) on some signal marshalling code, and not just in your code. As far as I can see you are not doing anything wrong though -- except for using gtk_signal_emit() (I assume you meant that and not gtk_emit_signal() which does not exist as far as I know): you should not use any gtk_signal-prefixed code: that stuff is all deprecated. See the reference for details. Use GObject instead: g_signal_emit() or g_signal_emit_by_name() should work for you.

The signal marshaller deprecations you mention are about this same thing: GObject handles everything related to this now (and has for a long time already).

As practical advice: Often adding things to signal signatures is not worth the trouble, and this might be the case for you as well: maybe your signal does not need the command string at all, and the signal handler could just query it with your_object_get_command()?

Practical advice #2: Consider using GTK+ 3 for new code. Not having all that deprecated stuff around confusing everyone is just lovely.

Upvotes: 2

Related Questions