May 12 20:36:22 <jpab>	oh, actually there's another bug that you might have a solution for
May 12 20:37:08 <jpab>	the settings screens use DropDown widgets. If you open up a drop-down list and then switch to a different tab in the TabGroup, the floating list stays on screen
May 12 20:37:36 <robn>	yeah, that's a bug
May 12 20:37:38 <jpab>	is there any way for a widget to know that it's no longer visible, so it can remove any popups it's created?
May 12 20:37:59 <jpab>	or have floating widgets associated with a non-floating parent somehow and remove them automatically?
May 12 20:40:44 <jpab>	I need a shower. I'll be back in a little while.
May 12 20:43:28 <robn>	not in the general case. "not visible" isn't a concept (purposely)
May 12 20:44:32 <robn>	I have considered associating floats with parents. it might be the right way to do it, but it would take some restructuring to be sane I think. basically generalising Container to have a separate float part
May 12 20:45:51 <robn>	there's a related problem where if you have mutiple dropdowns on screen at the same time, you can open them all
May 12 20:46:18 *	robn ponders
May 12 20:46:58 <robn>	if we were to say that floats are modal, then there can only ever be one on screen at a time, and it would receive all events
May 12 20:48:02 <robn>	then the floating widget will receive clicks outside its area, and can close up
May 12 20:48:06 <robn>	meanwhile
May 12 20:49:08 <robn>	we might need to have an expose event, that is sent to widgets in their first update call after being made visible
May 12 20:49:25 <robn>	which is a bit tricky, because visibility isn't quite a concept, as I say
May 12 20:49:29 <robn>	but I think it can be made to work
May 12 20:49:50 <robn>	when a widget gets added to a container, it and all its children get a flag set
May 12 20:50:19 <robn>	Update() will check that flag, and if set, send the Expose event and clear the flag
May 12 20:50:55 <robn>	I think I like that
May 12 20:51:19 <robn>	I haven't quite been happy with floats for a while
May 12 20:51:25 <robn>	mostly not properly understanding what they are
May 12 20:51:30 <robn>	I think thats a step in the right direction
May 12 20:58:48 <jpab>	but you need an event when a widget is hidden, not just when it's exposed
May 12 20:58:49 <jpab>	right?
May 12 20:59:28 <jpab>	You could walk the hierarchy when a widget is detached :-/
May 12 21:02:11 <robn>	not if a float widget is attached to a non-float widget
May 12 21:09:39 <jpab>	I suppose if it's rendered by the non-float...
May 12 21:10:46 <robn>	yeah
May 12 21:11:12 <robn>	in concept anyway. in reality it would all be handled in the context, which would queue up the floating widgets and draw them last
May 12 21:11:30 <robn>	its a moderately difficult change. I think its a good one
May 12 21:15:21 <jpab>	that's probably right