RE: [Inkscape-devel] sp_status_display()/sp_status_clear()
static SPDrawAnchor * sp_draw_anchor_new (SPDrawContext *dc, SPCurve *curve, gboolean start, gdouble dx, gdouble dy) { SPDrawAnchor *a;
sp_status_display(g_strdup_printf ("Creating anchor at %g %g",
dx, dy)); ... return a; }
Admittedly, the "original" would have been overly complex. The thing is, I think we have to be careful not to simplify the wrong things.
For example, why did we need the last parameter to sp_view_set_status() anyway? It's never actually used. It seems a good candidate to remove.
Done.
Also, shifting half the burden of memory management off is not a bad thing, but why not get both ends? Otherwise to people other than authors of sp_status_display(), it looks like a memory leak.
Sure, I would have done that myself, if only I knew how to define functions with variable number of arguments :) Now that you've shown me how to do that, I'll be able to avoid such things.
I see you could not wait and removed my functions replacing them with yours :) Sorry I'll now overwrite your changes, replacing them with still better functions that have time control (but implemented using your _statusf internally).
Right now I have one problem that I need help with. The stupid gtk_timeout_add can only pass one argument to the function it calls, but I need two arguments to remove the message: the statusbar * and the message_id. I tried packing them into a struct and passing a pointer to the struct, but here are two problems:
- if the struct is static, things break when a new timed message is displayed while a previous one's timeout has not yet elapsed, because the new call of the message display function will overwrite the static struct contents, and only the last message will be removed and the previous one will stuck forever;
- if the struct is local to the message display function, it does not work at all, because its content is lost when the function is over.
What I want is a way to pack the contents of the struct itself, not a pointer to it, to pass to gtk_timeout_add. But it won't convert a struct into a gpointer that this function requires. What to do?
A workaround might be to pass only message_id (converted to gpointer) and leave the statusbar stored in a global variable. But that is ugly and unreliable.
_________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...
On Sun, 2003-12-14 at 21:24, bulia byak wrote:
I see you could not wait and removed my functions replacing them with yours :) Sorry I'll now overwrite your changes, replacing them with still better functions that have time control (but implemented using your _statusf internally).
Ok. Be advised that the C++ conversion is going on right now; I'll try to merge anything you have committed, but you might want to hang back for a bit until the dust clears.
Right now I have one problem that I need help with. The stupid gtk_timeout_add can only pass one argument to the function it calls, but I need two arguments to remove the message: the statusbar * and the message_id.
You probably really want to use g_timeout_add_full():
g_timeout_add_full(gint priority, gint inteveral, GSourceFunc function, gpointer data, GDestroyNotify notify);
Use G_PRIORITY_DEFAULT for priority; as far as passing both bits of data, just g_malloc() your structure, and specify g_free for notify.
(gtk_timeout_add() is just a wrapper for g_timeout_add(), by the way -- the timeout and event loop stuff was moved into GLib for GTK 2.0)
(In general, actually, you might want to have a look at http://www.gtk.org/api/ and read through some of the changes introduced with GTK2 -- all kinds of good stuff in there.)
Actually, if statusbar * is a GtkStatusbar *, you'll need to make sure you increase the statusbar's refcount before calling g_timeout_add_full, and instead of g_free() use your own function that unrefs the statusbar and then g_free()s the structure.
If you don't handle the refcount properly, it can lead to crashes or memory leaks as the statusbar could potentially be freed to early, or never.
-mental
participants (2)
-
bulia byak
-
MenTaLguY