RE: [wxhaskell-users] Deleteing Controls / Derivation Viewer

[Brandon M. M. <br...@it...>]

On Sun, 17 Aug 2003, Daan Leijen wrote:

> Hi Brandon,
>
> > I'm writing a program that would like to display derivation
> > trees for simple proofs. I'm representing derivations as a
> > tree structure where the nodes are labeled with the result
> > and the rule used.
>
> Thanks for trying wxHaskell!
>
> > I have a function produces a tree from a derivation and a
> > parent, returning a panel with the conclusion, a horizonal
> > line (of the right width, using bestSize on the staticTest),
> > and a row of panels containing the subderivations. How
> > expensive are panels? Should I avoid deeply nested containers?
>
> Hmm, in general, using layout is not very expensive and you
> can surely use deeply nested containers. However, a "panel" is
> not like a Java panel. A wxWindows panel is in essence only used
> to manage keyboard navigation among controls in a dialog. As such,
> you don't need to use a panel to manage your subtrees but you can
> use layout directly.

Okay. I knew I could use layout to build the structure, but I didn't see a
clean way of recursively building the tree. I suppose I could return just
the Layout, if I don't need the widgets. Maybe I should try a
zygomorphism.
>
> Regarding your application, I would say that you are probably better
> off by drawing your derivation tree explicitly using an "on paint"
> event handler on a scrollable window. You will see that it is not
> so hard to write an algorithm that assigns locations to the nodes
> of your tree. After that, it is easy to draw them nicely on the DC.
>
> Using the same tree, that is attributed with locations, you can
> install an "on rightClick" event handler that checks which node
> is clicked and pop up a context menu with options for the user.
>
> (In general you should use the "on context" handler but unfortunately
> I made a little mistake in the type signature and forgot to pass the
> mouse position too, so you need to work around it using "on right
> click")

This is more than I need right now. I'm working with a model of type class
constraint solving. The goal is the solver rather than the individual
derivations, so I don't need to be able to change the derivation except by
changing the goal, or changing the solver. A richer interface might be
useful on bigger problems, but it's probably not worth the effort. Well,
maybe it would be worth it for learning more about wxHaskell.

About the particular implementation you suggested, is there any reason not
to use layout inside a scrolled panel? Stacking a row of subderivations
above the conclusion works well with minimal effort. I suppose I could use
a more compact layout, but again I'm working with tiny proofs. Is there
any reason other than better control for drawing my tree manually?

> > So far so good, but I would like to be able to change the
> > proof being displayed. I assume I could construct a new panel
> > from the new proof, and set the layout of my main window to a
> > new layout that doesn't mention the old panel, but I'm
> > worried that this leaks widgets. Does it?
>
> Does it leak widgets? In general, I have noticed that wxWindows seldom
> leaks. However, you never know if you can't check it :-) If you work
> on windows, and if you can use Visual C++ 6.0, you can build a debug
> version of the wxc library that will tell you if the program leaks
> or not. Let me know if you work on windows, maybe I'll put a debug
> version on the web.

I've tested a program that repeatedly opens a window and calls close on
it. It chews through memory as it runs. A program that repeatedly adds a
widget to a frame, sets a layout with it, and sets the empty layout also
chews through memory. I'm just watching the free system memory tend
downwards so I can't suggest anything about where the memory goes.

I'm working on Linux. I guess there's no configure option to build
profiling libraries? I'll try to build them myself then.

I am mostly worried that ommiting a widget from a layout and losing all
my references isn't enough to free it. Maybe the parent tracks all it's
children and I needed to call some magic method to break the reference.
Maybe widgets don't have finalizers in this 0.1 release, etc. What should
I be doing to avoid collecting lots of memory like this?

Thanks
Brandon

> Hope this helps,
>  All the best,
>   Daan.
>
> > Do I need to make
> > an explicit call to a "destroy this widget" function, or a
> > "remove this child" function?
>
>
> >
> > On the subject of leaks, wxHaskell wasn't build with ghci
> > libraries, or with profiling libraries. Are there any deep
> > reasons for this? Did I just miss the right configure options?
> >
> > This looks like a great library, I'm just clueless. Thanks
> > for building this.
> >
> > Brandon
> >
>
>