Open mdickinson opened 1 year ago
This seems reasonable, although it may be worth matching the create
/destroy
naming of the IWidget
interface for consistency, although that would be a more invasive change to shift any initialization code out of __init__
and into a create
method, so I'm not 100% sure of this. However the fact that this is to deal with global state makes me think that a side-effect free __init__
may be beneficial.
In terms of semantics, what should be the behaviour after close()
is called? Which methods, if any, should be expected to raise?
In terms of an is_closed
attribute, I'm not sure that I would expose anything publicly, and I suspect any internal use may be able to be handled by things like setting application objects or other global state to None
and using that as the flag.
In terms of semantics, what should be the behaviour after
close()
is called? Which methods, if any, should be expected to raise?
Most of them, I'd expect - the gui object would be unusable after closing. In the case of interest, we have an associated asyncio
event loop and the GUI
subclass close
method closes that event loop, after which it's not useful.
An idea that's been percolating for a few days around this: if we add start/stop methods then they could explicitly set Traits "ui" dispatch (or a better architected replacement) to use their call_later
on start
and then restore it on stop
.
Probably can't do it with the current GUI object, unfortunately, as the usage is too chaotic (because they explicitly aren't singletons but give access to the QApplication singleton, we tend to create them and throw them away or even just use the class); we might need to be a new IEventLoop
or something which the GUI objects reference to do their stuff.
Some downstream
IGUI
implementations allocate system resources, or modify global state, at instance creation time. (For example, oneGUI
subclass that we have in a downstream project changes theasyncio
global event loop.) As a result, we've addedclose
methods to those implementations to allow those resources to be released, and global state changes to be reverted. It's particularly important to have this functionality available in test suites, where manyIGUI
instances are being created and destroyed within a single process.To allow polymorphic cleanup, it would be useful to add a
close
method to theIGUI
interface itself, and theGUI
base class. The base class implementation would do nothing.This isn't without backwards compatibility risks: as always, an interface is a point of rigidity in a system, and in particular adding a
close
method would invalidate any existing implementations ofIGUI
that don't already inherit from theGUI
base class. However, I'm not aware of any such implementations in practice, and I think the risk here is manageable.On details: we'd need to decide whether it's also useful to have an
is_closed
property. The minimal useful interface would be just theclose
method, together with a guarantee thatclose
is idempotent, so that it's always safe to callclose
even if you're not sure whether theIGUI
object is already closed.