RE: gtk-list Digest, Vol 6, Issue 4
-Original Message- Date: Sun, 3 Oct 2004 14:28:38 -0700 From: Hudson T. Clark [EMAIL PROTECTED] Subject: Big problem now Michael Torrie _0 To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=windows-1252 Ok well I picked the advice that resulted in replacing my older version of glib with the newer one... everything seemed to go fine until I started fooling around with pango! Now I used removepkg on the old pango and installed the new pango (using -prefix=/usr to make sure, I don't know if that was good idea or not). Now gnome is crashing with the error: Gnome-session: error while loading shared libraries: libpangoft2-1.0.so.0: cannot open shared object file: No such file or directory libpangoft2-1.0.so.0 is usually a symbolic link that's part of the dynamic library lookup (dlopen) for the Pango freetype backend library. A typical set of symbolic links: libpangoft2-1.0.so - libpangoft2-1.0.so.0.600.0 libpangoft2-1.0.so.0 - libpangoft2-1.0.so.0.600.0 Where (in this example) libpangoft2-1.0.so.0.600.0 is the specific version of the library. A Pango application will dlopen with libpangoft2-1.0.so.0. Do an 'ls -l' in /usr/lib and see what's there. Is there a copy of libpangoft2-1.0.so.0.XXX.0 there? If not, check if Pango found freetype during configuration. I believe a relatively new version of freetype is required since the Pango freetype backend now does rotated text. (I'm guessing this is your problem.) If so, compare API version number (XXX) with version number of libpango-1.0.so.0.YYY.0 to ensure there are the same. Joe Vl ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_widget_queue_resize() forgetting allocation
On Mon, 27 Sep 2004, Owen Taylor wrote:
I'm not *completely* sure this should be considered a GTK+ bug, since
what you are doing is fairly marginal. But there is a fairly easy
fix, which would be, in gtk_widget_size_allocate(), do:
alloc_needed = GTK_WIDGET_ALLOC_NEEDED (widget);
- GTK_PRIVATE_UNSET_FLAG (widget, GTK_ALLOC_NEEDED);
+ /* Preserve request/allocate ordering */
+ if (!GTK_WIDGET_REQUEST_NEEDED (widget))
+GTK_PRIVATE_UNSET_FLAG (widget, GTK_ALLOC_NEEDED);
So, I'd actually appreciate it if you could file a bug in bugzilla
with your test case as an attachment and a link to this analysis
in the mail.gnome.org archives.
that is: #153896.
i've run into REQUEST_NEEDED still being set upon ::size-allocate while
debugging another scenario. unfortunately, the exact setup to reproduce
the bug i'm talking about is fairly complicated, it involves a lot of
widgets, a bunch of signal connections, size groups and a scrolled window.
here, siblings of a scrolled window (grouped together with the scrolled
window in a GtkSizeGroup) end up size requested but not properly size
allocated, with flags !REQUEST_NEEDED ALLOC_NEEDED or with both
flags unset, but the last size-allocate left out.
the actual problem is that gtk_widget_size_request() may be called
during size-allocation. with scrolled windows, this is actually not
uncommon, since size-allocate on a scrolled window changes the scroll
adjustments, and that in turn may change scrollbar visibility (which
queues a resize).
but if queue_resize is called during the size-allocation phase, for
some selected widgets inside a hirachy, the following state changes can
occour (widget and sibling don't need to share the same immediate parent,
but they have a common container in their ancestry and share a size-group):
queue_resize:
REQUEST_NEEDED ALLOC_NEEDED
ancestry* *
widget * *
sibling * *
size_request:
REQUEST_NEEDED ALLOC_NEEDED
ancestry*
widget *
sibling *
start of size_allocate phase:
REQUEST_NEEDED ALLOC_NEEDED
ancestry(got allocated)
widget (currently being allocated)
sibling *
widget calls queue_resize from size_allocate, which causes
queue_resize(sibling) (due to the GtkSizeGroup):
REQUEST_NEEDED ALLOC_NEEDED
ancestry* *
widget * *
sibling * *
end of first size_allocate phase:
REQUEST_NEEDED ALLOC_NEEDED
ancestry * *
widget * *
sibling * (got allocated)
after another size_request and size_allocate round, this will lead to
ancestry and widget being allocated new sizes, but will leave sibling
unallocated (though it was requested a new size).
calling gtk_widget_size_request() on a widget basically means:
1) call size_request on this widget (REQUEST_NEEDED set)
2) call size-allocate on this widget (ALLOC_NEEDED set)
and having REQUEST_NEEDED and/or ALLOC_NEEDED set on a widget requires
3) all its ancestry up to its resize-container have those flags set as well,
4) its resize-container must be in the idle-sizer queue.
so, doing just:
- GTK_PRIVATE_UNSET_FLAG (widget, GTK_ALLOC_NEEDED);
+ /* Preserve request/allocate ordering */
+ if (!GTK_WIDGET_REQUEST_NEEDED (widget))
+GTK_PRIVATE_UNSET_FLAG (widget, GTK_ALLOC_NEEDED);
in gtk_widget_size_allocate() isn't good enough.
only calling gtk_widget_size_allocate() will cause proper size
requisition on GtkSizeGroup siblings and care of the ancestry
invariants (3) and (4).
so CVS head now contains:
+Tue Oct 5 17:06:26 2004 Tim Janik [EMAIL PROTECTED]
+
+ * gtk/gtkwidget.c (gtk_widget_size_allocate): if REQUEST_NEEDED is still
+ set on ::size-allocate, another size-request has been queued since
+ ::size-request and needs to be requeued.
+
--- gtk/gtkwidget.c 16 Aug 2004 18:38:55 - 1.380
+++ gtk/gtkwidget.c 5 Oct 2004 15:08:14 -
@@ -2705,7 +2705,13 @@ gtk_widget_size_allocate (GtkWidget *wid
old_allocation.y != real_allocation.y);
if (!alloc_needed !size_changed !position_changed)
-return;
+{
+ if (GTK_WIDGET_REQUEST_NEEDED (widget))
+{ /* another resize has been queued */
+ gtk_widget_queue_resize (widget);
+}
+ return;
+}
g_signal_emit (widget, widget_signals[SIZE_ALLOCATE], 0, real_allocation);
@@ -2743,6 +2749,11 @@ gtk_widget_size_allocate (GtkWidget *wid
GdkRegion *invalidate = gdk_region_rectangle (widget-parent-allocation);
gtk_widget_invalidate_widget_windows (widget-parent, invalidate);
gdk_region_destroy (invalidate);
+}
+
+ if (GTK_WIDGET_REQUEST_NEEDED (widget))
+{ /* another resize has been queued */
+ gtk_widget_queue_resize (widget);
}
}
and i want to
Re: gtk_widget_queue_resize() forgetting allocation
On Tue, 2004-10-05 at 17:54 +0200, Tim Janik wrote: widget calls queue_resize from size_allocate, which causes queue_resize(sibling) (due to the GtkSizeGroup): REQUEST_NEEDED ALLOC_NEEDED ancestry * * widget* * sibling * * end of first size_allocate phase: REQUEST_NEEDED ALLOC_NEEDED ancestry * * widget* * sibling * (got allocated) after another size_request and size_allocate round, this will lead to ancestry and widget being allocated new sizes, but will leave sibling unallocated (though it was requested a new size). calling gtk_widget_size_request() on a widget basically means: 1) call size_request on this widget (REQUEST_NEEDED set) 2) call size-allocate on this widget (ALLOC_NEEDED set) and having REQUEST_NEEDED and/or ALLOC_NEEDED set on a widget requires 3) all its ancestry up to its resize-container have those flags set as well, 4) its resize-container must be in the idle-sizer queue. The way I'd think of this is that calling gtk_widget_size_request() sets the REQUEST_NEEDED flag, and we have a set of invariants: 1) If REQUEST_NEEDED is set on a widget, REQUEST_NEEDED is set on all parents up to the resize container 2) If REQUEST_NEEDED is set on the resize container, the resize container has an idle queued on it. 3) If REQUEST_NEEDED is set on a widget, ALLOC_NEEDED will be set on a widget. With the idle sizer behavior of calling request() than allocate() on the toplevel, I think this gives the correct behavior that queue_resize(widget) ensures ::request followed by ::allocate on the widget. As far as I can see, calls to gtk_widget_size_request() during size_allocate() still will handle 1) and 2) fine. The only problem comes with 3), which my patch should fix up. Regards, Owen signature.asc Description: This is a digitally signed message part ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_widget_queue_resize() forgetting allocation
On Tue, 5 Oct 2004, Owen Taylor wrote: The way I'd think of this is that calling gtk_widget_size_request() sets the REQUEST_NEEDED flag, and we have a set of invariants: 1) If REQUEST_NEEDED is set on a widget, REQUEST_NEEDED is set on all parents up to the resize container 2) If REQUEST_NEEDED is set on the resize container, the resize container has an idle queued on it. 3) If REQUEST_NEEDED is set on a widget, ALLOC_NEEDED will be set on a widget. With the idle sizer behavior of calling request() than allocate() on the toplevel, I think this gives the correct behavior that queue_resize(widget) ensures ::request followed by ::allocate on the widget. As far as I can see, calls to gtk_widget_size_request() during size_allocate() still will handle 1) and 2) fine. The only problem comes with 3), which my patch should fix up. ok, i tried hard, but after my initial example fell apart (idle sizer without size-request as discussed on irc), i can't come up with a scenrio to break the invariants with your patch at the moment. and since your patch does indeed fix my resizing bug, i gave you the benfit of a doubt and applied your patch. you agree on merging it down to 2.4? Regards, Owen --- ciaoTJ ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_widget_queue_resize() forgetting allocation
On Tue, 2004-10-05 at 21:10 +0200, Tim Janik wrote: On Tue, 5 Oct 2004, Owen Taylor wrote: The way I'd think of this is that calling gtk_widget_size_request() sets the REQUEST_NEEDED flag, and we have a set of invariants: 1) If REQUEST_NEEDED is set on a widget, REQUEST_NEEDED is set on all parents up to the resize container 2) If REQUEST_NEEDED is set on the resize container, the resize container has an idle queued on it. 3) If REQUEST_NEEDED is set on a widget, ALLOC_NEEDED will be set on a widget. With the idle sizer behavior of calling request() than allocate() on the toplevel, I think this gives the correct behavior that queue_resize(widget) ensures ::request followed by ::allocate on the widget. As far as I can see, calls to gtk_widget_size_request() during size_allocate() still will handle 1) and 2) fine. The only problem comes with 3), which my patch should fix up. ok, i tried hard, but after my initial example fell apart (idle sizer without size-request as discussed on irc), i can't come up with a scenrio to break the invariants with your patch at the moment. and since your patch does indeed fix my resizing bug, i gave you the benfit of a doubt and applied your patch. you agree on merging it down to 2.4? Yes, I think it's a pretty safe change. Regards, Owen signature.asc Description: This is a digitally signed message part ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
xpm from char string
In the toolbar section of the tutorial, there is this xpm gtk cube image declared as a string like that: static char * gtk_xpm[] I don't understand how that works. But actually my question is how to use it in the example. I tried to use method gtk_image_new_from_pixmap(), but how do I put this string in the pixmap? What is the way to do it? Thanks, Greg ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accelerators don't work
Thanks for the reply. I solved this problem by connecting the widget's can-activate-accel signal to a callback which will always return true. This solved the problem but now I am facing a new one. Some of the accelerators don't work even if the menubar is visible. But the shortcuts are shown as part of the menu item beside its name. Any thoughts on what might be happening here? From: edscott wilson garcia [EMAIL PROTECTED] Subject: Re: Accelerators don't work To: Pramod Patangay [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 El mié, 29-09-2004 a las 10:46, Pramod Patangay escribió: Hi All, I am trying to add accelerators to menu items. But they don't seem to work as they should. There's a menuitem which when activated will hide the menu bar. But once the menu bar is hidden, none of the accelerators work. I am using Fedora Core. Any idea on what's going on here? Why are accelerators disabled when menu bar is hidden? How do I enable them? and what are the other workarounds? Suprisingly I don't face this problem on RedHatLinux-8 but only on FedoraCore. I've got the same problem (Gentoo-linux with gtk-2.4). This fault is either a bug or the gtk developers decided that accelerators to hidden menu items is not a valid way to code. I'm not sure, but probably the latter is correct. To work around this issue, you could add in your own keypress event handlers. When you get a hit for a key that should accelerate to the hidden menu item, just go to the callback directly and return TRUE, otherwise FALSE. Edscott ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Changing the shortcut names for menu items
Hi, I have menu item to which I have added an accelerator. GTK automatically displays the shortcut as part of the text beside the menu item name. Is there any way I can change the shortcut string? Say for e.g., I add ctrl + as the shortcut, the displayed string is ctrl++ but I want it to be say ctrl plus or some othe string, can I do that? and how? Thanks ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
