Re: GTK+ CVS access FAQ out of date
Francesco, El Mon, 09-04-2007 a las 16:08 +0200, Francesco Montorsi escribió: Hi, the only document I could find for checking out the CVS repo of GTK+ is this: http://www.gtk.org/faq/#AEN325 and it seems out of date since if I follow the istructions I get: [EMAIL PROTECTED]:~/work$ CVSROOT=':pserver:[EMAIL PROTECTED]:/cvs/gnome' [EMAIL PROTECTED]:~/work$ export CVSROOT [EMAIL PROTECTED]:~/work$ cvs login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvs/gnome CVS password: Unknown host anoncvs.gnome.org. [EMAIL PROTECTED]:~/work$ cvs -z3 get gtk+ Unknown host anoncvs.gnome.org. What is the up2date URL for getting the GTK+ CVS repo? As others have pointed out, GNOME uses SVN now, instead of CVS. As I know there is people in gtk-devel-list@ currently updating the GTK+ webpages, I've added this list to the CC, with the hope we will see a patch for the webpage (which you could prepare yourself, if you have the time :-) Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
button_press_event signal in GtkCellRendererToggle
Hi, How can i add a GtkCellRendererToggle the button_press_event signal without making a new widget? I have a GtkTreeView with a CheckBox (GtkCellRendererToggle) in it and I want the user modify its value by clicking on it. How can I do this? Thanks in advance. Matias. ___ gtk-app-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How do you develop you GTK code?
Hi Diogo,
On Fri, 13 Apr 2007 23:57:12 -0300 you wrote:
I am curious about it and really want to know: How do you develop your GTK
codes?
Mostly by hand.
Before coming to GTK I had done some GUI apps on Windows with Borland C++
Builder, which is quite nice for drawing fixed size dialogs with a small
selection of different widgets. I had also briefly tried customizing a GUI
written in Tcl/Tk (and later Python/Tkinter) with no RAD support.
My first few GTK apps were hand written using tables of widgets. It does make
it harder to visualize what you're creating as you go, but anyone that's done
HTML will be accustomed to how tables work. If you draw your GUI out on paper,
it's really not hard to code from that.
I tried Glade more recently, thinking it would be easier, like the Borland
tool. Well, it does work as a drawing tool, and I guess if you use libglade and
don't care how it ends up being implemented then it isn't too bad. But the code
generator (now deprecated) produces something truly horrid.
The other thing to bear in mind is this:
If you have a row or column of similar widgets, say buttons, then a tool like
Glade or BCB requires you to place every one individually. Writing the code by
hand lets you do:
for ( cc=0; cc10; cc++ )
{
MyButtons[cc] = gtk_button_new (..);
gtk_box_pack_start ( );
}
This is even more relevant if the number of buttons isn't known at design time!
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On Fri, 13 Apr 2007 23:57:12 -0300 you wrote: I am curious about it and really want to know: How do you develop your GTK codes? I do a combination of by hand and via glade. Glade has several faults, the one being not being able to bind arbritrary information to widgets in the designer, which I doun't think would be possible anyways, though QT's designer offers something along those lines, as subclassing existing widgets is about 1000x easier than doing it in GTK+. So for my niche use, in order to be able to reuse signal handlers, and not end up with one handler per control, I have glue code in place that on initialization of the application it binds additional data per applicable widget which the signal handlers use to take appropriate action. so my code makes very extensive use of g_object_set_data(), and g_object_get_data(). Thus for all my buttons I have one handler std_button_handler(), and in my code I assign an enum to each control (i.e. g_object_set_data(G_OBJECT(widget), handler GINT_TO_POINTER(SOME_ENUM_NAME)); so that when that handler is called, it's is handled in a case statement inside that handler. -- David J. Andruczyk __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On 4/14/07, Robert Pearce [EMAIL PROTECTED] wrote:
The other thing to bear in mind is this:
If you have a row or column of similar widgets, say buttons, then a tool
like Glade or BCB requires you to place every one individually. Writing the
code by hand lets you do:
for ( cc=0; cc10; cc++ )
{
MyButtons[cc] = gtk_button_new (..);
gtk_box_pack_start ( );
}
This is even more relevant if the number of buttons isn't known at design
time!
This is a good point. In my app I have functions like (an example)
build_label_entry() which makes a GtkLabel + GtkEntry with layout
following the HIG guidelines. Once you have a few of these set up,
building a dialog from code is really easy. Plus now your layout is
just in one function, so you can change the layout of all label +
entry pairs by just altering a couple of lines of code.
It also depends on the kind of program you are writing. Mine has a
relatively 'small' GUI (most of the code is in the back end) so Glade
would not save me a significant amount of time.
Having said that, most people tell me it has an awful interface, so
maybe you shouldn't listen to me.
John
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On Sat, 2007-04-14 at 02:10 -0700, David J. Andruczyk wrote: though QT's designer offers something along those lines, as subclassing existing widgets is about 1000x easier than doing it in GTK+. if you opted to work in the same object oriented language that Qt uses, and just used gtkmm, you would find that subclassing existing widgets is about 1000x easier than doing it in GTK+. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
Hi, Like the others posting so far, I do not use any IDE to program my gtk + app. I had a quick look once upon a time, but quickly determined that if you want or require to change the code that is automatically generated, you might as well just write your own instead of trying to get in the deep-end of someone else's ideas about how this should be done. This subject came up a little while ago as well. Then, the poster found that writing your own code was a big pain since this required coming up with a variable name for every widget needing to be created. But I didn't and still don't understand this complaint. When creating widgets, two types of widgets are required, one which never again needs to be accessed (e.g., a static label (don't even start talking about dynamic labels...:) ), and the other requiring accessing (e.g., an entry area taking input from the user). For those widgets not needing to be accessed, it is not necessary to provide a unique variable name, rather, you can re-use the same variable over and over since once a widget is registered/packed/ whatever, you need not reference it again. To illustrate, the following snippet generates two buttons and an entry area with a label laid out simply in a vertical container: vbox = gtk_vbox_new(FALSE, 0); button = gtk_button_new_with_label(TRACES); g_signal_connect((button), clicked, G_CALLBACK(buttonCallback), enums[TRACES]); gtk_size_group_add_widget(size_group, button); gtk_container_add(GTK_CONTAINER (vbox), button); strcpy(toolTip, Open Trace files); gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip); button = gtk_button_new_with_label(Next); g_signal_connect((button), clicked, G_CALLBACK(nextTrace), enums [NEXT]); gtk_size_group_add_widget(size_group, button); gtk_container_add(GTK_CONTAINER (vbox), button); strcpy(toolTip, Display NEXT Screen of Trace Files); gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip); hbox = gtk_hbox_new(FALSE, 0); label = gtk_label_new(min:); MTfixed[MIN] = entry = gtk_entry_new(); g_signal_connect(MTfixed[MIN], activate, G_CALLBACK(reMag), OV [MAGNIFYSCR]); gtk_entry_set_width_chars(GTK_ENTRY (entry, 5); gtk_container_add(GTK_CONTAINER (hbox), label); gtk_container_add(GTK_CONTAINER (hbox), entry); gtk_container_add(GTK_CONTAINER (vbox), hbox); strcpy(toolTip, MIN: define as absolute (e.g., 1000) or as Percentage of MAX/MIN Mean (e.g., 50%) (BLANK = Real MIN)); gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), entry, toolTip, toolTip); As another poster pointed out, this repetitive type of widget creation can be contained within its own routine. But basically, once you've got the various types of widgets and layouts you require, it is trivial to copy and paste the code over and over, only requiring the widget's creation details to be changed for each new instance. The above snippet requires only that the entry area be uniquely named for later reference. In my code, all widgets are globally defined as GtkWidget *, casting when- and wherever appropriate. (Some purists might balk at global variables but I have no problem with globals which never change value over the entire life of a program, especially when they're widgets needed possibly anywhere.) To handle the problem of having to name so many widgets nonetheless, adopt a simple and shorthand naming convention you can immediately recognize, deduce, and even guess which makes sense somehow to the program and their usage. As well, arrays of widgets can be very helpful here. And like another poster, I highly recommend attaching as few callbacks as possible to the widgets. Like he does, as can be seen above, each button is attached to the same callback with an enum value passed to the callback routine. Once called, case statements handle each button's differing requirements. (Unlike how he does it, however, I do this more directly in the signal connection itself; either method works though depending on exact requirements, using g_object_*_data() may be more appropriate.) In general, try to attach like widgets to the same callback. In practice this won't be universal, some callbacks demand their own routine; the point is, maintaining code in the future is always made easier when the number of callbacks is minimized to the greatest extent possible. And good luck, richard___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On Sat, 2007-04-14 at 15:00 +0200, Richard Boaz wrote:
Hi,
Like the others posting so far, I do not use any IDE to program my gtk
+ app. I had a quick look once upon a time, but quickly determined
that if you want or require to change the code that is automatically
generated, you might as well just write your own instead of trying to
get in the deep-end of someone else's ideas about how this should be
done.
Right, first of all I dont think its correct to suppose that generated
code is anyone's idea of how it should be done, generated code is
a mechanical spew of code that works and should NEVER be used as
an example or reference implementation.
My opinions about glade are biased because I maintain glade, but my
opinion anyway: glade is not an IDE, its a user interface designer -
adding application data and modeling of that data is not a desirable
thing, you want to keep your user interface in one corner and your
data in another - not mix them up in one big pot of spaghetti code.
If you have concerns about dynamic portions of your interface, I agree
they should mostly be done by hand, but wait - glade can still help you
here, say you have a hbox with a label and an entry as was previously
described, you can always put one instance of that in your glade file
and loop like so:
for (i to ... dataentries) {
xml = glade_xml_new (...dataentryitem...);
widget = glade_xml_get_widget (xml, dataentryitem);
/* ... pack into your program somewhere by hand ... */
g_object_unref (xml);
}
This might or might not make sence depending on the application, but
it does have the advantage of keeping your UI dynamic, if you need to
add an item/label/separator or whatever to that subhierarchy than you
dont need to edit or compile code to update your interface.
I also believe that following a template design might be good
for a dumb little CLI wrapper in a GUI - but if you are really
developing an industry grade application then please use your
brain and understand the code - using libglade for your interface
is a good thing because it defers all the repetitive rigid GUI
building code to a library that takes care of it for you - it
also allows you to use YOUR OWN design that is appropriate for
your own application, either by loading dialogs on the fly or
at initialization time - keeping pointers around for the widgets that
you need referenced by name, or by using lookup_widget() types of
paradigms - point being - you are the author of your application
and the sources are in your hands, you should be able to organize
your code in a way that suits the application at hand.
For a good reference implementation - I've repeatedly been pointing
people in the direction of the DevHelp sources, since IMO they use
a sound OO design and a very practical use of libglade (its also
very simple code to understand).
Just my 2 cents, cheers,
-Tristan
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
In the case of my app (MegaTunix) the app gui is 100% glade, though some widget are built manually and placed into of a glade designed object as like others have said, they are dynamic and not predictable until during runtime. Due to the niche nature of my app, and the multitude of controls (well over 1500), I had to extend things as glade didn't do enough, but it worked and is fairly extensible even if it's design has numerous flaws... http://megatunix.sourceforge.net -- David J. Andruczyk __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
I do pretty much as you, regarding variable naming, unneeded vars (i.e. mainly layout containers and static labels in glade), are just left to be named via glade's default naming system. Since my app (megatunix) is 100% built in glade, pretty much evey widget there that require signal handlers has them defined IN GLADE, but on app initialization when the gui is created, I have extra config files I built, that share a common naming scheme with the glade files. I wrote a .ini style parser and code that traverses the weidget tree of each Gui tab, search for those widget names in my .ini files. if ti findsa match, it runs some code that looks for custom attributes I created and sets them on the widgets. (things like signal handler enumerations, and other simple and some very complex attributes. NOTE: My app is very much a NICHE app, and is designed to be modular as it has to adapt on runtime, and statically defining all these attributes in code made the code IMPOSSIBLE to be extensible. (megatunix adapts to ECU firmware on startup using a minimalist gui, and once it determines the ecu capability, it ONLY loads specific Glade tabs that correspond to controls valid for the device, hence my needs to be able to define my extended attributes outside of the application itself). I also use the trick of a global hashtable to store pointers to customized widgets, so they are easily retrieved without having to use: glade_xml_get_widget(). This is done because I want to reference NON glade created widgets, and prefer to rather just name one global definition of extern GHashTable *dynamic_widgets; instead of a pile of other externs. In one of my simple apps (part of megatunix), called gaugedesigner, this app is 100% glade, and I designed it the same way as megatunix, defining all signal handlers in the glade UI. On app startup are init functions that specifically retrieve widgets by name to manipulate or bind additional data to them tmp=glade_xml_get_widget(xml,save_gauge_menuitem); gtk_widget_set_sensitive(tmp,FALSE); tmp=glade_xml_get_widget(xml,save_as_menuitem); gtk_widget_set_sensitive(tmp,FALSE); g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,precision_spin)), handler,GINT_TO_POINTER(PRECISION)); g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,value_xpos_spin)), handler,GINT_TO_POINTER(VALUE_XPOS)); g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,value_ypos_spin)), handler,GINT_TO_POINTER(VALUE_YPOS)); and so on. --- Richard Boaz [EMAIL PROTECTED] wrote: Hi, Like the others posting so far, I do not use any IDE to program my gtk + app. I had a quick look once upon a time, but quickly determined that if you want or require to change the code that is automatically generated, you might as well just write your own instead of trying to get in the deep-end of someone else's ideas about how this should be done. This subject came up a little while ago as well. Then, the poster found that writing your own code was a big pain since this required coming up with a variable name for every widget needing to be created. But I didn't and still don't understand this complaint. When creating widgets, two types of widgets are required, one which never again needs to be accessed (e.g., a static label (don't even start talking about dynamic labels...:) ), and the other requiring accessing (e.g., an entry area taking input from the user). For those widgets not needing to be accessed, it is not necessary to provide a unique variable name, rather, you can re-use the same variable over and over since once a widget is registered/packed/ whatever, you need not reference it again. To illustrate, the following snippet generates two buttons and an entry area with a label laid out simply in a vertical container: vbox = gtk_vbox_new(FALSE, 0); button = gtk_button_new_with_label(TRACES); g_signal_connect((button), clicked, G_CALLBACK(buttonCallback), enums[TRACES]); gtk_size_group_add_widget(size_group, button); gtk_container_add(GTK_CONTAINER (vbox), button); strcpy(toolTip, Open Trace files); gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip); button = gtk_button_new_with_label(Next); g_signal_connect((button), clicked, G_CALLBACK(nextTrace), enums [NEXT]); gtk_size_group_add_widget(size_group, button); gtk_container_add(GTK_CONTAINER (vbox), button); strcpy(toolTip, Display NEXT Screen of Trace Files); gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip); hbox = gtk_hbox_new(FALSE, 0); label = gtk_label_new(min:); MTfixed[MIN] = entry = gtk_entry_new(); g_signal_connect(MTfixed[MIN], activate, G_CALLBACK(reMag), OV [MAGNIFYSCR]); gtk_entry_set_width_chars(GTK_ENTRY (entry, 5); gtk_container_add(GTK_CONTAINER (hbox), label);
calendar with Gtk+ 2.0
Hi, I'm programming a GTK program with freepascal and MySQL. The application must administer a Medical center and I need a calendar to show when the patients must go to the doctor. I'm working with the widget GtkCalendar, it's cool but I need something like this: http://farm1.static.flickr.com/176/434960008_65ab81bc16_o.jpg I need something that show me the weeks and the hours of the day that is occupated the medical center. I think I can't do this with GtkCalendar. Can somebody help me, please? Thanks :) ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: calendar with Gtk+ 2.0
vicente garcia wrote: Hi, I'm programming a GTK program with freepascal and MySQL. The application must administer a Medical center and I need a calendar to show when the patients must go to the doctor. I'm working with the widget GtkCalendar, it's cool but I need something like this: http://farm1.static.flickr.com/176/434960008_65ab81bc16_o.jpg I need something that show me the weeks and the hours of the day that is occupated the medical center. I think I can't do this with GtkCalendar. Can somebody help me, please? You'll have to write your own widget [1]. That said, check out the source code for Evolution and Dates [2], which both implement something like this. You might be able to steal their code :) (The Dates code is likely to be simpler and less full of CORBA than Evolution.) -- Andrew [1] http://gnomejournal.org/article/34/writing-a-widget-using-cairo-and-gtk28 and http://gnomejournal.org/article/36/writing-a-widget-using-cairo-and-gtk28-part-2 are good starting points. [2] http://pimlico-project.org/dates.html ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
Thank you for all your reply.
It's been really useful.
I am getting really good info about all of it. Not just the what use to
develop, but also about what technique to use.
For example, I use A LOT of variables to construct a simple dialog, but I
think it will be more sane to use just one or two, as mention by Richard
Boaz. Take a look at this part of my code: (don't mind for the names of the
variables, it's in my local language. And yes, I like to initialize
variables, always. :-) )
/***/
GtkWidget*
create_dialog_edit_disciplina_horario(void)
{
GtkWidget *dialog = NULL;
GtkWidget *vbox01 = NULL;
GtkWidget *rotulo_codigo = NULL;
GtkWidget *entrada_codigo = NULL;
GtkWidget *rotulo_nome = NULL;
GtkWidget *entrada_nome = NULL;
GtkWidget *rotulo_ano = NULL;
GtkWidget *spin_ano = NULL;
GtkObject *spin_ano_adj = NULL;
GtkWidget *rotulo_sem = NULL;
GtkWidget *spin_sem = NULL;
GtkObject *spin_sem_adj = NULL;
GtkWidget *rotulo_escolhe_semestre = NULL;
GtkWidget *cbox_escolhe_semestre = NULL;
GtkWidget *arvore_dados = NULL;
GtkTreeStore *armazena = NULL;
GtkWidget *hbox01 = NULL;
GtkWidget *hbox02 = NULL;
GtkWidget *hbox03 = NULL;
GtkWidget *hbox04 = NULL;
GtkWidget *hbox05 = NULL;
[...]
/***/
Another good one I think I will use is the reduced number of callbacks.
Every dialog in my code, for example, has its own callback. I think its
going to be more clear if I group all of them at the same one.
And more ideas that I am not going to bother you about.
I am a little excited about the possibilities, I admit. ;-)
Well, getting back to the IDEs (or as mentioned by Tristan Berkom, User
interface Designer), I am still thinking about it. I installed the new
version of Glade (was running glade-2, now running glade-3) and took a look
at the libglade. It seems to be a great idea, although I didn't really got
into it. Need more research by myself to understand how to use it.
What I am realizing is that if you want a specific GUI it's more convenient
to do it by hand but, if it's a general one, which will use the standard
widgets at the standard ways, the IDEs (or UIDs) happens to be a very good
idea.
Still a little confuse about what paradigm to use, I confess. But now with
more baggage to make my choice. :-)
Sincerely,
2007/4/14, Robert Pearce [EMAIL PROTECTED]:
On Sat, 14 Apr 2007 12:42:21 +0100 [EMAIL PROTECTED] wrote:
Having said that, most people tell me it has an awful interface, so
maybe you shouldn't listen to me.
If the sort of people who like most of what's out there think your
interface is awful then I'd probably think it's really nice. I'm
amazed at how ghastly most GUIs are. But then I think of computers as
tools for doing what I want them to do, not a display case for
avant-garde graphic design, so what would I know?
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
--
Diogo F. S. Ramos
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Selectively trapping keypresses
On 13/04/07, Jeffrey Ratcliffe [EMAIL PROTECTED] wrote: How do I check whether a Gtk2::Ex::Simple::List is being edited (when selectively trapping keypresses)? a. When the user presses enter, save the new data to a file I'm being dim (serves me right for coding when I should be in bed). row-changed will give me that. I still can't see how to check whether a Gtk2::Ex::Simple::List is being edited. Does it has something to do with custom cell renderers? Jeff ___ gtk-perl-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Selectively trapping keypresses
On Apr 14, 2007, at 8:39 AM, Jeffrey Ratcliffe wrote: On 13/04/07, Jeffrey Ratcliffe [EMAIL PROTECTED] wrote: How do I check whether a Gtk2::Ex::Simple::List is being edited (when selectively trapping keypresses)? a. When the user presses enter, save the new data to a file I'm being dim (serves me right for coding when I should be in bed). row-changed will give me that. I still can't see how to check whether a Gtk2::Ex::Simple::List is being edited. Does it has something to do with custom cell renderers? In order to get that sort of stuff to work, you have to use the TreeView API. The user does not edit a TreeView (which is what a SimpleList is). The user edits cells. Basically, when the user activates an editable cell, the tree view tells the cell to start editing itself. At this point the cell creates an editable that the tree view puts in the right spot. The user does stuff and then ends the editing somehow. Generally, it is up to your code to catch the editing-done signal and make appropriate changes to the model. SimpleList does some work for you to apply automatically a user's changes. To modify the behavior of SimpleList's editing controls, you'll basically have to create a custom column type, and handle the editing behavior all for yourself. There are other discussions on this list about how to make all that work, and several cell editing examples available. Does that answer your question? -- It's all very complicated and would take a scientist to explain it. -- MST3K ___ gtk-perl-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: GtkIMContext still be missed
Anybody can help me? 2007/4/9, [EMAIL PROTECTED] [EMAIL PROTECTED]: hi, I couldn't found GtkIMContext module in gtk2-perl. I remember muppet made a patch for it, but i lost that patch. Can muppet commit it to the cvs source? -- +---+ |By Alexe (http://alexe.cublog.cn)| +--+ -- +---+ |By Alexe (http://alexe.cublog.cn)| +--+ ___ gtk-perl-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: GtkIMContext still be missed
On Apr 14, 2007, at 10:07 PM, [EMAIL PROTECTED] wrote: Anybody can help me? 2007/4/9, [EMAIL PROTECTED] [EMAIL PROTECTED]: hi, I couldn't found GtkIMContext module in gtk2-perl. I remember muppet made a patch for it, but i lost that patch. Can muppet commit it to the cvs source? Sorry about the delay -- i had to dig up and recreate part of the patch. I know really nothing about input managers, so i have no idea how to test this. The patch does not give you all the hooks you need to make your own input manager, but will allow you to use existing ones. Is this sufficient? I'd be happy to commit after Torsten and Emmanuele review it, but also after your feedback as to whether it's a sufficient patch. imcontext.patch Description: Binary data -- It's all very complicated and would take a scientist to explain it. -- MST3K ___ gtk-perl-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-perl-list
