Re: gtktreeview / multiple cell renderers
Martyn Russell wrote: On Thu, 2005-02-10 at 14:46 +0100, Denis wrote: Hi everybody, Hi, I am trying to build a tree_view on top of a GtkTreeModel I made and I would like to see in each cell an icon of the gtk stock by giving its stock-id and a text. Instead of using the pixbuf property you can use the stock-id property and just specify a string - e.g. GTK_STOCK_YES. This is what I do What is the correct code to do that ? Should I implement my own cell renderer ? (hopfully no...) No. Cool ! I attached the code I have currently : it works partially : the pixbuf_cell_renderer is added to the layout with expand = TRUE which is not what I want and I get theses messages on the standard output : GLib-GObject-WARNING **: IA__g_object_set_property: object class `GtkCellRendererPixbuf' has no property named `text' This error basically says you have tried to associate the text attribute with the pixbuf cell renderer. The text attribute should be associated with the GtkCellRendererText and the pixbuf or stock-id attribute associated with the GtkCellRendererPixbuf. I understand that. I looked at many examples but never found one where both the icon and the text were computed with the content of the cell :-( Have a look at these posts: http://mail.gnome.org/archives/gtk-app-devel-list/2002- September/msg00086.html http://mail.gnome.org/archives/gtk-app-devel-list/2003- July/msg00301.html They do not answer my question, let me reask it more clearly : I implement my own GtkTreeModel. I want to have 2 cell renderers : pixbuf (not expandable in layout) and text (expandable in layout). Each cell icon and text must be dependent on the content of the cell = I have to use a GtkTreeCellDataFunc. So now, I understood that if I use a GtkTreeCellDataFunc, I can check in it for which cell renderer I have to put the property (I can test as the cell renderer is passed as argument). Then my problem is to be able to add the pixbuf cell renderer as the first one and not being expandable... Indeed, the only function I see to set my GtkTreeCellDataFunc is gtk_tree_view_column_set_cell_data_func(...) AND I do not see any way to say add this renderer WITHOUT it being EXPANDABLE :-( Thank you again, Denis ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_threads_enter/leave() in threaded and non threaded situation
On Fri, 11 Feb 2005 09:46:41 +0200, Olexiy Avramchenko [EMAIL PROTECTED] wrote: Stefan Kost wrote: hi hi, Hello I have a gobject property that is set (via g_object_set()) from within a thread and from the main thread. Further I have signal handlers that watch this via notify::property. These signal handler call gtk functions. Therefore in these signal handlers the gtk part is wrapped with gdk_threads_enter/leave(). Wrong. GTK signal handlers run from main loop which is protected (gdk_threads_enter() before gtk_main() call). So you never should place locks inside signal handlers. You have to protect any call from *another thread* that uses GDK/GTK functions or data. Hmmm, there seems to be some confusion in this area... signal callbacks do not run directly from the mainloop, and if its a signal that you're getting from a Gtk object, you can assume that you already have the gdk_threads_mutex locked (or at least that /should/ be the case). When the mainloop runs, the mainloop holds the mutex for a short time, and unlocks the mutex while executing source callbacks (GSource; i.e. idle functions, timeouts IO channel watches). OTOH, when you call a function in the gtk+ api, example gtk_toggle_button_set_active(), once this function returns; all callbacks registered to the toggle signal for that toggle button will have already ran (i.e. there execution in *not* defered to the main loop). So, signals are a result of an access to a GObject, if that GObject is a GtkWidget, then the calling code segment should already have protected that call with the gdk_threads_mutex, so essentialy; in signal callbacks you already have the lock, and in GSource callbacks, you need to aquire it yourself. I hope that clears things up a bit ;-) Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
date widget
Hi, there is a widget that show the current date and time? Giovanni ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Expose Event
On Fri, 11 Feb 2005 06:06:00 + [ A b h i s h e k ] [EMAIL PROTECTED] wrote: Im having problem regarding writing code in the expose event of my event box. Whenever this event occurs, i am writing code to draw a rectangle in the handler but nothing seems to happen whereas if i run the same code in any other function or event handler it works. Is there something i need to know about the expose event. If u could help out please reply to [EMAIL PROTECTED] The only explanation I can think of is that the widget hasn't been set up to receive expose events. Something like gtk_widget_add_events(mywidget, GDK_EXPOSURE_MASK) would do this. HTH JV -- A requirement of creativity is that it contributes to change. Creativity keeps the creator alive. -- FRANK HERBERT, unpublished notes ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_threads_enter/leave() in threaded and non threaded situation
Hi hi, it is still not that simple :( I have a core lib, that is used by a commandline and by a gtk based app. All is gobject based. In the core lib I have an object A that has a property A.a. Now from the gtk app I set this property from a thread (when playing) and from my main thread (via user interaction). Other parts in the app subscribe to notify::A.a. The property A.a can be changed via g_object_set, but also changes during an action (playing). In the later case I call g_object_notify(G_OBJECT(self),play-pos); The g_object_set() is called from a signal callback that gets triggered by user action and thus already runs gdk_mutex protected. Wrapping this with enter/leave would block. I can wrap the g_object_notify() with the mutex instead, but that feels wrong, as this is an object in the lib, that can be accessed from non-gtk apps as well. In that case gdk_thread would not be initialized. The main problem is that the docs are not clear where exactly one needs to put enter/leave call. And if the it is wrong in just one place that whole app can start to behave odd. On Thu, 10 Feb 2005 22:20:51 +0100, Stefan Kost [EMAIL PROTECTED] wrote: hi hi, I have a gobject property that is set (via g_object_set()) from within a thread and from the main thread. Further I have signal handlers that watch this via notify::property. These signal handler call gtk functions. Therefore in these signal handlers the gtk part is wrapped with gdk_threads_enter/leave(). When the singnal is triggered from the thread it works, but when it gets triggerd from the main thread gdk_threads_enter blocks. This is quite obvious, as in this thread I am already in gdk_threads_enter(). But how should the signal handler know that (wheter it has been triggered from the main thread or from another thread)? Maybe you should protect g_object_set() with gdk_threads_mutex and assume that when you are in a signal callback, that you already have aquired the mutex (which should be the case for any signal emited by gtk+ anyway). 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: gdk_threads_enter/leave() in threaded and non threaded situation
another go in trying to make the situation clear. I have two place in the source that is causing the notify signal to be emited: A) core lib :: sequence.play() * when called from a gtk app it will run inside a thread * the method directly changes the property and calls g_object_notify() B) gtk app :: sequence-view.button_press() * is already protected by enter()/leave() * uses g_object_set() to change the property in the core lib The consumer of the notify:: signal is in the gtk app and call gtk methods. When A) sent the notify it would need to protect the gtk-calls by enter()/leave(). If B) has triggered the notify if must not, as this blocks. Pushing the enter()/leave() upstream is not easy as well. A) can't use enter()/leave() as it is not gtk related and b) can't as this would block. The only idea I now have is when starting the thread from the gtk-app, not starting sequence.play() as a thread. Instead creating a method in the gtk app that is started as a thread and that calls sequence.play() wrapped by enter()/leave(). I'll try this now. Stefan On Thu, 10 Feb 2005 22:20:51 +0100, Stefan Kost [EMAIL PROTECTED] wrote: hi hi, I have a gobject property that is set (via g_object_set()) from within a thread and from the main thread. Further I have signal handlers that watch this via notify::property. These signal handler call gtk functions. Therefore in these signal handlers the gtk part is wrapped with gdk_threads_enter/leave(). When the singnal is triggered from the thread it works, but when it gets triggerd from the main thread gdk_threads_enter blocks. This is quite obvious, as in this thread I am already in gdk_threads_enter(). But how should the signal handler know that (wheter it has been triggered from the main thread or from another thread)? Maybe you should protect g_object_set() with gdk_threads_mutex and assume that when you are in a signal callback, that you already have aquired the mutex (which should be the case for any signal emited by gtk+ anyway). 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: gdk_threads_enter/leave() in threaded and non threaded situation
On Fri, 11 Feb 2005 19:06:44 +0100, Stefan Kost [EMAIL PROTECTED] wrote: [...] The g_object_set() is called from a signal callback that gets triggered by user action and thus already runs gdk_mutex protected. Wrapping this with enter/leave would block. I can wrap the g_object_notify() with the mutex instead, but that feels wrong, as this is an object in the lib, that can be accessed from non-gtk apps as well. In that case gdk_thread would not be initialized. gdk_threads_enter/leave do nothing if the gdk_thread_mutex is not initialized or the code is compiled without GDK_THREADS_ENABLED, actualy, gtk+ internals typicly make calls directly to the GDK_THREADS_ENTER/ LEAVE() macros because they expand to a no-op when compiled without GDK_THREADS_ENABLED. Again, I wouldn't sugest protecting g_object_notify(), because it is already part of an object's code (i.e. you dont call g_object_notify on an object that you've instantiated, only on the object that you are writing). The simple rule is this: If you protect your object accesses with the mutex and keep all your gdk_thread_enter/leave calls in the procedural code/buisiness logic (and outside of your objects or signal callbacks), then you wont have this problem. OTOH, there may be an issue in your time-slices; it might be too expensive to protect such a large non-critical area of code; if thats the case, you'll have to keep all your possible use cases in mind and handle them on a case per case basis or structure your code so that its always obvious which objects are owned by which objects and which of those are responsable for aquiring a lock when accessing its delagates; in other words you have a lot of thinking to do if you dont follow that simple rule. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to set cursor color in GtkEntry?
It seems by default the cursor color is always set to black. The problem is, I've set my entry widget background to black (per user's requirement), now the cursor is appears 'invisible', but is actually black on black. There should be a way to set the cursor color to the text color currently in use. This is how other widget sets seem to work. Is this a bug? Thanks ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: intercept nervous button clicks...
Am Fr, den 11.02.2005 schrieb Felix Kater um 22:09: Iago Rubio: Set the window insensitive - or the buttons - and use a wait cursor to tell the user the program is working and should not be disturbed :) Thanks, this is, however, no solution. The problem is harder than it seems in the beginning: Whatever you do/block/change inside the button's events (press/click/release), it will be undone too early. In other words: It's not gtk but the surronding plattform which keeps the unwanted button clicks as long as the first pressed button has *completely* returned... And *then* (like real mouse clicks) the next click is launched... That is a windows problem, not a GTK+ one. On FreeBSD the superfluous click are disposed (don't know about Linux). A solution might be to empty the message queue of your programm, the win api has functions for such tasks. But that would be clearly platform dependant. HTH, Marc ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: intercept nervous button clicks...
Let me sum up: * In the beginning of each button click callback you call a function to make the buttons insensitive (even the clicked one? protection is needed here also), I just kept a list of all the buttons that mattered, and insensitised them all rather indiscriminantly (even the clicked one) in a loop. As someone else mentioned, you could try insensitising the whole window; I still wanted to keep some of the widgets active. * in the end of each button click event you start an idle function (by the way do you start the same idle function for all buttons? if so, how did you make sure to not start it twice?) It shouldn't be able to start twice. The idle function was started from the same function that insensitised all the buttons, and it was only those buttons' click handlers that called it. So once one triggered it, they were all rendered insensitive until it was over. Even so, I did keep the id of the idle function as a global, though you could stash it in the window object or something. The idle callback set the ID to an invalid value, and then re-sensitised everything and removed itself. * the idle function make the buttons sensitive again after a delay An idle timeout should do it, assuming Windows delivers the clicks as fast as the app will take them. Otherwise make the user wait half a second, or maybe even a full second. It's dodgy, but then so is the reason you're having the problem in the first place. ;) You could also try waiting until the idle callback has been called a couple thousand times. The only correct solution I can really see, would be to make the idle callback check to see if there's any more mouse clicks in the message queue, if that's possible without a large amount of pain and suffering. * the idle function is killed when the program exits Insensitise the buttons as soon as possible, start your processing, then when it's done, we start some kind of timeout to soak up all those damn mouse clicks. The idea is that the idle timeout shouldn't trigger while there are events comming in. At least, that was always my impression of what idle means. ;) Seemes to work on my system. My swap partition is on a hard drive that I don't often use for anything else, so it sometimes gets to spin down, causing the whole system to stop for a second or two while it spins up again so the virtual memory system can do its thing. It seemed to work fine there... Did I get you right? Sure... Give it a shot, and let us know how you went. Insensitising things is the proper way to indicate they're not supposed to be used right now, and this way it uses the built in mechansism to eat the excessive mouse clicks. Hopefully I haven't forgotten anything. ;) 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: How to set cursor color in GtkEntry?
Hello, I used to do such a thing and my way of doing such stuff was using gtkrc files (which is what i still use). There are two arrays that you need to set here: text and fg. Set them both to black for all possible indexes and I think you'll get the behavior you want. Here is a how the relevent part in you rc file would look like: fg[NORMAL] = black fg[ACTIVE] = dark slate grey fg[PRELIGHT] = black fg[SELECTED] = black fg[INSENSITIVE] = black text[NORMAL] = black text[ACTIVE] = dark slate grey text[PRELIGHT] = black text[SELECTED] = black text[INSENSITIVE] = black Hope it helps. Bye. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
