#213 Fix event loop in file selector

[Bernhard Walle]

For example in the print dialog: Select something wrong
you get a warning message dialog. Click Ok and not the
print dialog gets the focus from the window manager but
the main window.

This is reproducable with xfwm4 (that one I use) and
Metacity. The reason is a wrong

WM_TRANSIENT_FOR(WINDOW): window id # 0x2e00070

information. Can this be changed easily?

[Stefan Ulrich]

Logged In: YES
user_id=177175

OK; I guess the solution is to pass the parent window as an
additional parameter; I've now done this for (hopefully) all
relevant windows in 22.79-CVS14.

[Bernhard Walle]

Logged In: YES
user_id=302109

> OK; I guess the solution is to pass the parent window as an
> additional parameter;

Yes, that's what I know from other toolkits. In Qt and C++
it's just (normally) a this pointer.

But: The problem is here not fixed, e.g. print dialog
"Invalid page range".

[Stefan Ulrich]

Logged In: YES
user_id=177175

> But: The problem is here not fixed, e.g. print dialog
> "Invalid page range".

Hmm, if I open the print dialog for a 1-page document and
enter 12 for `to', `xprop' shows the following information
for the resulting `Xdvi error' popup:

WM_TRANSIENT_FOR(WINDOW): window id # 0x1a0009f
WM_CLIENT_LEADER(WINDOW): window id # 0x1a0001b

0x1a0009f is the print dialog (checked with editres), and
0x1a0001b is the main window. With gnome/sawfish and fvwm
the focus switching seems to be OK.

How about other popups, e.g. if you press Ctrl-Mouse1 in a
file without source specials and click `Help' in the
resulting error popup - does the second one have the correct
parent?

Sure you tested it with 22.79-CVS14? Does
$ grep "popup_message" texk/xdvik/*.c | grep top_level
return matches?

[Stefan Ulrich]

Logged In: YES
user_id=177175

(sorry, somehow the bug title had become messed up)

[Bernhard Walle]

Logged In: YES
user_id=302109

Surprisingly, a complete rebuild solved the problem now.

Thanks for the quick response!

[Bernhard Walle]

Logged In: YES
user_id=302109

Reopened because the file dialog opened from the print
dialog still has the wrong parent. Maybe simply you forgot this.

[Stefan Ulrich]

Logged In: YES
user_id=177175

OK, it should be fixed now in 22.81.1-CVS14 (HEAD and
xdvik_STABLE).

However there's still a few problems with the Motif file popup:

- it prevents proper redrawing while open
- if the parent (e.g. print dialog) is closed, the file
window stays open.

Grabbing the pointer would solve the second problem, but
it's ugly.

I think we should replace the bogus event loop used by the
file selector (that had also caused the drag&drop pointer
grab and freeze, #884290) by proper callbacks that decide on
the further actions. That's quite a few changes, since it
also affects the startup code when called without a file
argument - something for a later release.

I'm changing the bug title accordingly as a reminder.

[Bernhard Walle]

Logged In: YES
user_id=302109

> - if the parent (e.g. print dialog) is closed, the file
> window stays open.

Why not just use a modal file dialog?

[Stefan Ulrich]

Logged In: YES
user_id=177175

That's what I meant by `grabbing the pointer' ... I don't
like modal dialogs from a usability point, and try to avoid
them whenever possible. So there's no modal dialogs in
xdvik so far, and we should avoid introducing them for
consistency reasons too ;-)

It also creates problems if e.g. the file selected by the
user is corrupted or doesn't exist, and you want to show an
additional warning, in which case you need to remove the
modality (or create a new modal dialog? I never found out
how to make this work). So I'd prefer the callback solution.

[Stefan Ulrich]

Logged In: YES
user_id=177175

Event loop fixed in the Motif version in 22.84.