Ok, this is most likely a question that could be answered by me "R-ing TFM," but so far I haven''t found it. Does anyone know if it''s possible to, rather than use a function as a callback when a button is clicked, simply return a value in the current function? If not, I may have to *gasp* resort to gotos. The Artist Formerly Known as CmndrM http://chaos.webhop.org

you could just have the function return the value, I dont think you can just return a value though. My group and I just finished our senior project using GTK, man was it a pain in the ass.

"I may not agree with what you say but I will defend to the death your right to say it."
--Voltaire

Well, here''s the problem. I''m trying to make a linux-equivalent version of the Win32 API MessageBox function, and I want the actual function to return a value. So in other words, having the buttons'' callbacks return a value won''t really do me any good, because I want the only function that is actually called by anyone be simply the MessageBox function itself.

Should I maybe use either Qt or (heaven forbid) X calls instead?

Oh, and I second the "pain in the ass" thing. I really don''t like GTK''s programming interface. I''m quite surprised that when they came out with GTK2, which isn''t supposed to be backwards compatible anyway, why they didn''t update the API to be a little nicer... But I digress.

The Artist Formerly Known as CmndrM

http://chaos.webhop.org

As far as I know, Qt has a much nicer api to use. It doesn''t have callbacks but it has its own slots/signals system, which may be slower but is certainly more modular and clean to use. The documentation is also quite nice. I''m thinking of starting a simple project using Qt, just to learn the basics of it. I''ve considered GTK too but I gave up when I realised that I would have to write my own wrapper to keep things nice and clean.

quote: Original post by Strife
Well, here's the problem. I'm trying to make a linux-equivalent version of the Win32 API MessageBox function, and I want the actual function to return a value. So in other words, having the buttons' callbacks return a value won't really do me any good, because I want the only function that is actually called by anyone be simply the MessageBox function itself.

I'm pretty sure you can do that. I'll throw an example together in a bit (I'm busy right now, probably shouldn't be wasting time online ).

quote: Original post by Strife
Oh, and I second the "pain in the ass" thing. I really don't like GTK's programming interface. I'm quite surprised that when they came out with GTK2, which isn't supposed to be backwards compatible anyway, why they didn't update the API to be a little nicer...

Probably because there are people like me, who really really like it .

quote: Original post by SwSh
I've considered GTK too but I gave up when I realised that I would have to write my own wrapper to keep things nice and clean.

Have you tried GTKmm (the C++-ified GTK+ wrapper; formerly known as GTK--)? I stick with the "default" C interface because I'm used to it and I use C more often when doing GUIs anyway (for whatever reason).



[edited by - Null and Void on August 9, 2003 4:05:18 PM]

@Null and Void:
I knew of the existance of gtk-- but I never tried it. I didn''t think it was "standard enough" to use it. (I''ve already installed a whole lot of different gtk applications and none of them ever used gtk--)
I''ve found some articles on this. This one seems interesting but I haven''t read it carefully yet. (It cuold be biased )

quote: Original post by SwSh
I knew of the existance of gtk-- but I never tried it. I didn''t think it was "standard enough" to use it. (I''ve already installed a whole lot of different gtk applications and none of them ever used gtk--)

It''s only "non-standard" in that most distros don''t install it by default since not many applications use it (even a lot of C++ applications just use the C interface to GTK+). Its interface stabilized a while ago, so if people begin to use it, it will be installed alongside GTK+ like the Python GTK+ bindings are often now.

It''s my opinion that there are much more objective comparisons out there than that one (can''t find the specific link I''m thinking of) if you want to read something more meaningful.

Here''s my quickly thrown together example of how to make a MessageBox immitation:

#include <gtk/gtk.h>/* The GNOME HIG says don''t use a title for alert dialogs, so I leave out   the option of setting it. You can add it back (for this type or other   types of dialogs). */GtkWidget *create_dialog_hig_information_alert(GtkWindow *parent, const gchar *text, void (*clicked_func)(GtkButton *, gpointer)) {	/* Glade 2 used to throw most of this together without thinking,	   then I ripped out the extraneous bits. */	GtkWidget *dialog_hia;	GtkWidget *dialog_vbox;	GtkWidget *dialog_hbox;	GtkWidget *image_icon;	GtkWidget *label_text;	GtkWidget *dialog_action_area;	GtkWidget *closebutton;	dialog_hia = gtk_dialog_new();	gtk_window_set_modal(GTK_WINDOW(dialog_hia), TRUE);	gtk_window_set_transient_for(GTK_WINDOW(dialog_hia), parent);	gtk_container_set_border_width(GTK_CONTAINER(dialog_hia), 6);	gtk_window_set_resizable(GTK_WINDOW(dialog_hia), FALSE);	gtk_dialog_set_has_separator(GTK_DIALOG(dialog_hia), FALSE);	gtk_window_set_title(GTK_WINDOW(dialog_hia), "");	dialog_vbox = GTK_DIALOG(dialog_hia)->vbox;	gtk_widget_show(dialog_vbox);	dialog_hbox = gtk_hbox_new(FALSE, 12);	gtk_widget_show(dialog_hbox);	gtk_box_pack_start(GTK_BOX(dialog_vbox), dialog_hbox, TRUE, TRUE, 0);	gtk_container_set_border_width(GTK_CONTAINER(dialog_hbox), 6);		image_icon = gtk_image_new_from_stock("gtk-dialog-info", GTK_ICON_SIZE_DIALOG);	gtk_widget_show(image_icon);	gtk_box_pack_start(GTK_BOX(dialog_hbox), image_icon, TRUE, TRUE, 0);	gtk_misc_set_alignment(GTK_MISC(image_icon), 0.5, 0);		label_text = gtk_label_new(text);	gtk_widget_show(label_text);	gtk_box_pack_start(GTK_BOX(dialog_hbox), label_text, FALSE, FALSE, 0);	gtk_label_set_use_markup(GTK_LABEL(label_text), TRUE);	gtk_label_set_justify(GTK_LABEL(label_text), GTK_JUSTIFY_LEFT);	gtk_label_set_line_wrap(GTK_LABEL(label_text), TRUE);	gtk_misc_set_alignment(GTK_MISC(label_text), 0.5, 0);		dialog_action_area = GTK_DIALOG(dialog_hia)->action_area;	gtk_widget_show(dialog_action_area);	gtk_button_box_set_layout(GTK_BUTTON_BOX(dialog_action_area), GTK_BUTTONBOX_END);		closebutton = gtk_button_new_from_stock("gtk-close");	g_signal_connect((gpointer) closebutton, "clicked", G_CALLBACK(clicked_func), GTK_WIDGET(dialog_hia));	gtk_widget_show(closebutton);	gtk_dialog_add_action_widget(GTK_DIALOG(dialog_hia), closebutton, GTK_RESPONSE_CLOSE);	GTK_WIDGET_SET_FLAGS(closebutton, GTK_CAN_DEFAULT);		return dialog_hia;}void message_box_close_clicked(GtkButton *button, gpointer vdialog) {	GtkWidget *dialog = (GtkWidget *) vdialog;	gboolean *finished_flag = g_object_get_data(G_OBJECT(dialog), "finished_flag");	if(finished_flag)		*finished_flag = 1;}/* You can change the type of finished_flag easily, I left it as an   integer so that memory management wouldn''t filter down too far */gint message_box_run(GtkWidget *dialog) {	gint *finished_flag, ret;	finished_flag = g_malloc(sizeof(gint));	g_assert(finished_flag != NULL);	*finished_flag = 0;	g_object_set_data_full(G_OBJECT(dialog), "finished_flag", finished_flag, g_free);	gtk_widget_show(dialog);	/* Take over the main loop, since it''s modal anyway. */	while(*finished_flag == 0)		gtk_main_iteration();	ret = *finished_flag;	gtk_object_destroy(GTK_OBJECT(dialog));	return ret;}/* NULL is allowed for parent */gint message_box_alert(GtkWindow *parent, const gchar *text) {	GtkWidget *dialog_hia = create_dialog_hig_information_alert(parent, text, message_box_close_clicked);	return message_box_run(dialog_hia);}/* You could add a message_box_yesno here, or extend the existing   message_box_alert, that uses a different/modified dialog widget and   has callback functions that set a different value depending on which button   they are. */

You''ll obviously have to build upon it to get whatever extra features you want out of it, but it should give you the idea */

All right, I still haven''t decided exactly what to use, and before I make a final decision, I should probably ask this first: I would like to be able to make a dialog box from an SDL application, not a GTK/whatever application. So would this be a problem using any of these things?

What about Motif or simple X calls? Would I be better off using one of those?

The Artist Formerly Known as CmndrM

http://chaos.webhop.org

Sorry if I a little out of stream
Why not to use QT?
Verry verry nice and powerful.
slot function can return value if you need to wrap around some event in your app or just can be filled with code
/**/
It doesn''t have callbacks but it has its own slots/signals system, which may be slower but is certainly more modular and clean to use
/**/

I am not sure about slower!!!!!!!!!!
Can You check speed of mfc vs w32 app or Qt vs app it wraps?
No!?
Ineritance making code slower?
No!?

class MyMsgBoxWrapperublic MyMsgBox
{
QOBJECT
MyMsgBoxWrapper(QWidget*parent,const char*name);
~MyMsgBoxWrapper();
public slot:
int newslotOnOkBut()
{
return 1;
}
or
void newslotOnOkBut()
{
response=IDB_OK;
}
};

Can''''t be root?Reboot!
mount -r /home/hell

Well, I haven''t done any testing regarding speed of Qt, but trolltech itself gives a believable explanation of this:

quote:
The signals and slots mechanism is efficient, but not quite as fast as "real" callbacks. Signals and slots are slightly slower because of the increased flexibility they provide, although the difference for real applications is insignificant. In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls. This is the overhead required to locate the connection object, to safely iterate over all connections (i.e. checking that subsequent receivers have not been destroyed during the emission) and to marshall any parameters in a generic fashion.

read more...