Hi Irtza,
On Sun, Apr 10, 2005 at 09:48:24PM -0400, Irtza Sharif wrote:
Thank you for your response. Let me clarify my situation.
I have a Scrolled Window within which I add a vbox
The widgets inside the vbox are held in a linked list that I have
setup. New widgets can be created and
Hello,
I use a scrolled window in a program of mine, and I've noticed that if I
set the value of its adjustment manually, the window is immediately
scrolled to the given position. For example, with something like the
following code (where vadj is the vertical adjustment of the window):
gdouble
On Mon, Sep 27, 2004 at 12:35:54PM -0400, Owen Taylor wrote:
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.
Done.
Two easy workarounds for your problem you might want to try:
at zero. But I can deal with that.
On Sun, Sep 19, 2004 at 12:02:48PM -0400, Stephen Bach wrote:
stuff
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Just a quick question. The gtk_layout_size_allocate() function seems to set
the page_increment fields of its layout's GtkAdjustments, but not the
step_increment fields.
So in, say, gtk_set_hadjustment_values() and gtk_set_vadjustment_values()
(called in gtk_viewport_size_allocate()) of
misunderstanding?
Thanks
On Sun, Sep 19, 2004 at 12:02:48PM -0400, Stephen Bach wrote:
Hello,
I've run into an issue in a program I'm writing where sometimes a call to
gtk_widget_queue_resize() ends in a request rather than an allocate. I've
put together a short test case (tested in GTK+ 2.4.4) which
Hello,
I've run into an issue in a program I'm writing where sometimes a call to
gtk_widget_queue_resize() ends in a request rather than an allocate. I've
put together a short test case (tested in GTK+ 2.4.4) which keeps the spirit
of the program intact (see below).
First, a little context --
I don't know if there's a tree view for this (I don't think so), but there
are a pair of widgets called GtkHWrapBox and GtkVWrapBox that may do what you
want. They work on an arbitrary group of widgets, but in a project I'm
working on I'm sort-of using them with labels to emulate a wrapping list.
I've come up with an acceptable solution to my problem, which I'll post here
for posterity. First my observations:
- The expose signal for the container was emitted only once, and after all the
widgets had been added/removed. This is good and means GTK is being smart,
and that
Hi Todd,
This sounds like a very similar problem I'm having. I'm curious if you
have some test case code that you could
post?
My testing was all done within the context of my program, but I can try. The
containers in question are WrapBox, which I've based on the GtkWrapBox class
from Gimp
Hello,
I have a container which periodically loses some of its widgets and gains
others, sometimes on the order of hundreds. The changeover happens all at
once (i.e. there's a big loop which does all the adding and destroying), but
it's still pretty ugly and slow because sometimes many repaints
BTW, I'm writing towards GTK+ 2.4.
On Sat, Aug 21, 2004 at 02:16:52PM -0400, Stephen Bach wrote:
Hello,
I have a container which periodically loses some of its widgets and gains
others, sometimes on the order of hundreds. The changeover happens all at
once (i.e. there's a big loop which
When I say repaint I just mean that the there is a visible change in the
widget. I guess I'm not using the word in its conventional GTK sense.
FWIW, I did connect to the expose signal of the container and found that it's
only called once, after the widget switchover is finished. Which I guess
13 matches
Mail list logo
