Re: embossing of text in insensitive buttons

2006-11-18 Thread Freddie Unpenstein
On Fri 10/27, David [EMAIL PROTECTED] wrote: would it really improve anything? if people complain about embossed labels without trying the non-embossed look, does it tell anything (beside the fact they don't care that much)? see http://kf.fyz.fce.vutbr.cz/~yeti/tmp/gtk-no-emboss.png I

Re: GTK+ Signals

2006-11-18 Thread Ralf Stephan
Is this possible in C++? I suppose the Gtkmm list would be more appropriate for this. But if you mean `in C++ not using C++ bindings' -- what problems you got into? Thread moved to gtkmm-list. Thanks. ralf ___ gtk-app-devel-list mailing list

Re: embossing of text in insensitive buttons

2006-11-18 Thread Yeti
On Sat, Nov 18, 2006 at 03:40:04AM -0500, Freddie Unpenstein wrote: I think it'd need to be a style property, personally, rather than a developer setting. That's what I suggested. How about a general style property for shadow colour? Have it set on button and menu item (etc.) styles...?

Re: GTK+

2006-11-18 Thread Guy Rouillier
The way this is typically done is to check in main() for any already-running processes, and if present just shut down the newly started one. If you want to be user-friendly, you can give focus to the already running version so the user is not left wondering why the app didn't start. One

Re: How to scale Gtk-GUI application

2006-11-18 Thread Guy Rouillier
[EMAIL PROTECTED] wrote: Hi; I want to scale my Gtk-GUI application (which is basically large in size, not fitted with the screen) dynamically depending upon screen size. I am thinking that can be done by modifying .gtkrc-2.0 file. Please help me, how can I modify .gtkrc-2.0 file or

Re: [Tracker] Filechooser search support

2006-11-18 Thread Mikkel Kamstrup Erlandsen
2006/11/17, Matthias Clasen [EMAIL PROTECTED]: I have put an updated patch for filechooser search support in http://bugzilla.gnome.org/show_bug.cgi?id=344785 It is a port of the NautilusSearchEngine framework and supports both beagle and tracker, as well as a simple ftw()-based search. It

Re: GEvent - Proposal for a new threading structure for GLib

2006-11-18 Thread Olexiy Avramchenko
On 11/17/06, Matthew Barnes [EMAIL PROTECTED] wrote: ... I've attached a patch that implements and documents GEvent. It closely mimics the Python class, so I won't bother describing the API here. Is GCond not suitable for this purpose? Olexiy ___

Re: GEvent - Proposal for a new threading structure for GLib

2006-11-18 Thread Matthew Barnes
On Sat, 2006-11-18 at 15:04 +0200, Olexiy Avramchenko wrote: Is GCond not suitable for this purpose? Not by itself, no. You also need a mutex and an actual condition to watch for. GEvent uses a GCond internally. Matthew Barnes ___ gtk-devel-list

Re: GEvent - Proposal for a new threading structure for GLib

2006-11-18 Thread Tristan Van Berkom
Olexiy Avramchenko wrote: On 11/17/06, Matthew Barnes [EMAIL PROTECTED] wrote: ... I've attached a patch that implements and documents GEvent. It closely mimics the Python class, so I won't bother describing the API here. Is GCond not suitable for this purpose? Yes it is, never

Re: GEvent - Proposal for a new threading structure for GLib

2006-11-18 Thread Matthew Barnes
On Fri, 2006-11-17 at 12:27 -0500, [EMAIL PROTECTED] wrote: Isn't this what a semaphore is? A GEvent is essentially a binary semaphore, yes. With perhaps a more intuitive name. I would suggest that somebody look at what the full requirements are, and not mimic Python. :-) I think a

g_hash_table_steal_extended()

2006-11-18 Thread Ken Ishii
Hi, When you want to steal a key/value pair from a GHashTable and at the same time retrieve the pair's value, doing something like value = g_hash_table_lookup (hash_table, key); g_hash_table_steal (hash_table, key); requires hashing the same key twice. So instead, something like if

Re: g_hash_table_steal_extended()

2006-11-18 Thread muppet
On Nov 18, 2006, at 1:51 PM, Ken Ishii wrote: if (g_hash_table_steal_extended (hash_table, key, value)) A nice idea, but extended isn't a great name. How about steal pair? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org