problems when using g_main_loop_quit from different thread
Hi everyone, i am experiencing random problems here if i use g_main_loop_quit from a different thread than where the GMainLoop runs. my program looks like this: 1. in main: create a new context and a new loop 2. spawn a thread 3. call g_main_loop_run in the thread on the previously created loop 4. some time later: call g_main_loop_quit from main whats supposed to happen (i guess) is that the main loop quits. But sometimes the call to loop_quit just has not effect, so the main loop continues to run. Is this a known problem or am i doing something wrong? Best Regards, Armin Bauer ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Left side widget of Evolution mail client
Hi all Can anyone tell me what kind of widget is used in the left side of the main window of Evolution mail client ? I found some probable stuff in the GAL library (e-shortcut-bar) but I would need that widget showing a treeview-like menu as evolution does. Waiting for some clue, many many thanks. Carlos Savoretti. [EMAIL PROTECTED] -- Carlos Savoretti [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: problems when using g_main_loop_quit from different thread
Armin Bauer wrote: Hi everyone, i am experiencing random problems here if i use g_main_loop_quit from a different thread than where the GMainLoop runs. my program looks like this: 1. in main: create a new context and a new loop 2. spawn a thread 3. call g_main_loop_run in the thread on the previously created loop 4. some time later: call g_main_loop_quit from main whats supposed to happen (i guess) is that the main loop quits. But sometimes the call to loop_quit just has not effect, so the main loop continues to run. Is this a known problem or am i doing something wrong? My guess is that it just doent make sence to remove the mainloop while the other thread is sleeping in poll(), sure the code will lock its mutex and everything; but when the other thread wakes up; how could it deal with a gone mainloop ? Solution ? I would use an idle function to the thread's loop; using the GSource lower level apis (i.e. create the idle source and do g_source_attach to the thread's context); and just quit from there. 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: problems when using g_main_loop_quit from different thread
Tristan Van Berkom wrote: My guess is that it just doent make sence to remove the mainloop while the other thread is sleeping in poll(), sure the code will lock its mutex and everything; but when the other thread wakes up; how could it deal with a gone mainloop ? Scratch that; doesnt make any sence; the code also seems to have thread conditional stuff; so it should work - I guess. ... Maybe it fails in the off chance that its not in poll() ? still should work ... Solution ? I would use an idle function to the thread's loop; using the GSource lower level apis (i.e. create the idle source and do g_source_attach to the thread's context); and just quit from there. I still bet this will work (unless you are running a rare gtk binary that was compiled without thread support; and that should have been indicated when you called g_thread_supported()). 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: Left side widget of Evolution mail client
On Thu, Mar 09, 2006 at 01:23:38PM -0500, Carlos Savoretti wrote: Hi all Can anyone tell me what kind of widget is used in the left side of the main window of Evolution mail client ? The source code of Evolution is freely available, so anyone can tell by looking there (but no, I did not look there for you because I believe people learn more by finding out themselves). Yeti -- That's enough. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: problems when using g_main_loop_quit from different thread
Armin Bauer wrote: Is this a known problem or am i doing something wrong? Heh, I think I figured it out; I think that after calling g_main_loop_quit(); if the thread is sleeping, you'll have to call g_main_context_wakeup() on it for _run() to return; I wonder if that is a bug or should be considered one (i.e. should that be implicit ?). 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: problems when using g_main_loop_quit from different thread
Tristan Van Berkom wrote: Armin Bauer wrote: Is this a known problem or am i doing something wrong? Heh, I think I figured it out; I think that after calling g_main_loop_quit(); if the thread is sleeping, you'll have to call g_main_context_wakeup() on it for _run() to return; I wonder if that is a bug or should be considered one (i.e. should that be implicit ?). as far as i can tell this seems to solve the problem (i havent been able to trigger this bug reliably, so i just ran my unit until i was confident enough). Dont know if the wakeup should be implicit. it should at least be noted in the docs. Thanks for your help! Best Regards, Armin Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
buffer locking for DMA?
Hi, I use glib on windows to allocate memory for a camera. Its DLL then uses the memory and pass it to the kernel and fill it via DMA. I have to be sure that windows doesn't move my buffer(s) later since the kernel has built its allocation table using it. With windows there are functions to prevent that (VirtualAlloc with parameters for reserving and locking/unlocking), is there anything in glib? Felix ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Customizing multiple selection behavior in TreeView
There is a TreeView widget whose TreeSelection's mode is SELECTION_MULTIPLE. I'd like to change how a single mouse click (and any of the equivalent actions from the keyboard and other input methods) on a row impacts the selection. The rest of the selection UI should behave as usual: Ctrl+click toggles one row, Shift+click selects a range, Ctrl+A selects all, etc. By default when the user clicks on a row, the selection is reset so that only the row clicked becomes selected. Instead of that, I'd like to make it toggle the selection of the row while leaving other rows alone (that's what Ctrl+click does). I've read the relevant parts of the API docs but still can't come up with a clean way to do that. Could you please describe such a way or give any clue about the relevant documentation I might have missed? By `clean' way I mean reusing what is already in GTK+ rather than reimplementing it. Such code duplication can result in UI inconsistencies over platforms and input methods, especially as time goes by. I'm a GTK+ newbie using the Python wrapper. Please CC me. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: selected text is PRIMARY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/9/2006 11:38 AM, Yevgen Muntyan wrote: Hello everybody, I opened a bug http://bugzilla.gnome.org/show_bug.cgi?id=334060 , about selected text == PRIMARY gtk thing. What do people think about enabling people use gtk in 'mozilla-like' mode, when losing PRIMARY doesn't mean unselecting text? Please read: http://www.jwz.org/doc/x-cut-and-paste.html I believe there's a more formal document on fd.o about how the clipboard/primary selections should behave, but that's a nice easy-to-read document that does a good job explaining. It's not really gtk that's in the wrong here - IMHO mozilla/firefox is buggy. (I didn't really read the bug you pointed to, so this may have already been discussed. Seems like you're asking for an unbreak my setup configuration option, which is IMO a waste of time and the absolute wrong way to approach the problem.) -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEELAI6XyW6VEeAnsRAtXsAJ4jLt10VJWJ/GvCIfdxfsB+CQgwJgCg6dPi nODFlT3kwBHZCSccXMZlhzs= =XdxZ -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
Brian J. Tarricone wrote: It's not really gtk that's in the wrong here - IMHO mozilla/firefox is buggy. mozilla allows user having multiple selections, and it doesn't clear selection when you select something else. It's not buggy, it's correct (not for everyone, of course). The document you posted link to tells about what X selection is and what happens when you select text/do whatever. Question is not what gtk does, we know that. Question is why am I not allowed to have multiple selections? Because of X is not the right answer. Some people believe there should be not more than one piece of selected text and they know about X selections and stuff, and are happy with that; another people believe that they should be able to have as many selections as they wish, like they select text to highlight it or use Ctrl-C to copy it to clipboard. These two points of view are both valid, this is why I am proposing a choice. Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/9/2006 3:05 PM, Yevgen Muntyan wrote: Brian J. Tarricone wrote: It's not really gtk that's in the wrong here - IMHO mozilla/firefox is buggy. mozilla allows user having multiple selections, and it doesn't clear selection when you select something else. It's not buggy, it's correct (not for everyone, of course). Not according to accepted practice. At the very least (not even talking about any kind of spec), one could argue that, since moz/ffx uses gtk, it should emulate gtk's behavior. The document you posted link to tells about what X selection is and what happens when you select text/do whatever. Question is not what gtk does, we know that. Question is why am I not allowed to have multiple selections? Because of X is not the right answer. Unfortunately it *is* the answer, regardless of whether it's right or not. You can only have one PRIMARY selection at one time. De-selecting all other selected text serves as visual indication of which text will get pasted from PRIMARY. It's of course a matter of opinion as to whether or not that visual indication is useful and necessary, or counter-productive and annoying. Adding a pref to accomodate that sounds like an consistency-breaking kludge[1]. Some people believe there should be not more than one piece of selected text and they know about X selections and stuff, and are happy with that; another people believe that they should be able to have as many selections as they wish, like they select text to highlight it or use Ctrl-C to copy it to clipboard. These two points of view are both valid, this is why I am proposing a choice. Maybe some people don't care about the PRIMARY selection. Fine. But in a sense, you kinda have to if you want to get the most out of X's somewhat unique (and IMHO very useful) copy/paste semantics. For people who are content to do the Windows-like CLIPBOARD method and totally ignore PRIMARY, I can understand why losing selected text would be annoying. But why should we dumb down the interface for the lowest common denominator? Sure, sure, it's a pref, and the default behavior can stay the same. Whatever. Yay pref-bloat! Fixing gtk in this sense is not a magic bullet, either. What about custom text-entry implementations? The GtkIMHtml WYSIWYG entry widget in Gaim comes to mind. They'd have to implement support for your pref. What about custom icon view cell-editing widgets (I believe Thunar[1] has or will have one)? That would have to support your pref as well. I'd bet there are others. -brian [1] Of course, one could (correctly) argue that consistency in this matter is generally broken already across many apps on the X desktop, unless you only use applications written using a single toolkit. Even then, consistency isn't guaranteed (Firefox, some versions of Anjuta, IIRC). [2] http://thunar.xfce.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEELo56XyW6VEeAnsRAqXfAJ0csVytOL7yGtyLFyerXN3I/stGFACdFAMu i6oT8ltIJyzhx6O8I2oB5vc= =z+NT -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/9/2006 3:51 PM, Yevgen Muntyan wrote: Brian J. Tarricone wrote: mozilla allows user having multiple selections, and it doesn't clear selection when you select something else. It's not buggy, it's correct (not for everyone, of course). Not according to accepted practice. At the very least (not even talking about any kind of spec), one could argue that, since moz/ffx uses gtk, it should emulate gtk's behavior. Accepted here is what we currently have. I claim that mozilla is right, and it correctly does not emulate wrong gtk behavior. (right and wrong for many people, not for everybody, etc., etc.) Well, we're arguing over what boils down to a personal opinion/aesthetics, which is useless. No agreement can be made here, so let's just drop it. The document you posted link to tells about what X selection is and what happens when you select text/do whatever. Question is not what gtk does, we know that. Question is why am I not allowed to have multiple selections? Because of X is not the right answer. Unfortunately it *is* the answer, regardless of whether it's right or not. You can only have one PRIMARY selection at one time. De-selecting all other selected text serves as visual indication of which text will get pasted from PRIMARY. It's of course a matter of opinion as to whether or not that visual indication is useful and necessary, or counter-productive and annoying. Exactly. In my opinion it is wrong that I have this indicator. I care more about selection in the editor more than about fact that if I see selected text, then middle button click will paste this text. Again, personal opinion. Adding a pref to accomodate that sounds like an consistency-breaking kludge[1]. Well, see your footnote :) Why make matters more confusing and inconsistent? About consistency, should we use bash/tcsh/eamcs/vi shortcuts in GtkEntry? I believe it's same kind of question. I disagree. The issue at hand is text selection behavior regarding copy/paste across GUI applications of different toolkits (and sometimes the same toolkit). You're bringing up specific features of certain applications. (On a side note, emacs keyboard shortcuts are supported in gtk if you use a different keytheme. I imagine you could support vi as well.) Maybe some people don't care about the PRIMARY selection. Fine. But in a sense, you kinda have to if you want to get the most out of X's somewhat unique (and IMHO very useful) copy/paste semantics. Err, what exactly? Middle-button-click would still work. Do I miss something or you mean that seeing not more than one selection is most of X copy/paste semantics? No, you just misquoted me. Re-read it. I'm actually for some reason not talking about text-selection at all here. Just that if you want to get the most out of X copy/paste (i.e., being able to intelligently use *both* the CLIPBOARD and PRIMARY selections), there's a slight learning curve involved. It's a tangent topic, so feel free to ignore it. For people who are content to do the Windows-like CLIPBOARD method and totally ignore PRIMARY, I can understand why losing selected text would be annoying. But why should we dumb down the interface for the lowest common denominator? Because we are doing it all the time maybe? Terrible, terrible justification. Anyway, I do not totally ignore PRIMARY nor I want to disable it; still, I want to have multiple selections. Again, personal opinion. Sure, sure, it's a pref, and the default behavior can stay the same. Whatever. Yay pref-bloat! No option and half of people happy is better than letting them choose? Who said half of people like it your way? Who said half of people like it my way? In lieu of a real usability study, you go with what the developers prefer. Fixing gtk in this sense is not a magic bullet, either. What about custom text-entry implementations? The GtkIMHtml WYSIWYG entry widget in Gaim comes to mind. Made of GtkTextView? Just because it derives from GtkTextView doesn't mean it behaves the same way. I haven't checked it in a while, though. They'd have to implement support for your pref. What about custom icon view cell-editing widgets (I believe Thunar[1] has or will have one)? That would have to support your pref as well. I'd bet there are others. Sure, I have two. One is textview-derived widget where I intentionally hack-around this GTK thing, because otherwise search in selected is simply impossible. About implementation, it's a matter of checking one gtk setting before calling unselect() or whatever. Yes, but it's something that everyone who has a custom widget has to do. As in, you can't passively support it. While it's not strictly hard to do it, you have to know that the particular option is there to be able to support it. How many people can rattle off the list of all the registered GtkSettings from
Re: selected text is PRIMARY?
Brian J. Tarricone wrote: Well, we're arguing over what boils down to a personal opinion/aesthetics, which is useless. No agreement can be made here, so let's just drop it. We can't! This is what I am talking about: I like this, and you like that, and it's impossible to satisfy both. And this selection stuff is important enough to add an option. Exactly. In my opinion it is wrong that I have this indicator. I care more about selection in the editor more than about fact that if I see selected text, then middle button click will paste this text. Again, personal opinion. Yep. Why make matters more confusing and inconsistent? To add valuable functionality. About consistency, should we use bash/tcsh/eamcs/vi shortcuts in GtkEntry? I believe it's same kind of question. I disagree. The issue at hand is text selection behavior regarding copy/paste across GUI applications of different toolkits (and sometimes the same toolkit). You're bringing up specific features of certain applications. (On a side note, emacs keyboard shortcuts are supported in gtk if you use a different keytheme. They are not supported. gtk supports shortcuts schemes, but they do not work properly, since all applications use hard-coded shortcuts instead of signals. Look at bugzilla for problems arising when people use emacs scheme. Err, what exactly? Middle-button-click would still work. Do I miss something or you mean that seeing not more than one selection is most of X copy/paste semantics? No, you just misquoted me. Re-read it. I'm actually for some reason not talking about text-selection at all here. Just that if you want to get the most out of X copy/paste (i.e., being able to intelligently use *both* the CLIPBOARD and PRIMARY selections), there's a slight learning curve involved. It's a tangent topic, so feel free to ignore it. Hm, okay. For people who are content to do the Windows-like CLIPBOARD method and totally ignore PRIMARY, I can understand why losing selected text would be annoying. But why should we dumb down the interface for the lowest common denominator? Because we are doing it all the time maybe? Terrible, terrible justification. I agree. Can we please get entry in FileChooser? Anyway, I do not totally ignore PRIMARY nor I want to disable it; still, I want to have multiple selections. Again, personal opinion. Yes, it's certainly my personal opinion about what I want :) No option and half of people happy is better than letting them choose? Who said half of people like it your way? Who said half of people like it my way? In lieu of a real usability study, you go with what the developers prefer. This is the most important thing. Of course I am not able to conduct usability study, and we have what gtk devs did. The problem is that gtk developers do not use text widget written by them (please don't tell about some entries in some applications, I mean real work, like coding). Fixing gtk in this sense is not a magic bullet, either. What about custom text-entry implementations? The GtkIMHtml WYSIWYG entry widget in Gaim comes to mind. Made of GtkTextView? Just because it derives from GtkTextView doesn't mean it behaves the same way. I haven't checked it in a while, though. If it overrides GtkTextView behavior (I bet it doesn't), it's its problem. It should know how to do it properly. Sure, I have two. One is textview-derived widget where I intentionally hack-around this GTK thing, because otherwise search in selected is simply impossible. About implementation, it's a matter of checking one gtk setting before calling unselect() or whatever. Yes, but it's something that everyone who has a custom widget has to do. As in, you can't passively support it. While it's not strictly hard to do it, you have to know that the particular option is there to be able to support it. How many people can rattle off the list of all the registered GtkSettings from memory? You can't passively support clipboards. If you are writing a widget from scratch, you must deal with clipboard api. If you are implementing gtk-like behaviour, you must manually unselect text when PRIMARY is stolen. Getting a setting value in that method *is* easy. As a random example, a piece of software I maintain had an option for whether or not to show application icons in a menu for over a year before I discovered the global gtk-menu-images setting. Err, and? It sounds rather like an argument against gtk-menu-images setting. Or like an example of why people should read api docs ;) Anyway, I'm past the point of truly caring either way. I just enjoy a debate sometimes. ^_^ Well, thanks for this at least. Regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/9/2006 5:31 PM, Yevgen Muntyan wrote: I agree. Can we please get entry in FileChooser? Try ctrl+L. Assuming that's what you mean. As a random example, a piece of software I maintain had an option for whether or not to show application icons in a menu for over a year before I discovered the global gtk-menu-images setting. Err, and? It sounds rather like an argument against gtk-menu-images setting. Exactly. Or, more general, an argument against having a large number of global settings -- for any purpose -- including the one you want to introduce. Or like an example of why people should read api docs ;) I do. Almost daily. But why would I expect there to be a global setting for whether or not to display icons in menus? Especially when no DE I've used (disclaimer: I haven't used GNOME since 2.2, so this may have been added) includes a global preference for this in a user-visible location? By the same token, why would I, as a hypothetical text entry widget author, expect there to be a global preference dealing with selection handling? You probably would, because you seem to care a great deal about it. But why would someone -- especially someone who is happy with the current behavior -- think about it? -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEENpr6XyW6VEeAnsRAnNJAJ9KhB3vfUuPq8V8XashTVmi4xcYpQCgxFAL OIijf8SwfYZ/ywx0Y1V4Rew= =ftvJ -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Usability of the GTK+ 2 file open dialog
Hi, Peter Eckersley [EMAIL PROTECTED] writes: No, you haven't. Just type the name of the file to open (or rather only the first letters of it). Then press Enter once. Do _not_ press Ctrl-L before you do this, just use typeahead as in any other list view. This fragment of a solution is a good example of my problems with the GTK2 chooser. It works fine, but *only* if the file path you want to type starts with / . Typing relative paths, or paths that start with ~, leads to random crazyness. Why is typeahead random crazyness? All GTK+ list views do this (well, at least if the application programmer cared to specify a search column). So this is exactly what the GTK+ user expects because it is consistent with the rest of the application. Opening a dialog box with a text entry is definitely not what the user would expect to happen and I am all for getting rid of this dialog. If we need a text entry (and I agree that it sometimes makes sense to have one), then it should replace the path-bar just like it is done in Nautilus. Perhaps I will try to cook up a patch for that as soon as Federico has committed the pending changes to the file-chooser. Sven ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: More on GTK usability
Peter Eckersley wrote: control-u to blank the line, anyone? Put gtk-key-theme-name=Emacs in ~/.gtkrc-2.0 I almost broke a bottle of champagne when I discovered this gem on a random webpage :-) someone should really get around to building a new command line shell that is GUI-fied and does things the same way. People have been trying (and failing) to do it for ages. You're welcome to design your own version. I wish you success! Toby -- Signed/encrypted mail welcome. GPG/PGP Key-Id: 0x15C5C2EA ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Usability of the GTK+ 2 file open dialog
On Thu, 2006-03-09 at 09:23 +0100, Sven Neumann wrote: You are using a rather old version of GTK+ then. I suggest that you update before you continute to bash the file-chooser. A lot of usability problems have been taken care of in recent versions. I am currently using 2.8.6 which behaves as I describe. I look forward to trying the newer version out. Sven ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Usability of the GTK+ 2 file open dialog
On Thu, 2006-03-09 at 09:23 +0100, Sven Neumann wrote: You are using a rather old version of GTK+ then. I suggest that you update before you continute to bash the file-chooser. A lot of usability problems have been taken care of in recent versions. I am wrong in my other post. 2.8 definitely does handle my / problem quite nice. But the problems with the ~ stuff we are talking about, and the relative paths, still stands. I am definitely glad these little things are being addressed. Michael Sven ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Not understanding the principles of drawing areas and primitives etc...
I want to be able to draw lines on a gtkDrawingArea, with a color the user selects (r,g,b), however I don't understand how I would do. The whole business with gdkGC's and gdcColors seems very alien. If somebody could point me to a tutorial (the scribble one isn't enough since that one doesn't use color). What I simply want to do is something like line(gtkDrawingArea* da, int x1, int y1, int x2, int y2, r, g, b) ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Non-editable GtkComboBoxEntry?
Can you maybe return TRUE from some of the GtkWidget signals to prevent further handling... like the enter-event and grab-focus or something along those lines? I'm not sure what/when all those events do what they do. But just an idea. - Micah Murray Cumming wrote: Is there any good way to make a GtkComboBoxEntry non-editable? Calling gtk_entry_set_editable() on the child GtkEntry isn't enough. The user can still change the contents of the GtkEntry by choosing something from the drop-down menu. Calling gtk_widget_set_sensitive() on the GtkComboBoxEntry isn't enough, because the user then can't select the text to copy it. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Not understanding the principles of drawing areas and primitives etc...
On Thu, 2006-03-09 at 19:39 +0100, Leo - wrote: I want to be able to draw lines on a gtkDrawingArea, with a color the user selects (r,g,b), however I don't understand how I would do. The whole business with gdkGC's and gdcColors seems very alien. If somebody could point me to a tutorial (the scribble one isn't enough since that one doesn't use color). no tutorial here, but a brief lecture. there are many different possible parameters for many drawing primitives. in your case of line drawing, we have things like: * is the line dashed? * if dashed, what are the stroke gap sizes? * the pen width * the color of the line for other drawing primitives, there are many more. rather than constantly pass all these parameters into every drawing function, most drawing kits based on the X Window System instead using a Graphics Context (or GC) which contains a set of values that can be used by any drawing primitive. This is more efficient in other ways too, but you probably don't need to worry about them. You generally work with a fixed number of What I simply want to do is something like line(gtkDrawingArea* da, int x1, int y1, int x2, int y2, r, g, b) just grab a suitable GC, such as Glib::RefPtrGC gc = get_style()-get_fg_gc(); change its foreground color, specifically for whatever state the drawing area is in right now (widgets in GTK can be in one of several possible states): gc.set_foreground_gdk (redColor, get_state()); and draw on the window: get_window()-draw_line (gc, x1, y1, x2, y2); the precise details might be slightly off, i am writing from memory. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: glib\guitls.h, atexit and the windows DDK
You probably should build some helloworld type program that includes
some typical DDK headers without actually using any DDK functionality,
and includes glib.h, and just calls g_print(hello, dude\n) and see
what happens...
with some very kind guidance from Tor I was able to compile and run the
following program:
#include stdio.h
#include fcntl.h
#include glib.h
#include limits.h
#include stdlib.h
#include string.h
#include windows.h
#include winsock2.h
#include ws2tcpip.h
int __cdecl
main(int argc, char *argv[]) {
g_print(hello world\n);
}
so it would _seem_ that the add the __cdecl to the atexit declaration
in gutil.h change is safe?
rick jones
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Wait until widget is shown
I have a function that will take some time to run.. actually, it forks out another process which can take up to say 4 seconds. I want to display a modal dialog during this time, or perhaps just a statusbar message. In any case, whatever I do does not show up until AFTER the process is finished (and thus only shows up for an isntance). I thought I could maybe create a global flag that is set right before gtk_widget_show() , and is cleared once the show signal occurs for that widget, and then have an infinate loop waiting for that flag to be clear before calling that process. This bothers me because of the infinate loop and because it just seems like there's likely a better way. Like is therea function call that allows pending redraws or whatever to complete before continuing? Like a do pending tasks sort of thing. I saw a gtk_wait in another program once but I don't see that in the documentation. Any help? - Micah ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: status of IO Channels on Windows?
Tor Lillqvist wrote: Rick Jones writes: I was wondering about the status of IO Channels under Windows - specificially with respect to SOCKETs (the capitalization is Windows', not mine :) I ask because: Currently full support is available on UNIX platforms, support for Windows is only partially complete. There are some gotchas, but many things work without problems... Is that vague enough? ;) Yep. And with the little learning program I'm writing under linux, I've had fun with getting things non-buffered and NULL encoded :) A bit of a mindwarp for me. Probably good for me, but had me grumbling a couple times thinking this isn't a blankety blank socket, it is a FILE stream! :) I take it that the deprecated status of g_io_channel_[read|write] is for real and not just to scare people away? One gotcha is that setting up a watch on a GIOChannel to a socket puts the socket in non-blocking mode. This doesn't happen on Unix. But then, if you are using watches, your program presumably should use non-blocking IO anyway (otherwise, why not just use blocking socket API calls directly), so this shouldn't be a big deal. I suspect I can deal with that. There are also differences in how and when the callbacks are called. There are some open bugs on this (see for instance #331214) and things may change a bit (to make the behaviour more like on Unix) soon. Anyway, your best bet is to write your code so that when you get a callback for G_IO_IN, you keep looping reading as much as you can get until you get the G_IO_STATUS_AGAIN indication. Ditto. (BTW, see http://www.iki.fi/tml/fosdem-2006.pdf for some hints.) So, has it been compiled P64 yet?-) Don't yo just love how 64-bit windows went P64 rather than LP64 ?-) rick jones ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wait until widget is shown
On Thu, Mar 09, 2006 at 03:03:25PM -0800, Micah Carrick wrote: I have a function that will take some time to run.. actually, it forks out another process which can take up to say 4 seconds. I want to display a modal dialog during this time, or perhaps just a statusbar message. In any case, whatever I do does not show up until AFTER the process is finished (and thus only shows up for an isntance). I thought I could maybe create a global flag that is set right before gtk_widget_show() , and is cleared once the show signal occurs for that widget, and then have an infinate loop waiting for that flag to be clear before calling that process. This bothers me because of the infinate loop and because it just seems like there's likely a better way. Like is therea function call that allows pending redraws or whatever to complete before continuing? Yes, it is: gtk_main_iteration_do() (see also documentation of gtk_events_pending()). Yeti -- That's enough. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wait until widget is shown
Yes, it is: gtk_main_iteration_do() (see also documentation of gtk_events_pending()). Yeti Hah! Perfect. I knew it. Thanks! :) - Micah ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
