#1816 fix parenting/close behavior for Gtk drop-down dialog box #1818
Conversation
|
I see no good way at the widget level in Gtk to know when the form is being moved/resized. Perhaps a solution would be to simply add an "Expanded" property to the Eto DateTimeControl control to allow an app, if interested, to programmatically query, expand/collapse the dialog -- but then the support would need to be added in all the other modalities. Opinion? |
|
Could we close the form when it loses focus? Or does it not lose focus when moving the parent dialog? |
|
Unfortunately, it doesn't - only the GtkWindow widget knows it's being moved and you can't really got to in in GtkSharp -- the "ParentWindow" gets you a GdkWindow which is the rectangle that the GtkWindow is in. In theory, you can get to that as part of the UserData but the whole things started feeling like a giant kludge. The more I looked the worse it got - trying this out on a non-Ubuntu Wayland implementation (touch), the current "lose focus" thing breaks when the OSK pops up (which is does when you click on the Entry combo box button -- which then clobbers the drop-down. If you go back to the grab/click anywhere else approach to close, it's completely unusable on a touch screen (vs. mouse) because the targets are so small (even if I increase the font size). I think part of the problem is that trying to create a drop-down dialog in Gtk depends on both GTK and the Linux compositors doing sensible things --- which they don't. Went through a lot of experiments and variations this morning to no avail. At this point I just implemented my own dialog box (in Eto) and threw the "calendar" and "clock" part overboard - they're pretty but not worth the time and trouble. Probably the "real" portable solution here would be to implement this dialog in Eto and draw the calendar and clockface on the same form as the Entry (not a child window) The update performs better than the existing as long as you have a mouse and no OSK. |
This still needs some cleanup but the control no longer loses parenting for the drop-down on a form. This result is still messed up if the control is located on a Dialog - guessing the two fight for the always on top but at least will behave on a Form. I have seen this problem in other Gtk situations and my response is to turn all my "dialogs" into forms so the only remaining are the "system" dialogs e.g. Save/Open/Print. Basically the code changes allow the combo-box part of the control to manage the lifetime of the dialog and will pull the dialog down when focus is lost to the control
As far as root cause -- the "Close" on the dialog gets called but seems to only partially close the window -- perhaps the underlying controls in Gtk-land abort the Close or there is a race condition or..??? I originally thought a race condition or non-UI thread since these are coming in from events - but I tested calling/sending the Close request to the context used to create the control to no effect -- seems something is "cancelling" the close request somehow. I may move my investigation over to the UNIX side so I can debug into GtkSharp and see what's going on down below.