Re: Argument passing / GTKTextView
- you can either use gtk_object_set_data() on the widget, to set associate a key string with a gpointer data element: gtk_object_set_data(GTK_OBJECT(widget),"struct",structure); then in the callback: structure = gtk_object_get_data(GTK_OBJECT(widget),"struct"); or pass a structure containing everything (gints,other structs, etc) From: Raymond Wan Subject: Argument passing / GTKTextView Date: Wed, 13 Jun 2001 13:01:54 +1000 (EST) > > Hi all, > > My GTK+ program is getting fairly large and until now, I've had > one big global variable structure that has all the information I need. I > was wondering if there is an alternative to this. > > The program I'm having seems to be in the call back functions, > which I don't seem to entirely understand. For example, in a call back > function such as this: > > void closeChildWindow (GtkWidget *widget, gpointer data) > > I've been passing ints from my program using GPOINTER_TO_INT and > GINT_TO_POINTER. But, can I pass anything else, such as a C pointer to a > structure or can I pass more than one argument? If so, how would I do > this? > > Also, a separate question...does anyone know of a GTKTextView > example (GTK 1.3) that is slightly more involved than the HTML GTK > Reference under the section Text Widget Overview? Possibly using tags, > marks, and iterators? > > Thank you! > > Ray > > > > ___ > gtk-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/gtk-list > > -- Charlie Schmidt - <[EMAIL PROTECTED]> ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
Paul Davis <[EMAIL PROTECTED]> writes: > >>>Widgets are sent key presses before GTK+ checks for focus keys. If the > >>>widget handles the key press in its event handler and returns TRUE, > >>>then GTK+ will not check for tab/arrows. > > not true in GTK+ 1.2. you have to stop the signal emission as well. > > in GTK+ 1.2, the default handler is run regardless of the return > status of other connected handlers. the docs for GTK+ 1.2 do not make > this particularly clear. i believe that in GTK+ 1.3/2.0, this is no > longer true, and things work the way the docs tend to suggest. In this case, what was being discussed was the return value of the default handler, so stopping emission isn't necessary - if someone connects another signal handler using gtk_signal_connect_after() they mean to override the return value. > its the default handler for key press events in a GtkWindow that > controls the movement of focus between widgets in that window. the > handler is executed unless you block the emission in the widget that > currently has focus (i.e. the one that the window directs the events > to). This isn't quite right. In GTK+-1.2 - for every time a signal is run, up to three things may happen: 1) signal handlers run 2) the default handler runs 3) Signal handlers connected with gtk_signal_connect_after run. The return value from the signal is the return value from the last of these; so if 1) returns TRUE meaning "handled", 2) will still be run and override this unless gtk_signal_emit_stop_by_name() is called. In GTK+-2 a TRUE return immediately stops emission. However - this all only applies to a SINGLE signal emission - even in 1.2, if the result of sending the widget to the focus widget is TRUE, no further handling will be done. http://people.redhat.com/otaylor/tmp/key-handling.eps is a diagram of key handling in GTK+-1.2 which may help (or may further confuse) > as i've mentioned, i find it easier to do all this stuff using a key > snooper, which allows you to completely bypass all of GTK+'s builtin key handling is quite complicated enough without getting key snoopers involved! The idea of key snoopers was to handle hotkeys that would work in any window - like the hotkey to invoke the GLE widget tree debugger. If you have a particular GtkWindow, a connection to "key_press_event" on the toplevel already allows you to override all key handling behavior. Regards, Owen [ Actually the situation with Komodo is rather more complicated again - having GTK+ widgets inside mozilla is basically two inter-toolkit widget embeddings. GtkWindow Mozilla content area GtkMozBox holding GTK+ widgets (GtkMozBox derives from GtkWindow!) ] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
>>>Widgets are sent key presses before GTK+ checks for focus keys. If the >>>widget handles the key press in its event handler and returns TRUE, >>>then GTK+ will not check for tab/arrows. not true in GTK+ 1.2. you have to stop the signal emission as well. in GTK+ 1.2, the default handler is run regardless of the return status of other connected handlers. the docs for GTK+ 1.2 do not make this particularly clear. i believe that in GTK+ 1.3/2.0, this is no longer true, and things work the way the docs tend to suggest. its the default handler for key press events in a GtkWindow that controls the movement of focus between widgets in that window. the handler is executed unless you block the emission in the widget that currently has focus (i.e. the one that the window directs the events to). as i've mentioned, i find it easier to do all this stuff using a key snooper, which allows you to completely bypass all of GTK+'s builtin key handling. --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
Ken Simpson wrote: >>Widgets are sent key presses before GTK+ checks for focus keys. If the >>widget handles the key press in its event handler and returns TRUE, >>then GTK+ will not check for tab/arrows. >> >>For instance, this is how GtkText prevents a tab key from tabbing out >>of the GtkText widget. >> > > Hrm.. I guess the problem with Mozilla is that I need the keypress event > to live on for a little while so that Mozilla can grab it. I can't just > kill all the navigation keys -- Mozilla needs them so that it can farm > them out to its command system. > > i.e., the order of operations should be: > > 1. Mozilla grabs ALL gdk events and processes them in its own handler >(i.e. gdk_event_handler_set (handle_gdk_event, NULL, NULL);) > > 2. Events are then farmed out to the widget from which they >originated (an nsWindow pointer is stored in the user data of the >event's any.window object). > > 3. The widget's key_press handler returns 0 for any keypress which is not >something simple, like [A-Za-z0-9_-+] etc.. > > 4. (hopefully) The key_press event travels up the window hierarchy to the >main Mozilla window, where it is ground through the Mozilla keybinding >system and produces some result. The event then should _die_. > > The problem is that, between stages 3 and 4, gtk intercepts the key press > and changes the focus. Yuck. I don't think the fix here is going to be > easy... > > Ideas?? What is it that intercepts the key presses? Is it the gtkwindow class that is being used by the mozbox? Or is it being farmed all the way up to the toplevel? We might need to override the keypress handler for the mozbox class so that the default gtkwindow handler doesn't change focus on you like it sounds like is happening. --Chris ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Argument passing / GTKTextView
Hi all, My GTK+ program is getting fairly large and until now, I've had one big global variable structure that has all the information I need. I was wondering if there is an alternative to this. The program I'm having seems to be in the call back functions, which I don't seem to entirely understand. For example, in a call back function such as this: void closeChildWindow (GtkWidget *widget, gpointer data) I've been passing ints from my program using GPOINTER_TO_INT and GINT_TO_POINTER. But, can I pass anything else, such as a C pointer to a structure or can I pass more than one argument? If so, how would I do this? Also, a separate question...does anyone know of a GTKTextView example (GTK 1.3) that is slightly more involved than the HTML GTK Reference under the section Text Widget Overview? Possibly using tags, marks, and iterators? Thank you! Ray ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
>i.e., the order of operations should be: > >1. Mozilla grabs ALL gdk events and processes them in its own handler > (i.e. gdk_event_handler_set (handle_gdk_event, NULL, NULL);) > >2. Events are then farmed out to the widget from which they > originated (an nsWindow pointer is stored in the user data of the > event's any.window object). > >3. The widget's key_press handler returns 0 for any keypress which is not > something simple, like [A-Za-z0-9_-+] etc.. > >4. (hopefully) The key_press event travels up the window hierarchy to the > main Mozilla window, where it is ground through the Mozilla keybinding > system and produces some result. The event then should _die_. > >The problem is that, between stages 3 and 4, gtk intercepts the key press >and changes the focus. Yuck. I don't think the fix here is going to be >easy... use a key snooper instead of an event handler. --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: drawing_area->window != NULL
Thanks for your help...
Ok I've got it! The window is not realized yet, so I
put the drawing code in the expose_event function,
but...
It only works if I connect the expose event signal to
the drawing_area member, not if I connect it to the
entire structure... why?
This is using the entire structure (That's how I want
it). It doesn't work...
/*/
typedef struct _GtkNewLabel GtkNewLabel;
struct _GtkNewLabel
{
GtkVBox vbox;
GtkWidget *drawing_area;
};
static void gtk_newlabel_init (GtkNewLabel *newlabel)
{
GtkWidget *table;
table = gtk_table_new (1, 1, TRUE);
gtk_container_add (GTK_CONTAINER (newlabel),
table);
gtk_widget_show (table);
newlabel->drawing_area = gtk_drawing_area_new ();
gtk_table_attach_defaults (GTK_TABLE(table),
newlabel->drawing_area, 0, 1, 0, 1);
gtk_widget_show (GTK_WIDGET (newlabel));
gtk_signal_connect(GTK_OBJECT (newlabel),
"expose_event",
GTK_SIGNAL_FUNC
(on_gtk_newlabel_expose_event), &newlabel);
}
void on_gtk_newlabel_expose_event (GtkNewLabel
*newlabel)
{
GdkGC *gc_back, *gc_fore;
GdkDrawable *drawable;
drawable = newlabel->drawing_area->window;
gc_back = GetPen (NewColor (newlabel->back_red,
newlabel->back_green,
newlabel->back_blue),
drawable);
}
GdkGC *GetPen (GdkColor *c, GdkDrawable *drawable)
{
GdkGC *gc;
gc = gdk_gc_new (drawable);
gdk_gc_set_foreground (gc, c);
return (gc);
}
GdkColor *NewColor (long red, long green, long blue)
{
GdkColor *c = (GdkColor *) g_malloc (sizeof
(GdkColor));
c->red = red;
c->green = green;
c->blue = blue;
gdk_color_alloc (gdk_colormap_get_system (), c);
return (c);
}
/*/
And this is using the drawing_area member, It Works...
static void gtk_newlabel_init (GtkNewLabel *newlabel)
{
GtkWidget *table;
table = gtk_table_new (1, 1, TRUE);
gtk_container_add (GTK_CONTAINER (newlabel),
table);
gtk_widget_show (table);
newlabel->drawing_area = gtk_drawing_area_new ();
gtk_table_attach_defaults (GTK_TABLE(table),
newlabel->drawing_area, 0, 1, 0, 1);
gtk_widget_show (newlabel->drawing_area);
gtk_signal_connect(GTK_OBJECT
(newlabel->drawing_area), "expose_event",
GTK_SIGNAL_FUNC
(on_gtk_newlabel_expose_event), NULL);
}
void on_gtk_newlabel_expose_event (gpointer data)
{
GdkGC *gc_back, *gc_fore;
GdkDrawable *drawable = GTK_WIDGET(data)->window;
drawable = newlabel->drawing_area->window;
gc_back = GetPen (NewColor (newlabel->back_red,
newlabel->back_green,
newlabel->back_blue),
drawable);
}
So... what I'm doing wrong?
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
> Widgets are sent key presses before GTK+ checks for focus keys. If the > widget handles the key press in its event handler and returns TRUE, > then GTK+ will not check for tab/arrows. > > For instance, this is how GtkText prevents a tab key from tabbing out > of the GtkText widget. Hrm.. I guess the problem with Mozilla is that I need the keypress event to live on for a little while so that Mozilla can grab it. I can't just kill all the navigation keys -- Mozilla needs them so that it can farm them out to its command system. i.e., the order of operations should be: 1. Mozilla grabs ALL gdk events and processes them in its own handler (i.e. gdk_event_handler_set (handle_gdk_event, NULL, NULL);) 2. Events are then farmed out to the widget from which they originated (an nsWindow pointer is stored in the user data of the event's any.window object). 3. The widget's key_press handler returns 0 for any keypress which is not something simple, like [A-Za-z0-9_-+] etc.. 4. (hopefully) The key_press event travels up the window hierarchy to the main Mozilla window, where it is ground through the Mozilla keybinding system and produces some result. The event then should _die_. The problem is that, between stages 3 and 4, gtk intercepts the key press and changes the focus. Yuck. I don't think the fix here is going to be easy... Ideas?? TTUL Ken -- New! ASPN - ActiveState Programmer Network Essential programming tools and information http://www.ActiveState.com/ASPN ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: _() macro?
> "Ron" == Ron Steinke <[EMAIL PROTECTED]> writes:
> I'm seeing a lot of elements like:
> _("some string")
> in function calls. Is _() a macro? What does it do?
It either calls gettext with the string as a parameter so that the
program uses the translated strings. Otherwise (if i18n is not enabled
during compilation) it just returns the same string.
W.
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
_() macro?
I'm seeing a lot of elements like:
_("some string")
in function calls. Is _() a macro? What does it do?
Ron Steinke
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
drawing_area->window!=NULL
Hi!
I'm trying to create a new widget, this is my init
object function:
static void gtk_newlabel_init (GtkNewLabel *newlabel)
{
GtkWidget *table;
GdkGC *gc;
table = gtk_table_new (1, 1, TRUE);
gtk_container_add (GTK_CONTAINER (newlabel),
table);
gtk_widget_show (table);
newlabel->drawing_area = gtk_drawing_area_new ();
gtk_table_attach_defaults (GTK_TABLE(table),
newlabel->drawing_area, 0, 1, 0, 1);
gtk_widget_show (newlabel->drawing_area);
gc = GetPen (NewColor (0x, 0x, 0x),
newlabel->drawing_area->window);
}
/*
These functions, returns a GdkGC * color;
*/
GdkGC *GetPen (GdkColor *c, GdkDrawable *drawable)
{
GdkGC *gc;
gc = gdk_gc_new (drawable);
gdk_gc_set_foreground (gc, c);
return (gc);
}
GdkColor *NewColor (long red, long green, long blue)
{
GdkColor *c = (GdkColor *) g_malloc (sizeof
(GdkColor));
c->red = red;
c->green = green;
c->blue = blue;
gdk_color_alloc (gdk_colormap_get_system (), c);
return (c);
}
/*
The Widget structure
*/
struct _GtkNewLabel
{
GtkVBox vbox;
GtkWidget *drawing_area;
};
/*/
Why Gdk returns:
Gdk-CRITICAL **: file gdkgc.c: line 51
(gdk_gc_new_with_values): assertion `window != NULL'
failed.
Gdk-CRITICAL **: file gdkgc.c: line 456
(gdk_gc_set_foreground): assertion `gc != NULL'
failed.
It doesn't work even if I show the
newlabel->drawing_area widget or not...
Why?
Thanks!
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GDK-PixBuf
Thank you very much, everybody!
> In GTK 2, you could just do:
> image = gtk_image_new_from_file ("test.jpg");
> gtk_container_add (GTK_CONTAINER (window), image);
>
> So look forward to that. ;-)
>
I am looking forward to that! In the meantime, since there's been a lot of questions
on a working example for Gtk1.2, I'm posting my solution, hoping someone too will find
it useful!
#include
#include
#include
#include "gtk/gtk.h"
#include "gdk-pixbuf/gdk-pixbuf.h"
GdkPixmap *picture;
static gint expose_event (GtkWidget *widget, GdkEventExpose *event)
{
gdk_draw_pixmap (widget->window, widget->style->fg_gc[GTK_WIDGET_STATE (widget)],
picture, event->area.x, event->area.y, event->area.x, event->area.y,
event->area.width, event->area.height);
return FALSE;
}
int main (int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *vbox;
GdkPixbuf *image;
GdkGC *setup;
GtkWidget *drawing_area;
gtk_init (&argc, &argv);
printf ("\n");
if (gdk_init_check (&argc, &argv) == 1) printf ("Connection to X Server Successful\n");
if (gdk_init_check (&argc, &argv) == 0) printf ("Connection to X Server Failed\n");
printf ("Display: %s\n", gdk_get_display () );
printf ("ScrWidth: %d\n", gdk_screen_width () );
printf ("ScrHeight: %d\n", gdk_screen_height () );
gtk_widget_push_visual (gdk_rgb_get_visual ());
gtk_widget_push_colormap (gdk_rgb_get_cmap());
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_signal_connect (GTK_OBJECT (window), "destroy", GTK_SIGNAL_FUNC (gtk_main_quit),
"WM destroy");
gtk_widget_set_usize (window, 512, 512);
gtk_widget_pop_visual ();
gtk_widget_pop_colormap ();
vbox = gtk_vbox_new (FALSE, 0);
gtk_container_add (GTK_CONTAINER (window), vbox);
drawing_area = gtk_drawing_area_new ();
gtk_drawing_area_size (GTK_DRAWING_AREA (drawing_area), 512, 512);
gtk_box_pack_start (GTK_BOX (vbox), drawing_area, TRUE, TRUE, 0);
gtk_signal_connect (GTK_OBJECT (drawing_area), "expose_event",
(GtkSignalFunc) expose_event, NULL);
image = gdk_pixbuf_new_from_file ("test.gif");
picture = gdk_pixmap_new (NULL, 512, 512, gtk_widget_get_visual (drawing_area)->depth);
setup = gdk_gc_new (picture);
printf ("Visual:%d\n", gtk_widget_get_visual (drawing_area)->depth);
printf ("Channels: %d\n", gdk_pixbuf_get_n_channels (image));
printf ("Width: %d\n", gdk_pixbuf_get_width (image));
printf ("Height:%d\n", gdk_pixbuf_get_height (image));
printf ("Alpha: %d\n", gdk_pixbuf_get_has_alpha (image));
printf ("Bits: %d\n", gdk_pixbuf_get_bits_per_sample (image));
printf ("Rowstride: %d\n", gdk_pixbuf_get_rowstride (image));
printf ("\n");
gdk_pixbuf_render_to_drawable (image, picture, setup, 0, 0, 0, 0, 512, 512,
GDK_RGB_DITHER_NONE, 0, 0);
gdk_draw_pixmap ((GdkDrawable *)drawing_area, setup, picture, 0, 0, 0, 0, 512, 512);
gtk_widget_show_all (window);
gtk_main();
return (0);
}
Thanks again!
Andrej
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk font dependancies
I had the same problem and partially solved it (though i still get the squares every so often, particuallarly when its looking for helvetica. Although, other apps which use helvetica display it just fine. anyway, here's the relevant config file from /etc/X11/fs catalogue = /usr/X11R6/lib/X11/fonts/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/100dpi:unscaled, /usr/X11R6/lib/X11/fonts/75dpi, /usr/X11R6/lib/X11/fonts/100dpi, /usr/share/fonts/default/Type1, /usr/X11R6/lib/X11/fonts/latin2/75dpi, /usr/X11R6/lib/X11/fonts/latin2/100dpi, /usr/X11R6/lib/X11/fonts/truetype, #/usr/X11R6/lib/X11/fonts/tt, /usr/X11R6/lib/X11/fonts/latin2/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/latin2/100dpi:unscaled, /usr/X11R6/lib/X11/fonts/local, /usr/X11R6/lib/X11/fonts/CID, /usr/X11R6/lib/X11/fonts/misc:unscaled, /usr/X11R6/lib/X11/fonts/misc, /usr/X11R6/lib/X11/fonts/Type1, /usr/X11R6/lib/X11/fonts/Speedo On Mon, 11 Jun 2001, Ira Weiny wrote: > > I am running linuxppc-2000-Q4 on my Apple Titanium PowerBook. I am > _not_ runnig gnome just straight enlightenment. I have rpm's for > XFree86 installed (4.0.99) version. > > My question is: where does gtk get it's fonts from? (xfs?) I have a > couple of > programs, namely gscanbus and gaim which don't display certian text > correctly. I have messed with xfs and I have _many_ font's installed > but I still get "square" characters in certian dialogs. > > Here is a list of the font packages I have intsalled. > > $ rpm -qa | grep font > ghostscript-fonts-5.50-1 > chkfontpath-1.7-2 > XFree86-ISO8859-2-100dpi-fonts-4.0.99.3-0b > urw-fonts-2.0-4 > XFree86-ISO8859-2-75dpi-fonts-4.0.99.3-0b > tetex-fonts-1.0.6-11a > XFree86-cyrillic-fonts-4.0.99.3-0b > XFree86-100dpi-fonts-4.0.99.3-0b > XFree86-75dpi-fonts-4.0.99.3-0b > XFree86-ISO8859-7-100dpi-fonts-1.0-4 > XFree86-ISO8859-7-75dpi-fonts-1.0-4 > XFree86-ISO8859-7-Type1-fonts-1.0-4 > XFree86-ISO8859-9-100dpi-fonts-2.1.2-10 > XFree86-ISO8859-9-75dpi-fonts-2.1.2-10 > > Thanks in advance, > Ira Weiny > [EMAIL PROTECTED] > > ** Sent via the linuxppc-user mail list. See http://lists.linuxppc.org/ > > ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
>Widgets are sent key presses before GTK+ checks for focus keys. If the >widget handles the key press in its event handler and returns TRUE, >then GTK+ will not check for tab/arrows. Owen, I'm suprised! You must be too used to Gtk 1.3 :) Returning TRUE by itself isn't enough to stop focus navigation under 1.2 ... ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
>I apologize if I wasn't clear in my email. The problem is that pressing >keys such as the arrow keys, the backspace, and the tab cause my widget to >lose focus and for its containing window to gain focus. The key press >event first hits my widget and then, once I have returned 0 from the >key_press handler, control returns to gtk, the focus is removed, and the >event is propagated to the containing window where it is handled. > >So I suppose it could have something to do with gtk's support for moving >the focus with tab, etc.. How does one turn this functionality off? you can't turn it off per se. you have two choices: 1) on a per-widget basis, catch key_press/key release events. if they are for one of the navigation keys, do nothing except: gtk_signal_emit_block_by_name (...); return TRUE; 2) install a global key snooper, inspect all key press events, and discard or translate the navigation keys. and yes, i don't like it any more than you do :) --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
Havoc Pennington <[EMAIL PROTECTED]> writes: > Ken Simpson <[EMAIL PROTECTED]> writes: > > Is this the code which performs automatic focus changing in response to > > keypresses? It certainly seems to fit the symptoms :) > > Hmm.. But there doesn't appear any way of "turning it off". > > > > Yep, that's the code. Writing other widget sets is not what GTK is > made for, so we don't have an easy way to change this. ;-) That's why > Chris was working on Xlib Mozilla for a while I imagine. > > However you can do a hack to GtkWindow - connect to key_press_event, > when you see one of these keys call gtk_signal_emit_stop_by_name to > kill the event. Or subclass GtkWindow and override the default signal > handler and do something a bit differently there. Should be able to > get it working. You could possibly also override set_focus or > grab_focus and do some sort of hack. > > You may well have weird interactions with GtkMozEmbed and apps like > Galeon... You shouldn't need anything this complicated, or this likely to break stuff. Widgets are sent key presses before GTK+ checks for focus keys. If the widget handles the key press in its event handler and returns TRUE, then GTK+ will not check for tab/arrows. For instance, this is how GtkText prevents a tab key from tabbing out of the GtkText widget. Regards, Owen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtkclist
Just access the GtkClist widget structure member "rows" and this will tell you how many items there are in the Clist. GtkWidget *CList_Widget; gint rows; row = GTK_CLIST(CList_Widget)->rows; You can then loop throught the clist based on the "rows" variable. for (i=0; i > Hello everybody: > how can i know how many rows are there in a gtkclist > Is there any conversion macro to get a glist from a gtkclist??? > > ___ > gtk-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/gtk-list -- __.--'\ \.__./ /'--.__ _.-' '.__.''.__.' '-._ .' '. / Matt Keenan (MattMan)\ | CDE, Sun Microsystems Ireland | | GO JAGUARS !! | | E-Mail : [EMAIL PROTECTED] | |[EMAIL PROTECTED] | | URL: http://www.iol.ie/~mattman | | Phone : +353 1 8199251, Sun Ext : 19251 | \ .---. .---. / '._.' '.''..''.' '._.' '-./\ /\.-' '' ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
