Re: GError and gettext. Should I or shouldn't I?
Uzytkownik wrote: Should I use gettext in GError messages? In message is position of error in file. Or it will be print on stdout or for example on GUI show fragment of file. Heh, You made me jump, I've been using error-message to display save/load errors in glade3, dont worry; I just verified that its ok. You should use: g_set_error (error, domain, error_num, _(Translated error)); and *not* use: display_error (error_window, _(error-message)); 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: Doubt about free or dont free
Greg Breland wrote: [...] What really needs to happen(and I believe is in the works) is that the GTK manual needs user comments or wiki goodness. This would solve almost everything except that each function might have too much information before too long. :) While we're on a rant about API docs... After years of using gtk+, the thing I find most annoying about the API docs is the generic delagate functions. When I write: node = g_list_find_custom (list_of_addresses, joe, find_address_by_name); I invariably have to ask myself what argument comes first in: static gint find_address_by_name (AddressStruct *address, const gchar *name) /me ponders: Maybe that could be fixed by aliasing function typedefs, i.e. typedef GListFindFunc GCompareFunc And have a more specific documentation for GListFindFunc in the source. Hmmm, is there a way to do this without making the compiler complain ? maybe by using #define instead of typedef ? 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: Where the stock items are stored?
Hazael Maldonado Torres wrote: Hi guys Can anyone tell me where are *.[png|xpm] files for the stock items? This mailing list, this week: http://mail.gnome.org/archives/gtk-app-devel-list/2005-July/msg00238.html 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: To spawn or not to spawn? This is the question...
The Saltydog wrote:
I have an application that performs deep directory recurrent scanning.
During such scan, at each iteration, I execute while
(gtk_events_pending()) { gtk_main_iteration(); }in order to keep the
GUI updated from the directory scans results. It works fine, at an
acceptable speed.
Now my question: is it worth, in terms of application speed, to spawn
the reccurrent iteration and get the data thru a pipe, instead of
directly sending the data to the display routine?
Your application might respond better if each itteration was executed
in a g_idle_add callback instead of hijacking the mainloop, also;
if you use threads for this you dont have to bother with all the
gdk_threads_enter/leave stuff as long as your child thread is just
a worker thread, it can communicate with a GAsyncQueue.
Whether this is worth it is entirely up to you, ask yourself how
responsive the application has to be and also how unresponsive it
will get when faced with huge datasets.
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: simple example of gtk-scrolled-window not working
David Morse wrote: [...] The source is attached, hehe, no its not. you can quickly find the changed lines because the originals are commented with the c++ '//' comments. Basically I replaced gtk_window_new() with gtk_scrolled_window_new(), and also gtk_container_add() with gtk_scrolled_window_add_with_viewport(). GtkScrolledWindow is not a GtkWindow derivative or replacement (although the name might sound misleading). A GtkWindow *must* be present as a toplevel, you can add anything to the GtkWindow as it is a GtkBin (and GtkContainer). So put your GtkScrolledWindow inside the GtkWindow and all should work fine. Cheers, -Tristan Note that you can use this page to easily see what object derives from what: http://developer.gnome.org/doc/API/2.0/gtk/ch01.html (I usualy browse the docs from here). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [GObject] Error in unref
Uzytkownik wrote: [...] It's print address, but after it's error of memory. What do you mean by error of memory ? What do I do wrong? finalize isn't calling What does WocPagerParser derive from ? If there is GtkObject in the heirarchy, then gtk_object_sink() needs to be called (or gtk_object_destroy). 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: calling gtk_menu_popup from a button's clicked signal
Hubert SokoĊowski wrote:
Hi!
I have a GtkMenu which I want to popup when a user clicks a button.
my function that is called when user clicks the button looks like this
void
on_zamowienia_button_print_clicked (GtkButton *button,
gpointer user_data)
{
...
}
How do I get the GdkEventButton here so I can pass the time and button
values to gtk_menu_popup ?
You cant,
usualy you would use button-press-event for that.
I suppose generating the arguments for gtk_menu_popup() is no big deal
but why would you want to use a GtkButton to create a context menu ?
Cheers,
-Tristan
Note that You can't is an overstatement, you probably /could/ get
ahold of the button-release-event emmission which is being handled
by GtkButtonClass (hence the emmission of clicked) but that would
just be an API abuse :)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Window Visibility Signal
Kevin DeKorte wrote: What Signal is issued when a window becomes visible or invisible. Say I have a window and other window covers it up, is there signal that is emitted or if a window is uncovered? You'll recieve expose-event whenever X needs to redraw a widget, I think that in cases where the window is actualy presented (like with `gtk_window_present()') you'll recieve focus-in-event on the toplevel. 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: calling gtk_menu_popup from a button's clicked signal
Greg Breland wrote: [...] For example, our product helps users keep track of customers and what they've done for these customers. When our user's phone rings, they instantly hit F6 which is an activity dialog that lets them pick the customer and enter in free form notes. The user is only given the option to save or cancel. When the user clicks save they get a context menu where they can pick what to do with the data. There are about ~13 options on the menu. Here are a couple of examples: 1) Save as Note 2) Save as Completed Phone Call 3) Save as Completed Phone Call with Followup 4) Etc. Until the user has been using that screen for a few days, it confuses the mess out of them. There are only maybe 5 places that technique is used in the product thank goodness. Having a required combo box where the user chooses the type of record to create would slow the user down or so the thinking went by the developer. The only other option would have been to make the combo change save the form, but that would have been even worse. Maybe you could have a GtkTreeView + GtkListStore in a scrolled window on the same page with Save / Cancel, just make sure that the Save button is insensitive untill the selection in the list store is made. Just a thought. 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: Window Visibility Signal
Kevin DeKorte wrote: [...] Nice tip, but unfortunately the expose event does not signal when the object is covered up. Only when revealed. I even hooked event and event-after and nothing was emitted when I covered up the window. Only events were triggered when I moved the mouse into the window and out of it and clicks. I found what your looking for :) http://developer.gnome.org/doc/API/2.0/gtk/GtkWidget.html#GtkWidget-visibility-notify-event http://developer.gnome.org/doc/API/2.0/gdk/gdk-Event-Structures.html#GdkEventVisibility http://developer.gnome.org/doc/API/2.0/gdk/gdk-Event-Structures.html#GdkVisibilityState 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: Question? Broadcast to widget in a window
Carsten Rasmussen wrote:
I am new in GUI programming!
I just want to know if the is a function in GTK which can broadcast a
signal to all member widget of the Window.
What do you mean by broadcast a signal ?
Do you just want a function to be called for every widget in
a container ?
You can use gtk_container_foreach with a recursive callback like so:
==
gtk_container_foreach (GTK_CONTAINER (window),
recursive_foreach,
func_to_call);
void
recursive_foreach (GtkWidget *widget,
gpointer data)
{
func_to_call = (cast *)data;
func_to_call (widget); // Call the callback for this widget
if (GTK_IS_CONTAINER (widget)) {
gtk_container_foreach (GTK_CONTAINER (window),
recursive_foreach,
func_to_call);
}
}
==
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: getting real widget sizes how and when
Karl H. Beckers wrote: Hi all, Hi, I'm afraid I havent the time to try and deciepher your email, I can see that your having trouble getting the allocated size of your widgets in a viewport. There is a good chance that a widget will never get an allocation untill its actualy shown. I'm not very familliar with the GtkViewport but its the parenting container's responsability to give the child an allocation (at initialization and resizes etc). So maybe the solution to your problem is: Widgets in an area of a GtkViewport that is not shown (i.e. not in part of the scrolled window) /dont have a size/. 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: getting real widget sizes how and when
Karl H. Beckers wrote: [...] So maybe the solution to your problem is: Widgets in an area of a GtkViewport that is not shown (i.e. not in part of the scrolled window) /dont have a size/. Well, I've realized that and AM doing a gtk_widget_show before attempting to get the sizes. But the dialog does not seem to be rendered immediately. I anticipated that misunderstanding and still managed to not get across properly, when I say shown I really mean shown, not flagged with GTK_WIDGET_VISIBLE flag via the gtk_widget_show() api :) The viewport probably doesn't care about allocating any space for a child widget that is not in the viewing area, regardless of that widget's visibility flag. Ooops ... just thought of smth What I'm doing is check parameters for an app and pop up a modal warning dialog if smth. is wrong. Now, atm I'm doing this before I start the main loop does that sound like an explanation? Yes, configure-event should work for you, its emitted for resizes in general, but I believe there is an initial configure-event fired at allocation time. 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: cloning an object ...
Antonio Gomes wrote: [...] Depending on what you are trying to acomplish, you probably want to forget about cloning objects and take some other approach, but you are welcome to take a look at the `glade_widget_dup()' function in glade-widget.c (cvs co glade3). hu ... I got it. Well, being honest, I don't wanna to use any glade function, since I hope there is a simplest way to do this. Well, I wasn't sugesting that you link with glade (which wouldn't work anyway), just sugesting that you look at the code I wrote to get the feel of how to do it yourself. Let me explain better my situation: Basicly, I have a populated menu widget, and I *must* to clone it between two window (I don't wanna to share it between two windows).. Hmm, then your probably better off writing some menu specific code; rather than writing GObject based generic code. Heres an idea thats kindof a shot in the dark: - Build your first menu and make it the master menu (i.e. always base your replicas on the master menu), use GtkUIManager for it. - When building your replica menu(s), use `gtk_ui_manager_get_ui (master_menu)'. Seems like it should work, but it might be a naive guess :-/ HTH, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: cloning an object ...
Antonio Gomes wrote: [...] ANSWER from the list : Make an item with the same name to all the menus, and connect the same callback to both/all of them. This is the only way to do this currently, in the future you can do it with *GtkUIManager* magic, but that's in the future... :( so , there is no 'gtk_ui_manager_get_ui' available. I have try found out another way ... Is this an old message in a mail archive ? gtk_ui_manager_get_ui() /is/ in the GTK+ API docs, check it out. I'm pretty sure you just have to use a seperate GtkUIManager for each menu respectively (and rebuild the 'slave' menus entirely every time the master menu changes). 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: Will this create a memory leak? Can't determine from top.
Bartek Kostrzewa wrote:
Should I define an array of char pointers
*message[TABLE_SIZE][TABLE_SIZE] to hold the pointers created by
g_strdup_printf or would that just be a waste of memory?
I guess you want to free the string when the object emmiting the
signal is finalized, in that case you can use a function like
g_object_weak_ref like so:
===
void
free_signal_string (gpointer data,
GObject *where_the_object_was)
{
/* free the string here */
g_free (data);
}
/*
.
.
.
*/
string = g_strdup_printf (...);
g_signal_connect(button[i][j], clicked,
G_CALLBACK(print_position), string);
/* Hook onto buttons finalization */
g_object_weak_ref (G_OBJECT (button[i][j]),
free_signal_string, string);
===
Ofcourse you could think up a million solutions for this
problem and they could all be good.
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: Will this create a memory leak? Can't determine from top.
Tristan Van Berkom wrote: Bartek Kostrzewa wrote: Should I define an array of char pointers *message[TABLE_SIZE][TABLE_SIZE] to hold the pointers created by g_strdup_printf or would that just be a waste of memory? I guess you want to free the string when the object emmiting the signal is finalized, in that case you can use a function like g_object_weak_ref like so: Come to think of it, you can make it even simpler by just doing: g_object_weak_ref (G_OBJECT (button[i][j]), (GWeakNotify)g_free, string); 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: [GObject, long] Gtype for enum + runtime init or by init function.
Uzytkownik wrote:
Hi,
You should start off by reading:
http://www.le-hacker.org/papers/gobject/
1. In g_param_spec_enum I must have GType of this enum.
a) Why this function need it?
Its needed to register metadata about the enum type
to the type system, furthermore the object will refuse
invalid values for the said enum.
b) How create for enum GType?
Copy paste from my code:
=== header file ===
enum GtkTtScrollTypeEnum {
GTKTT_SCROLL_JUMPY,
GTKTT_SCROLL_CATCH
};
#define MY_PACKAGE_ENUM_TYPE (my_package_enum_type ())
GType gtktt_scroll_type (void);
= source file ==
GType
gtktt_scroll_type (void)
{
static GType etype = 0;
if (etype == 0) {
static const GEnumValue values[] = {
{ GTKTT_SCROLL_JUMPY, GTKTT_SCROLL_JUMPY, jumpy },
{ GTKTT_SCROLL_CATCH, GTKTT_SCROLL_CATCH, catch },
{ 0, NULL, NULL }
};
etype = g_enum_register_static (GtkTtScrollType, values);
}
return etype;
}
2. I should register GType in package_name_get_type or
package_class_init:
You must register the GType in the _get_type().
(if the type is not registered, then the type system didnt
get your GTypeInfo struct holding the pointer to the
_class_init function).
So, g_object_new (my_package_get_type())
will construct the object using the information stored
in the type system which was registered in my_package_get_type()
the first time it was called.
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: What key is now pressed?
Jan wrote: The main idea to know that key press or down in whole system, not only if my window have focus. I think this is as close as it gets using GTK+: http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-key-snooper-install This callback will be called for every key press /that gets delivered to your application/ so it isn't system wide. 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: Any way to disable window decorations (including X button)?
Paul Santa Maria wrote: Hi - I'm implementing a kiosk-style application in GTK+, and it's important to *disable* window resize, minimize, maximize, etc. Is there any way to simply remove window decorations (especially the X close button) from a GTK+ window? Hi, IMO, the kiosk itself should ensure that there is no window manager noise interfereing with the application on display; I work on an embedded jukebox system wich runs a GTK+ gui, we actually just dont run any window manager at all. 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: Clarification about gtk_main() and running simultaneous non-gtk functions
Michal Porzuczek wrote: Correct me if I'm wrong but the gtk_main() acts like an infinite while loop that waits for callbacks to the widgets that have been created before gtk_main() was called. gtk_main will run a GMainLoop: http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html The main loop will process event sources (IO events and timeout events). X server events get interpreted by GDK and sent to the appropriate GTK+ objects for processing as GSignals (such as button-press-event); sometimes other signals are emitted as a result (such as clicked on a button which recieved a button-press-event followed by a button-release-event). Note that signals are emitted synchronously and are not deffered to the main loop. My question is, except for the g_timer function which seems to just be for measuring proccesses inside actual callbacks, is it possible to have timers running simultaneously with gtk_main() without calling a separate program? That is, would it be possible to create a seperate while(1) that say checks for the value of some variable while gtk_main() is already running? You probably want to register a timeout GSource into your mainloop using g_timeout_add (), so that gtk_main () (i.e. the GMainLoop) will wakeup at the requested time and call your callback. If you run a while (1) in your process; then you are hijacking the main loop and your interface wont respond (not to mention that all your event sources, such as IO watches and timeouts wont be run either). If you must see while (1) in your code; you'll have to do it in another process or another thread. 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: Memory problems with gdk_pixbuf
John Coppens wrote:
Hello people.
A few weeks ago I posted a message about memory leaking. I haven't solved
the problem yet (thanks for a few privately received suggestions though).
The example below is taken largely from the GGAD manual, but, if the
segment is called repeatedly, allocates large chunks of memory, until a
certain point, where things break ('process killed')
--
global variableGnomeCanvasItem *img_item = NULL;
--
pxb = gdk_pixbuf_new_from_file(path, err);
// Check if the image was previously allocated. If so, destroy it
// Note that this relies on the pxb being destroyed too. It seems
// this does _not_ happen (Valgrind indicate this)
if (img_item)
gtk_object_destroy(GTK_OBJECT(img_item));
img_item = gnome_canvas_item_new(root,
gnome_canvas_pixbuf_get_type(),
pixbuf, pxb,
x, 0.0, y, 0.0,
width, pxb_w, height, pxb_h,
NULL);
gdk_pixbuf_unref(pxb);
--
My question is, what is the mechanism to destroy canvas items so that all
resources are freed too. (The above is derived from example in the GGAD, I
believe). Do I have to free the pxb manually?
You could try:
(gdb) watch ((GObject *)pxb)-ref_count
and see if you can find a reference leek, maybe the
canvas item isn't releasing its reference when it gets
destroyed ? maybe there is a reference leek somewhere else ?
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
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
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: Arguments in GObject-based object constructor
Jacob Kroon wrote: [...] What does it mean by delay initialization completion until the property is set ? You can override the constructor in your class_init function see: le-hacker.org/papers/gobject/ and read about the constructor, it is important that you chain up to the real gobject constructor in your constructor, after the real constructor returns, your my_instance_init() function will have been called and all construct properties will have been applied. 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: Newbey Question
Jamiil Abdullah-Alkadir wrote: [...] //Register CallBacks == **Here is the problem 8) gtk_signal_connect(GTK_OBJECT(btnExit), clicked, Quit, NULL); gtk_signal_connect uses functions with any signatures, they must all be cast to `void (*) ()' though first. try: gtk_signal_connect(GTK_OBJECT(btnExit), clicked, GTK_CALLBACK (Quit), NULL); 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: Using arguments in callbacks
Irwin Michael G DLVA wrote:
I'm not sure what exactly you mean by not supporting dlsym lookups for user
data. If I just want to pass a single integer as an argument to my
callback, is that even possible? And if so, how do I do it? You are
correct that I am trying to build the source with glade.
I'm assuming that whether you use generated code or libglade the
significance of the object field in the signal editor are the
same.
When you specify object in your signal; the object is a widget
name in the glade project (like label1 or togglebutton2 or something
smarter that you chose yourself).
When the signal callback gets called the said object will be the
*first* argument to the callback. So a decent example is:
- You connect to the clicked signal on the Quit button and
pass main window as the object field.
- The said signal callback gets called as such:
/* callback for clicked on quit_button connected with
* the G_CONNECT_SWAPPED flag.
*/
void callback (GtkWidget *main_window,
gpointer quit_button)
{
gtk_widget_destroy (main_window);
}
As far as libglade functionality goes; this is the *only* way that
the object field works; the object field refers to the name of
a widget in the said glade project, nothing else.
Cheers,
-Tristan
BTW: what I meant by dlsym lookups is that it's possible to use
the object field to pass a string to libglade so that libglade
will lookup the symbol in the calling code (in the global scope
ofcourse); I have a patch pending which implements this.
http://bugzilla.gnome.org/show_bug.cgi?id=161903
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Large files and asynchronous IO
Alexander Lyakas wrote: Hi all, I have been really impressed with GLib, portability and all. There are, however, two features I need, but I am not sure whether they exist. 1) Can I create large files with GLib? (Over 2 GB) That should depend on the filesystem you are using, otherwise; A quick glance at giounix.c says that there is no mention of `O_LARGEFILE' but I dont think many systems use this flag. (Note also you can open any file in whatever way you like and then feed the descriptor to g_io_channel_unix_new ()) 2) Is there some support for asynchronous IO? I would like to issue an IO request and to proceed immediately, being able to check/be notified when the request is completed. There is no integrated support for async io requests, you'd probably have to thread your io request; and when your thread finishes its io, it can notify the main thread of the io status (and that it probably neads to be reaped with g_thread_join() ) via the g_idle_add () function. 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: Pixmaps transparency
Peter Zhelezniakov wrote: Hello GTK developers, I have an external library that draws possibly transparent/translucent images to a GdkDrawable only. I want to capture these images in a pixbuf, but when i try to copy pixels from the drawable (a pixmap), all information about transparency is lost. So far i can think of two ways to solve this: - Draw every image to two pixmaps with different backgrounds, then compare results - Extend GdkPixmap somehow (isn't Gdk an object system, after all?) and override painting methods so that they keep track of transparency. I'm not sure this is feasible however. Could anyone please comment on this, or come up with better ideas? If your external library uses gdk_draw_pixbuf () to draw to the said drawables, you could hold a reference to the passed pixbuf by overriding the GdkPixmap implementation of -draw_pixbuf() in your GdkPixmap derivative, it doesn't sound elegant but if your stuck with that functionality; it'll do the trick. 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: can I pass user data to a button callback?
On Tue, 15 Feb 2005 09:32:46 -0800, Paolo Costabel
[EMAIL PROTECTED] wrote:
[...]
can I pass (a pointer to) user data to a button's callback? The compiler
wants me to create button callbacks like void (*)(void) -- but what I
need is void (*)(void*), at least for the pressed and released
signals
How could I do that?
Different GSignal's have different callback signatures; g_signal_connect
only needs the address of your callback code segment, typicly we use
the G_CALLBACK macro to cast like so:
/** */
void
foo_button_pressed (GtkButton *button, FooData *foo)
{
}
/** */
g_signal_connect (G_OBJECT (button), pressed,
G_CALLBACK (foo_button_pressed),
(gpointer)foo);
/**/
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 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
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
