! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
thunar-progress-dialog.c sets window as NORMAL instead of DIALOG
Status:
RESOLVED: FIXED

Comments

Description carlosf 2015-01-19 01:49:11 CET
In line 99
gtk_window_set_type_hint (GTK_WINDOW (dialog), GDK_WINDOW_TYPE_HINT_NORMAL);
GDK_WINDOW_TYPE_HINT_NORMAL should be GDK_WINDOW_TYPE_HINT_DIALOG
In some Tilling WMs this hint makes the windows use tilling instead of floating, it is a big annoyance, some people control this setting rules manually using the window title, but in some WMs just isn't possible to do so.
It is a minor change and looks like a typo given that the name of the file says dialog, so I thing the original idea was to really be a dialog window.

thanks,
carlosf
Comment 1 Matt32 2015-01-26 18:29:13 CET
Created attachment 5882 
Expected patch

I don't know the consequences of the requested change.
Can you confirm that the attached file is the patch that you are asking for ?
Have you tested the patch for any regression ?
Regards,
Comment 2 carlosf 2015-01-28 09:49:15 CET
Hi..

That seems right.
I am using thunar with this patch for a few weeks now, and no problem.
If we thing about this, this don't play a role in most WM, but gives a hint about the window type, in the case progress dialog should be a dialog window, what most WMs do is if the window is small they just put it in float, other just put windows in float mode if they are dialog (and other cases possibly).
So, I'm pretty sure it will not cause any problem, and will enable a good default behavior in all WMs.
I hope to see this patch soon,
thank you very much..

carlosf
Comment 3 Harald Judt editbugs 2015-01-31 18:45:50 CET
*** Bug 11246 has been marked as a duplicate of this bug. ***
Comment 4 Hugo Osvaldo Barrera 2015-02-01 01:37:31 CET
Just a side comment: while this affects tiling WMs the most (and it's almost critical to fix this), it also affects others. For example, compiz will can use differente animations for dialogs vs normal. Window decorations and positioning might also vary a bit.

More on track: This patch looks good to me.
Comment 5 carlosf 2015-02-01 05:05:01 CET
Yes, everything that uses Window Type Hints is affected.
I'm still using the patched version of thunar that I compiled right before reporting the bug (and possible solution).
I don't see this change doing anything wrong to thunar or even strange behaviors with composite manager or window managers, if something it will improve the behavior for everybody. I'm really looking forward to have thunar with this annoyance fixed.

carlosf
Comment 6 Steve Dodier-Lazaro editbugs 2015-02-08 19:47:44 CET
This patch appears to cause no regression with xfwm git
Comment 7 carlosf 2015-02-19 02:03:49 CET
still using git version with this patch, no problems at all.
any news on the patch being applied to the main branch? I would like to go back to the normal Thunar (instead of having to apply the patch every time)
Comment 9 Harald Judt editbugs 2015-02-23 20:26:03 CET
The new behaviour sucks: If you have opened multiple thunar windows (maybe even on different workspaces), then clicking on the copy dialog window raises *all* thunar windows to the top. I've tried other hints like UTILITY etc., but only NORMAL prevents this.

If there is no better solution, then I will have to revert this commit.
Comment 10 Harald Judt editbugs 2015-02-23 20:39:17 CET
Reverted until someone can provide a solution that doesn't break usability: http://git.xfce.org/xfce/thunar/commit/?id=2de64695a8e69bd5f20379af4452fc24dd58feaf
Comment 11 Hugo Osvaldo Barrera 2015-02-23 21:18:02 CET
> The new behaviour sucks: If you have opened multiple thunar windows (maybe even on different workspaces), then clicking on the copy dialog window raises *all* thunar windows to the top. I've tried other hints like UTILITY etc., but only NORMAL prevents this.

That's your window manager that's configured to do that, you need to deal with it on the WM configuration side, not break Thunar again.

> If there is no better solution, then I will have to revert this commit.

Please don't. The previous behaviour made the copy dialog occupy half the screen on tiling window managers. That's awful, and in that case, it's actually thunar that's using the incorrect hints.

https://i.imgur.com/mm32NtD.png
Comment 12 Harald Judt editbugs 2015-02-24 07:47:37 CET
Indeed, this does not happen when using xfwm4. I need to recheck with an up-to-date version though and look out for other user reports about this. If it works fine in xfwm4, then applying the patch again is also fine with me.
Comment 13 Steve Dodier-Lazaro editbugs 2015-02-24 14:50:52 CET
Hugo, can you please provide a list of tiling WMs that would need the patch? We need the exact name they give to X11. 

Harald, we can apply the DIALOG hint for specific tiling WMs by using gdk_x11_screen_get_window_manager_name () to detect them, e.g.:

    wm_name = gdk_x11_screen_get_window_manager_name (gdk_screen_get_default ());
    if (G_LIKELY (g_ascii_strcasecmp (wm_name, "TILINGNAME") && other_strcmp...))
        hint = DIALOG;
    else
        hint = NORMAL;
Comment 14 Hugo Osvaldo Barrera 2015-03-28 00:56:31 CET
> Hugo, can you please provide a list of tiling WMs that would need the patch? We need the exact name they give to X11. 

So far, I've noticed this affects the behaviour of i3 and compiz. I recall someone else mentioning others on the arch forums.

But proper X hints should be the default. Manually keeping a list of all the WMs that need to be passed the *correct* hints (DIALOG) is unmaintainable (and doesn't really follow a principle of least surprise either).

Can't we rather keep a list of WMs that have a *negative* effect when receiving the right hints (DIALOG) and pass NORMAL to those? (effectively keeping DIALOG the default)

Bug #11467

Reported by:
carlosf
Reported on: 2015-01-19
Last modified on: 2015-03-28
Duplicates (1):
  • 11246 Copy progress dialog is missing some X11 hints

People

Assignee:
Jannis Pohlmann
CC List:
5 users

Version

Version:
unspecified

Attachments

Expected patch (734 bytes, patch)
2015-01-26 18:29 CET , Matt32
no flags

Additional information