Re: catching destroying a window
On Wed, 2003-05-28 at 09:40, Peter Van Osta wrote: Hi, When destroying a window by clicking on the cross in the upper right corner the window gets destroyed and cannot be opend again afterwards: Gtk-CRITICAL **: file gtkwidget.c: line 1428 (gtk_widget_show): assertion `GTK_IS_WIDGET (widget)' failed. How to avoid this behavior and to make it possible to reopen the window again ? See usage of delete_event in http://www.gtk.org/tutorial/ch-gettingstarted.html Regards, Owen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Transparent buttons
On Wed, 2003-05-28 at 06:20, Sven Neumann wrote: Hi, Paul Davis [EMAIL PROTECTED] writes: On Tue, 2003-05-27 at 18:51, sydney barrow wrote: Is there a way to create transparent buttons (so that the background pixmap shows through) in GTK+ (1.2)? Any help would be greatly appreciated. IIRC, this was one of the really cool features of GTK+ 2, and it isn't possible in GTK+ 1. it certainly is possible, though it can be quite a bit more work. you need to use gtk_widget_shape_combine_mask() together with a GtkEventBox as the underlying widget type. getting full GtkButton semantics from this is hard, but if you want something that responds with generic (ie. button_press, button_release) events, its not that bad. If all you want is the background pixmap to show through, you don't need to do anything special since a GtkButton does not have it's own window but draws on the window of it's parent. Actually, this changed between 1.2 and 2.0. It's possible to right a widget that works like the GTK+-2.x GtkButton for GTK+-1.2 ... the GTK+-1.2 GtkCheckButton works that way, in fact. But you'd have to do it yourself. Or just use gtk2. Regards, Owen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: theme question
On Tue, 2003-05-27 at 22:50, Tony Denault wrote: I'm using gtk on solaris/sparc, but can't themes to work. I installed gtk-engines-2.2.0 using the standard way: ./configure make make install Copy a .gtkrc file: cp /usr/local/share/themes/Metal/gtk-2.0/gtkrc ~/.gtkrc-2.0 The way that most people would select a theme is, to put in their ~/.gtkrc-2.0 gtk-theme-name = Metal (Or select it through the GNOME UI for theme selection, if you are running GNOME) When I start a gtk2.2 program I get: Gtk-WARNING **: Unable to locate theme engine in module_path: metal, So I tried adding module_path in my .gtkrc-2.0 file, but I got: Gtk-WARNING **: module_path directive is now ignored Why can't my 2.0 theme load? I can find any instruction to indicate what I should do. Help.. If GTK+ was installed some place other than /usr/local, the gtk-engine's README file explains what to do: If you configured GTK+ in a non-default prefix, you should configure this package the same way. For instance: ./configure --prefix=/opt/gtk+ If you need to install this package in a different prefix from GTK+, then you'll have to set your GTK_PATH environment variable to point to the installed prefix. For instance, if this package was configured with: ./configure --prefix=/home/john.doe/gtk-engines/ Then you'd set: GTK_PATH=/home/john.doe/gtk-engines/lib/gtk-2.0/ export GTK_PATH This will allow GTK+ to find the newly installed theme engines. To use the sample themes (installed into $prefix/share/themes), you'll need to copy or link them into your ~/.theme [should ~/.themes - OT] directory. Regards, Owen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkWindow and GtkPaned and check-resize
On Tue, 2003-05-27 at 21:57, Paul Davis wrote: On Tue, 2003-05-27 at 18:33, Marcin Krzyzanowski wrote: Hi, I have a strange problem. I have a window, inside I put GtkPaned, and conenct to window as GTK_CONTAINER() to signal check-size, I suppose that it shoult be invoked only when window resize, but is is also when I move divider up or down, why ? check-resize is nothing you want to connect to ... it's very much an internal implementation detail. or could anybody tell me how to get moment when window window resized right ? I tried size-request, but there is the same situation. All I want to do is change divider position after window resize. ::configure-event is probably best ... note that you'll need to look the size in the event, since when ::configure-event is received the widgets in the layout have not yet been layed out at the new size. heh, heh. i wrote about this last week (not sure if i got a reply, i was gone). i don't know much about Paned has changed for gtk+2, but in gtk+1, its horrible for this kind of thing. to do what you want, i had to (a) write gtk_paned_get_position(), since gtk+1.2 didn't provide it and (b) connect to the size_allocate event for the paned. there, i would check that the allocation was larger than the desired position, and if so, would set the position. then i would have to flag that i had done this for that pane, because if you do it again later, you get into an endless feedback loop of size_allocate() events induced by the set_position() call. in the end, it all works nicely. in gtk+1.2 at least, if you attempt to set the position when the allocation is too small, the position is clamped to the current I don't think any of this is relevant here. See my response to you last week. Regards, Owen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gtk Refresh Problem
Hey Diego,
Thanks for the suggestion. it worked to some extent. Now I dont
get any error or warning but my GUI freezes now. I display a message box
in my program and I have put the code for GUI is in a separate thread.
I do something like this in the thread function:
gdk_threads_enter();
GtkWidget *dialog;
gint result = 0;
dialog = gtk_message_dialog_new (NULL, GTK_DIALOG_MODAL,
GTK_MESSAGE_WARNING, GTK_BUTTONS_NONE, No new hard drive was found.
Please check cable connections and jumper setting on the hard drive. Check
out Hardware Guide for details.\n);
gtk_dialog_add_buttons(GTK_DIALOG(dialog), View Hardware Guide,
GTK_RESPONSE_HGUIDE, NULL);
gtk_dialog_add_buttons(GTK_DIALOG(dialog), GTK_STOCK_OK,
GTK_RESPONSE_ACCEPT,
NULL);
/*-- Display the widgets --*/
gtk_widget_show_all(dialog);
result = gtk_dialog_run (GTK_DIALOG (dialog));
switch (result)
{
case GTK_RESPONSE_ACCEPT:
printf(OK BUTTON PRESSED\n);
gtk_widget_destroy(dialog);
break;
case GTK_RESPONSE_HGUIDE:
printf(HGUIDE BUTTON PRESSED\n);
gtk_widget_destroy(dialog);
break;
default:
printf(WINDOW WAS KILLED\n);
gtk_widget_destroy(dialog);
break;
}
gdk_threads_leave();
And I never see the result of clicking any button. The program seems to
freeze after showing the message box.
Can you suggest anything?
regards,
Bharat
On Wed, 28 May 2003, Diego Zuccato wrote:
Bharat Bhushan wrote:
I am developing this GUI in GTK+ and it seems gtk doesnt refresh the GUI
until a callback function returns. I saw some newsgroup and found that
other people have also had this problem.
I tried to fix this problem by running a separate whic practically does
following:
You're tking it the wrong way. If your callbacks are slow, then create
THEM as separate threads, but remember to GDK_THREADS_ENTER() and
GDK_THREADS_LEAVE() where needed. This way, the actual callback is more
or less just a pthread_create() call.
Hope that helps.
BYtE,
Diego.
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: problems with GtkPaned and allocation/set_position
[ Owen - I missed this while I was away, but dug it out the archive ] I'm not sure what you mean by allocated a final size. Most programs allocate each widget only once when a window is initially shown, my code traces at least 3 calls to size_allocate() for a given Paned. it happens, as far as i can tell, as a whole bunch of resizings take place as various scrolled windows adapt to their contents, which are added after the paneds are first sized. and I'm pretty sure GtkPaned handles set_position() before size_allocate() fine. it doesn't if the position is larger than the initial allocation. what happens is that gtk_paned_compute_position() uses the current allocation as the max position, and ends up setting paned-child1_size based on it. since child1_size is the only place where the requested position is ever stored, its then lost for ever, so to speak. if the position will fit into the *eventual* allocation, but don't fit into the current allocation, you lose the requested position. If widgets are getting allocated to a tiny size before they get their final size, then you are probably doing something funny in your app. well, i'm adding stuff to the window later, and the allocation for existing widgets (including several scrolled windows and paneds) changes because of the fill/expand settings i used when packing them. It might be possible to treat the set position as virtual and never clamp it, I might even take a patch to do that, though I'd be worried that it would look bizarre to the user if the paned was clamped to the right edge, they resized the window bigger, and the paned stayed clamped to the right edge. personally, i'd prefer gtk_paned_set_percentage(), which didn't use a hard position at all. to fix set_position() for these cases, paned's should leave the requested position untouched at all times. if the allocated size grows, then one child will benefit (could be either one, depending on how the paned was packed and how the window is stretched. But I don't think it should be necessary in most cases, and I'd like to see an test case of where things don't work first. that might be tricky to come up with. i'm in the middle of the release road map for ardour, and to create an example, i'd have to spend a while coding up some fairly complex box packing+run-time widget addition. do you really believe that size_allocate() is only called once? --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gtk Refresh Problem
Bharat Bhushan wrote:
Hey Diego,
Thanks for the suggestion. it worked to some extent. Now I dont
get any error or warning but my GUI freezes now. I display a message box
in my program and I have put the code for GUI is in a separate thread.
I do something like this in the thread function:
ARGH! That's obvious! You have to GDK_THREADS_ENTER()/LEAVE() multiple
times!
I hope leaving and reentering around gtk_dialog_run() is enough. But IMO
you're taking the wrong approach to event-driven programming: you're
trying to write a sequential program...
gdk_threads_enter();
This one is too early! Move it down after var decl.
GtkWidget *dialog;
gint result = 0;
dialog = gtk_message_dialog_new (NULL, GTK_DIALOG_MODAL,
GTK_MESSAGE_WARNING, GTK_BUTTONS_NONE, No new hard drive was found.
Please check cable connections and jumper setting on the hard drive. Check
out Hardware Guide for details.\n);
gtk_dialog_add_buttons(GTK_DIALOG(dialog), View Hardware Guide,
GTK_RESPONSE_HGUIDE, NULL);
gtk_dialog_add_buttons(GTK_DIALOG(dialog), GTK_STOCK_OK,
GTK_RESPONSE_ACCEPT,
NULL);
/*-- Display the widgets --*/
gtk_widget_show_all(dialog);
gdk_threads_leave();
result = gtk_dialog_run (GTK_DIALOG (dialog));
gdk_threads_enter();
switch (result)
{
case GTK_RESPONSE_ACCEPT:
printf(OK BUTTON PRESSED\n);
gtk_widget_destroy(dialog);
break;
case GTK_RESPONSE_HGUIDE:
printf(HGUIDE BUTTON PRESSED\n);
gtk_widget_destroy(dialog);
break;
default:
printf(WINDOW WAS KILLED\n);
gtk_widget_destroy(dialog);
break;
}
gdk_threads_leave();
And I never see the result of clicking any button. The program seems to
freeze after showing the message box.
Can you suggest anything?
It could be better to have a callback for every button in the dialog,
then just display it. The following switch() is unnecessary, since the
proper case is handled by the callback. You could even write a single
callback function, connecting it with different data. It's better if you
read some source code from a not-so-trivial program.
BYtE,
Diego.
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: theme question
On Wed, 28 May 2003, Owen Taylor wrote: On Tue, 2003-05-27 at 22:50, Tony Denault wrote: I'm using gtk on solaris/sparc, but can't themes to work. The way that most people would select a theme is, to put in their ~/.gtkrc-2.0 gtk-theme-name = Metal Tried this - no luck. If GTK+ was installed some place other than /usr/local, the gtk-engine's README file explains what to do: I am just using GTK (no gnome) on a sparc/Solaris8 system. I install everything (atk, glib, pango, gtk, gtk-engines) into their default locations: ./configure make make install Then I created a ~/.gtkrc-2.0. Still this didn't work. After some poking around, I found that my directory /usr/local/lib/gtk-2.0 contain the following: /usr/local/lib/gtk-2.0/ |--2.0.0/ |-engines |-immodules |-loaders |--2.2.0/ |-immodules |-loaders After I did this, gtk found my themes: cd /usr/local/lib/gtk-2.0/2.2.0 ln -s ../2.0.0/engines So it look like the gtk-engine installed itself in the 2.0.0. GTK 2.0 and 2.2 confusion. In many instances 2.2 really acts like 2.0. I ran across a similiar problem in the pkg-config utility too: 'pkg-config --cflags gtk+-2.2' doesn't work but I can use 'pkg-config --cflags gtk+-2.0' to compile my 2.2 apps. Tony /---\ | Tony Denault | Email: [EMAIL PROTECTED] | | Institute for Astronomy | Phone: (808) 932-2378 | | 640 North Aohoku Place |Fax: (808) 933-0737 | | Hilo, Hawaii 96720 || \---/ ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
