After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 636416 - Show when window cannot be tiled
Show when window cannot be tiled
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.3.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2010-12-04 00:41 UTC by liam
Modified: 2021-07-05 14:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description liam 2010-12-04 00:41:09 UTC
Evolution refuses to tile vertically. It will maximize if brought to the top of the screen but you can't undo that action by moving window away from top.
I've only noticed this problem with this application but haven't tested exhaustively.

Running latest (as of 3-12-10) build of GS.
Comment 1 Florian Müllner 2010-12-04 01:28:10 UTC
(In reply to comment #0)
> Evolution refuses to tile vertically.

Yes. In short, Evolution has a minimal size which is larger than half the screen width. If you resize Evolution manually, you will notice that at some point you cannot make the window any smaller, which means that it is now at its minimal size.

GNOME Shell won't tile any windows that cannot be resized to the tiled size. It won't tile windows which are not resizable either, e.g. the standard "About" dialogs.

So the bug in GNOME Shell is not that Evolution cannot be tiled(*), but that it does not provide proper feedback. Ideas how to handle this case are certainly appreciated - I'll also add the ui-review keyword to get some input from designers.


> It will maximize if brought to the top of the screen but you can't undo that 
> action by moving window away from top.

That's weird. I can't think of a good reason for that happening right now.



(*) You could consider that an Evolution bug though ...
Comment 2 liam 2010-12-04 07:36:45 UTC
Hey Florian,

I was aware of the min size constraints of Evolution but observed that in my case the reported (by xwininfo) halving window size was still greater than the min that evolution registered for itself.
FYI, Evo reports 415 as min while my screen halving size would be 926. Manually adjusting Evo gives a min of 1076, so either the application is reporting the wrong number or mutter is reading the number. I don't know which. So, do you know if this is an Evo registering bug, or a Mutter reporting bug? In short, do I need to file a bug with the Evo devs?

BTW, try tiling the About dialog for Firefox. Yes, it indeed tiles:) I'm sure they're using incorrect hints, but still, kinda funny to see it.


As for UI feedback, I'll ask around and see if anyone has any good ideas.
Comment 3 Owen Taylor 2010-12-05 22:10:50 UTC
(In reply to comment #2)
> Hey Florian,
> 
> I was aware of the min size constraints of Evolution but observed that in my
> case the reported (by xwininfo) halving window size was still greater than the
> min that evolution registered for itself.
> FYI, Evo reports 415 as min while my screen halving size would be 926. Manually
> adjusting Evo gives a min of 1076, so either the application is reporting the
> wrong number or mutter is reading the number.

Are you aren't mixing up width and height?

Here for my Evolution window, xprop reports:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 944 by 424
		window gravity: NorthWest

And when I resize it to the minimum size, xwininfo shows:

  Width: 944
  Height: 424

 I don't know which. So, do you
> know if this is an Evo registering bug, or a Mutter reporting bug? In short, do
> I need to file a bug with the Evo devs?

Assuming that there isn't anything weird going on with hint (and it seems fine to me) then a report against evolution to ask for it to be allowed to be made smaller seems like a reasonable idea.

> BTW, try tiling the About dialog for Firefox. Yes, it indeed tiles:) I'm sure
> they're using incorrect hints, but still, kinda funny to see it.

Wonder if we should forbid tiling windows that seem to be dialogs - if the dialog is resizable, then tiling it conceptually makes sense, but it probably is going to very seldom be useful to do so.
Comment 4 liam 2010-12-06 11:01:35 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Hey Florian,
> > 
> > I was aware of the min size constraints of Evolution but observed that in my
> > case the reported (by xwininfo) halving window size was still greater than the
> > min that evolution registered for itself.
> > FYI, Evo reports 415 as min while my screen halving size would be 926. Manually
> > adjusting Evo gives a min of 1076, so either the application is reporting the
> > wrong number or mutter is reading the number.
> 
> Are you aren't mixing up width and height?
> 
Yes:)

> Here for my Evolution window, xprop reports:
> 
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
>         program specified minimum size: 944 by 424
>         window gravity: NorthWest
> 
> And when I resize it to the minimum size, xwininfo shows:
> 
>   Width: 944
>   Height: 424
> 
>  I don't know which. So, do you
> > know if this is an Evo registering bug, or a Mutter reporting bug? In short, do
> > I need to file a bug with the Evo devs?
> 
> Assuming that there isn't anything weird going on with hint (and it seems fine
> to me) then a report against evolution to ask for it to be allowed to be made
> smaller seems like a reasonable idea.
> 
OK.

> > BTW, try tiling the About dialog for Firefox. Yes, it indeed tiles:) I'm sure
> > they're using incorrect hints, but still, kinda funny to see it.
> 
> Wonder if we should forbid tiling windows that seem to be dialogs - if the
> dialog is resizable, then tiling it conceptually makes sense, but it probably
> is going to very seldom be useful to do so.
Seems reasonable, if you can reliably determine the function of a window. Given that the devs didn't set a min/max maybe they know something we don't?
Comment 5 liam 2010-12-09 07:56:06 UTC
Regarding ways of communicating to user that a window cannot be tiled these ideas were mentioned:

Obviously it's best to avoid an unnecessary dialogs but if the user continuously tries to tile an untile-able a dialog should probably be displayed so the user understands that GS isn't the culprit:)

Another idea was to change the color of the tiling overlay from blue to red -- would be theme dependent but red is a fairly universal color of error.

Yet another was to display some sort of error or warning icon over the window.

Honestly -- although it may be quite complicated to implement -- in principle, I don't see why a vertically tiled window needs be restricted to at most 50% of the screen width.
Comment 6 GNOME Infrastructure Team 2021-07-05 14:03:59 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.