gtk entry
hi; i am developing gui with glade, C. i have some pbm in passing signal from one callback signal to another callback. i have a text_entry_activate callback, in which i am checking text entered or not. if not warning msg will pop up. i am getting this functionality. now i have one more callback button_next_click. i want functionality like when i press this next button, first it will check the text entry for entered or not. if entered then the next layout displayed. if not the same pop up has to display. now due to glade, widget creation in interface and callbacks in callbacks.c, i am not getting how to refer the entry widget using button_next_click. how to create object of entry widget and how can i pass the signal to text_entry_activate. thanks; vasu. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Multiple delimeters with g_strsplit
Hi, I have a string this way: Name Surname AddressTelephone I'm not able to split it as: Name Surname Address Telephone with g_strsplit. I tried as delimeter + to mean multiple spaces as in regular expression but it doesn't work, may anyone help, please ? -- Colossus Cpsed, a Linux OpenGL 3D scene editor http://cpsed.sourceforge.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK application key bindings?
To make this easier, I'll quote from the first post I made about this, and the response that prompted me to cross post this: (url: http://groups-beta.google.com/group/comp.terminals/browse_thread/thread/b8a9fd0feafdb86b/c8fe1ea7e9f55642#c8fe1ea7e9f55642) This may be a GTK question, but I figured I'd start here first. We're using PuTTY on Linux workstations to access a termapp. The users are accustomed to the windows style of using the PrintScreen command to dump a copy of what's on the screen to the default printer. This doesn't work under Gnome, but I have most of a workaround set up. In the PuTTY command menu (Ctl-Right click) there's an option for copy all. If you hover over any of the menu commands with the mouse, you can assign keystrokes to them. Thing is that when you close the PuTTY window, the setting dissapears. I can't find a file that's being created by PuTTY to store the setting, and nor can I find a place to set it up in the gconf-editor. Do I just have a piece of weirdness that happens to work, or is there a way to map a selection from the command menu to a keystroke and have it stick? Simon Tatham Jun 1, 11:16 am show options Newsgroups: comp.terminals From: Simon Tatham [EMAIL PROTECTED] - Find messages by this author Date: 01 Jun 2005 16:16:39 +0100 (BST) Local: Wed,Jun 1 2005 11:16 am Subject: Re: Putty Command meny Keymapping Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse [EMAIL PROTECTED] wrote: This may be a GTK question, but I figured I'd start here first. [...] In the PuTTY command menu (Ctl-Right click) there's an option for copy all. If you hover over any of the menu commands with the mouse, you can assign keystrokes to them. Goodness, I'd never noticed that! It's certainly not anything I did, so I can only assume GTK is doing it on my behalf and didn't even bother to tell me :-) I think you were right the first time, I'm afraid: this is a GTK question. -- Simon Tatham The difference between theory and practice is [EMAIL PROTECTED]that, in theory, there is no difference. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_thread_init question
Alan M. Evans wrote: Hello all! The docs on developer.gnome.org state that g_thread_init() will abort if called twice and suggest the following construct to avoid multiple calls: if (!g_thread_supported ()) g_thread_init (NULL); Has nobody noticed that there's a race condition there? If I make a class that internally uses threads and mutexes, how do I protect myself against another class (not necessarily mine) created in another thread (not necessarily under my control) also calling g_thread_init() because it is also internally using gthread? That sounds conceptualy broken, if I instantiate a GObject that is a GtkWidget, the GtkWidgetClass initializer will not call gtk_init() for me, so why should an object using the thread system have to call g_thread_init () ? Maybe it would be appropriate for the class initializer to do: if (!g_thread_supported ()) g_critical (You must initialize the thread subsystem to use MyObjectClass); Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_thread_init question
On Wed, 2005-06-01 at 12:25, Tristan Van Berkom wrote: Alan M. Evans wrote: If I make a class that internally uses threads and mutexes, how do I protect myself against another class (not necessarily mine) created in another thread (not necessarily under my control) also calling g_thread_init() because it is also internally using gthread? That sounds conceptualy broken, if I instantiate a GObject that is a GtkWidget, the GtkWidgetClass initializer will not call gtk_init() for me, so why should an object using the thread system have to call g_thread_init () ? The comparison lacks parity, in my opinion. It seems unlikely to me that a class which uses GtkWidget would be used in a non-GTK+ program. (Class in the C++ sense, not the GObject sense.) On the other hand, It seems completely feasable that a class that uses GLib types and threads might be used in an application which has no knowledge of GLib. In fact, that's exactly what I'm doing. In other words, a shared object that uses GLib might not expose GLib, but how would a shared object that uses GTK+ not expose that? Maybe it would be appropriate for the class initializer to do: if (!g_thread_supported ()) g_critical (You must initialize the thread subsystem to use MyObjectClass); Perfectly appropriate in an environment where GLib is assumed to be part of the development chain. Not so when the application developers (think Win32) have never heard of GLib. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_thread_init question
Alan M. Evans wrote:
[...]
The comparison lacks parity, in my opinion. It seems unlikely to me that
a class which uses GtkWidget would be used in a non-GTK+ program.
(Class in the C++ sense, not the GObject sense.)
I am tempted to argue that class in the c++ sence *is* the same
as a class in the GObject sence; but that is a little off-topic :)
On the other hand, It seems completely feasable that a class that uses
GLib types and threads might be used in an application which has no
knowledge of GLib. In fact, that's exactly what I'm doing.
In other words, a shared object that uses GLib might not expose GLib,
but how would a shared object that uses GTK+ not expose that?
The race condition is present only if you make it possible that
you call g_thread_init () from two seperate threads, to be blunt;
its your responsability to make sure that doesn't happen.
Lets take another few examples, firstly; you cannot use any
GObject derivitive unless the typesystem is initialized; so
g_type_init() must be called first (whether it is called by
gtk_init () or by gdk_rgb_init () or whatever).
Same goes for gdk objects, the gdk_rgb_init() function will
initialize subsystems that must be present first.
I think that a more appropriate example would be GStreamer,
GStreamer needs to have threads initialized to function;
So GStreamer demands that you call gst_init () /before/
using GStreamer objects.
So lets say that you are writing an application that uses
GStreamer, GTK+ your shared object, in your main () you
will call each of the following:
void main () {
gtk_init (); // -- calls g_threads_init ()
gst_init (); // -- calls g_threads_init ()
my_customlib_init (); // your shared object library init point
// that will also call g_threads_init ()
}
Since all library entry points check g_thread_supported (), there
is no crash, also since it is part of the apps initialization
proceedure; there is no danger of a race condition.
Cheers,
-Tristan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_thread_init question
On Wed, 2005-06-01 at 14:28, Tristan Van Berkom wrote:
Alan M. Evans wrote:
(Class in the C++ sense, not the GObject sense.)
I am tempted to argue that class in the c++ sence *is* the same
as a class in the GObject sence; but that is a little off-topic :)
I knew you would be, and so would I. What I meant by that is, that a C++
API exporting a simple class makes no demands about the application
knowing GLib. One which exports a GObject or descendant implies that the
application know GLib.
The race condition is present only if you make it possible that
you call g_thread_init () from two seperate threads, to be blunt;
its your responsability to make sure that doesn't happen.
I know that it's my responsibility. That is why I asked the question in
the first place.
So lets say that you are writing an application that uses
GStreamer, GTK+ your shared object, in your main () you
will call each of the following:
void main () {
gtk_init (); // -- calls g_threads_init ()
gst_init (); // -- calls g_threads_init ()
my_customlib_init (); // your shared object library init point
// that will also call g_threads_init ()
}
I thought of this, but it seemed ... inelegant. Suppose I create a
drop-in replacement for the Win32 CAsyncSocket class. (Not what I'm
doing, by the way.) Now CAsyncSocket does not require calling some init
procedure, but MyClass does. Not really a drop-in replacement, is it?
I didn't come here to pick a fight. Honest. But it seems to me that this
whole thing would be a non-issue if g_threads_init() would respond to a
second call by returning instead of aborting. Imagine:
void g_threads_init(GThreadFunctions *vtable) {
static GStaticMutex only_once = G_STATIC_MUTEX_INIT;
if (g_static_mutex_trylock(only_once)) {
g_threads_real_init(vtable);
}
}
and no more aborting! I'm probably oversimplifying something there, but
it seems to me that the proper place to assure something is exclusive is
at the point of exclusivity (inside GLib) not independently by every
user of the exclusive procedure.
Sorry, now I'm ranting. I'll go away; just came here hoping there was
another choice...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glade C code a bad thing? (was: root windows)
Hello guys, I think Gus forgot to CC his email to the list, so i am forwarding it here. -- Forwarded message -- From: Gus Koppel [EMAIL PROTECTED] Date: Jun 1, 2005 9:40 AM Subject: Re: Glade C code a bad thing? (was: root windows) To: Zeeshan Ali [EMAIL PROTECTED] Zeeshan Ali wrote: BTW, i think this seperation of glade into two utilities would result in much greater freedom than now (quite contrary to the fear of some people on this list) since it open's up a new possiblity: you'll then be able to write your GUI in XML and getting it transformed into the source-code without using any GUI utility. :) The freedom of designing a GUI without using a GUI while doing so? What else? Writing C programs without using a C compiler during development? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glade C code a bad thing? (was: root windows)
Answers to comments from several people here... No particular order. The freedom of designing a GUI without using a GUI while doing so? What else? Writing C programs without using a C compiler during development? What, you saying you can't? I've built some moderately complicated 3D models back when I was playing with OpenGL, and I never had any 3D modelling software (in fact, I still don't). That's an awful lot harder than building a GUI. Sometimes it's easier to tweak the XML file directly, than it is to load up Glade, make the change, and save it back again. Especially if you're using telnet from another computer without an X server, which I've done! For quite a while, a couple years back, I had to do my programming from a Windows box, and schedule time on a Linux PC to actually test it. What if I have a GUI with a stack of check boxes and other widgets, that themselves can be auto-generated. I can roll together a quick program to load up the XML, track down the specific container, replace its contents with the autogenerated content (all within an XML library, so I don't have to fiddle with parsing XML myself), and save it back down again. I've had occasions where I've been able to auto-generate large amounts of nobrainer code hat had a lot of little bits that needed to be kept in psynch. Large lookup-tables full of pre-calculated mathematics are a prime example. Not much difference there. I was convinced that Linux was about freedom of choice? If code designers start limiting the choice of users, next we'll have to throw peripherals away because someone decides it's time... (sounds familiar?) I did read somewhere that it would be simple to write a code converter to re-generate the missing C-code. You're going backwards here... Having the code generation part of Glade limits you to what the Glade developers have done, and how good they are at doing it. Having the code generation seperate, allows someone else to take over that burdon, who could potentially be better at it than they are. And moreso, it allows several people to take over that burdon, each with a different target language in mind. Or just a difference of technique. Linux is built on connecting together a number of strong components to form an equally strong chain. Unlike something else that joins a mix of strong and weak components to form a weak chain (because not even those people you referred to, are good at EVERYTHING). So where's the loss of freedom of choice? I already see messages from someone planning to pick up the torch. Thhank you, sir. This confirms that reinventing the wheel, even with rough edges, must be more important than i.e. working on end user applications using GTK+ and Glade. Reinventing the wheel is sometimes the only way to remove the kinks.If the tyre on my car blows, I don't try to stitch it back together, I get a new one. But more importantly, I do so with the knowledge of how that last one performed, and what to look for in the next one. That's why we have version 2 of GTK, and why there'll be a version 3 of Glade, and why there'll be a version 2.8 of the kernel. And besides, I'm sure the old glade source generating code won't go to waste. Even if it doesn't get reused, it'l at least be looked at for ideas. I do hope Glade will provide a plugin system to allow the same style of use as before, but regardless, a commandline tool that generates C-source from the glade XML file, and a few extra lines in your Makefile, and you won't even notice the difference. Except for a bunch of new options and flexability! Fredderic ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Images in the Drawing Area
I was wondering whether or not it is possible to display a .jpeg, .png or .bmp in the drawing area and then be able to draw lines over this image. If this is possible, what functions can I use in order to get the image from file and then be able to display the image in thebrdrawing area. http://www.gtk.org/api/ Knock yourself out! It's all in there. Look under the gdk pixbuf sections (gdk, and gdk-pixbuf). Fredderic ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
