Resizing windows by grabbing window borders is difficult

Reported by Robert Lee on 2007-11-05
This bug affects 613 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Critical
Unassigned
One Hundred Papercuts
Low
Sam Spilsbury
Release Notes for Ubuntu
Undecided
Unassigned
Unity
Undecided
Unassigned
emerald
New
Undecided
Unassigned
metacity
In Progress
Low
unity-2d
Critical
Unassigned
light-themes (Ubuntu)
Low
Unassigned
Nominated for Dapper by dsa42
Nominated for Hardy by camoguy
Nominated for Intrepid by camoguy
Nominated for Jaunty by Neil Broadley
Nominated for Karmic by Nenad Radulovic
Nominated for Lucid by Nenad Radulovic
Nominated for Natty by Ben Shadwick
Nominated for Precise by Keng-Yu Lin

Bug Description

This bug is fixed in unity-3d since ubuntu 11.04.
It still exists in unity-2d and will never be fixed as unity-2d is no longer supported since ubuntu 12.10 (see comment #343).

*************

This should mostly be fixed for Natty and might get backported to earlier releases as well.

For Precise (12.04) this is again broken for unity-2d (as of 17.7.2012 unity-2d 5.12.0-0ubuntu1.1).
Note that if the window has a scrollbar, you can grab that to resize the window. If not, you are stuck with the 1px border. Workaround: NONE KNOWN (see comment 320)?

*************

*************Blueprint for Natty, Ubuntu 11.04:

https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-dx-n-resizing-windows

Work items1 * Make sure the new resize grip fits in current applications; doesn't interfere with anything. We should make some noise about this during the Natty cycle so people keep their eyes open and file bugs.
2 * Invisible window resize area - around 3px invisible area to allow resize on all sides.

*************

Working grip backported to gtk2 already available in ppa : https://launchpad.net/~bratsche/+archive/gtk

*************

Workaround for Compiz/Unity: Alt+Middlemousebutton resizes a window most comfortably.

Workaround: Edit /usr/share/themes/Ambiance/metacity-1/metacity-theme-1.xml. Set the following values in frame_geometry_normal as desired:

        <distance name="left_width" value="3"/>
        <distance name="right_width" value="3"/>
        <distance name="bottom_height" value="3"/>

************

Binary package hint: metacity

- The issue has been an issue for users (especially of large) screens for several releases- Trackpad users seem to be particularly impacted by this- The issue appears to have been significantly aggravated in Lucid by changing the border width from 3 pixels to 1 pixel

The window borders in metacity are far too thin to be used for comfortable window resizing, and resize handles are not available in all applications (or even most). In fact, of all the windows I have open right now, not a single one of them has a resize handle. The result is that I get a lot of "misses" when I try to drag a window border, which usually results in my clicking on the wrong window altogether. The best fix for this usability bug is to create an "invisible" region around each non-maximized window about 4px thick that can be used for resizing (in addition to the visible border). Or perhaps there should be a border thickness option on the System > Preferences > Windows dialog (although the default thickness should still be increased considerably). Ideally all windows would also have a resize handle but I realize that these have to be application controlled (at least that seems to be the position of the metacity team).

Related branches

Siegfried Gevatter (rainct) wrote :

Thanks for taking the time to report us your comments. However, I don't think that that most users have any problem with that, perhaps it's the theme you are using? Also notice that if you right click the title of a window you will find a "Resize" option there (and also the same if you right click the title of window on the bottom panel).

Changed in metacity:
importance: Undecided → Wishlist
Neil Broadley (scaine) wrote :

I'll second this - I can't find any way to make the windows resize border bigger than (I think) 1px. Resizing windows is cumbersome, frustrating and far too easy to get wrong. I'm running compiz-fusion enabled from a stock Gutsy build, with almost no additions (ccsm is the only change I've made so far) and the resize handles are all but invisible. I've tried all the stock themes in systems/prefs/appearance, but none of those appear to change the resize handles.

In Emerald, when using my older Beryl/Emerald combo (on Feisty), this was a simple change to make the handles bulkier and easier to grab.

And yep - of course I can also use the menu and choose the resize option, but obviously this is NOT a solution to the handles being to small. It's a workaround, which is even more cumbersome (but admittedly less frustrating) than hunting for the resize handles in the first place. I can also use ALT-BothMouseButtons to initiate a resize. But that's not useful if my keyboard isn't available/handy (which it often isn't when I'm using the PC in the living room).

Chris Coulson (chrisccoulson) wrote :

I thought I'd also add to this bug just to say that this is definately a problem. I've had this issue since as long as I can remember. You have to be very accurate with the positioning of the mouse to get the resize handle, especially for resizing from the corner of a window. It's very hit-and-miss. My girlfriend and I both struggle with window resizes and I'm fairly certain it's theme independent as well.

Chris Coulson (chrisccoulson) wrote :

Note that with the default Human theme, I need to get the pointer to within an area of 4 pixels at the edge of a window to be able to resize it (I know I'm sad, I counted!) On a 1600x1200 monitor, this is a difficult task, and requires great precision. I can't believe this is marked as 'Wishlist'. It's definately a usability bug.

Siegfried Gevatter (rainct) wrote :

I forwarded the problem to metacity's developers.

Thanks for your feedback!

Siegfried Gevatter (rainct) wrote :

Closing metacity bug, it *is* theme dependant. Add the human theme as affected package.

Changed in metacity:
status: New → Invalid
Changed in human-gtk-theme:
importance: Undecided → Low
Chris Coulson (chrisccoulson) wrote :

Siegfried: I understand now that this is theme dependant and I agree that the Human theme should be fixed, but this seems to be a problem with all Metacity themes I've used, including other Metacity themes that ship with Ubuntu. For example, the 'Metabox' theme (on my default install) seems to be *much* worse than Human - it seems to only give you a single pixel width in which to position the mouse, which is nearly impossible at 1600x1200 resolution.

So, is this an indication of a wider problem with the implementation of Metacity themes? Is this something that the Metacity developers still need to consider, in order to improve consistency across themes/improve usability?

Thomas Thurman (marnanel) wrote :

As the person who mostly looks after theme support in Metacity, I'd love to hear discussions on and suggestions for what's needed in version three of the format.

Siegfried Gevatter (rainct) wrote :

See my opinion on this below, but note that I can't speak in name of the theme designers (in fact, I've no experience in this field):

I don't really think this is a bug nor that it's very several (I hadn't heard anything like this until this report was created), but if some users have problems with the currently provided themes a variant of the human theme (or whatever it will now be called on Hardy) with thicker borders (and perhaps other usability changes) would be adequate to be also included in the default installation.

Of course adding an option to change the border thickness on the properties dialog would be better, but as the GNOME guys said this isn't that trivial, there's really more important stuff where time should be spend than on patching this. Unless someone could come up with an easy fix for it, of course.

Well, as I said this is just my opinion, and I'm not really sure about what I'm speaking, so I think I'll just stop following this now and leave it for someone else that knows more about this subjects.

If you have any other idea on how to fix this, let us hear it :).

Thomas Babut (thbabut) wrote :

I am running 1600x1200 resolution and I have to say, that Robert is right. It's not very comfortable to resize a window. Is there an easy way to change this?

Thanks.

It is relatively painless to change the dimensions of the surrounding border for themes. That said, you may end up with a gaudy looking heavy window, but I assume that you don't care about that.

To change border widths, simply open up the theme's Metacity XML file. For example, Human's theme is located in /usr/share/themes/Human/metacity-1/metacity-theme-1.xml

The stanza in question should be apparent:
  <distance name="left_width" value="5"/>
  <distance name="right_width" value="5"/>
  <distance name="bottom_height" value="5"/>

Try mucking with the values until you get something you are happy with. Unfortuanately, resolution dependency still plagues much of Gnome.

The original bug suggested an extra transparent area added to the width which is a good idea to keep things functional and clean.

> From: <email address hidden>> To: <email address hidden>> Date: Wed, 14 Nov 2007 01:04:56 +0000> Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)> > It is relatively painless to change the dimensions of the surrounding> border for themes. That said, you may end up with a gaudy looking heavy> window, but I assume that you don't care about that.> > To change border widths, simply open up the theme's Metacity XML file.> For example, Human's theme is located in> /usr/share/themes/Human/metacity-1/metacity-theme-1.xml> > The stanza in question should be apparent:> <distance name="left_width" value="5"/>> <distance name="right_width" value="5"/>> <distance name="bottom_height" value="5"/>> > > Try mucking with the values until you get something you are happy with. Unfortuanately, resolution dependency still plagues much of Gnome.> > -- > Window Resize Difficult (Window Border Thickness)> https://bugs.launchpad.net/bugs/160311> You received this bug notification because you are a member of Ubuntu> Artwork Team, which is a bug contact for human-gtk-theme in ubuntu.
_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

Sounds like this is, indeed, resolution dependant. I'm running a 24" Dell flat panel and its resolution is 1920x1200. This may be why only a small number of people have hooked onto this issue.

To be honest, I've fixed this now, simply by installing the Emerald manager straight from the Gutsy repos. Now, in System/prefs/Emerald Themes, I can just click on Frames/Borders and use the sliders there to alter the size for each side. Just installing Emerald helps though, since its default appears to be 4px. I've upped my right and bottom frames to 7px. It does create lopsided frames, but at this res, it's not obvious, but makes resizing from the lower right corner much, much easier.

I like the transparent idea however, providing it's not overdone. I reckon a 4-5px frame with another 3-4px transparent frame would be awesome. I'll be interested to see if anything along those lines is implemented in either Emerald or Metacity.

Hello I've been trying to get off this mailing list but the the web site
thing that makes me off the list doesn't work so please TAKE ME OFF THE LIST

Changed in metacity:
status: Unknown → Invalid

I find resizing windows on Gutsy very frustrating. The draggable window borders are narrower than the accuracy with which I can position the mouse.

Obviously this is one of those things where some people cannot imagine how anyone could be bothered by it, others (like me) don't have to imagine it, they experience it. 1440x900 dot screen. I may investigate this "Emerald" windowmanager, I just wonder what it may break if I install it?

Thomas Thurman (marnanel) wrote :

Paul: You also have the option of changing the theme size, of course.

Thomas Thurman (marnanel) wrote :

(Sorry, that "of course" wasn't supposed to be patronising; I apologise if it sounded that way.) You can install a theme with wider borders, or modify the borders of the existing one as explained elsewhere on this page.

Mark Edgington (edgimar) wrote :

I have a 1280x800 LCD display, and trying to resize windows by dragging corners or edges has always been frustrating to me -- just as described by others above, it usually takes several tries before the edge/corner is correctly "grabbed".
(I am presently using the Mist theme under Gutsy)

Jonathan Kerls (jkerls) wrote :

As a theme designer it would be nice to be able to specify regions that could act as resize areas. A theme with 1 pixel or no side borders, but a thick 5px bar on bottom would work fine if you could declare that the 10 pixels of the bottom bar at the left and right side were to act as a corner resize, giving the user a 50 pixel area on either corner for resizing. As is, if you have no border or a thin border, it's virtually impossible to actually resize a window without using shortcuts.

zarathustra (garyyuen) wrote :

I just started using Ubuntu as a Desktop instead of server (even just today). So coming from using Windows and OS X for so long, I find this a big deal also. A resize control that is part of theme and displayed in the bottom corner would make thing much easier. I've tried all other included themes and none seem any better. I've tried adjusing my mouse sensitivity but it would be too slow to make just window resizing easy. I would switch to something besides Metacity just because of this reason.

zarathustra (garyyuen) wrote :

To further ad, I noticed apps like Gedit have a resize handle and it's much easier than with programs like Firefox and Terminal. I'm not sure if there are guidelines or anything that can be recommended to all developers.

Hi,

Use Alt+Middle Clic to resize from anywhere in the window. In Unix,
windows manager does not draw inside the window, only outside (border,
title, etc.). So only window with status bar have the resize handle at
bottom.

Regards,
Étienne.
--
E Ultreïa !

Mihai Niculescu (q-quark) wrote :

On Thu, 2008-02-21 at 17:17 +0000, zarathustra wrote:
> I just started using Ubuntu as a Desktop instead of server (even just
> today). So coming from using Windows and OS X for so long, I find this a
> big deal also. A resize control that is part of theme and displayed in
> the bottom corner would make thing much easier. I've tried all other
> included themes and none seem any better. I've tried adjusing my mouse
> sensitivity but it would be too slow to make just window resizing easy.
> I would switch to something besides Metacity just because of this
> reason.
>

Hi,

If you don't like or you don't feel OK with the included themes, you may
check this: http://gnome-look.org

It contains a lot of ways to change the look&feel of your desktop. For
your problem, it may be better for you to use a theme which has a bigger
window border. Take a look at gnome-look. You'll find metacity themes on
the left side of the page. (click the link "Metacity").

To install the theme do the following:
1 - download the Metacity theme you like somewhere on your computer
(lets say on Desktop)
2 - Open the theme manager: go to Main
Menu->System->Preferences->Appearance (or Theme)
3 - Drag and drop the file you downloaded to the window (or click the
install button and select the theme )

Don't be afraid to ask for further help when you need :)

@Mihai

This isn't about changing the look and feel, this is about the underlying architecture.

1) The window's grab area should be separated from its aesthetic border trim area ( as per Jonathan Kerls suggestion at https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/160311/comments/19 )

2) Device display independence will help to alleviate this issue as well.

Alden (jason-alden-benoit) wrote :

As someone fairly new to Linux, yet understand things far better than the average newbie, I want to add my 2 cents.

 On a scale of 1-4
1 - Emergency
2- High
3- Medium
4 Low

 I have to say this issue is a medium priority. It is a usability issue, and will turn people away. It's the little things that get you. They add up. I understand that it will take resources, but I think getting this issue resolved being resolution dependent will alleviate others as well. The sad truth is this will probably get fixed because of something else being resolution dependent.

IMHO the theme shouldn't matter, and or even better a simple GUI setting. At the least, we need this to be more generous in default themes. Were it not for Compiz ALT-Middleclick I would have gone nuts already. Glad the theme change helps, but is a work around.

josef.sabl (josef-sabl-gmail) wrote :

I absolutely hate this bug.

I would also note that the most problematic are the top cornersas area above window icon and control box with maximize, minimize and close button cannot be used for resizing.

And I would also note that the window control menu (the one you get when you press Alt+Space) is broken for move and resize options.

Problem with Move - this menu is great to be used as a keyboard option for moving windows, right? When coding, I use mouse very little and use this to move windows instead. But, when I am finished moving the window, the mouse cursor is left right in the middle of the window, so I have to grab the mouse anyway and move the pointer away so it does not get in my way.

Problem with Resize - sometimes it works, but mostly it does pretty funky stuff. I noticed that it has biggest problems when the window is partially "behind the corner". I mean on another desktop.

I should maybe note that I use Compiz with cube enabled.

Thomas Thurman (marnanel) wrote :

Josef: If you use compiz, you should raise another bug against compiz. This is a metacity bug.

Richard (rd1) wrote :

This is a real pain on larger displays (e.g. mine is 1680x1050). It's also an accessibility issue - those with motor control problems may find it very hard to position the mouse to drag a window even on smaller displays such as 1280x1024 17" monitors.

Having switched from KDE, where this is a simple configuration option and the first thing I set up, I'm really surprised that GNOME doesn't allow this. Windows has of course allowed this for a very long time, certainly Windows 95 if not Windows 3.1.

Installing Emerald is reasonable workaround I suppose but that's hardly new user friendly - it would be much better if this was configurable. Having to search for a theme with wider borders is a pain, you might well end up with a theme you don't like for aesthetic reasons. As someone said, it's the small things that put you off when you are trying out Ubuntu for the first time. (I've used Ubuntu for a few years and Linux for ages but am setting up Ubuntu for an elderly relative who has some trouble with precise mouse movements.)

Hello,
I am having a little difficulty understanding your problem, but what I get to know from your email is  that you are having problems setting up a new monitor and some other little resizing problems.  You should check your graphic card  and you might have to get a good graphic card to a higher resolution like the one you are using.  Try ATI 4850 and also check that someone has not messed up the display settings that are on your monitor buttons, that might help you getting the borders you want.
Sorry I wasn't able to help much,
Vikram

----- Original Message ----
From: Richard <email address hidden>
To: <email address hidden>
Sent: Sunday, August 17, 2008 11:14:22 AM
Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)

This is a real pain on larger displays (e.g. mine is 1680x1050). It's
also an accessibility issue - those with motor control problems may find
it very hard to position the mouse to drag a window even on smaller
displays such as 1280x1024 17" monitors.

Having switched from KDE, where this is a simple configuration option
and the first thing I set up, I'm really surprised that GNOME doesn't
allow this.  Windows has of course allowed this for a very long time,
certainly Windows 95 if not Windows 3.1.

Installing Emerald is reasonable workaround I suppose but that's hardly
new user friendly - it would be much better if this was configurable.
Having to search for a theme with wider borders is a pain, you might
well end up with a theme you don't like for aesthetic reasons. As
someone said, it's the small things that put you off when you are trying
out Ubuntu for the first time.  (I've used Ubuntu for a few years and
Linux for ages but am setting up Ubuntu for an elderly relative who has
some trouble with precise mouse movements.)

--
Window Resize Difficult (Window Border Thickness)
https://bugs.launchpad.net/bugs/160311
You received this bug notification because you are a member of Ubuntu
Artwork Team, which is subscribed to human-gtk-theme in ubuntu.

Vikram:

I don't think he has a problem with the resolution. I think he wants that resolution, but with thicker borders on all themes for the sake of accessibility, which is a perfectly reasonable request.

I am bouncing ideas around in my head about how to fix this one.

How about a couple pixels worth of thickness that are transparent. This way the metacity themes won't have to be bulky.

> From: <email address hidden>
> To: <email address hidden>
> Date: Sun, 17 Aug 2008 19:41:33 +0000
> Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)
>
> Vikram:
>
> I don't think he has a problem with the resolution. I think he wants
> that resolution, but with thicker borders on all themes for the sake of
> accessibility, which is a perfectly reasonable request.
>
> I am bouncing ideas around in my head about how to fix this one.
>
> --
> Window Resize Difficult (Window Border Thickness)
> https://bugs.launchpad.net/bugs/160311
> You received this bug notification because you are a member of Ubuntu
> Artwork Team, which is subscribed to human-gtk-theme in ubuntu.

_________________________________________________________________
Get ideas on sharing photos from people like you. Find new ways to share.
http://www.windowslive.com/explore/photogallery/posts?ocid=TXT_TAGLM_WL_Photo_Gallery_082008

We could do that, although it would mean you'd need the shape extension; does anyone not have that these days? Alternatively, we could have an accessibility option that meant "Make all frame borders at least five pixels wide" or something.

Thomas Thurman (marnanel) wrote :

I foresee a post about this on the Metacity blog.

Richard (rd1) wrote :

I would like two options really:

1. Set pixel width of the border, ideally in the GNOME Appearance tool where you select a theme - have an option to Customize Theme (this is what Windows does). Should be a variable value, either by typing a number or using up/down buttons to change a displayed mockup of the border.

2. Have this feature also present in the Accessibility setup tool, perhaps with a fixed value. However, people's disabilities vary a lot so I don't think a fixed value is the best option, better to let it be changed as (1)

If you don't want a GUI option for (1), at least provide a documented gconf option for this if possible.

GNOME really is astonishingly good these days, and I've chosen it over KDE for this elderly relative based on usability, but this would improve it further.

Bill Smith (bsmith1051) wrote :

Sorry for the spam, but I just wanted to add my name to the list of people who have ALWAYS thought this was a problem ( going back to Ubuntu 6.06).

Yes I agree. This is a major usability problem.

On Tue, Aug 19, 2008 at 10:20 AM, Bill Smith <email address hidden> wrote:

> Sorry for the spam, but I just wanted to add my name to the list of
> people who have ALWAYS thought this was a problem ( going back to Ubuntu
> 6.06).
>
> --
> Window Resize Difficult (Window Border Thickness)
> https://bugs.launchpad.net/bugs/160311
> You received this bug notification because you are a member of Ubuntu
> Artwork Team, which is subscribed to human-gtk-theme in ubuntu.
>

It's a PITA to change the window sizes. I use a Razer mouse which has little to no linux support and it's very sensitive and I can tell you that I have a one in 1680 chance of catching that window edge to resize it. Do what ever you have to, make it happen it's annoying and really a pain on my wrists to have to spend time just trying to resize a window and it's embarrassing when trying to show the operating system to others.

Make Ubuntu the best it can be, you got my support.

Neil Broadley (scaine) wrote :

I've commented before, but I'll say it again - resizing is unbelievably difficult at 1920x1280 resolution. Near impossible in fact. I routinely use "ALT-Space R" now. Trying to hit a one pixel (it feels like it) border on my screen is hopeless. I worry about the accessibility issues implied by this bug.

@Thomas Thurman, you hinted that certain metacity themes have wider drag borders - if you have one in mind, can you share its name on this list, please? You also mention that you were hoping for a blog entry on the metacity blog. If this ever happened, can you share the URL. I'd like to raise the profile if this issue any way I can (digg the blog post for example).

I notice that Gnome closed their bug claiming that drag border sizes were theme controlled. I'm not sure this is actually the case. So far, I've tried built-in themes (Clearlooks, Cruz, Glider, etc) and some gnome-look themes (Dust, DarkRoom, Brushed, Blended, and Shiki). Themes do not appear to have any effect on the drag border. Perhaps someone with theme experience can shed some light on this.

Kenneth Wimer (kwwii) wrote :

Apps have a resize area at the bottom right...using this might make things easier.

Neil Broadley (scaine) wrote :

Some "gnome" apps have a resize corner, like Nautilus, but most GTK+ generic apps don't - Avidemux, Thunderbird, Firefox, DeVeDe and so on. In fact, many gnome apps themselves don't bother with the resize corner - look at the terminal for example.

Besides, that doesn't help you much when you want to resize down from the top - you'd have to resize up, then drag down. So much for ease of use in that scenario.

Just crazy that the entire experience of using Gnome can be tarnished by what should be easily fixed, and yet has been outstanding for nearly a year (probably much longer), spanning three O/S's (Gutsy, Hardy and now Intrepid).

Since posting, I've been messing about with themes and I've found one setting that makes a small difference. Go to System/Preferences/Appearance, then choose "Customise", then the tab "Window Border". They all seem to be 2px or 3px in size, APART from one called "Bright". It seems to have a 4px or 5px border. Sadly, it also changes all your window styles (looks awful) and min/max/close widgets (also looks awful). And it's a kinda bad looking brown colour, which doesn't fit the rest of my current theme. Not really much of a fix then.

But, I'm going to see if I can find the file that refers to "Bright" in gnome themes (where ever they might be - the system themes certainly aren't in ~/themes) and see what makes it's borders bigger. If I can find that I might be able to hack my "Dust" theme to have bigger borders.

What a pile of shxx. This, just so I can resize windows without having to have the coordination of an olympic athlete.

Kenneth Wimer (kwwii) on 2008-10-30
Changed in metacity:
assignee: nobody → kwwii
status: Invalid → New
Changed in human-gtk-theme:
status: New → Invalid
Changed in metacity:
status: Invalid → In Progress
Changed in hundredpapercuts:
milestone: none → round-4
status: New → Confirmed
Changed in metacity (Ubuntu):
status: New → Triaged
summary: - Window Resize Difficult (Window Border Thickness)
+ Resizing windows by grabbing window borders is difficult
Changed in hundredpapercuts:
milestone: round-4 → lucid-round-3
Vish (vish) on 2010-01-23
Changed in hundredpapercuts:
importance: Undecided → Low
status: Confirmed → Triaged
Kenneth Wimer (kwwii) on 2010-03-11
tags: added: gloam
Vish (vish) on 2010-03-17
Changed in light-themes (Ubuntu):
importance: Undecided → Low
status: New → Triaged
description: updated
description: updated
Ivanka Majic (ivanka) on 2010-04-26
tags: added: rhubarb
removed: gloam
tags: added: patch
Nigel Babu (nigelbabu) on 2010-05-07
tags: added: patch-needswork
removed: patch
Ivanka Majic (ivanka) on 2010-07-14
affects: ayatana-ubuntu → ayatana-design
Changed in ayatana-design:
importance: Undecided → Critical
assignee: nobody → Michael Forrest (michaelforrest)
Changed in ayatana-design:
assignee: Michael Forrest (michaelforrest) → Kenneth Wimer (kwwii)
tekstr1der (tekstr1der) on 2010-08-05
Changed in ayatana-design:
status: New → Confirmed
tags: added: regression-release
summary: - Resizing windows by grabbing window borders is difficult
+ Resizing windows by grabbing window borders is difficult [please no more
+ comments; patches welcome]
Changed in metacity:
importance: Unknown → Low
Vish (vish) on 2010-10-08
Changed in ubuntu-release-notes:
status: New → Fix Committed
Changed in metacity (Ubuntu):
assignee: Kenneth Wimer (kwwii) → nobody
Changed in ayatana-design:
assignee: Kenneth Wimer (kwwii) → Vish (vish)
assignee: Vish (vish) → nobody
Changed in ubuntu-release-notes:
status: Fix Committed → Fix Released
Changed in metacity (Ubuntu):
status: Triaged → Confirmed
Steve Langasek (vorlon) on 2010-10-16
Changed in metacity (Ubuntu):
status: Confirmed → Triaged
Vish (vish) on 2010-11-01
description: updated
Bryce Harrington (bryce) on 2010-12-13
description: updated
Andrew Schulman (andrex) on 2010-12-13
description: updated
Vish (vish) on 2011-01-02
description: updated
Changed in light-themes (Ubuntu):
status: Triaged → Fix Released
Paul Sladen (sladen) on 2011-01-27
Changed in ayatana-design:
status: Confirmed → Fix Released
Changed in hundredpapercuts:
status: Triaged → Fix Released
Changed in metacity (Ubuntu):
status: Triaged → Fix Released
Vish (vish) on 2011-01-27
Changed in hundredpapercuts:
milestone: lucid-round-3 → nt3-ayatana
assignee: nobody → Sam "SmSpillaz" Spilsbury (smspillaz)
summary: - Resizing windows by grabbing window borders is difficult [please no more
- comments; patches welcome]
+ Resizing windows by grabbing window borders is difficult
Changed in unity-2d:
importance: Undecided → Critical
status: New → Confirmed
no longer affects: unity
tekstr1der (tekstr1der) on 2012-03-19
tags: added: regression-potential
komputes (komputes) on 2012-03-20
tags: added: css-sponsored-p
Omer Akram (om26er) on 2012-03-26
no longer affects: unity
description: updated
description: updated
Keng-Yu Lin (lexical) on 2012-08-21
Changed in metacity (Ubuntu):
importance: Wishlist → High
status: Fix Released → Confirmed
MC Return (mc-return) on 2013-01-27
description: updated
no longer affects: human-gtk-theme (Ubuntu)
no longer affects: human-gtk-theme (Ubuntu Maverick)
no longer affects: light-themes (Ubuntu Maverick)
description: updated
307 comments hidden view all 387 comments

2013/1/31 Sam Spilsbury <email address hidden>

> On Thu, Jan 31, 2013 at 6:08 AM, OpenLaptop <email address hidden> wrote:
> > Funny to see this bug is still not fixed sinds 2007 (6 YEARS AGO!!!)
>
> Hi.
>
> 1. It is fixed in Unity-3D, which has been the default since 12.10
>

No it's not. I'm using Unity-3D, which is also the default in 12.04, and
borders aren't equal when it comes to resizing. It's almost imposible for
me to grab top and left borders, while bottom and right are pretty easy to
grab. I'd say there's at least a 3-4 pixels difference between the two
cases.

And no, it's not funny seeing how a basic usability like this is not being
properly addressed after six years.

Sam Spilsbury (smspillaz) wrote :
Download full text (4.6 KiB)

On 31/01/2013 8:51 AM, "Aleve Sicofante" <email address hidden> wrote:
>
> 2013/1/31 Sam Spilsbury <email address hidden>
>
> > On Thu, Jan 31, 2013 at 6:08 AM, OpenLaptop <email address hidden> wrote:
> > > Funny to see this bug is still not fixed sinds 2007 (6 YEARS AGO!!!)
> >
> > Hi.
> >
> > 1. It is fixed in Unity-3D, which has been the default since 12.10
> >
>
> No it's not. I'm using Unity-3D, which is also the default in 12.04, and
> borders aren't equal when it comes to resizing. It's almost imposible for
> me to grab top and left borders, while bottom and right are pretty easy to
> grab. I'd say there's at least a 3-4 pixels difference between the two
> cases.

Code-wise its exactly the same for the right, left and bottom borders.

The top border doesn't have the padding as it already has a grab area on
the titlebar.

>
> And no, it's not funny seeing how a basic usability like this is not being
> properly addressed after six years.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/160311
>
> Title:
> Resizing windows by grabbing window borders is difficult
>
> Status in Ayatana Design:
> Fix Released
> Status in One Hundred Paper Cuts:
> Fix Released
> Status in The Metacity Window Manager:
> In Progress
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in Unity 2D:
> Confirmed
> Status in “light-themes” package in Ubuntu:
> Fix Released
> Status in “metacity” package in Ubuntu:
> Confirmed
> Status in “metacity” source package in Maverick:
> Triaged
>
> Bug description:
> This bug is fixed in unity-3d since ubuntu 11.04.
> It still exists in unity-2d and will never be fixed as unity-2d is no
longer supported since ubuntu 12.10 (see comment #343).
>
> *************
>
> This should mostly be fixed for Natty and might get backported to
> earlier releases as well.
>
> For Precise (12.04) this is again broken for unity-2d (as of 17.7.2012
unity-2d 5.12.0-0ubuntu1.1).
> Note that if the window has a scrollbar, you can grab that to resize
the window. If not, you are stuck with the 1px border. Workaround: NONE
KNOWN (see comment 320)?
>
> *************
>
> *************Blueprint for Natty, Ubuntu 11.04:
>
> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-
> dx-n-resizing-windows
>
> Work items1 * Make sure the new resize grip fits in current
applications; doesn't interfere with anything. We should make some noise
about this during the Natty cycle so people keep their eyes open and file
bugs.
> 2 * Invisible window resize area - around 3px invisible area to allow
resize on all sides.
>
> *************
>
> Working grip backported to gtk2 already available in ppa :
> https://launchpad.net/~bratsche/+archive/gtk
>
> *************
>
> Workaround for Compiz/Unity: Alt+Middlemousebutton resizes a window
> most comfortably.
>
> Workaround: Edit /usr/share/themes/Ambiance/metacity-1/metacity-
> theme-1.xml. Set the following values in frame_geometry_normal as
> desired:
>
> <distance name="left_width" value="3"/>
> <distance name="right_width" value="3"/>
> <distanc...

Read more...

Aleve Sicofante (sicofante) wrote :

2013/1/31 Sam Spilsbury <email address hidden>

> On 31/01/2013 8:51 AM, "Aleve Sicofante" <email address hidden> wrote:
> >
> > 2013/1/31 Sam Spilsbury <email address hidden>
> >
> > > On Thu, Jan 31, 2013 at 6:08 AM, OpenLaptop <email address hidden>
> wrote:
> > > > Funny to see this bug is still not fixed sinds 2007 (6 YEARS AGO!!!)
> > >
> > > Hi.
> > >
> > > 1. It is fixed in Unity-3D, which has been the default since 12.10
> > >
> >
> > No it's not. I'm using Unity-3D, which is also the default in 12.04, and
> > borders aren't equal when it comes to resizing. It's almost imposible for
> > me to grab top and left borders, while bottom and right are pretty easy
> to
> > grab. I'd say there's at least a 3-4 pixels difference between the two
> > cases.
>
> Code-wise its exactly the same for the right, left and bottom borders.
>
> The top border doesn't have the padding as it already has a grab area on
> the titlebar.
>

That's why we call it a bug: probably you see the code being correct, but
since the behavior isn't, there's something going on and it must be fixed.

The grab area in the titlebar has nothing to do with the resizing area (or
shouldn't).

1 comments hidden view all 387 comments

On Thu, Jan 31, 2013 at 10:34 AM, Aleve Sicofante <email address hidden> wrote:
That's why we call it a bug: probably you see the code being correct, but
since the behavior isn't, there's something going on and it must be fixed.

The grab area in the titlebar has nothing to do with the resizing area (or
shouldn't).

Please, feel free to report an another bug about that. There is a detailed guide on how you can do that here:

    https://help.ubuntu.com/community/ReportingBugs

It does not make any sense to continue a discussion on an old bug report that is about a totally different issue.

no longer affects: metacity (Ubuntu Maverick)
no longer affects: metacity (Ubuntu)
Changed in unity-2d:
status: Confirmed → Invalid
John Lea (johnlea) wrote :

@sicofante; window title bar resizing issue is a different bug, see bug #717444

This change is signed off and is now waiting for someone to implement it, also see vanvugt's comment as to the original reason for this bug in the comments of the bug.

1 comments hidden view all 387 comments
MC Return (mc-return) wrote :

Sam, I'm running Emerald on Raring, so maybe that is why - but here grabbing window borders to initiate a resize is still very fuzzy...
We maybe should retest and revisit this issue for 13.04 ?

Aleve Sicofante (sicofante) wrote :

2013/1/31 Andrea Corbellini <email address hidden>
>
> On Thu, Jan 31, 2013 at 10:34 AM, Aleve Sicofante <email address hidden> wrote:
> It does not make any sense to continue a discussion on an old bug report
> that is about a totally different issue.

Excuse me? The title and description of this bug is EXACTLY the issue.
The fact that it's not about Metacity anymore, but about Unity-3D
doesn't make the slightest difference.

Resizing windows by grabbing window borders is INDEED difficult after
all these years, and a fix is needed for the current window manager.

Whoever has the power to do that, please add Unity-3D as a project
affected by this bug. Then let's try to fix it.

Aleve Sicofante (sicofante) wrote :

Just added Unity as a project affected by this bug.

Dear Aleve,

Please, do not modify this old bug. You are wasting contributors' time.

As John Lea has already pointed out, the issue you are describing has already been reported as bug #717444.

The reason why this bug should remain closed is that a fix has already been written for it. If you are still affected by the bug, then the root cause may be totally different. 'Symptoms' and 'causes' are totally different concepts, and for the propuse of this bug tracker we only look at causes (because we fix the causes, not the symptoms).

I'm sorry that you are having difficulties, but this is not the right place to discuss.

Changed in unity:
status: New → Fix Released
madbiologist (me-again) wrote :

Aleve - I think what Andrea was trying to say is what John Lea subsequently said - the specific bug for the window title bar/top border resizing issue is bug #717444. However that does ignore your first paragraph about the left border being more difficult to grab than the bottom and right borders. It is a puzzling dilemma about whether the latter should be opened as a new bug or not - technically it might have a different cause, but usability-wise it has the same effect.

What really annoys me is the comments made by Sam Spilsbury:

> 1. It is fixed in Unity-3D, which has been the default since 12.10
> 2. It isn't worth fixing in Unity-2D, since it would require extensive patching to metacity's frame display code

If I understand this bug's description correctly, this problem exists in Unity-2D on Ubuntu 12.04 "Precise Pangolin". This is an LTS release - according to https://wiki.ubuntu.com/Releases it will be supported on both the desktop and the server until April 2017. This should mean fully and wholly supported, not partly supported.

I also disagree with marking this bug's unity-2d task as Invalid while the upstream GNOME bug is still open as this implies that even if GNOME were to develop and deploy a fix, Ubuntu would not adopt the fix. And of course the fact that GNOME are considering fixing this issue should not in any way preclude Ubuntu from attempting to fix it.

> 3. Comments like these are not helpful.

Sam - these comments are not intended to help you. They are intended to help the people using Unity-2D on Precise. And even if the issue of providing full-support for Precise were to be sadly and frustratingly ignored, advising people using Unity-2D on Precise to upgrade to Ubuntu 12.10 "Quantal Quetzal" is unlikely to help matters, due to the fact that if their GPU is too old/weak to run Unity-3D then their CPU is also likely to be too old/weak to run Unity-3D using the LLVMpipe fallback code - see bug 1046497 and bug 1055936.

Dan Halbert (dhalbert) wrote :

To Andrea, Sam, and other developers: The title of this bug is broad and describes a problem encountered in multiple window managers. That is what draws people to this bug. I would suggest that you edit the title and narrow it to describe the manager(s) in which it has been fixed, and to add text to the beginning of the description to point to the specific bugs filed for other window managers.

> If I understand this bug's description correctly, this problem exists in Unity-2D on
> Ubuntu 12.04 "Precise Pangolin". This is an LTS release - according to
> https://wiki.ubuntu.com/Releases it will be supported on both the desktop and
> the server until April 2017. This should mean fully and wholly supported, not
> partly supported.

That's true, but 'supported' means "security and severe bug fixes only". See https://wiki.ubuntu.com/StableReleaseUpdates#When for more information.

> I also disagree with marking this bug's unity-2d task as Invalid while the upstream GNOME
> bug is still open

Also, you should note that the situation in the GNOME bug is a bit different. Firstly, there is no consensus on whether Metacity or the theme(s) should be fixed. Secondly, whilist Metacity has not been deprecated (AFAIK), it is no longer the development focus of GNOME. In fact, the last comment made by a developer was made on 2011-01-10.

> as this implies that even if GNOME were to develop and deploy a fix,
> Ubuntu would not adopt the fix.

I removed the metacity task just to make it clear that this bug is closed and to reduce the bug noise. This does not imply that if a fix is released by GNOME, then it won't be adopted by Ubuntu. We do not 'filter' upstream code. If Metacity makes a new release with the fix included, then it will just be packaged.

> And of course the fact that GNOME are considering fixing
> this issue should not in any way preclude Ubuntu from attempting to fix it.

Again, you are free to open a bug about it, although I doubt it will be fixed as there are no developers working on Metacity on Ubuntu. Anyhow, the point is: this particular one is too old and too long to be useful. Your opinions are welcome, but if you continue posting here, they will just be ignored.

madbiologist (me-again) wrote :

Andrea - thank you for your comments. I do appreciate your attention to my concerns. I have one final question before I shut up.

What is your/Canonical's advice to users experiencing this bug on Unity-2D on Precise? There are a few workarounds presented/discussed in this bug report, but in would be good to know the official Canonical recommendation. And can that advice be added to the release notes for Ubuntu 12.04.02 (and possibly 12.04 and 12.04.1 as well) on the Ubuntu Wiki?

Aleve Sicofante (sicofante) wrote :

2013/1/31 Andrea Corbellini <email address hidden>:
> Dear Aleve,
>
> Please, do not modify this old bug. You are wasting contributors' time.
>
> As John Lea has already pointed out, the issue you are describing has
> already been reported as bug #717444.
>
> The reason why this bug should remain closed is that a fix has already
> been written for it. If you are still affected by the bug, then the root
> cause may be totally different. 'Symptoms' and 'causes' are totally
> different concepts, and for the propuse of this bug tracker we only look
> at causes (because we fix the causes, not the symptoms).
>
> I'm sorry that you are having difficulties, but this is not the right
> place to discuss.
>
> ** Changed in: unity
> Status: New => Fix Released
>

Dear Andrea:

This bug is NOT fixed in Unity, so "Fix Released" is a plain lie. I
kindly suggest you change the status ASAP.

The title and description of this bug define perfectly well what
happens not just in my system, but in many others. As a matter of
fact, I have read people complaining about the reverse of my own
situation: they can grab the resizing handlers easily at the top and
the left, but not at the right and bottom.

Resizing handlers are definitely broken in Unity. Do you prefer to
open a new bug with exactly the same title and description as this one
but referred only to Unity? Be my guest. But that's exactly the case.
The title and description perfectly match what's going on TODAY on
Ubuntu 12.04 and 12.10.

The bug suggested by John Lea is the one which should be closed,
deleted or marked as a duplicate, since it's just a particular case of
this bug (it refers ONLY to the top handler). In no way it defines
COMPLETELY what I and others are experiencing regarding windows
resizing in Unity.

Sam Spilsbury (smspillaz) wrote :
Download full text (4.0 KiB)

On Thu, Jan 31, 2013 at 6:32 PM, MC Return <email address hidden> wrote:
> Sam, I'm running Emerald on Raring, so maybe that is why - but here grabbing window borders to initiate a resize is still very fuzzy...
> We maybe should retest and revisit this issue for 13.04 ?

The invisible border logic is only implemented in gtk-window-decorator.

It would have to be implemented on a per-decorator basis.

>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/160311
>
> Title:
> Resizing windows by grabbing window borders is difficult
>
> Status in Ayatana Design:
> Fix Released
> Status in One Hundred Paper Cuts:
> Fix Released
> Status in The Metacity Window Manager:
> In Progress
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in Unity 2D:
> Invalid
> Status in “light-themes” package in Ubuntu:
> Fix Released
>
> Bug description:
> This bug is fixed in unity-3d since ubuntu 11.04.
> It still exists in unity-2d and will never be fixed as unity-2d is no longer supported since ubuntu 12.10 (see comment #343).
>
> *************
>
> This should mostly be fixed for Natty and might get backported to
> earlier releases as well.
>
> For Precise (12.04) this is again broken for unity-2d (as of 17.7.2012 unity-2d 5.12.0-0ubuntu1.1).
> Note that if the window has a scrollbar, you can grab that to resize the window. If not, you are stuck with the 1px border. Workaround: NONE KNOWN (see comment 320)?
>
> *************
>
> *************Blueprint for Natty, Ubuntu 11.04:
>
> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-
> dx-n-resizing-windows
>
> Work items1 * Make sure the new resize grip fits in current applications; doesn't interfere with anything. We should make some noise about this during the Natty cycle so people keep their eyes open and file bugs.
> 2 * Invisible window resize area - around 3px invisible area to allow resize on all sides.
>
> *************
>
> Working grip backported to gtk2 already available in ppa :
> https://launchpad.net/~bratsche/+archive/gtk
>
> *************
>
> Workaround for Compiz/Unity: Alt+Middlemousebutton resizes a window
> most comfortably.
>
> Workaround: Edit /usr/share/themes/Ambiance/metacity-1/metacity-
> theme-1.xml. Set the following values in frame_geometry_normal as
> desired:
>
> <distance name="left_width" value="3"/>
> <distance name="right_width" value="3"/>
> <distance name="bottom_height" value="3"/>
>
> ************
>
> Binary package hint: metacity
>
> - The issue has been an issue for users (especially of large) screens
> for several releases- Trackpad users seem to be particularly impacted
> by this- The issue appears to have been significantly aggravated in
> Lucid by changing the border width from 3 pixels to 1 pixel
>
> The window borders in metacity are far too thin to be used for
> comfortable window resizing, and resize handles are not available in
> all applications (or even most). In fact, of all the windows I have
> open right now, not a single one of them has a resize handle. The
> res...

Read more...

Sam Spilsbury (smspillaz) wrote :
Download full text (4.1 KiB)

On Thu, Jan 31, 2013 at 9:07 PM, Dan Halbert <email address hidden> wrote:
> To Andrea, Sam, and other developers: The title of this bug is broad and
> describes a problem encountered in multiple window managers. That is
> what draws people to this bug. I would suggest that you edit the title
> and narrow it to describe the manager(s) in which it has been fixed, and
> to add text to the beginning of the description to point to the specific
> bugs filed for other window managers.

I agree.

>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/160311
>
> Title:
> Resizing windows by grabbing window borders is difficult
>
> Status in Ayatana Design:
> Fix Released
> Status in One Hundred Paper Cuts:
> Fix Released
> Status in The Metacity Window Manager:
> In Progress
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in Unity:
> Fix Released
> Status in Unity 2D:
> Invalid
> Status in “light-themes” package in Ubuntu:
> Fix Released
>
> Bug description:
> This bug is fixed in unity-3d since ubuntu 11.04.
> It still exists in unity-2d and will never be fixed as unity-2d is no longer supported since ubuntu 12.10 (see comment #343).
>
> *************
>
> This should mostly be fixed for Natty and might get backported to
> earlier releases as well.
>
> For Precise (12.04) this is again broken for unity-2d (as of 17.7.2012 unity-2d 5.12.0-0ubuntu1.1).
> Note that if the window has a scrollbar, you can grab that to resize the window. If not, you are stuck with the 1px border. Workaround: NONE KNOWN (see comment 320)?
>
> *************
>
> *************Blueprint for Natty, Ubuntu 11.04:
>
> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-
> dx-n-resizing-windows
>
> Work items1 * Make sure the new resize grip fits in current applications; doesn't interfere with anything. We should make some noise about this during the Natty cycle so people keep their eyes open and file bugs.
> 2 * Invisible window resize area - around 3px invisible area to allow resize on all sides.
>
> *************
>
> Working grip backported to gtk2 already available in ppa :
> https://launchpad.net/~bratsche/+archive/gtk
>
> *************
>
> Workaround for Compiz/Unity: Alt+Middlemousebutton resizes a window
> most comfortably.
>
> Workaround: Edit /usr/share/themes/Ambiance/metacity-1/metacity-
> theme-1.xml. Set the following values in frame_geometry_normal as
> desired:
>
> <distance name="left_width" value="3"/>
> <distance name="right_width" value="3"/>
> <distance name="bottom_height" value="3"/>
>
> ************
>
> Binary package hint: metacity
>
> - The issue has been an issue for users (especially of large) screens
> for several releases- Trackpad users seem to be particularly impacted
> by this- The issue appears to have been significantly aggravated in
> Lucid by changing the border width from 3 pixels to 1 pixel
>
> The window borders in metacity are far too thin to be used for
> comfortable window resizing, and resize handles are not available in
> all applications (or ev...

Read more...

Sam Spilsbury (smspillaz) wrote :
Download full text (4.5 KiB)

On Thu, Jan 31, 2013 at 8:36 PM, madbiologist <email address hidden> wrote:
> Aleve - I think what Andrea was trying to say is what John Lea
> subsequently said - the specific bug for the window title bar/top border
> resizing issue is bug #717444. However that does ignore your first
> paragraph about the left border being more difficult to grab than the
> bottom and right borders. It is a puzzling dilemma about whether the
> latter should be opened as a new bug or not - technically it might have
> a different cause, but usability-wise it has the same effect.
>
> What really annoys me is the comments made by Sam Spilsbury:
>
>> 1. It is fixed in Unity-3D, which has been the default since 12.10
>> 2. It isn't worth fixing in Unity-2D, since it would require extensive patching to metacity's frame display code
>
> If I understand this bug's description correctly, this problem exists in
> Unity-2D on Ubuntu 12.04 "Precise Pangolin". This is an LTS release -
> according to https://wiki.ubuntu.com/Releases it will be supported on
> both the desktop and the server until April 2017. This should mean
> fully and wholly supported, not partly supported.
>
> I also disagree with marking this bug's unity-2d task as Invalid while
> the upstream GNOME bug is still open as this implies that even if GNOME
> were to develop and deploy a fix, Ubuntu would not adopt the fix. And
> of course the fact that GNOME are considering fixing this issue should
> not in any way preclude Ubuntu from attempting to fix it.

Of course there would be no preclusion from including such a fix if it
were to be done.

What I'm saying is that I've worked extensively on multiple window
managers, and I can tell you with a lot of confidence that
implementing the same kind of invisible padding that we have in compiz
inside of metacity would not be an easy task, and as such, isn't going
to be a priority any time soon as far as I can tell. Those who worked
on this functionality for compiz (myself and Thomas) no longer work
for Canonical, and have no intention of implementing it inside of
metacity.

>
>> 3. Comments like these are not helpful.
>
> Sam - these comments are not intended to help you. They are intended to
> help the people using Unity-2D on Precise. And even if the issue of
> providing full-support for Precise were to be sadly and frustratingly
> ignored, advising people using Unity-2D on Precise to upgrade to Ubuntu
> 12.10 "Quantal Quetzal" is unlikely to help matters, due to the fact
> that if their GPU is too old/weak to run Unity-3D then their CPU is also
> likely to be too old/weak to run Unity-3D using the LLVMpipe fallback
> code - see bug 1046497 and bug 1055936.

If you have a GPU that is "too old" to run unity-3D, you will likely
have trouble running unity-2D as well. Both are hardware accelerated
(in different ways, the former using OpenGL, the latter using
XRender).

I understand the providing support for precise is important, but the
reality is that Canonical wasn't ever structured to do that. Basically
the entire team that worked on the Unity shell from 11.04 - 12.04 has
moved on from the company. As far as I'm aware, patches are accepted
for the olde...

Read more...

Sam Spilsbury (smspillaz) wrote :
Download full text (4.5 KiB)

On Thu, Jan 31, 2013 at 7:07 PM, Aleve Sicofante <email address hidden> wrote:
> 2013/1/31 Andrea Corbellini <email address hidden>
>>
>> On Thu, Jan 31, 2013 at 10:34 AM, Aleve Sicofante <email address hidden> wrote:
>> It does not make any sense to continue a discussion on an old bug report
>> that is about a totally different issue.
>
> Excuse me? The title and description of this bug is EXACTLY the issue.
> The fact that it's not about Metacity anymore, but about Unity-3D
> doesn't make the slightest difference.
>
> Resizing windows by grabbing window borders is INDEED difficult after
> all these years, and a fix is needed for the current window manager.
>
> Whoever has the power to do that, please add Unity-3D as a project
> affected by this bug. Then let's try to fix it.

Aleve, if you are still having problems resizing windows you can bump
up the padding around the window. If I remember correctly its in the
key org.gnome.mutter:draggable-border-width

>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/160311
>
> Title:
> Resizing windows by grabbing window borders is difficult
>
> Status in Ayatana Design:
> Fix Released
> Status in One Hundred Paper Cuts:
> Fix Released
> Status in The Metacity Window Manager:
> In Progress
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in Unity 2D:
> Invalid
> Status in “light-themes” package in Ubuntu:
> Fix Released
>
> Bug description:
> This bug is fixed in unity-3d since ubuntu 11.04.
> It still exists in unity-2d and will never be fixed as unity-2d is no longer supported since ubuntu 12.10 (see comment #343).
>
> *************
>
> This should mostly be fixed for Natty and might get backported to
> earlier releases as well.
>
> For Precise (12.04) this is again broken for unity-2d (as of 17.7.2012 unity-2d 5.12.0-0ubuntu1.1).
> Note that if the window has a scrollbar, you can grab that to resize the window. If not, you are stuck with the 1px border. Workaround: NONE KNOWN (see comment 320)?
>
> *************
>
> *************Blueprint for Natty, Ubuntu 11.04:
>
> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-
> dx-n-resizing-windows
>
> Work items1 * Make sure the new resize grip fits in current applications; doesn't interfere with anything. We should make some noise about this during the Natty cycle so people keep their eyes open and file bugs.
> 2 * Invisible window resize area - around 3px invisible area to allow resize on all sides.
>
> *************
>
> Working grip backported to gtk2 already available in ppa :
> https://launchpad.net/~bratsche/+archive/gtk
>
> *************
>
> Workaround for Compiz/Unity: Alt+Middlemousebutton resizes a window
> most comfortably.
>
> Workaround: Edit /usr/share/themes/Ambiance/metacity-1/metacity-
> theme-1.xml. Set the following values in frame_geometry_normal as
> desired:
>
> <distance name="left_width" value="3"/>
> <distance name="right_width" value="3"/>
> <distance name="bottom_height" value="3"/>
>
> ************
>
> Binary package hint: metacity
>
> ...

Read more...

MC Return (mc-return) wrote :

> The invisible border logic is only implemented in gtk-window-decorator.

> It would have to be implemented on a per-decorator basis.

Oh, I see. Thanks for the fast reply.
Seems like gtk-window-decorator is more advanced in this case than Emerald. :)

I see my comment is helpful after all. Because now I know this bug never gonna be fixed in Unity 2D, which is strange.. because it is still part of the current and future window manager of the almighty Ubuntu. So I really don't see any reason to not solve this critical issue.

Aleve Sicofante (sicofante) wrote :

2013/1/31 Sam Spilsbury <email address hidden>

>
> Aleve, if you are still having problems resizing windows you can bump
> up the padding around the window. If I remember correctly its in the
> key org.gnome.mutter:draggable-border-width
>

There's no such thing in Unity. Mutter is used in Gnome Shell...

madbiologist (me-again) wrote :

OpenLaptop - Unity-2D is not part of the future window manger of Ubuntu. Ubuntu 12.10 "Quantal Quetzal" and later only have Unity-3D, which uses the LLVMpipe software driver if the GPU is not capable of running Unity-3D.

That still leaves over 4 years of Unity-2D on Ubuntu 12.04 "Precise Pangolin" though.

Sam Spilsbury (smspillaz) wrote :
Download full text (4.0 KiB)

On Fri, Feb 1, 2013 at 4:20 AM, Aleve Sicofante <email address hidden> wrote:
> 2013/1/31 Sam Spilsbury <email address hidden>
>
>>
>> Aleve, if you are still having problems resizing windows you can bump
>> up the padding around the window. If I remember correctly its in the
>> key org.gnome.mutter:draggable-border-width
>>
>
> There's no such thing in Unity. Mutter is used in Gnome Shell...
>

gtk-window-decorator integrates with the mutter keys.

> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/160311
>
> Title:
> Resizing windows by grabbing window borders is difficult
>
> Status in Ayatana Design:
> Fix Released
> Status in One Hundred Paper Cuts:
> Fix Released
> Status in The Metacity Window Manager:
> In Progress
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in Unity:
> Fix Released
> Status in Unity 2D:
> Invalid
> Status in “light-themes” package in Ubuntu:
> Fix Released
>
> Bug description:
> This bug is fixed in unity-3d since ubuntu 11.04.
> It still exists in unity-2d and will never be fixed as unity-2d is no longer supported since ubuntu 12.10 (see comment #343).
>
> *************
>
> This should mostly be fixed for Natty and might get backported to
> earlier releases as well.
>
> For Precise (12.04) this is again broken for unity-2d (as of 17.7.2012 unity-2d 5.12.0-0ubuntu1.1).
> Note that if the window has a scrollbar, you can grab that to resize the window. If not, you are stuck with the 1px border. Workaround: NONE KNOWN (see comment 320)?
>
> *************
>
> *************Blueprint for Natty, Ubuntu 11.04:
>
> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-
> dx-n-resizing-windows
>
> Work items1 * Make sure the new resize grip fits in current applications; doesn't interfere with anything. We should make some noise about this during the Natty cycle so people keep their eyes open and file bugs.
> 2 * Invisible window resize area - around 3px invisible area to allow resize on all sides.
>
> *************
>
> Working grip backported to gtk2 already available in ppa :
> https://launchpad.net/~bratsche/+archive/gtk
>
> *************
>
> Workaround for Compiz/Unity: Alt+Middlemousebutton resizes a window
> most comfortably.
>
> Workaround: Edit /usr/share/themes/Ambiance/metacity-1/metacity-
> theme-1.xml. Set the following values in frame_geometry_normal as
> desired:
>
> <distance name="left_width" value="3"/>
> <distance name="right_width" value="3"/>
> <distance name="bottom_height" value="3"/>
>
> ************
>
> Binary package hint: metacity
>
> - The issue has been an issue for users (especially of large) screens
> for several releases- Trackpad users seem to be particularly impacted
> by this- The issue appears to have been significantly aggravated in
> Lucid by changing the border width from 3 pixels to 1 pixel
>
> The window borders in metacity are far too thin to be used for
> comfortable window resizing, and resize handles are not available in
> all applications (or even most). In fact, of all the windows I have...

Read more...

Aleve Sicofante (sicofante) wrote :

2013/2/1 Sam Spilsbury <email address hidden>

>
> > There's no such thing in Unity. Mutter is used in Gnome Shell...
> >
>
> gtk-window-decorator integrates with the mutter keys.
>

Lovely, but there's stil no "org.gnome.mutter:draggable-
border-width" key in my Unity-only installation's dconf. Actually, there's
nothing like org.gnome.mutter there.

Sam Spilsbury (smspillaz) wrote :
Download full text (4.3 KiB)

On Fri, Feb 1, 2013 at 1:38 PM, Aleve Sicofante <email address hidden> wrote:
> 2013/2/1 Sam Spilsbury <email address hidden>
>
>>
>> > There's no such thing in Unity. Mutter is used in Gnome Shell...
>> >
>>
>> gtk-window-decorator integrates with the mutter keys.
>>
>
> Lovely, but there's stil no "org.gnome.mutter:draggable-
> border-width" key in my Unity-only installation's dconf. Actually, there's
> nothing like org.gnome.mutter there.

Ah, I believe I made it so that if mutter wasn't installed, it just
uses the default value of 10px, as there was very little usecase for
making it configurable.

If you want to adjust it, you'll have to install mutter, and adjusting
that setting will adjust the draggable border width on both mutter and
unity.

>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/160311
>
> Title:
> Resizing windows by grabbing window borders is difficult
>
> Status in Ayatana Design:
> Fix Released
> Status in One Hundred Paper Cuts:
> Fix Released
> Status in The Metacity Window Manager:
> In Progress
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in Unity:
> Fix Released
> Status in Unity 2D:
> Invalid
> Status in “light-themes” package in Ubuntu:
> Fix Released
>
> Bug description:
> This bug is fixed in unity-3d since ubuntu 11.04.
> It still exists in unity-2d and will never be fixed as unity-2d is no longer supported since ubuntu 12.10 (see comment #343).
>
> *************
>
> This should mostly be fixed for Natty and might get backported to
> earlier releases as well.
>
> For Precise (12.04) this is again broken for unity-2d (as of 17.7.2012 unity-2d 5.12.0-0ubuntu1.1).
> Note that if the window has a scrollbar, you can grab that to resize the window. If not, you are stuck with the 1px border. Workaround: NONE KNOWN (see comment 320)?
>
> *************
>
> *************Blueprint for Natty, Ubuntu 11.04:
>
> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-
> dx-n-resizing-windows
>
> Work items1 * Make sure the new resize grip fits in current applications; doesn't interfere with anything. We should make some noise about this during the Natty cycle so people keep their eyes open and file bugs.
> 2 * Invisible window resize area - around 3px invisible area to allow resize on all sides.
>
> *************
>
> Working grip backported to gtk2 already available in ppa :
> https://launchpad.net/~bratsche/+archive/gtk
>
> *************
>
> Workaround for Compiz/Unity: Alt+Middlemousebutton resizes a window
> most comfortably.
>
> Workaround: Edit /usr/share/themes/Ambiance/metacity-1/metacity-
> theme-1.xml. Set the following values in frame_geometry_normal as
> desired:
>
> <distance name="left_width" value="3"/>
> <distance name="right_width" value="3"/>
> <distance name="bottom_height" value="3"/>
>
> ************
>
> Binary package hint: metacity
>
> - The issue has been an issue for users (especially of large) screens
> for several releases- Trackpad users seem to be particularly impacted
> by this- The issue appears to have bee...

Read more...

Aleve Sicofante (sicofante) wrote :

2013/2/1 Sam Spilsbury <email address hidden>

>
> Ah, I believe I made it so that if mutter wasn't installed, it just
> uses the default value of 10px, as there was very little usecase for
> making it configurable.
>
> If you want to adjust it, you'll have to install mutter, and adjusting
> that setting will adjust the draggable border width on both mutter and
> unity.

Thanks. I might do that. I still urge the developers to either add such a
key to dconf or just fix the issue in Unity.

vmajor (victor-major) wrote :

Still broken. Fresh install 12.04.2. Just looking at the logs using the GUI log viewer is nearly impossible as I cannot resize the log viewer window. This finally got me annoyed enough to add to this mega bug report.

The border appears to be 1px wide. Please fix this. It is an LTS release afterall right?

In a fresh 12.04 install it is next to impossible to grab the bottom right or bottom left resize handle (firefox, pidgin, avidemux)

vexacious Unity -- an open house divided cannot sell.

JLuc (jluc-q) wrote :

With current 12.04 LTS it is impossible to grab the border or the corner of the window at first time. Maybe my screen is too big (20") so it makes the border too thin. It takes many try to manage to get it. Spending so much time just to resize a window is all the more painfull since i want to concentrate on my work, not on such basic UI actions.

Andrei (0p-andrei) wrote :

Fresh install of Ubuntu 13.04 raring , resizing windows is a PITA. Please reopen.

On top border are only 2 pixels available for resize, on the other borders seems to be 8 pixels. [I can't be sure because (of course) zooming in Universal Access is not working.]

Also clicking outside the visible window to resize is counter intuitive. [I would take a better screenshot but (of course) setting a solid background doesn't work (except black to be precise)]. [I would attach a screenshot if I could include the mouse pointer in the picture. Even Shutter seems to show only the "default" pointer icon]

The selection in corners is strange too: not symetric, tip of the pointer not consistent etc.

Aleve Sicofante (sicofante) wrote :

Why isn't this configurable in gconf/dconf or something? It seems every system behaves differently, which is quite weird (maybe it depends on the monitors resolution?)

Please don't hardcode this and give us a workaround, at least until the touch OS is ready and resources come back to the desktop.

Ben Shadwick (benshadwick) wrote :

This bug is going to be ignored unless you can get someone to revert the "fix released" status. I've contacted some of the people who set that status on this bug, and I suggest that others do the same.

Personally I have no stake in this any more, since I ditched Ubuntu proper and have been using derivatives such as Xubuntu, Mint and XMBCBuntu that do not use Unity.

Aleve Sicofante (sicofante) wrote :

And who are those Masters of the Universe who can revert the "fix released"
status?

2013/7/29 Ben Shadwick <email address hidden>

> This bug is going to be ignored unless you can get someone to revert the
> "fix released" status. I've contacted some of the people who set that
> status on this bug, and I suggest that others do the same.
>
>

Sam Spilsbury (smspillaz) wrote :

Please stop asking to revert the status of this bug. It is fine as is:

 1. This bug was fixed in compiz and Unity in 11.04 (two years ago now). The left, right and bottom window borders now have a ten-pixel each-way grab area.
 2. A similar grab area was added to the top border in 13.04
 3. If no such grab area exists and you are running Unity 3D, you can configure the borders so that they do exist:
     11.04: Open /usr/share/themes/Ambiance/metacity-1/metacity-theme-1.xml and edit the <padding> tags under <frame_tyle> with the name "normal_focused" and "normal_unfocused" and add left="left_padding" right="right_padding" bottom="bottom_padding"
    11.10 and onwards: Install mutter (sudo apt-get install mutter) and edit org.gnome.mutter 'draggable-border-width' in dconf-editor
 4. No such grab area exists in Unity 2D. It will not be added to Unity 2D because it would entail making metacity into a non-simple compositing manager. Unity 2D was designed to be run without any hardware acceleration. As such, the Unity 2D bug status is, and will remain "Invalid".
 5. This bug is only fixed in Unity 3D. Any similar issues with other desktop environments (gnome-classic, xfce, kde) should be reported to the relevant upstream.

Aleve Sicofante (sicofante) wrote :

2013/7/29 Sam Spilsbury <email address hidden>

> Please stop asking to revert the status of this bug. It is fine as is:
>
> 1. This bug was fixed in compiz and Unity in 11.04 (two years ago now).
> The left, right and bottom window borders now have a ten-pixel each-way
> grab area.
>

This is plain false. Wanna come over my place to see it for yourself?

> 2. A similar grab area was added to the top border in 13.04
>

Again, this can be proved false on many computers. I can show you a few.

> 3. If no such grab area exists

In other words: such grab area might not exist, so how on Earth can you say
this is fixed?

> and you are running Unity 3D, you can configure the borders so that they
> do exist:
> 11.04: Open
> /usr/share/themes/Ambiance/metacity-1/metacity-theme-1.xml and edit the
> <padding> tags under <frame_tyle> with the name "normal_focused" and
> "normal_unfocused" and add left="left_padding" right="right_padding"
> bottom="bottom_padding"
> 11.10 and onwards: Install mutter (sudo apt-get install mutter) and
> edit org.gnome.mutter 'draggable-border-width' in dconf-editor
>

What about 12.04, 12.10 and 13.04 users? Can't you see there are complaints
from users of these versions as well?

  5. This bug is only fixed in Unity 3D. Any similar issues with other
> desktop environments (gnome-classic, xfce, kde) should be reported to the
> relevant upstream.
>

This bug IS NOT FIXED. Just saying so won't magically change facts. And the
facts show very clearly LOTS of people have a really hard time grabbing
windows borders. Some people experience it at the top of the windows, some
at the sides, some at the bottom... (and we're not even talking about the
elusive target of Nautilus' sidebar resizing handle...). I'm no developer
so I can't imagine how you guys go about this thing, but it behaving
differently for different users on different computers should tell you
something.

Andrei (0p-andrei) wrote :

1. This bug was fixed in compiz and Unity in 11.04 (two years ago now). The left, right and bottom window borders now have a ten-pixel each-way grab area.
  How much pixels have the top and bottom?
  Was fixed and now it's the same?
  I've counted only 8, not 10 on left and right.
  How about the corners? Is there an image which shows the invisible border?

2. A similar grab area was added to the top border in 13.04
2 pixels top border grab area in http://mirrors.melbourne.co.uk/ubuntu-releases//raring/ubuntu-13.04-desktop-amd64.iso , installed yesterday and also updated. The single difference from the standard is a newer kernel, to fix a bug with video camera http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11-rc2-saucy/ . But then again, this video/microphone bug was also fixed sometunes in 3.5, so it shouldn't be back again.
Should I download another 13.04 Ubuntu version?

3. If no such grab area exists and you are running Unity 3D,
I should (re)open a ticket, but it's too freaking hard, because bug has been solved. The same way as bug #1 probably. This is not one of a 100 paper cuts, this is like smashing your hand with a hammer. Not being able to change the background to a solid color is a paper cut. After using computers for the last 15 years almost every day, more than 8 hours a day, and coming again to Ubuntu to see how it's doing, and being greeted by a crippled interface, it's saddening. But not so much as the attitude of not seeing how broken the usability is.

4. No such grab area exists in Unity 2D.
Not using 2D, as far as I know.

5. This bug is only fixed in Unity 3D.
  This bug was (probably) fixed in Unity 3D.

Can you tell me on what computer configuration runs the automated test which measures this grab border?

Canonical should close all regression bugs, because they were once fixed.

madbiologist (me-again) wrote :

Sam Spilsbury (smspillaz) wrote:

> 11.10 and onwards: Install mutter (sudo apt-get install mutter) and edit org.gnome.mutter 'draggable-border-width' in dconf-editor

Aleve Sicofante (sicofante) wrote:

> What about 12.04, 12.10 and 13.04 users? Can't you see there are complaints from users of these versions as well?

I write:

"and onwards" means 12.04, 12.10, 13.04 and 13.10.

Aleve - Which Ubuntu release and variety (Ubuntu/Kubuntu/Xubuntu/Lubuntu/GNOMEbuntu) are you using? I'm wondering if your implementation is not using gtk-window-decorator.

madbiologist (me-again) wrote :

Sam Spilsbury - Is http://wiki.compiz.org/ meant to be empty?

Aleve Sicofante (sicofante) wrote :

> "and onwards" means 12.04, 12.10, 13.04 and 13.10.
>

My fault. You're right.

>
> Aleve - Which Ubuntu release and variety
> (Ubuntu/Kubuntu/Xubuntu/Lubuntu/GNOMEbuntu) are you using? I'm
> wondering if your implementation is not using gtk-window-decorator.
>

Plain mainstream official Ubuntu 13.04. It works differently in a Macbook
Pro A1150 (32 bits), a Lenovo T400, a Dell Studio 1537, a BTO workstation...

Aleve Sicofante (sicofante) wrote :

Just one more question: why should I have to install mutter on plain Unity
Ubuntu which doesn't use it at all?

Sam Spilsbury (smspillaz) wrote:

>
> > 11.10 and onwards: Install mutter (sudo apt-get install mutter) and
> edit org.gnome.mutter 'draggable-border-width' in dconf-editor
>

Displaying first 40 and last 40 comments. View all 387 comments or add a comment.