Kenny and Peter,
thanks for your response.
On Tue, 04 Dec 2007 17:57:47 +0100, Peter Denno <[EMAIL PROTECTED]>
wrote:
I usually structure my applications with a "system" instance at the
top, system being a family subclass, each child being a window. Or
I go further and have system be a tree of applications of windows.
That sort of thing. If I was doing a network app I would extend
that to model a bigger world. Anyway, then new windows are made at
the repl with:
(push (my-new-window) (kids *sys*))
Where I have bound the system instance to *sys*.
Sounds extremely reasonable. I guess that's what I will do in my
application.
Come to think of it you could call,
(depth-first-search <root-window> #'fail #'kids :do #'(lambda (k)
(push k <whatever>)))
at any point, and <whatever> would contain the list of all widgets
found through navigating the kids slot.
#'depth-first-search and #'fail are in pod-utils. It is part of the
distribution.
I wonder whether this is really what one wants in a gui toolkit.
Cells-gtk should simply find all windows and get rid of them, s.t. no
inactive ones remain. The approach above would miss windows which are
created by plainly using (make-be 'window).
Is there anything wrong with hooking into md-awaken/not-to-be? I put the
following in my code:
(let ((open-windows nil))
(defmethod md-awaken :after ((self window))
(pushnew self open-windows))
(defmethod not-to-be :before ((self window))
(setf open-windows (delete self open-windows )))
(defun not-to-be-all ()
(mapcar #'not-to-be open-windows)
(setf open-windows nil)))
where not-to-be-all is called when the user closes the main window.
Appears to be working perfectly. Am I missing something?
Checked creating a dozen windows, closing some with Alt-F4, some with
menu-close, some with the close box, and having the main app (test-gtk,
surprise, surprise) take the rest down with it.
The other way I have been known to get to all windows is to use
some hook offered by the windowing API, but I do not know if GTk
offers such a beast.
I'll keep that one in mind, in case the former approach fails.
As for the rest, yes, many times I have wrestled with the different
world view held by the C developer to get to the point where I can
do iterative development in Lisp calling a C windowing library that
expects to get a fresh process with each run. Obviously a
make/break deal for us Lispniks, and it can indeed require detailed
analysis of the internals of the target platform, especially at the
edges where we are creating and disposing of windows. It took me
more than a few hours to sort out the various sequences of
messages/events arising during the various ways a window can be
closed, such as by the user clicking the close box vs the
application initiating a close in response to alt-F4 vs etc etc
So you all are on the right track, don't get discouraged, use as
much duct tape as you need to get to interactive development.
Glad to hear that I'm not alone. Actually it is strange anyone would give
up and settle for any other type of UI development. This is so much fun,
like I'm not merely poking around in the internals of my application while
it is running, I can watch even watch it react. Kinda like when I pulled
those cylinder heads on my 1962 Cadillac a couple years ago.
And
to be honest, if certain nasty combinations arise and force a
complete bounce of my Lisp once a day I just get on with it. :)
:)
Regards,
Peter
kt
_______________________________________________
cells-gtk-devel site list
[email protected]
http://common-lisp.net/mailman/listinfo/cells-gtk-devel
