Style
Hello, All. Sorry for my English. When i try create and destroy widget with changed style, I get Gtk-CRITICAL **: file gtkstyle.c: line 606 (gtk_style_ref): assertion `style-ref_count 0' failed. What's wrong ? See my code: #include gtk/gtk.h #include stdio.h static GtkWidget *create_mw(void); static GtkWidget *create_button(void); int main(int argc, char *argv[]) { gtk_set_locale(); gtk_init(argc, argv); create_mw(); gtk_main(); return (0); } static GtkWidget *create_mw() { int i; GtkWidget*mw, *button; mw = gtk_widget_new(gtk_window_get_type(), "GtkObject::user_data", NULL, "GtkWindow::type", GTK_WINDOW_TOPLEVEL, NULL); gtk_signal_connect(GTK_OBJECT(mw), "destroy", GTK_SIGNAL_FUNC(gtk_main_quit), NULL); gtk_widget_show(mw); for (i = 0; i 100; ++i) { button = create_button(); gtk_widget_destroy(button); printf("i - %d\n", i); } return (mw); } static GtkWidget *create_button() { GtkWidget*foo, *button; GtkStyle *style; GdkPixmap*pixmap; GdkBitmap*mask = NULL; button = gtk_fixed_new(); gtk_widget_set_usize(button, 143, 19); gtk_widget_show(button); pixmap = gdk_pixmap_colormap_create_from_xpm(NULL, gtk_widget_get_colormap(button), mask, NULL, "button.xpm"); gtk_style_unref(button-style); style = gtk_style_copy(gtk_widget_get_default_style()); style-bg_pixmap[GTK_STATE_NORMAL] = pixmap; gtk_widget_set_style(button, style); foo = gtk_label_new("test"); gtk_fixed_put(GTK_FIXED(button), foo, 5, 0); gtk_widget_show(foo); return (button); } Output: [bash]$ ./bg_xpm i - 0 i - 1 i - 2 Gtk-CRITICAL **: file gtkstyle.c: line 606 (gtk_style_ref): assertion `style-ref_count 0' failed. i - 3 i - 4 i - 5 i - 6 i - 7 Segmentation fault (core dumped) // DS ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Style
On Wed, 26 Jul 2000, Denis Serebro wrote: Hi Denis, Just remove line with gtl_style_unref(button-style); gtk_widget_set_style() does this itself. When I tried your code, the program didn't segfaulted though (I use gtk+-1.2.3). Hello, All. Sorry for my English. When i try create and destroy widget with changed style, I get Gtk-CRITICAL **: file gtkstyle.c: line 606 (gtk_style_ref): assertion `style-ref_count 0' failed. What's wrong ? See my code: [...] Best regards, -Vlad ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Glib + glib-config
On Sun, 16 Jul 2000, jerrud wrote: Hi, Hi, I`m installing GTK+ 1.2.8 and in order to do that i have to install glib 1.2.8. My problem rests in that I have glib 1.2.6 installed from my distrobution`s install. (I`m running Storm Linux, Debian 2.2 based) So my question to you guys is:: How do i install over this older glib version (or uninstall, if need be) in order to install GTK+ ? It looks like glib-1.2.8 and 1.2.6 coexist. It looks like glib-1.2.8 is installed in /usr/local/lib. If you wish all already installed apps to use new glib and gtk, you should have erase glib-1.2.8, erase gtk-1.2.6 and glib-1.2.6 using package management software (apt?), and then you should build glib-1.2.8 and gtk-1.2.8. To do this properly, run 'configure --prefix=/usr' for each package, then make glib, install it, then make gtk, install it. But even better, try to get precompiled debs from somewhere. The error that ./configure produces is (from GTK):: glib-config --version returned 1.2.8, but GLIB (1.2.6) was found! Then it procedes to tell me how to fix this problem, but I do not know how to do so... All help appreciated Jerrud. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list Best regards, -Vlad ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Glib + glib-config
jerrud [EMAIL PROTECTED] writes: Hi, I`m installing GTK+ 1.2.8 and in order to do that i have to install glib 1.2.8. My problem rests in that I have glib 1.2.6 installed from my distrobution`s install. (I`m running Storm Linux, Debian 2.2 based) So my question to you guys is:: How do i install over this older glib version (or uninstall, if need be) in order to install GTK+ ? dpkg --remove glib. But it's going to complain about lots of broken dependencies. The error that ./configure produces is (from GTK):: glib-config --version returned 1.2.8, but GLIB (1.2.6) was found! Then it procedes to tell me how to fix this problem, but I do not know how to do so... All help appreciated If you're just developing against 1.2.8, and want to keep using packages for applications, you want to leave 1.2.6 around. The way to do that is to put 1.2.8 in /usr/local or /opt/gnome. Then write a script like this: #! /bin/bash export C_INCLUDE_PATH=/home/hp/unst/include:$C_INCLUDE_PATH export LD_LIBRARY_PATH=/home/hp/unst/lib:$LD_LIBRARY_PATH export ACLOCAL_FLAGS='-I /home/hp/unst/share/aclocal' export PATH=/home/hp/unst/bin:$PATH exec $* I call this script "unst" and as you can see I have installed to --prefix=/home/hp/unst. To use the libs in /home/hp/unst I prefix commands with "unst": unst ./configure unst make Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Focus question
I know I must be looking in the wrong place, but being naturally lazy, I thought I'd check here before really looking seriously :-) I'm having trouble getting a custom widget to be included in the focus traversal with the Tab key. Any quick and easy clues? - Mark Leisher Computing Research LabOnce you fully apprehend the vacuity of a New Mexico State University life without struggle, you are equipped Box 30001, Dept. 3CRL with the basic means of salvation. Las Cruces, NM 88003-- Tennessee Williams ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Minor menu nit
This may be fixed in the latest version, and apologies if so, but in 1.2.8 when using the arrow keys to select a menu item, empty items being used as separators get the focus when they should be skipped. - Mark Leisher Computing Research LabOnce you fully apprehend the vacuity of a New Mexico State University life without struggle, you are equipped Box 30001, Dept. 3CRL with the basic means of salvation. Las Cruces, NM 88003-- Tennessee Williams ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accelerators and gtk_grab_add
Tim Janik wrote: On 24 Jul 2000, Havoc Pennington wrote: Matt Carlson [EMAIL PROTECTED] writes: Hi folks. I'm having trouble with menu accelerators whenever I bring up a modal dialog. I tried to disable them through the use of gtk_grab_add(), but accelerators don't seem to be affected by this function. Is there a way to do this? Thanks in advance for your time. Yikes, that seems like a pretty serious bug. CC'd Tim to see if he has comments. i'm not able to reproduce this, and i couldn't imagine how accelerators could get delivered to windows while there's a modal dialog popped up (dialog modality does involve gtk_grab_add() btw). Yah, I know. If fact, I don't even bother with the gtk_window_set_modal() function. so if you could send me a short test case matt, that'd be aprechiated. I've attached it. I've programmatically set the menuitem accelerator to the 'N' key...for convenience. Just run the program, select the "Do Something" menu option, move the window out of the way, move the cursor over the main window, use the 'N' key to bring up another dialog (which shouldn't happen). Thanks for your help. :) === Matt Carlson 250 El Camino Real, Suite 100 Programmer Tustin, CA 92780 Loki Entertainment Softwarehttp://www.lokigames.com/~mindbender #include gdk/gdkkeysyms.h #include gtk/gtk.h gint CloseWindow( void ) { gtk_main_quit(); return TRUE; } static gint MenuItemEventHandler( void ) { /* Create a new dialog and display it. */ GtkWidget * window = gtk_window_new( GTK_WINDOW_DIALOG ); gtk_window_set_position( GTK_WINDOW(window), GTK_WIN_POS_CENTER ); gtk_widget_set_usize( window, 100, 100 ); GtkWidget * vbox = gtk_vbox_new( FALSE, 0 ); gtk_container_add( GTK_CONTAINER(window), vbox ); gtk_widget_show( vbox ); GtkWidget * label = gtk_label_new( "Main dialog area" ); gtk_box_pack_start( GTK_BOX(vbox), label, TRUE, FALSE, 0 ); gtk_widget_show( label ); GtkWidget * button = gtk_button_new_with_label( " OK " ); gtk_box_pack_start( GTK_BOX(vbox), button, TRUE, FALSE, 0 ); gtk_signal_connect( GTK_OBJECT(button), "clicked", GTK_SIGNAL_FUNC(CloseWindow), NULL ); gtk_widget_show( button ); gtk_signal_connect( GTK_OBJECT(window), "delete_event", GTK_SIGNAL_FUNC(CloseWindow), NULL ); gtk_widget_show( window ); /* Basically make it a modal dialog */ gtk_grab_add( window ); gtk_main(); gtk_grab_remove( window ); /* Kill it! */ gtk_widget_destroy( window ); gtk_main_iteration(); /* Don't propagate the event any further */ return TRUE; } int main( int argc, char ** argv ) { gtk_init( argc, argv ); GtkWidget * window = gtk_window_new( GTK_WINDOW_TOPLEVEL ); gtk_window_set_position( GTK_WINDOW(window), GTK_WIN_POS_CENTER ); gtk_widget_set_usize( window, 200, 200 ); GtkWidget * vbox = gtk_vbox_new( FALSE, 0 ); gtk_container_add( GTK_CONTAINER(window), vbox ); gtk_widget_show( vbox ); GtkWidget * menubar = gtk_menu_bar_new(); gtk_box_pack_start( GTK_BOX(vbox), menubar, FALSE, FALSE, 0 ); gtk_widget_show( menubar ); GtkWidget * menu = gtk_menu_new(); GtkWidget * majormenu = gtk_menu_item_new_with_label("File"); gtk_menu_bar_append( GTK_MENU_BAR(menubar), majormenu ); gtk_widget_show( majormenu ); GtkWidget * submenu = gtk_menu_new(); gtk_menu_item_set_submenu( GTK_MENU_ITEM(majormenu), submenu ); GtkWidget * menuitem = gtk_menu_item_new_with_label( "Do Something" ); gtk_menu_append( GTK_MENU(submenu), menuitem ); gtk_signal_connect( GTK_OBJECT(menuitem), "activate", GTK_SIGNAL_FUNC(MenuItemEventHandler), NULL ); /* Just for kicks let's add an accelerator programmatically */ gtk_widget_add_accelerator( menuitem, "activate", gtk_accel_group_get_default(), GDK_N, 0, GTK_ACCEL_VISIBLE ); gtk_widget_show( menuitem ); gtk_signal_connect( GTK_OBJECT(window), "delete_event", GTK_SIGNAL_FUNC(CloseWindow), NULL ); gtk_widget_show( window ); gtk_main(); return 0; }
Re: Focus question
Mark Leisher [EMAIL PROTECTED] writes: I know I must be looking in the wrong place, but being naturally lazy, I thought I'd check here before really looking seriously :-) I'm having trouble getting a custom widget to be included in the focus traversal with the Tab key. Any quick and easy clues? Does your widget turn on the GTK_CAN_FOCUS flag? Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Minor menu nit
Mark Leisher [EMAIL PROTECTED] writes: This may be fixed in the latest version, and apologies if so, but in 1.2.8 when using the arrow keys to select a menu item, empty items being used as separators get the focus when they should be skipped. Not on my computer. Test case? Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Focus question
Havoc Does your widget turn on the GTK_CAN_FOCUS flag? Well, dang. I somehow missed the obvious. Thanks. - Mark Leisher Computing Research LabOnce you fully apprehend the vacuity of a New Mexico State University life without struggle, you are equipped Box 30001, Dept. 3CRL with the basic means of salvation. Las Cruces, NM 88003-- Tennessee Williams ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Minor menu nit
Havoc Not on my computer. Test case? Hmm. It works fine when I use the itemfactory, just not when I create the menus myself. But when I create the menus using the itemfactory, I run into the problem of a menu item getting its global accelerator replaced by keystrokes that occur when that item has focus. Again the problem can be replicated by running the "itemfactory" example program, click once to pull down the "File" menu, type Ctrl+G and the global accelerator for the "New" menu item, which has the focus, changes to Ctrl+G. Handy for working out global accelerators on the fly, but should be lockable for applications. Yes. I posted about the same question some time ago. I suspect they cannot be locked. I would be very interested in solutions other than copying/pasting gtkitemfactory and changing some params. Manually creating menus is a real pain and very bad to maintain/update. Perhaps a wrapper which runs through the whole container and modifies the accelerator states?? greetings, xander van wiggen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Minor menu nit
xander Yes. I posted about the same question some time ago. I suspect xander they cannot be locked. I would be very interested in solutions xander other than copying/pasting gtkitemfactory and changing some xander params. When I create menus manually, the global accelerators are locked. I just have to go through the itemfactory code and mine and see what difference causes this to happen. Doing menus manually is indeed messy. - Mark Leisher Computing Research LabOnce you fully apprehend the vacuity of a New Mexico State University life without struggle, you are equipped Box 30001, Dept. 3CRL with the basic means of salvation. Las Cruces, NM 88003-- Tennessee Williams ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accelerators and gtk_grab_add
On Wed, 26 Jul 2000, Matt Carlson wrote: Tim Janik wrote: On 24 Jul 2000, Havoc Pennington wrote: Matt Carlson [EMAIL PROTECTED] writes: Hi folks. I'm having trouble with menu accelerators whenever I bring up a modal dialog. I tried to disable them through the use of gtk_grab_add(), but accelerators don't seem to be affected by this function. Is there a way to do this? Thanks in advance for your time. Yikes, that seems like a pretty serious bug. CC'd Tim to see if he has comments. i'm not able to reproduce this, and i couldn't imagine how accelerators could get delivered to windows while there's a modal dialog popped up (dialog modality does involve gtk_grab_add() btw). Yah, I know. If fact, I don't even bother with the gtk_window_set_modal() function. so if you could send me a short test case matt, that'd be aprechiated. I've attached it. I've programmatically set the menuitem accelerator to the 'N' key...for convenience. Just run the program, select the "Do Something" menu option, move the window out of the way, move the cursor over the main window, use the 'N' key to bring up another dialog (which shouldn't happen). Thanks for your help. :) ok, that's something to work from. the problem is the accelerator you setup programmatically: /* Just for kicks let's add an accelerator programmatically */ gtk_widget_add_accelerator( menuitem, "activate", gtk_accel_group_get_default(), GDK_N, 0, GTK_ACCEL_VISIBLE ); you're using the global default accelerator group that _all_ windows will resort to if they can't handle the keypress. what you actually want is to create a new accelerator group per menubar, install the accelerators on that and add it to the window with gtk_window_add_accel_group(). i can see why you used this though, i'll put the foolowing on my 2.0 todo list: 1) provide gtk_menu_bar_get_accel_group() (creates the menubar accel group for you, you just need to add it to the window then) 2) gtk_window_get_default_accel_group() (should be provided by havoc's recent patches already), to be used for non-menu, per-window accelerators 3) rename gtk_accel_group_get_default() to gtk_accel_group_get_global(), since that's how it's really used. [i didn't actually run your programm when i saw your usage of gtk_accel_group_get_default(), so if the above advice doesn't fix things for you, bug me again ;)] --- ciaoTJ ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Updating a statusbar widget
On Sun, 23 Jul 2000, Vlad Harchev wrote: while (gtk_events_pending()) gtk_main_iteration(); I am doing this, see my print_status function to write text status to a label: int print_status( char *fmt, ... ) { char buf[256]; va_list argptr; va_start( argptr, fmt); vsprintf( buf, fmt, argptr); va_end( argptr ); /* update single line feedback widget on main screen */ gtk_label_set_text( GTK_LABEL(Feedback_search_w), buf ); /* force update of widgets */ while ( gtk_events_pending() ) gtk_main_iteration(); // while ( gtk_main_iteration()); - this one from the FAQ don't work! return ERR_NONE; } Some problems: 1. The suggested code from the FAQ doesn't work: "while (gtk_main_iteration(FALSE));" I am using GTK 1.2.7. Is the FAQ out of date with the GTK release? 2. Worse, this solution does more than just drawing updates. It also processing other events on the queue. If I call print_status(), any user input to widget and their call backs are called, expired timers call backs get called, etc This make the cure, worse that the problem. Is there a better method to handle this situation? I think this is the best gtk 1.2.x can do. Will 1.4.x work better? Tony /-\ | Tony Denault| Internet: [EMAIL PROTECTED] | | NASA IRTF, Institute of Astronomy | Phone: (808) 974-4206 | | 1175 Manono St., Bldg 393 | Fax: (808) 974-4207 | | Hilo, Hawaii 96720 | | \-/ ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accelerators and gtk_grab_add
Tim Janik wrote: On Wed, 26 Jul 2000, Matt Carlson wrote: Tim Janik wrote: On 24 Jul 2000, Havoc Pennington wrote: Matt Carlson [EMAIL PROTECTED] writes: Hi folks. I'm having trouble with menu accelerators whenever I bring up a modal dialog. I tried to disable them through the use of gtk_grab_add(), but accelerators don't seem to be affected by this function. Is there a way to do this? Thanks in advance for your time. Yikes, that seems like a pretty serious bug. CC'd Tim to see if he has comments. i'm not able to reproduce this, and i couldn't imagine how accelerators could get delivered to windows while there's a modal dialog popped up (dialog modality does involve gtk_grab_add() btw). Yah, I know. If fact, I don't even bother with the gtk_window_set_modal() function. so if you could send me a short test case matt, that'd be aprechiated. I've attached it. I've programmatically set the menuitem accelerator to the 'N' key...for convenience. Just run the program, select the "Do Something" menu option, move the window out of the way, move the cursor over the main window, use the 'N' key to bring up another dialog (which shouldn't happen). Thanks for your help. :) ok, that's something to work from. the problem is the accelerator you setup programmatically: /* Just for kicks let's add an accelerator programmatically */ gtk_widget_add_accelerator( menuitem, "activate", gtk_accel_group_get_default(), GDK_N, 0, GTK_ACCEL_VISIBLE ); you're using the global default accelerator group that _all_ windows will resort to if they can't handle the keypress. what you actually want is to create a new accelerator group per menubar, install the accelerators on that and add it to the window with gtk_window_add_accel_group(). i can see why you used this though, i'll put the foolowing on my 2.0 todo list: 1) provide gtk_menu_bar_get_accel_group() (creates the menubar accel group for you, you just need to add it to the window then) 2) gtk_window_get_default_accel_group() (should be provided by havoc's recent patches already), to be used for non-menu, per-window accelerators 3) rename gtk_accel_group_get_default() to gtk_accel_group_get_global(), since that's how it's really used. [i didn't actually run your programm when i saw your usage of gtk_accel_group_get_default(), so if the above advice doesn't fix things for you, bug me again ;)] Hmmm... I may be misunderstanding your proposed solution. The reason I used gtk_accel_group_default() is because that is where the user defined accelerators for the menus wind up. Here is the substitution if you would like to see it. #if 0 GtkWidget * menuitem = gtk_menu_item_new_with_label( "Do Something" ); gtk_menu_append( GTK_MENU(submenu), menuitem ); gtk_signal_connect( GTK_OBJECT(menuitem), "activate", GTK_SIGNAL_FUNC(MenuItemEventHandler), NULL ); /* Just for kicks let's add an accelerator programmatically */ gtk_widget_add_accelerator( menuitem, "activate", gtk_accel_group_get_default(), GDK_N, 0, GTK_ACCEL_VISIBLE ); gtk_widget_show( menuitem ); #else GtkWidget * menuitem1 = gtk_menu_item_new_with_label( "Do Something" ); gtk_menu_append( GTK_MENU(submenu), menuitem1 ); gtk_signal_connect( GTK_OBJECT(menuitem1), "activate", GTK_SIGNAL_FUNC(MenuItemEventHandler), NULL ); GtkAccelGroup* accelgroup = gtk_accel_group_new(); gtk_accel_group_add( accelgroup, GDK_N, (GdkModifierType)0, GTK_ACCEL_VISIBLE, GTK_OBJECT(menuitem), "activate" ); gtk_accel_group_attach( accelgroup, GTK_OBJECT(menu) ); gtk_widget_show( menuitem ); /* Now let's add another menu option to test where the user * defined accelerator will be assigned. Our accelerator or the default? */ GtkWidget * menuitem2 = gtk_menu_item_new_with_label( "Do Something Else" ); gtk_menu_append( GTK_MENU(submenu), menuitem2 ); gtk_signal_connect( GTK_OBJECT(menuitem2), "activate", GTK_SIGNAL_FUNC(MenuItemEventHandler), NULL ); gtk_accel_group_attach( accelgroup, GTK_OBJECT(menuitem2) ); gtk_widget_show( menuitem2 ); #endif The user defined assignment happens at runtime, not at creation time. The function you identified was only to avoid the hassle of resetting the accelerator key during test cases, if multiple runs were required to nail down the problem. Sorry :) I imagine the solution would look something more like : 1) Create the menubar accelerator at creation time. 2) Do all of what you proposed. I'd imagine the gtk_menu_bar_get_accel_group() would be reduced to an accessibility function. 3) Change menu bar accelerator assignment so that they
Re: Accelerators and gtk_grab_add
On Wed, 26 Jul 2000, Matt Carlson wrote: Tim Janik wrote: ok, that's something to work from. the problem is the accelerator you setup programmatically: /* Just for kicks let's add an accelerator programmatically */ gtk_widget_add_accelerator( menuitem, "activate", gtk_accel_group_get_default(), GDK_N, 0, GTK_ACCEL_VISIBLE ); you're using the global default accelerator group that _all_ windows will resort to if they can't handle the keypress. what you actually want is to create a new accelerator group per menubar, install the accelerators on that and add it to the window with gtk_window_add_accel_group(). i can see why you used this though, i'll put the foolowing on my 2.0 todo list: 1) provide gtk_menu_bar_get_accel_group() (creates the menubar accel group for you, you just need to add it to the window then) 2) gtk_window_get_default_accel_group() (should be provided by havoc's recent patches already), to be used for non-menu, per-window accelerators 3) rename gtk_accel_group_get_default() to gtk_accel_group_get_global(), since that's how it's really used. [i didn't actually run your programm when i saw your usage of gtk_accel_group_get_default(), so if the above advice doesn't fix things for you, bug me again ;)] Hmmm... I may be misunderstanding your proposed solution. The reason I used gtk_accel_group_default() is because that is where the user defined accelerators for the menus wind up. Here is the substitution if you would like to see it. what do you mean "that is where the user defined accelerators for the menus wind up"? who would put them there except you? there's only one global default_accelerator group, and you rarely want to really use it, it's featured by every window at every time. #if 0 GtkWidget * menuitem = gtk_menu_item_new_with_label( "Do Something" ); gtk_menu_append( GTK_MENU(submenu), menuitem ); gtk_signal_connect( GTK_OBJECT(menuitem), "activate", GTK_SIGNAL_FUNC(MenuItemEventHandler), NULL ); /* Just for kicks let's add an accelerator programmatically */ gtk_widget_add_accelerator( menuitem, "activate", gtk_accel_group_get_default(), GDK_N, 0, GTK_ACCEL_VISIBLE ); gtk_widget_show( menuitem ); #else GtkWidget * menuitem1 = gtk_menu_item_new_with_label( "Do Something" ); gtk_menu_append( GTK_MENU(submenu), menuitem1 ); gtk_signal_connect( GTK_OBJECT(menuitem1), "activate", GTK_SIGNAL_FUNC(MenuItemEventHandler), NULL ); GtkAccelGroup* accelgroup = gtk_accel_group_new(); ^ creates an accel_group with ref_count=1 gtk_accel_group_add( accelgroup, GDK_N, (GdkModifierType)0, GTK_ACCEL_VISIBLE, GTK_OBJECT(menuitem), "activate" ); gtk_accel_group_add() is an internal function, take a look at the header file. use gtk_widget_add_accelerator() as you did above. gtk_accel_group_attach( accelgroup, GTK_OBJECT(menu) ); gtk_accel_group_attach() is an internal function also, i said "add it to the window with gtk_window_add_accel_group()" ;) gtk_widget_show( menuitem ); /* Now let's add another menu option to test where the user * defined accelerator will be assigned. Our accelerator or the default? */ GtkWidget * menuitem2 = gtk_menu_item_new_with_label( "Do Something Else" ); gtk_menu_append( GTK_MENU(submenu), menuitem2 ); gtk_signal_connect( GTK_OBJECT(menuitem2), "activate", GTK_SIGNAL_FUNC(MenuItemEventHandler), NULL ); gtk_accel_group_attach( accelgroup, GTK_OBJECT(menuitem2) ); gtk_widget_show( menuitem2 ); this code doesn't make much sense ;) #endif but that's probably due to me not being clear enough, lemme set out pseudo flow here: w = create_window (); mb = menubar_new (); mb_ag = gtk_accel_group_new (); // create menubar's accel group /* save it for later reference if needed: */ gtk_object_set_data_full (mb, "accel-group", mb_ag, gtk_accel_group_unref); /* create menu items and install accelerators */ mi1 = menu_item_new (); gtk_widget_add_accelerator(mi1, "activate", mb_ag, GDK_N, 0, GTK_ACCEL_VISIBLE); mi2 = menu_item_new (); gtk_widget_add_accelerator(mi2, "activate", mb_ag, GDK_X, 0, GTK_ACCEL_VISIBLE); /* complete widget tree */ add (w, mb); m = menu_new(); add (mb, m); add (m, mi1); add (m, mi2); /* for mi1 and mi2 we've now accelerators setup in mb_ag, now we * have to install it on some key-handling object to take effect. * that key handling object could only meaningfull be the window * that we added the menubar to, so we do: */ gtk_window_add_accel_group (w, mb_ag); if you create a _new_ window with a new menu bar, you also use a new accel group
Re: Accelerators and gtk_grab_add
Should the attached program make some changes before it can be compiled? Otherwise how to compile? int main( int argc, char ** argv ) { gtk_init( argc, argv ); GtkWidget * window = gtk_window_new( GTK_WINDOW_TOPLEVEL ); gtk_window_set_position( GTK_WINDOW(window), GTK_WIN_POS_CENTER ); gtk_widget_set_usize( window, 200, 200 ); int main( int argc, char ** argv ) { GtkWidget * window ; gtk_init( argc, argv ); window = gtk_window_new( GTK_WINDOW_TOPLEVEL ); ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
[Q] How many arguments can I use in GTK_SIGNAL_FUNC
Hi all~ Examaple 1) gtk_signal_connect(GTK_OBJECT(clist), "select_row", GTK_SIGNAL_FUNC(selection_made), NULL); void selection_made( GtkWidget *clist, gintrow, gintcolumn, GdkEventButton *event, gpointerdata ) { . . } selection_made function have 5 arguments. but gtk_signal_connect function's last arguments is NULL. Example 2) gtk_signal_connect (GTK_OBJECT (button), "clicked", GTK_SIGNAL_FUNC (callback), (gpointer) "cool button"); void callback( GtkWidget *widget, gpointer data ) { g_print ("Hello again - %s was pressed\n", (char *) data); } callback function have 2 arguments. and gtk_signal_func's last arguments is strings. in this case, I want to know How many arguments can I use in callback fuction. and What arguments can I use? Thank you... ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accelerators and gtk_grab_add
hi matt, sorry for replying to your email in public, but this is the second private email on this topic and both raise the same point which actually results out of a misconception in gtk (which is also why i put gtk-devel on the Cc: list). i'll first quote my reply to that other email, since it pretty much covers the issue already: On Thu, 27 Jul 2000, Tim Janik wrote: On Thu, 27 Jul 2000, someone wrote: On Thu, 27 Jul 2000, Tim Janik wrote: Hmmm... I may be misunderstanding your proposed solution. The reason I used gtk_accel_group_default() is because that is where the user defined accelerators for the menus wind up. Here is the substitution if you would like to see it. what do you mean "that is where the user defined accelerators for the menus wind up"? who would put them there except you? Exactemundo! But then, can you explain why menu's created with GtkItemFactory allow users to change the accelerators? that's a generic feature not limited to teh item factory. the item factory just does a few extra things: 1) provides a simple interface to setup a mass of menu items in a hirachy 2) maintains a global hash table for menupath (string) - accelerator (string) association 3) provides functions to read in and write out that global hash table to from rc files 4) override accelerator specifications in 1) according to loaded data stored in 2) 5) keep 2) uptodate according to runtime changes made by the user, so the updated data is kept persistent across programm invokations using the functions from 3) the ability to change accelerators at runtime is implemented in GtkMenu actually, it either eplaces the existing accelerator of a menu item in the accel group that the accelerator is stored in, or if there's no accelerator uses the global default accelerator group . now writing that out, i actually see your problem ;) for 2.0, i'll probably change that use the corresonding menu's accelerator group instead of the global accelerator group, since that behaviour is hardly desired ;) but that carries the problem of that accelerator group not neccessarily being installed on the corresponding window, which would make the accelerator appear on the GUI but not work ;( hm, gotta ponder this a bit more, i'm kinda getting a feeling that the explicit add_accel_group() call on windows/menus we currently require might not be the all and end of it... ;) --- ciaoTJ On Wed, 26 Jul 2000, Matt Carlson wrote: what do you mean "that is where the user defined accelerators for the menus wind up"? who would put them there except you? Sorry. I guess I wasn't too clear here. If you remove the gtk_widget_add_accelerator() line you highlighted in your 1st response and then run the program, the menu item "Do Something" will accept user keystrokes which dynamically seta the key accelerator for that menu item. I like this behavior and would like to keep it. Here's where I get confused. How do I tell gtk that I would like a group of widgets to be a part of an accelerator group, but not assign their accelerator keys (i.e. leave it to the user)? To phrase the question from another perspective, how to I tell gtk not to assign whatever accelerator the user sets to the default accelerator, but to an accelerator that I can turn off when displaying a modal dialog? The answers to these questions are what I'm trying to get from the discussion. I apoligize for being a thorn. you haven't, instead, i should have figured the issue earlier ;) as written above gtkmenu.c handles the accelerator installation. if the item factory is used, it automatically assures every menu gets the factory's accel group and that is added to the main window. that's also where newly added accelerators end up, so they are kept per-window. if a gtkmenu is created manually, it doesn't have that accelerator group though, and it can't create it on demand, since it wouldn't know what menu to add it to (it could be a popup menu that doesn't have the window(s) it is used in it's runtime widget tree as an anchestor). so instead it uses the global default accelerator group, returned from gtk_accel_group_get_default(). every window resorts to that group if it couldn't find an accelerator binding for a key being pressed. that's why you have window A where the user installed a new accelerator on menu item A.m, and then popup a modal dialog B that resorts to activating A.m if the accelerator is pressed. as a workaround for 1.2.x, follow my advice as far as i gave it, and do one extra thing ;) the accel group that you create per menu bar has to be added to all menus you create, so they don't store the new accelerators in the global default group. you do that by ading to your code, such as: w = window_new (); mb = menu_bar_new (); mb_ag = gtk_accel_group_new (); add (w, mb); gtk_window_add_accel_group (w, mb_ag); mi = menu_item_new (); ad (mb,
Re: [Q] How many arguments can I use in GTK_SIGNAL_FUNC
Woo-Sick Choi [EMAIL PROTECTED] writes: in this case, I want to know How many arguments can I use in callback fuction. and What arguments can I use? It depends on the signal, each signal has its own matching callback type that's expected. My book has info on how to find out the callback type: http://developer.gnome.org/doc/GGAD// Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list