Re: Win32 - handling mainloop while showing modal comon controls

["Charles Reilly" <gtk-devel-list 2005 charlesreilly com>]

The idea seems sound, but I think you could maybe change it a bit so it
would work for other common dialogs, without the need for a hook function.

At the moment, you post the "GDK_WIN32_GOT_EVENTS" message to the print
dialog and you use a print dialog hook function to catch the message and
pump the gtk events.

Instead, you could post the "GDK_WIN32_GOT_EVENTS" to an invisible gdk
window and make the handling of "GDK_WIN32_GOT_EVENTS" part of the
standard message processing for all gdk windows. 
gdk_win32_set_modal_dialog() would take a bool (since the particular
window wouldn't matter), and you could drop the print hook function. 
Other common dialogs could easily take advantage of this.

Disclaimer: I haven't actually tried this and I don't have much gdk
experience :)

Cheers,
Charles

> I'm working on the win32 printing backend again, and I'm now looking at
> the "windows don't redraw while print dialog is up" issue. The issue is of
> course that we don't run the gtk mainloop while the common dialogs run.
> Previous proposals where running the dialog in a new thread or calling th
> mainlop from a SetTimer callback. Neither of these approaches is very
> nice, and I have figured out another approach that I'd like some feedback
> on.
>
> First I'd like to outline the problems with the suggested approaches:
>
> Threads:
> Gtk+ on windows doesn't really handle threads well due to the threading
> model of windows. Also, you can't always be sure that gtk+ apps initialize
> threading. This is extra problematic since we really want to try to embed
> gtk+ widgets into the print dialogs.
>
> Timeouts:
> Pumping the mainloop in timeouts can easily cause stutter or flashing,
> since we don't immediately respond to WM_PAINT messages. Also, iterating
> the gtk+ mainloop will cause gdk-win32 to pump the win32 mainloop
> (i.e. call DispatchMessage), something that the dialog mainloop is also
> doing. This could cause all sorts of weird recursion.
>
> So, what happens when you run the printing dialog? Its got its own win32
> mainloop, so it will be calling GetMessage() and DispatchMessage(), which
> will cause the gdk Window Process to get called. This will convert the
> Win32 events to Gdk events and put them on the gdk event queue. However,
> we will never actually handle the events in the gdk queue, because we're
> not iterating the mainloop.
>
> My approach is to iterate the gtk+ mainloop from the win32 mainloop when
> there are messages in the gdk queue, but limit the gtk+ mainloop so that
> it only looks at events in the gdk event queue and touch the Win32
> message queue. The way we do this is that whenever there is a modal win32
> dialog (with its own mainloop) up we set a special variable in gdk that
> causes it to not get messages from win32, and to send a message to a
> specified window whenever we put an event in the gdk event queue. We then
> use special hooks in the print dialog functions to receive this message
> and pump the gtk+ mainloop.
>
> The attached patch does this, and it seems to work fine for me. Its not an
> ideal solution, since we only handle events generated from windows, not
> e.g. glib timeouts, or other fd:s added to the gtk+ mainloop. However, i'm
> not sure that is an enourmous problem.
>
> I'd like to get some feedback on this approach and patch from the win32
> developers though.
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>                    alexl redhat com    alla lysator liu se
> He's a war-weary bohemian househusband with a winning smile and a way with
> the
> ladies. She's a violent Buddhist research scientist trying to make a
> difference in a man's world. They fight crime!
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>