I've got a GTK+ based program and I'm trying to clean up the memory leaks. I'm
running it through valgrind using the instructions here:
http://live.gnome.org/Valgrind
I'm building against GTK 2.10.4.
Even with the suppressions, I'm getting lots of memory leaks reported.
First question: If I
Ack, that looks messy. Anyway, here's my current codeall the objects and
checks are sucessful, right up to the creation of the GdkPixbuf, but the damn
thing is blank---no image in it. I even glClear()'d the buffer to green so I'd
know it was getting *something*, but.nope.
I'm still trying to create a screenshot mechanism for my GtkDrawingArea which
will work even when the area isn't visible on-screen. I've made progress, but
there's still a problem.
The GtkDrawingArea is OpenGL-enabled (cc'ing to the GtkGLExt list), and it's
very difficult to draw OpenGL to an
I'm trying to allow an offscreen render to a pixmap to occur now, instead of
trying to force an expose event while a window is offscreen like I was before.
I've looked over the example code in pixmap.c that comes with GtkGLExt, but my
adaptation of it isn't working.
My configure-event handler:
projection were messed
up; but I've checked that, it's fine. So is the viewport. So it must be
something else?
- Original Message -
From: Lindley M French lfren...@gmu.edu
Date: Wednesday, August 26, 2009 2:46 pm
Subject: [GtkGLExt] GdkGLPixmap troubles
I'm trying to allow an offscreen render
for the vertexes as I did
for the glOrtho() call.
However, the attached image is what comes out. One corner right, the
othernot. *Something* fishy is going on
- Original Message -
From: Lindley M French lfren...@gmu.edu
Date: Wednesday, August 26, 2009 3:59 pm
Subject: Re: [GtkGLExt
About a month ago I posted that my GTK+ app stopped getting expose events when
I bg'd the app in Linux. Got no response, though.
Well, it seems to be worse than that.
I'm running the program through Putty from a Windows machine. If I minimize the
main window, or even just lock the screen,
Okay, I've determined that this new behavior is still just a symptom of expose
events not occurring.
Still curious why expose events don't happen when the program is bg'd but
on-screen, though.
- Original Message -
From: Lindley M French lfren...@gmu.edu
Date: Thursday, August 20, 2009
, 2009 at 6:55 PM, Lindley M French
lfren...@gmu.edu wrote:
Okay, I've determined that this new behavior is still just a
symptom of
expose events not occurring.
Still curious why expose events don't happen when the program is
bg'd but
on-screen, though.
- Original Message
) the back buffer without trouble? I don't know what
sort of tricks the expose event causes which are necessary to set up drawing.
- Original Message -
From: Lindley M French lfren...@gmu.edu
Date: Thursday, August 20, 2009 3:21 pm
Subject: Re: Odd Linux behavior
I'll try to throw something
Date: Thu, 20 Aug 2009 18:31:27 +0200
From: Nicolas George nicolas.geo...@normalesup.org
Subject: Re: Odd Linux behavior
To: gtk-list@gnome.org
Message-ID: 20090820163127.ga14...@phare.normalesup.org
Content-Type: text/plain; charset=iso-8859-1
What do mean, bg'd, exactly?
I've got a GtkScrolledWindow which contains an hbox that in turn contains a
number of other widgets, and each of those widgets has an ability to become
active in some sense.
What I'd like to do is arrange things so that when a particular widget becomes
active, the ScrolledWindow is adjusted to
If I start my GTK+ GUI up in Linux, it works fine---at least until I move it to
the background. At this point, all of the controls and UI elements continue to
display properly, but my GtkDrawingArea stops getting expose events.
There may be other related difficulties, but that's the most
I've got a scrolled window containing an OpenGL-enabled drawing area, and I'm
trying to implement drag-selection of OpenGL-rendered items.
This works just fine so long at the entire area I'm selecting is within the
drawing area. However, if it isn't, the program crashes because I can't control
, then gdk_window_get_size() on
viewport-view_window to get the width and height of the visible region.
There *must* be a better way do get this information, but damned if I can find
it.this just seems too useful to make it so obscure to locate.
- Original Message -
From: Lindley M French [EMAIL PROTECTED
I used a GtkScrolledWindow with a GtkDrawingArea inside it for OpenGL drawing
in my program. I found that yes, I did have to set_size_request when zooming in
and out.
Be warned: Due to the way resizing works in GTK+, it's impossible to do smooth
zooming where your scrolled window remains
It looks to me like you're making gtk calls in *both* threads?
This is bad, and can result in strange behavior. Don't do it. Secondary threads
should only make gtk calls via functions called via g_idle_add().
In this case, you may not even need a second thread. Instead of a loop with a
sleep
What could cause gdk_gl_config_new_by_mode() not to return? I'm finding this
behavior when my program is spawned by another process, but not when it's
started normally.
It's new---this didn't use to happen, and none of the code I've changed should
affect this directly.
I have a GtkTreeView representing a recently used history of items. I know
Gtk has specialized recent managers, but for my purposes they didn't seem
entirely appropriate.
Anyway, I'd like a way to delete items from this history. Three options present
themselves:
1) Have a delete button on
Well, the way that seems obvious to me would be to attach the newly allocated
data in some way to the user_data pointer passed to the first callback, and
have it accessible via the user_data pointer of the second callback as well.
In the simplest case, the pointer passed to the first would be
I've asked this question on several Gtk forums on previous occasions, but never
got much of a response. As this list seems a bit more active, perhaps my luck
will be better here.
I'm trying to implement a zoomable + scrollable window which remains centered
on the same point while it zooms. To
I have a GtkTable containing labels and entries. I don't want all label/entry
pairs to be visible at all times. To control this, I use gtk_widget_show/hide
on the labels and entries of a given row.
Previously, this worked just fine. After I refactored slightly, it no longer
does, and I cannot
PROTECTED]
Date: Monday, February 18, 2008 11:56 am
Subject: Re: GtkTable isn't updating properly
On 18/02/2008, Lindley M French [EMAIL PROTECTED] wrote:
I have a GtkTable containing labels and entries. I don't want
all label/entry pairs to be visible at all times. To control this,
I use
Message -
From: Lindley M French [EMAIL PROTECTED]
Date: Monday, February 18, 2008 2:56 pm
Subject: Re: GtkTable isn't updating properly
Well, calling gdk_window_invalidate_rect doesn't appear to be
helping. gtk_widget_queue_draw and gtk_widget_queue_resize didn't
help either, applied either
: Lindley M French [EMAIL PROTECTED]
Date: Thursday, February 14, 2008 11:17 am
Subject: Destroying widgets
Let's say I've got a hierarchy of widgets inside a C++ class.
There's a vbox which is the top of the hierarchy, and it may or may
not be attached to a parent; it's the handle by which
I'd like to make images appear on buttons, particularly buttons produced from
stock items.
Navigating the Gtk Reference Manual has made it clear that I somehow need to
activate the gtk-button-images property of the GtkSettings object for my
screen.
However, this class appears woefully
Let's say I've got a hierarchy of widgets inside a C++ class. There's a vbox
which is the top of the hierarchy, and it may or may not be attached to a
parent; it's the handle by which users of the class connect the internal GTK
hierarchy to whatever they've got.
I want to be able to cleanly
A couple of questions.
I have a GtkExpander containing a fairly large child. I have a GtkMenuBar above
the expander (positionally, not hierarchically), and a GtkTreeView below it.
Ideally, I'd like the behavior to be the following:
When the expander is collapsed, the GtkTreeView should
thought i'd throw it in.)
richard
On Feb 13, 2008 5:07 PM, Lindley M French [EMAIL PROTECTED] wrote:
A couple of questions.
I have a GtkExpander containing a fairly large child. I have a
GtkMenuBar above the expander (positionally, not hierarchically),
and a GtkTreeView
below
window,
specifying 1 for
both width and height, which will make it as small as possible as
defined by
the window's contents.
richard
On Feb 13, 2008 5:39 PM, Lindley M French [EMAIL PROTECTED] wrote:
Whoops, I was using gtk_container_add for the menu rather than
gtk_box_pack_start
[EMAIL PROTECTED]
Date: Monday, February 11, 2008 4:49 pm
Subject: Re: Does gtk have issues with STL?
On Mon, 2008-02-11 at 15:45 -0500, Lindley M French wrote:
I suspect these are merely symptoms of some other corruption,
but I can't seem to find it.
with a 99.872% confidence level, i
the very latest release) as
well
might help you quite a bit.
Sounds like you're dealing with race conditions (or could be
memory
corruption, of course). Valgrind/Helgrind could find your problems.
On 02/08/2008 11:50 AM, Lindley M French wrote:
I'd love to think it's my own source code
The problem may not be related to g_idle_add after all. It merely seems to
appear after some large number of iterations of the main loop (1+,
typically); including an idle function seemed to exacerbate it.
I have no idea how to track this down.
I'm experiencing instability when I call g_idle_add().
I say [i]instability[/i] because the crashes don't always occur at the same
time, so I can't pin them down. But they definitely go away if I comment the
g_idle_add call.
Sometimes---not always---the program will output something about
The instability I was seeing before might have been due to my use of an STL map
to maintain my list of available windows. Is this a known issue, or should I be
looking elsewhere?
I'm suspicious because several of the errors I've gotten (they're different
each time, even if I don't recompile)
gtk have issues with STL?
On Fri, 2008-02-08 at 10:44 -0500, Lindley M French wrote:
The instability I was seeing before might have been due to my
use of an STL map to maintain my list of available windows. Is
this a known issue, or should I be looking elsewhere?
I'm suspicious
36 matches
Mail list logo