[cells-gtk-devel] Lispworks Linux / SuSE 9.2

[Peter Denno]

The following works:
<pdenno at bordercollie:/local/lisp>diff -r --context 
cvs-cells-gtk/root/cells-gtk/gtk-app.lisp 
cells-gtk/root/cells-gtk/gtk-app.lisp
***************
*** 81,87 ****
            
            (when *gtk-debug*
              (trc nil "STARTING GTK-MAIN") (force-output))
!           (gtk-main)))))
  
  (defvar *gtk-global-callbacks* nil)
  (defvar *gtk-loaded* #+clisp t #-clisp nil) ;; kt: looks like CLisp does 
this on its own
--- 81,89 ----
            
            (when *gtk-debug*
              (trc nil "STARTING GTK-MAIN") (force-output))
!           (loop 
!              (loop while (gtk-events-pending) do
!                   (gtk-main-iteration-do)))))))
  
  (defvar *gtk-global-callbacks* nil)
  (defvar *gtk-loaded* #+clisp t #-clisp nil) ;; kt: looks like CLisp does 
this on its own


Of course, it now sits in the outer loop forever -- even after killing the 
window. If I knew what a quit-app event looked like, maybe I could exit the 
outer loop. 

I start the window in its own process and can kill it easily enough. So the 
above is OK with me.

On Sunday 30 January 2005 17:54, Kenny Tilton wrote:
> Peter Denno wrote:
> >OK. My first question: Is this code running mp:without-scheduling, or
> >something like it? (grepping, it appears not). In my code, when a callback
> >attempts a mp:process-run-function, the function doesn't start until I
> > kill the cells-gtk window. Hmmm... In fact, I don't get the listener back
> > until after I kill the cells-gtk window, even when I start the gui with:
> >
> >(mp:process-run-function
> >     (format nil "Ion Version ~A" *m-version*) ()
> >     #'(lambda ()
> >         (cells-gtk-init)
> >         (cells-gtk:start-app 'cgui :debug dbg)))
>
> OK, I see at least that the AllegroCL IDE is not responsive after
> control is given to gtk-main. I imagine this explains also why
> mp:process-run-function does not work (or help when used to spawn the
> demo originally).
>
> I am using ACL 6.2 on win32 which is documented as using native OS
> threads, so I am not sure why gtkMain is blocking the other ACL IDE
> windows. I do find that a break statement within a callback gets me to
> the debugger and then all IDE windows are responsive, for what little
> that is worth.
>
> One ugly workaround I used in the same situation with the OpenGL GLUT
> application framework was to call glutMainLoopEvent repeatedly instead
> of giving up control to glutMainLoop with one call. i would then sleep
> 0.05 seconds in the loop, which gave ACL a chance to process events for
> IDE windows. It seemed, btw, that if I set the sleep duration too low
> (such as 0.03) the trick stopped working.
>
> I just looked at Gtk main documentation:
>
>   http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-main
>
> It looks as if a similar hack is possible, perhaps involving
> gtk_main_iteration_do.
>
> of course I am only guessing that this will even work, and there may be
> a simpler fix. if you want to try this approach and code something up
> and have problems, send me what you come up with and I will try to find
> time to look at it.
>
> cheers, kenny

-- 
Best Regards, 
- Peter 

Peter Denno 
National Institute of Standards and Technology, 
Manufacturing System Integration Division, 
100 Bureau Drive, Mail Stop 8264             Tel: +1 301-975-3595 
Gaithersburg, MD, USA 20899-8264          FAX: +1 301-975-4694