[cells-gtk-devel] start-app and multithreading?

[Peter Hildebrandt]

On Tue, 04 Dec 2007 23:48:07 +0100, Ken Tilton <kennytilton at optonline.net>  
wrote:
> I just glanced at the GTk doc and did not see anything that would  
> support such a safety net, so you are probably on the right track  
> rolling one into Cells-Gtk. One might check with the GTk mailing list to  
> see if we are missing something. Basically the Prime Directive in these  
> GUI wrapper deals is to use the C library wherever possible.

Thanks for the hint.  Indeed there is a way to do this with GTK.   
Actually, there is two:  The good people at gtk-app-devel-list at gnome.org  
pointed me to gtk_quit_add [1] and gtk_quit_add_destroy [2].  The former  
registers a callback which is called once gtk-main quits, while the latter  
simply schedules a window for destruction upon quitting the main app (as I  
learned, this was discussed on the GTK mailing list in February 1999 [3]).

http://mail.gnome.org/archives/gtk-list/1999-February/msg00577.html
[1] http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-quit-add
[2]  
http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-quit-add-destroy
[3] http://mail.gnome.org/archives/gtk-list/1999-February/msg00577.html

I assume what we want is the former, that is code it along these lines

- upon creation of a window we register a callback to dispose of the  
window once the app is closed (either md-awaken :after or make-instance  
:after -- which one is more appropriate?  I'd go with the former,  since  
this is the point in time where the window actually shows up on the screen)

- in the callback we finally call not-to-be on self to properly dispose of  
the 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?
>>>
>>> Anyone?
>>   It'd like to hear some comments, too.
>
> It's a toss-up. The above has a slight "backdoor" feel to it, but that  
> might be the right way to go.

It is definitely a hack.  That's why I'm discussing this issue with you  
guys before publishing a patch.

> Some background: Cells is all about making sure everything gets done and  
> in the right order when things change. But because the Cells engine is  
> ordering operations, interesting code is almost compelled to play within  
> the Cells framework, or it misses out on vital action (does not learn  
> about change) or at best runs at the wrong time.

I think I understand.

> If you creat a class called gtk-application and hang windows off that as  
> kids of an instance of that, then you can just not-to-be that instance  
> and have all windows tended to. Use of this instance gets enforced  
> simply by having the md-awaken method merely enforce that with a helpful  
> error message telling the developer the right way to make a window (push  
> a new instance onto the kids of a gtk-application instance.

Well, the problem is that gtk-app is derived from window, hence its kids  
are the widgets to be displayed within it.  As I mentioned before, I'd  
like to maintain compatibility, thus I'd rather leave this as it is.  My  
suggestion:

We introduce a new class, gtk-application, which so far does nothing but  
keep track of all windows opened by the app in its kids slots.  Since  
not-to-be will remove them properly (and will be called either by the user  
or through the callback), we do not have to keep track of that.  All  
that's left to do is register new instances -- which I'd do within the  
md-awaken method, so that instances are registered with the application  
object at the same time the callback is registered.

> Of course some renegade developer might start leaking gtk-app instances,  
> but the sense I have here is that you just want to be able to work  
> freely, not fend off deliberate incompetence and sabotage.

True.  All I want is play freely at the repl, sleep quietly, and not worry  
about left-over instances, forgotten destroy calls etc.  I.e. when I  
make-instance an object, the GC is eventually gonna get rid of it for me  
-- and so should cells-gtk.

> With a gtk-app family, other bits of the application can then be aware  
> of the coming and going of windows. Perhaps like PhotoShop you have a  
> menu for open windows. That sort of thing.

So be it.  In the current model, this bookkeeping is independent of the  
destruction of windows, however, since we handle this with the gtk  
callback.

> Otoh, the above slightly backdoor scheme is a lot simpler, and it may  
> even be superior/the only way to go. As I have said elsewhere, at the  
> boundary with the wrapped C library things can get ugly, you might  
> /need/ to step out of the Cells constraints a little. (And I hasten to  
> add you are not all that far outside the Cells system with the above.)
>
> Me, I would err on the side of using the gtk-app instance by default to  
> get other benefits (eg, a windows menu for some app) and fall back onto  
> managing windows outside Cells as usage persuades me that the gtk-app  
> approach will not hunt.

I'll put together the model as described above and mail out a patch later  
today, so you guys can have a look at it.

>
>>
>>>> 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.
>
> If the engine was running, I just hope it was the valve covers PD  
> pulled. :)

Well ... I turned over the crank shaft with a big lever while the head  
were off (kinda like calling functions from the repl, isn't it?) ;)

Peter


> kt