On Wed, 2003-01-08 at 21:33, Federico Mena Quintero wrote:
I don't think that's the bug. I couldn't replicate the problem with the
attached program (e.g. it works fine and displays nothing).
Let me get Evo built on 2.0 to see where the calendar is breaking.
I've implemented a workaround in
On Wed, 2003-01-08 at 21:33, Federico Mena Quintero wrote:
I don't think that's the bug. I couldn't replicate the problem with the
attached program (e.g. it works fine and displays nothing).
Actually, it works fine here too. So it looks like you're right, and
this is a canvas issue after all
On Tue, 2002-12-10 at 20:58, Federico Mena Quintero wrote:
On Fri, 2002-12-06 at 14:52, Hans Petter Jansson wrote:
To make it display, you also have to apply the attached patch to
libgnomecanvas trunk, which makes it not try to draw a rectangle if its
area is zero (prior to patch it won't
I've committed code to the calendar to make it start up and display more
or less correctly. There are still a bunch of issues - it doesn't load any
data and still has several crashes, and clicking in the day view doesn't
produce expected results.
To make it display, you also have to apply the
On Fri, 2002-11-29 at 22:03, Mike Kestner wrote:
On Tue, 2002-11-26 at 00:44, Hans Petter Jansson wrote:
The GAL patch is just two small leaks.
Looks good. Please commit. Are you reworking it for trunk too?
Just did so. The logic is the same in trunk, so I don't think the
attached patch
On Tue, 2002-11-26 at 08:35, Dan Winship wrote:
The code should be unreffing it, not destroying it. Destroy doesn't
explicitly unref the widget, it's just that normally destroying a widget
will cause its parent to unref it. Since the invisible doesn't have a
parent, it still has a refcount of
For the past few days, I've been trying to find and eliminate as many
memory leaks as possible in the Evolution 1.2 calendar. I have CVS diffs
for Evolution, GAL and Bonobo.
The Evo patch is pretty straightforward: One big leak (all property
setters in libical omitted freeing the old value) and
