gtk_file_chooser_hangs (win32 libgdk-win32-2.0-0.dll)
Hello, i updated my mingw with the new All-in-one bundle on gtk download page. Now i have the problem, that the gtk_file_chooser is not working anymore in my application under win32. I get just a sandglass-curser over it. I get no warning or errormessage on the console. When I am taking older dll's (libgdk-win32-2.0-0.dll and libgtk-win32-2.0-0.dll) from August 26, everything works fine. With the new one from January 8 I have the problem. An idea what could be the problem? regards Arne -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Question about Callback
Hi,
thanks for your answer. I think I understand my code a bit better now...
I wonder whether it is best practice to use static functions for these
callbacks - in my code it is actually a member function (because of
having many different buttons whose states form a bitfield that is
compressed to one int value. I did not find any example that does not
use such static functions.
Greetings,
Christoph Hartwig
James Scott Jr schrieb:
You can also use:
- in the routine that creates the button, save a unique value.
g_object_set_data(G_OBJECT(button), Unique-Key, some-value)
-in button callback routine, retrieve the unique value.
some-value-pointer = g_object_get_data(G_OBJECT(button), Unique-Key);
This in addition to any pre-allocated memory structure you passed in the
g_signal_connect(), or g_signal_connect_swapped(). The issue with
reuse of button callbacks is always how to determine which button! I do
two things;
1. pre-allocate a memory structure with the first value a fixed id of
some sort (or related to the button's function). example
#def EXIT_BUTTON_FLAG 1
.
.
.
typedef struct _SomeButton {
gint cb_id;
...
} SomeButton, *PSomeButton;
.
.
.
PSomeButton memButton = NULL;
.
memButton = g_new0(SomeButton, 1);
memButton-cb_id = EXIT_BUTTON_CBID;
.
g_signal_connect(G_OBJECT(button), toggled,
G_CALLBACK(fn_callback), memButton);
.
.
2. g_object_set_data() and g_object_get_data() as described earlier.
checking the cb_id of the userdata from g_signal... and also getting
this extra value helps your positively identify which button was
pressed.
Either method will work, but sometimes both come in handy.
Hope that helps. Also, here is a link to source code that may help
explain better.
http://mysite.verizon.net/ressgdw8/sitebuildercontent/sitebuilderfiles/gtkstatusicon-starter-program-0.1.0.tar.bz2
And don't forget to review 'gtk-demo', it has good examples.
James,
On Sun, 2009-01-11 at 12:42 +0100, Rudolfo Pinewood wrote:
Hi,
I have a question regarding Callback functions for Toggle buttons.
I have several togglebuttons, that are all registered to call one
specific function (ApplyFlags). In this function I actually don't know
which button was activated.
My attempt was giving each button/callback an additional parameter that
should be passed to my ApplyFlags function.
However I was not able to do so - MemberCaller1 seems to fit (regarding
the call one function with one parameter) but I did not manage to get
my parameter into that Callback in
g_signal_connect_swapped(G_OBJECT(button), toggled,
G_CALLBACK(callback.getThunk()), callback.getEnvironment()).
How could this be done?
Thanks in advance
Christoph Hartwig
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: qt vs gtk
Some of my thoughts on the matter: On Wed, Jan 14, 2009 at 10:10:42AM -0600, Thomas Stover wrote: ... -QT (last time I checked) is not even C++. It's C++ and a custom macro language. building ouch. debugging ouch. C++ paradigm ouch. The Qt macros aren't very intrusive. Once you have your makefiles figured out, it's not building is not terribly painful, for either one. Figuring out the makefiles means automating moc for Qt, and glib-genmarshal for Gtk. I agree 100% that debugging with gdb is much easier for C than C++. I find that deriving classes in C++ is alot easier than going through the GObject type system. -HUGE: glib and gtk are separate. glib can be used on it's own. so one mental model to work with for gui and non-gui events. Qt4 has been split into different modules -- QtCore (think glib), QtGui (think Gtk), QtXml, etc. -When you start getting into it, there is just no contest. I love GTK. I have no doubt that if I started to read about qt, that I would constantly be saying, oh you can't do that, and you mean you have to that. Long live GTK! When it comes to documentation, Qt really outshines Gtk. I have never had to dive through code to figure something out in Qt. I always have a copy of the Gtk source code untarred and ready, though. JV ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Question about Callback
Hi,
thanks again for your help.
1) I did change my function to a static one
2) I updated my g_signal_connect_swapped to use G_CALLBACK(staticfunc) +
param parent (which I use to get the other buttons)
3) I noticed that the pointers were in wrong order (parent was the first
one instead of second) - changed to g_signal_connect instead and order
is right.
I now can use my function as desired. I only have to integrate some
other fields, but I think I'll get that ready with the knowledge I
received here.
Many thanks!
Christoph Hartwig
James Scott Jr schrieb:
Rudolfo,
In your case where you have multiple buttons operating on the same
logical data field, using a single callback function is very practical.
The same can be said for a callback that performs a single logical
function, all windows/object should attempt to reuse that callback if
they need that functions.
Example; being a pair of callback I wrote that is called when a window
is hidden or shown. All my dialogs/windows that need that service reuse
those single callbacks. To handle the fact that each window instance
saves its visibility value in a different variable/address, I pass into
the g_signal_connect(..., b_visible) the address of that variable when
creating each window.
void cb_main_interface_show (GtkWidget * widget, gboolean *pb_visible)
{
g_return_if_fail (pb_visible != NULL);
*pb_visible = TRUE;
}
void cb_main_interface_hide (GtkWidget * widget, gboolean *pb_visible)
{
g_return_if_fail (pb_visible != NULL);
*pb_visible = FALSE;
}
To me this helps organize the code and makes it easier to maintain. The
cost of this reuse is fairly low, and the g_object_[set|get]_data()
along with user-data cb_id flags, normally handles it well. Of course
all this reuse can be impacted by the to many global/static variables --
which limits the re-entrancy or reuse of any program.
My two.
James,
On Tue, 2009-01-13 at 20:40 +0100, Rudolfo Pinewood wrote:
Hi,
thanks for your answer. I think I understand my code a bit better now...
I wonder whether it is best practice to use static functions for these
callbacks - in my code it is actually a member function (because of
having many different buttons whose states form a bitfield that is
compressed to one int value. I did not find any example that does not
use such static functions.
Greetings,
Christoph Hartwig
James Scott Jr schrieb:
You can also use:
- in the routine that creates the button, save a unique value.
g_object_set_data(G_OBJECT(button), Unique-Key, some-value)
-in button callback routine, retrieve the unique value.
some-value-pointer = g_object_get_data(G_OBJECT(button), Unique-Key);
This in addition to any pre-allocated memory structure you passed in the
g_signal_connect(), or g_signal_connect_swapped(). The issue with
reuse of button callbacks is always how to determine which button! I do
two things;
1. pre-allocate a memory structure with the first value a fixed id of
some sort (or related to the button's function). example
#def EXIT_BUTTON_FLAG 1
.
.
.
typedef struct _SomeButton {
gint cb_id;
...
} SomeButton, *PSomeButton;
.
.
.
PSomeButton memButton = NULL;
.
memButton = g_new0(SomeButton, 1);
memButton-cb_id = EXIT_BUTTON_CBID;
.
g_signal_connect(G_OBJECT(button), toggled,
G_CALLBACK(fn_callback), memButton);
.
.
2. g_object_set_data() and g_object_get_data() as described earlier.
checking the cb_id of the userdata from g_signal... and also getting
this extra value helps your positively identify which button was
pressed.
Either method will work, but sometimes both come in handy.
Hope that helps. Also, here is a link to source code that may help
explain better.
http://mysite.verizon.net/ressgdw8/sitebuildercontent/sitebuilderfiles/gtkstatusicon-starter-program-0.1.0.tar.bz2
And don't forget to review 'gtk-demo', it has good examples.
James,
On Sun, 2009-01-11 at 12:42 +0100, Rudolfo Pinewood wrote:
Hi,
I have a question regarding Callback functions for Toggle buttons.
I have several togglebuttons, that are all registered to call one
specific function (ApplyFlags). In this function I actually don't know
which button was activated.
My attempt was giving each button/callback an additional parameter that
should be passed to my ApplyFlags function.
However I was not able to do so - MemberCaller1 seems to fit (regarding
the call one function with one parameter) but I did not manage to get
my parameter into that Callback in
g_signal_connect_swapped(G_OBJECT(button), toggled,
G_CALLBACK(callback.getThunk()), callback.getEnvironment()).
How could this be done?
Thanks in advance
Christoph Hartwig
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: qt vs gtk
jvette...@users.sourceforge.net wrote: I find that deriving classes in C++ is alot easier than going through the GObject type system. Yes this is true, in C. GTKmm makes things rather nice if you work in C++. In fact I kind of like how GTKmm works without a preprocessor, with type-safe callbacks. I wish Qt folks would compare Qt against GTKmm rather than just GTK+, as they are looking at things from a C++ point of view anyway. When it comes to documentation, Qt really outshines Gtk. I have never had to dive through code to figure something out in Qt. I always have a copy of the Gtk source code untarred and ready, though. GTK is always in need of people willing to flesh out the documentation. It is nice that one can refer to the source code in any open source project. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
some erros
Hi,
anybody can help me to resolve this?
GtkFileFilter *filtro;
GtkWidget *chooser;
//GtkFileChooser *chooser;
gtk_file_filter_set_name(filtro,bmp);
chooser = gtk_file_chooser_dialog_new (Open File,
parent_window,
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_STOCK_CANCEL,
GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
NULL);
gtk_file_chooser_add_filter(*chooser, *filtro);
gtk_widget_show(chooser);
if (gtk_dialog_run (GTK_DIALOG (chooser)) == GTK_RESPONSE_ACCEPT)
{
char *filename;
filename = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER (chooser));
g_print (filename);
}
gtk_widget_destroy (chooser);
how I can add filter to my chooser??
thanks
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: some erros
On Thu, 15 Jan 2009, frederico schardong wrote:
anybody can help me to resolve this?
GtkFileFilter *filtro;
GtkWidget *chooser;
//GtkFileChooser *chooser;
gtk_file_filter_set_name(filtro,bmp);
chooser = gtk_file_chooser_dialog_new (Open File,
parent_window,
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_STOCK_CANCEL,
GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
NULL);
gtk_file_chooser_add_filter(*chooser, *filtro);
gtk_widget_show(chooser);
if (gtk_dialog_run (GTK_DIALOG (chooser)) == GTK_RESPONSE_ACCEPT)
{
char *filename;
filename = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER (chooser));
g_print (filename);
}
gtk_widget_destroy (chooser);
how I can add filter to my chooser??
By using gtk_file_chooser_set_filter().
Allin Cottrell
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: some erros
Frederico,
From your code listing part of your problem could be this syntax error:
gtk_file_chooser_add_filter(*chooser, *filtro);
it should read;
gtk_file_chooser_add_filter(chooser, filtro);
James,
On Thu, 2009-01-15 at 22:58 -0200, frederico schardong wrote:
Hi,
anybody can help me to resolve this?
GtkFileFilter *filtro;
GtkWidget *chooser;
//GtkFileChooser *chooser;
gtk_file_filter_set_name(filtro,bmp);
chooser = gtk_file_chooser_dialog_new (Open File,
parent_window,
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_STOCK_CANCEL,
GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
NULL);
gtk_file_chooser_add_filter(*chooser, *filtro);
gtk_widget_show(chooser);
if (gtk_dialog_run (GTK_DIALOG (chooser)) == GTK_RESPONSE_ACCEPT)
{
char *filename;
filename = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER (chooser));
g_print (filename);
}
gtk_widget_destroy (chooser);
how I can add filter to my chooser??
thanks
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: set_resize
Il giorno mer, 14/01/2009 alle 23.00 +0200, Markku Vire ha scritto: Hi, 0On Wed, 2009-01-14 at 17:00 +0100, Pietro Battiston wrote: Forcibly clipping window size would anyway only be band-aid to the real problem in the application, which can be: ... - it doesn't constrain the size of a dynamically resizing widget I don't see how this is a problem; instead, it is where my question came from: I had a ScrolledWindow which I wanted to be as big as possible, but not as big as its child if that meant overflowing screen. The problem here is that the application might, for example, display a label with content it reads from somewhere. So, the application doesn't know in advance, how long the text can be. If it's displayed straight away, it can end up containing thousands of characters, which will expand the window very large horizontally. The right approach would be to enable ellipzation (or scrolling), which quarantees that the label will only consume some sane amount of space, no matter how long string it will display. Then the user can resize the window if she wants to see larger piece of ellipsized content. Usually it's better to left sizing of the window to the user. So, you don't need to make your scrolled window as large as possible. The user will make the toplevel window larger if she is interested about the content. But certainly you can provide some initial size for your app. Actually, all my problems come from a zoom to fit content button, which _the user_ can press. But I do recognize it's something very particular of my app. Pietro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: set_resize
Il giorno gio, 15/01/2009 alle 08.55 +0200, Kalle Vahlman ha scritto: So while setting sensible minimum sizes and constraining maximum by ellipsation or scrolled container for your *widgets* makes totally sense (to ensure the application will be usable on the first run), taking over the window management by controlling the *window* size really isn't worth the effort. It only brings error possibilities and since you never really can trust the window manager (not to mention the user) to grant your request anyway... Got it. I'll take look on the metacity side. thank you both Pietro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Animation in Gtk+
Hello devel list, during the last months I looked for a way to bring animation into Gtk+. The last few weeks I looked especially into an idea timj came up with. I try to give a briefly overview over it here. The idea The main idea is to obtain the pixmap representation of a widget in the main loop. Why in the main loop? Every expose event has to pass it and because of the double buffering code it's easy to obtain the new pixmap with gdk_window_redirect_to_drawable (). So the animation process can look like this: 1) Widget state changes: the widget exposes its area and sets an animation flag 2) Expose event arrives at the main loop: the new pixmap representation is obtained and an timer starts when the animation flag of the widget connected to the expose event is set 3) Timer event is running: this timer calls a callback that defines the change between the old and the new pixmap representation of the widget This is a very briefly description of how it can work but it is only for the sake of giving an idea. The problems 1) Many widgets are containers and an animation of a container can imply the animation of its children. Example: You have a GtkBox and you add an additional widget then there is maybe an animation which smoothly slides in the new widget and scales down the others (see http://video.google.de/videoplay?docid=-5544546765623963617 for an example). That means that you have to obtain the new representation of children before you start the animation but in the main loop you would get the representation of the entire widget hierarchy. A possible solution would be to queue the children instead of passing the expose event down the widget hierarchy. The main loop can work on the queue and control that all pixmap representations are obtained. With g_object_set_data () it can also connect the new pixmap with the widget. 2) Not all elements of a widget are in turn widgets. This makes it difficult to apply the stated method on them. This would concern e.g. the tabs of the GkNotebook or the elements of a GtkTreeView. There are at least 2 possible solutions to this problem: - These elements become widgets, - The widget obtains the pixmap representation and the connection to the child elements by itself. That's it! I hope that this mail gives a good overview of the idea. Questions, comments, additional ideas or problems are appreciated! Best regards, Hagen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: set_resize
Hi, 2009/1/14 Pietro Battiston too...@email.it: the documentation for gtk_widget_size_request () says: Also remember that the size request is not necessarily the size a widget will actually be allocated. While there may be a lot of reasons why a widget doesn't get the area requested, I imagine(d) the basic one would be because there is not enough space on the screen for everyone. Instead, size_requests are indeed fulfilled at cost of greating a window much bigger than the screen. Then, I frankly don't see the point of set_size_request (but I understand why it's very rarely used!). The size request should be called the minimum size but is only called size request for historical reasons. What you want is gtk_window_set_default_size() perhaps. Or gtk_window_resize(), or gtk_window_fullscreen()/gtk_window_maximize() perhaps. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: set_resize
Il giorno gio, 15/01/2009 alle 16.41 -0500, Havoc Pennington ha scritto: Hi, On Thu, Jan 15, 2009 at 10:04 AM, Pietro Battiston too...@email.it wrote: I already considered my doubt as answered (see below), but I disagree with what you say: if you call size_request minimum size, why don't you fulfill it, and how do you call set_size_request?! Maybe you meant set_size_request? I don't know what you mean; set_size_request just sets the size request. The size request is defined as the minimum size, that is how GTK works. If you don't set it with set_size_request, then the size request (aka minimum size) of a window will be the sum of the minimum sizes (size requests) of all the contained widgets in the window. set_size_request is just a way to override the normal minimum size. I promise I am right, I added gtk_widget_set_size_request in the first place: 2001-08-07 Havoc Pennington h...@pobox.com * gtk/gtkwidget.c (gtk_widget_set_size_request): new function (gtk_widget_get_size_request): new function And the API docs are: * gtk_widget_set_size_request: * @widget: a #GtkWidget * @width: width @widget should request, or -1 to unset * @height: height @widget should request, or -1 to unset * * Sets the minimum size of a widget [...] When the docs say Also remember that the size request is not necessarily the size a widget will actually be allocated, they are primarily referring to the fact that the widget can be *larger* than its size request, because there is extra space in the window for whatever reason. MMhhh... I think there is somewhere a problem in communication, and since you forged the terms at the time I still was a schoolboy, the problem is evidently mine... So I'll try to explain what I mean: get_size_request returns a size that I'll call x and that is a request stronger than the one returned by size_request, right? I mean: the user can't shrink it. How do you call x? Or is the fact that the user can't shrink a window just related to a particular flag set collaterally by set_size_request? I searched for something like that in the documentation, but with no luck. It is possible for widgets to get a size smaller than their minimum size, but only due to a bug in something, really. It can be due to a bug in the window manager rather than the app, so gtk widgets usually try not to crash if they get a size below the minimum. can't it also just be due to a user resizing?! When I program in gtk, I always think to size_request (or if you prefer the do_size_request() method of the python subclass of gtk.SomeThing I'm working on) as a size I'd like for my widget. But when I really need a size under which the widget is really ugly, or maybe crashes, I use set_size_request. Is this approach totally wrong? That said, I thought that instead as far as a user can resize (=as far as I use size_request but not set_size_request), I don't see anything bad in the window manager doing it (this is referred to your above text). So in my utopic world (where every window manager obeys my orders), metacity would have just said size_request? sorry, I'll give you less, I have not enough screen. get_size_request (yours or of some children)? OK, here you are, but it's your fault if you overflow. Anyway, I woke from this dream already a couple of emails ago. What I wanted is: windows which don't overflow the screen when their size_request (but not their set_size_request) is too big; however, I understood this is impossible without coordinate improvements to the window manager(s) _and_ gtk. Some window managers may automatically force windows to fit on the screen, but it's not technically allowed for them to force windows below their minimum size. Some may do it anyway, perhaps, but it's pretty much a bug. If you want to resize a window without changing its minimum size, then the right calls are things like gtk_window_set_default_size() and gtk_window_resize(). Yes, that's what I do. Together with ugly hacks to know how much I can resize before overflowing screen... Pietro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
