Opened 10 years ago

Last modified 8 years ago

#9267 new patch

Log window inconvenience - dialog

Reported by: jankratochvil Owned by: deryni
Milestone: Patches Needing Review Component: pidgin (gtk)
Version: 2.5.6 Keywords:


I found the "View Log" window inconvenient to use as:

  • It has no maximize (+minimize) button (and starts pretty small).
  • It still stays in front of any other (even new) Pidgin windows.

This makes it difficult to lookaside some log window(s) while discussing its content.

This behavior is window-manager dependent, using `metacity-2.26.0'.

Attachments (1)

pidgin-log-dialog.patch (675 bytes) - added by jankratochvil 10 years ago.

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by jankratochvil


comment:1 Changed 10 years ago by deryni

  • Status changed from new to pending

I've been convinced recently that the File Transfers window is not a dialog (the way we have it currently marked), I'm not convinced that this isn't a dialog. I'm even less convinced that we should play with window types to get specific desired behaviour in specific window managers. The fact that your wm has a dialog policy you appear to dislike (at least for this case) is not something I feel pidgin needs to work around.

I'm open to being convinced that this in fact should not be a dialog, so if you really feel it shouldn't be please explain.

comment:2 Changed 10 years ago by jankratochvil

  • Status changed from pending to new



_NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If _NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST be taken as this type.

This IMO suggests that GDK_WINDOW_TYPE_HINT_DIALOG also means "transient-for" relationship (even despite the parent window has not been specified by Pidgin).

Regarding whether to use gtk_dialog_new*() or gtk_window_new*() I do not find important, gtk_dialog_new_with_buttons() just provides some widgets-from-va_list build framework and use whatever is easier.

Whether dialogs should / should not have minimize/maximize buttons is probably a bug of the metacity wm. Still the transient-for relationship comes from the wm spec so one cannot say metacity is wrong for it.

That the "View Log" window should not be transient-for the other Pidgin windows is I hope without a dispute.

comment:3 Changed 10 years ago by rekkanoryo

I see the same always-on-top behavior in XFCE's xfwm. I strongly dislike it as well. If this is because of the transience mentioned above, I'm all for killing it.

comment:4 Changed 10 years ago by deryni

  • Owner set to deryni

I read the EWMH the other direction, non-specified windows that are transient to some other window should be treated similarly to _TYPE_DIALOG windows (specifically to avoid them being treated as any other window type, like _UTILITY, I'd imagine), but _TYPE_DIALOG windows need not be transient to anything.

You cannot be 'in a "transient-for" relationship' without a parent window, not meaningfully at least (I'm ignoring any potential application transience/modality here). Further, the EWMH suggests (as an implementation note) that "Windows that are transient for another window should be kept above this window" but makes no such claim about _TYPE_DIALOG windows and does not place them anywhere explicit in the stacking order.

I'm not sure I agree with the handling of _TYPE_DIALOG in metacity and xfwm (even less so in the non-transient case), but I haven't thought about it enough (or know enough of the implementation details) to have an actual opinion at the moment, nor do I care much.

The issue at hand is whether the "Conversations with ..." windows are 'dialogs' or not, if they are then we are doing things exactly as we should be, and your dislike of your environments handling of such windows is unfortunate but not our problem.

If, on the other hand, they should not be considered 'dialogs' then we likely should not be (ab)using gtk_dialog_new_with_buttons to create them and regardless of that should not be setting them as _TYPE_DIALOG (which may mean overriding the type setting that the gtk_dialog_* functions do automatically).

Keeping in mind my caveats before about my lack of fully considered opinion on this, I would suggest that the (apparent) policy of keeping all _TYPE_DIALOG windows above all windows (either of all applications or only of the parent application) regardless of actual transience marking is a poor policy and the cause of the problems here.

comment:5 Changed 10 years ago by deryni

  • Milestone set to Patches Needing Review
  • Type changed from enhancement to patch

This is related (in the discussion of what windows should and should not be dialogs) to #7693.

I'm leaning towards being convinced that the "Conversations with ..." windows are not dialogs.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!