Resizing windows by grabbing window borders is difficult

[Robert Lee]

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).

[Siegfried Gevatter (rainct)]

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).

[Neil Broadley (scaine)]

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)]

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)]

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)]

I forwarded the problem to metacity's developers.

Thanks for your feedback!

[Siegfried Gevatter (rainct)]

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

[Chris Coulson (chrisccoulson)]

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?

[Marnanel Thurman (marnanel)]

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)]

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)]

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.

[Troy James Sobotka (troy-sobotka)]

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.

[xl_cheese (xl-cheese)]

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

[Neil Broadley (scaine)]

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.

[Skorn (korn94sam)]

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

[Paul Perkins (thirdspace)]

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?

[Marnanel Thurman (marnanel)]

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

[Marnanel Thurman (marnanel)]

(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)]

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)]

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.

[aphemos (aphemos)]

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.

[aphemos (aphemos)]

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.

[Étienne BERSAC (bersace)]

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)]

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 :)

[Troy James Sobotka (troy-sobotka)]

@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)]

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)]

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.

[Marnanel Thurman (marnanel)]

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

[Richard (rd1)]

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.)

[Vikram Dhillon (dhillon-v10)]

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.

[Marnanel Thurman (marnanel)]

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.

[xl_cheese (xl-cheese)]

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

[Marnanel Thurman (marnanel)]

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.

[Marnanel Thurman (marnanel)]

I foresee a post about this on the Metacity blog.

[Richard (rd1)]

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)]

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).

[dubski (dubski)]

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.
>

[camoguy (pacnow)]

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)]

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)]

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

[Neil Broadley (scaine)]

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)]

I have a 24" screen and have no problem resizing the windows. Making the window deco bigger is simply not an option when working on a smaller sized screen...the borders are huge and waste space. It has nothing to do with being an olympic athlete, if you do not like the default, change it, you are certainly free to do that with linux.

[Kenneth Wimer (kwwii)]

In any case, the bug would be against the metacity theme and not the gtk theme

[Kenneth Wimer (kwwii)]

Actually, after taking a screenshot, there are 5 pixels available for resizing the window on any side. I don't see the point in this bug anymore...maybe running some *really* big screen makes this hard but under normal circumstances it should not be hard to hit 5 pixels.

[Neil Broadley (scaine)]

What resolution are you running at? Are you seriously suggestion that because YOU don't have a problem resizing, then everyone else who's filed against this bug must be wrong?

You say that if I don't like the default, change it. How? How do you make grab borders bigger in Ubuntu?

And what theme are you running that has 5px of border? Mine doesn't. 2px at the most here, using ClearLooks, although I've since changed it to Dust.

Did you actually read ANY of the preceeding comments from the many, many people experiencing this problem? There are about 30 interested parties here I think. I'd really like to hear how to fix this - I've been waiting (and struggling) for over a year now.

I'm also really confused about your last comment - you "don't see the point of this bug anymore". What does that mean?

[Kenneth Wimer (kwwii)]

I am runnig at 1920x1200 with the normal murrine based human theme.. ake a screenshot and look at it yourself, if that is not true, feel free to ping me personally.

If you want larger borders you select another theme or find one which suits your needs. Even 30 (and I really doubt that many are interested) doesn't mean much against millions of users. I am not saying that this my reason for refusal but it is certainly a reason.

[Adam Del Vecchio (tux.ice)]

Does this affect COMPIZ as well?

-----Original Message-----
From: Kenneth Wimer <email address hidden>
Sent: October 30, 2008 7:32 PM
To: <email address hidden>
Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)

In any case, the bug would be against the metacity theme and not the gtk
theme

** Changed in: metacity (Ubuntu)
     Assignee: (unassigned) => Kenneth Wimer (kwwii)
       Status: Invalid => New

** Changed in: human-gtk-theme (Ubuntu)
       Status: New => Invalid

--
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.

[Adam Del Vecchio (tux.ice)]

Kenneth, I agree, although there should be an app somewhere, possibly built into gtkrc that allows change to little details like this.

-----Original Message-----
From: Neil Broadley <email address hidden>
Sent: October 30, 2008 7:53 PM
To: <email address hidden>
Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)

What resolution are you running at? Are you seriously suggestion that
because YOU don't have a problem resizing, then everyone else who's
filed against this bug must be wrong?

You say that if I don't like the default, change it. How? How do you
make grab borders bigger in Ubuntu?

And what theme are you running that has 5px of border? Mine doesn't.
2px at the most here, using ClearLooks, although I've since changed it
to Dust.

Did you actually read ANY of the preceeding comments from the many, many
people experiencing this problem? There are about 30 interested parties
here I think. I'd really like to hear how to fix this - I've been
waiting (and struggling) for over a year now.

I'm also really confused about your last comment - you "don't see the
point of this bug anymore". What does that mean?

--
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.

[Adam Del Vecchio (tux.ice)]

*gtk not gtkrc

-----Original Message-----
From: Kenneth Wimer <email address hidden>
Sent: October 30, 2008 8:26 PM
To: <email address hidden>
Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)

I am runnig at 1920x1200 with the normal murrine based human theme.. ake
a screenshot and look at it yourself, if that is not true, feel free to
ping me personally.

If you want larger borders you select another theme or find one which
suits your needs. Even 30 (and I really doubt that many are interested)
doesn't mean much against millions of users. I am not saying that this
my reason for refusal but it is certainly a reason.

--
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.

[josef.sabl (josef-sabl-gmail)]

I absolutely hate this bug. Am I weirdo too?

> Even 30 (and I really doubt that many are interested)
> doesn't mean much against millions of users.
How many of those millions you think will go throught the process of
registering here at launchpad and complain here? Not many, lots of them just
dump OS as flawed or grind teeth. 30 fix requests is a huge number by my
scales.

I am sure that feature which requires user to digg through forums to find a
fix for such a basic feature as resizing window is a bug and requires
immediate correction.

On Fri, Oct 31, 2008 at 01:26, Kenneth Wimer <email address hidden> wrote:

> I am runnig at 1920x1200 with the normal murrine based human theme.. ake
> a screenshot and look at it yourself, if that is not true, feel free to
> ping me personally.
>
> If you want larger borders you select another theme or find one which
> suits your needs. Even 30 (and I really doubt that many are interested)
> doesn't mean much against millions of users. I am not saying that this
> my reason for refusal but it is certainly a reason.
>
> --
> Window Resize Difficult (Window Border Thickness)
> https://bugs.launchpad.net/bugs/160311
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Josef Sábl

[josef.sabl (josef-sabl-gmail)]

I disagree, there should be a default setting that works for everyone. That
is point of default settings, right?

On Fri, Oct 31, 2008 at 02:30, Adam Del Vecchio <email address hidden> wrote:

> *gtk not gtkrc
>
> -----Original Message-----
> From: Kenneth Wimer <email address hidden>
> Sent: October 30, 2008 8:26 PM
> To: <email address hidden>
> Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)
>
> I am runnig at 1920x1200 with the normal murrine based human theme.. ake
> a screenshot and look at it yourself, if that is not true, feel free to
> ping me personally.
>
> If you want larger borders you select another theme or find one which
> suits your needs. Even 30 (and I really doubt that many are interested)
> doesn't mean much against millions of users. I am not saying that this
> my reason for refusal but it is certainly a reason.
>
> --
> 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.
>
> --
> Window Resize Difficult (Window Border Thickness)
> https://bugs.launchpad.net/bugs/160311
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Josef Sábl

[Richard (rd1)]

Ubuntu aims to be usable by ordinary human beings and accessible to the disabled. This issue is hurting those goals as follows:

(1) Usability: Windows (95 onwards), Mac OS and KDE all have the ability to change border thickness *because clicking on a thin border is a problem for some people*. Microsoft, Apple and the KDE team all added this feature for a reason, and don't require you to change theme to change the border thickness. Border thickness is not a problem for many people I'm sure, but Ubuntu is missing out on part of its target market.

(2) Accessibility: some people have motor control disabilities, e.g. tremor in the hand - it's important for them that it's *really easy* to set a larger window border, even on a smaller monitor. Ubuntu has relatively good support for visually impaired users - why not for users with motor control problems? Note that elderly people often have problem controlling the mouse (if they are new to computer), which is another accessibility issue - if you are struggling to accurately position the mouse pointer, a small window border makes it harder still.

(3) Look and Feel: People should be able to choose a nice theme that they like (or is accessible to them), and independently tweak the border thickness - what if you hate blue but the only theme with a thicker border is blue? More importantly, what if you are visually impaired *and* have motor control problems, so you need a high-contrast theme, yet the only themes with a wide border are low contrast.

The fact that "only" 30 people have commented here is misleading - only a tiny percentage of those experiencing this problem will bother to find the right bug and register on Launchpad. It's very likely it's affecting tens to hundreds of thousands of people, assuming Ubuntu's user base of 6 million is correct.

Finally, Ubuntu should be *better* than Mac OS, Windows, etc - this is one area where its GNOME flavour is behind the competition.

[Adam Del Vecchio (tux.ice)]

We will look into a fix.

-----Original Message-----
From: Richard <email address hidden>
Sent: October 31, 2008 3:41 AM
To: <email address hidden>
Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)

Ubuntu aims to be usable by ordinary human beings and accessible to the
disabled. This issue is hurting those goals as follows:

(1) Usability: Windows (95 onwards), Mac OS and KDE all have the ability
to change border thickness *because clicking on a thin border is a
problem for some people*. Microsoft, Apple and the KDE team all added
this feature for a reason, and don't require you to change theme to
change the border thickness. Border thickness is not a problem for many
people I'm sure, but Ubuntu is missing out on part of its target market.

(2) Accessibility: some people have motor control disabilities, e.g.
tremor in the hand - it's important for them that it's *really easy* to
set a larger window border, even on a smaller monitor. Ubuntu has
relatively good support for visually impaired users - why not for users
with motor control problems? Note that elderly people often have
problem controlling the mouse (if they are new to computer), which is
another accessibility issue - if you are struggling to accurately
position the mouse pointer, a small window border makes it harder still.

(3) Look and Feel: People should be able to choose a nice theme that
they like (or is accessible to them), and independently tweak the border
thickness - what if you hate blue but the only theme with a thicker
border is blue? More importantly, what if you are visually impaired
*and* have motor control problems, so you need a high-contrast theme,
yet the only themes with a wide border are low contrast.

The fact that "only" 30 people have commented here is misleading - only
a tiny percentage of those experiencing this problem will bother to find
the right bug and register on Launchpad. It's very likely it's
affecting tens to hundreds of thousands of people, assuming Ubuntu's
user base of 6 million is correct.

Finally, Ubuntu should be *better* than Mac OS, Windows, etc - this is
one area where its GNOME flavour is behind the competition.

--
Window Resize Difficult (Window Border

[The entire original message is not included]

[camoguy (pacnow)]

God speed and God bless you

[Matthew Paul Thomas (mpt)]

It is not true that Mac OS lets you change window border thickness: since 2001 its windows have had no resize border at all. Instead, resizable windows always have a resize grippy in the lower right corner.

Apple does provide an example, however, of another of the solutions proposed in previous comments: an invisible drag area. In iTunes 7.0 the border between the source list and the rest of the window was a 1-pixel-wide draggable splitter. In iTunes 7.3 an invisible 6-pixel-wide draggable area was added around the 1-pixel border. <http://thinkmac.co.uk/blog/2007/07/itunes-73-ushers-in-welcome-ui-changes.html> But apparently that still wasn't enough, and in 7.4 a grippy at the bottom was added as well. <http://inessential.com/?comments=1&postid=3100>

I have no insight on whether an invisible draggable area would be both sufficient and error-free enough to work well for resizing windows. User-test it and see. :-) Meanwhile, report bugs that GTK should provide a corner resize grippy that doesn't require a status bar, and that more apps should use corner resize grippies.

[Chris Coulson (chrisccoulson)]

Richard - I corrected your accessibility tag. The official tag for accessibility related bugs is 'a11y'

[Wouter Stomp (wouterstomp-deactivatedaccount)]

"report bugs that more apps should use corner resize grippies.": see bug 19232 for that

[camoguy (pacnow)]

I found a very useful resize tool for the mean time. I installed the CompizConfig Settings Manager and found that ALT + BUTTON 2 initiates the resize with the mouse.

[Neil Broadley (scaine)]

I have managed to manually hack the theme files to allow for a larger border. Obviously, not really a solution and use at your own risk, but as long you make a back of the file involved (an xml file), you should have an easy time following this.

After some searching, it turns out that the pre-distributed themes such as clearlooks are located in /usr/share/themes. I'll assume you're using clearlooks, but if you'd like to edit a custom theme that you've downloaded, you'll find the same file structure, but in ~/.themes. So inside /usr/share/themes/Clearlooks/metacity-1, there's a file called metacity-theme-1.xml. You'll need to be sudo to edit this file (gksudo gedit or similar) and you should back up this file before you start.

The very first entry in the GEOMETRY section has three values that relate to the left, right and bottom borders (no idea why there's no top-border entry, but I couldn't find one). Anyway, in most themes, the default appears to be 4, which on my monitor/mouse set up translates to 2px. Of course, I'm sure the value 4 is meant to be 4px, but what I mean is that my mouse only physically moves twice before it's off the drag-area, which is why it's so damn hard to hit.

I've changed all three entries to 10. This equates to about 6 movements of my mouse over the drag-area and makes massive difference.

<!-- ::: GEOMETRY ::: -->
<frame_geometry name="normal" rounded_top_left="true" rounded_top_right="true" rounded_bottom_left="false" rounded_bottom_right="false">
 <distance name="left_width" value="10"/>
 <distance name="right_width" value="10"/>
 <distance name="bottom_height" value="10"/>
 <distance name="left_titlebar_edge" value="4"/>
 <distance name="right_titlebar_edge" value="4"/>
 <aspect_ratio name="button" value="1.0"/>
 <distance name="title_vertical_pad" value="0"/>
 <border name="title_border" left="2" right="2" top="4" bottom="3"/>
 <border name="button_border" left="1" right="1" top="2" bottom="2"/>
</frame_geometry>

Of course, if you ever change your theme, you'll have to find the corresponding theme directory and make these changes all over again. Also, in order to activate any changes after saving the file you'll have to either log out/in, or quicker still - open system/preferences/appearance and choose a different theme briefly, then switch back to the one you just edited.

I should stress, I don't see that this workaround could, in any way be construed as a fix for this bug - the appearances window should simply provide a slider, or perhaps an accessibility option is required.

I think I'll try opening another bug against gnome for this too. The more I think about this, the original gnome bug was closed because gnome feels that this is a theme related issue, and while that's probably true in the purest sense, it's crazy to suggest that I need to download new themes over and over until I find one that has thicker borders. And it's crazy to think that we need to manually edit xml files to make things better.

However, I hope this helps someone else.

[Dan Liberatore (dan-liberatore)]

I have this problem at work, where we use Ubuntu. That's a win for the project, for sure!

I've used two different mice: one optical, one laser with adjustable DPI; I've used several display resolutions from 1024x768 through 1600x1200; in no case was I satisfied with the size of the resize handles in the themes I got by default. I do need to resize windows a lot to keep a large amount of information on the screen. I'll typically have 7 or 8 virtual desktops populated with multiple windows each, and I do a ton of coding and testing. I have 7 right now. So you can't chalk it up to people with disabilities or the elderly or the computer illiterate - I am one of you, or should I say "us" or "we" power-users, who CAN tweak things to my liking without asking on forums!

However, being at my job, this means I can't spend all day tweaking things to make my life easier. I have to account for my time, and management doesn't want to find out that I spent an hour downloading themes, finding and tweaking XML to make my GUI better. Neither do I want to have to do this at home and bring it to work. That helps nobody.

I am stuck with an OS that I can't alter in a fundamental way. I quite literally would lose a large amount of productivity if I was forced to use Windows or MacOS, and installing some other distribution isn't a possibility because Ubuntu+GNOME is our standard desktop OS. Being condescending, insulting the intelligence and ability of your fellow users and Linux advocates, and calling a report like this trivial and useless is not in the spirit of GNOME, nor is it the spirit of Ubuntu that I have known. I know it's stressful to moderate threadlike bug reports where people don't understand each other, I'm right there with you, and I personally will give my thanks when this is done.

All the other commenters and I want is a simple control in the appearance control panel. One that should be there, but isn't. I do not have the time to write a control panel extension for GNOME, nor do I have the patience to support one, nor the desire to produce on my own limited time a buggy crapplet that gets rejected and postpones the development a real solution longer. Yes, I know it's annoying to have users demand something, and I do ticket work for clients all the time so I understand that very well, but don't you think it's about time to add that one control to the panel? This enhancement request has been open for a year and a month now.

Is somebody working on this and that's just not being mentioned? Because I'd love to thank them for it, believe me. I'd donate a beer or two for sure if I knew it would get this done. See, I'm even willing to pay a small amount for the development...

BTW, Trivia: Other commenters were correct when they said Windows has had this, and I do remember having the setting in Windows 3.1. There was actually a "Granularity" setting as well that allowed you to set the granularity of window resizing - so it would snap to multiples of X pixels where X was normally 1 but you could say you wanted 4px, 8px, etc.

[Marnanel Thurman (marnanel)]

Dan: Okay, you convinced me. I've attached a patch upstream. Here's a screenshot.

[Kenneth Wimer (kwwii)]

It seems to me that this is an upstream problem for gnome/metacity and not ubuntu specific. Increasing the default size is not an option because it makes everyone else's setup ugly and wastes space.

[Marnanel Thurman (marnanel)]

Kenneth:

The patch I have attached upstream allows a minimum width to be set for the border size. Setting this to 0 causes no difference from the status quo. Setting it to, say, 20 causes 20px borders throughout.

[Kenneth Wimer (kwwii)]

Thomas: this would need ot be accepted upstream and the UI would need to be changed to allow for this additional functionality.

[Marnanel Thurman (marnanel)]

Kenneth: I'm the upstream maintainer :)

I can't speak for the control-center UI, though.

[Dan Liberatore (dan-liberatore)]

Thomas: Nice demo. If I can't drag THAT, I fail :) All joking around aside, that patch looks useful. Even if it's only in the config editor (which is not necessarily easy to find for some newbies, I know) it's still there and much more easily tweakable than theme XML. Thanks.

Kenneth: Absolutely. There's no need to alter the default wholesale. I don't think anyone would disagree with you on those points - this should be an opt-in thing and it has huge potential to make things hideous, especially themes based on bitmapped images rather than vector art. Some of us don't care so much if it looks bad as long as we can use it.

Looks like Thomas has done it! Is there any probability that it will be included in an update in the near future? Can I download a package and have it?

Now, about buying you a beer or two.. I'm serious, email me about it

[Shirish Agarwal (shirishag75)]

Hi all,
 Can somebody tell me where is this config editor and is this patch included in the jaunty release so it could be tested here as well during the alpha phase?

There is a pool of people who could help with testing if needed.

http://ubuntuforums.org/showpost.php?p=6535929&postcount=157

[umutuygar (umutuygar)]

This resize problem is the first thing that disturbs me whenever I install a gnome based linux. I'm looking forward seeing a reasonable solution to this.

[Jared Biel (sylvester-0)]

I'm here to add my concern for this bug. I'm currently using a jaunty netbook with a 1024x600 resolution and resizing windows "naturally" (using my cursor on a window edge) is almost always an absolute chore if not impossible. On my 1920x1200 desktop computer it's not quite as difficult with my trackball but it's more difficult than it should be.

Now, I don't know if a patch that allows for border resizing is the right step. Making the borders larger takes away from screen real estate. Would it be possible to keep the borders at 1px while extending the [invisible] "resize threshold" out 5 or 10 pixels on each side of the border?

I haven't used KDE since they released version 4 [ick] but I don't remember having any issues resizing windows with version 3.X - maybe the gnome project can borrow their window resize code?

[fermulator (fermulator)]

I concur with Jared.

Also running Jaunty and I've tried various themes for Gnome including "Human", "New Wave", "Dust", etc.

All of these themes have different border sizes, and for aesthetics, many themes have a very thin border (1 pix). When the border is so thin, it's extremely difficult to "naturally" move your mouse cursor over that 1 pixel thickness.

As per some discussion in the "New Wave" Gnome theme (https://bugs.launchpad.net/bugs/371833), you can customize the border width as follows:
I've edited my metacity-theme-1.xml (found in /usr/share/themes/New Wave/metacity-1) as follows:
<distance name="left_width" value="5"/>
<distance name="right_width" value="5"/>

Again though, forcing users to have a thicker border to make resizing windows natural isn't the correct solution. Having an "invisible" thicker resize area would work, or perhaps a "snap to" border edge when you're within 5 or 10 pixels of the border.

[fermulator (fermulator)]

NOTE: This bug also applies to compiz, would a fix to metacity transfer to compiz?

[Travis Watkins (amaranth)]

It depends on what the fix is. If the fix is to change the themes that would apply. A global setting for theme thickness or an invisible border would require changes in compiz to match.

[daniel (bocardo+u)]

PLease check the following bug:
https://bugs.edge.launchpad.net/hundredpapercuts/+bug/388160

It's quite possible that most of the troubles with resizing are in fact a manifestation of this bug.

[Alden (jason-alden-benoit)]

Maybe it contributes to some percieved issues, but the main issue for me is that I have high resolution monitor combined with a high DPI mouse, while trying to grab a 1 pixel wide border. My setup is for gaming (in Windows), but I like linux too.
-----Original Message-----
Date: Saturday, June 20, 2009 5:50:54 pm
To: <email address hidden>
From: "daniel" <email address hidden>
Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)

PLease check the following bug:
https://bugs.edge.launchpad.net/hundredpapercuts/+bug/388160

It's quite possible that most of the troubles with resizing are in fact
a manifestation of this bug.

--
Window Resize Difficult (Window Border Thickness)
https://bugs.launchpad.net/bugs/160311
You received this bug notification because you are a direct subscriber
of the bug.

[daniel (bocardo+u)]

Would it be possible to have a different border size depending on the display's DPI? That would help in this issue without using too much space on smaller screens.

[Alden (jason-alden-benoit)]

The ideal solution would indeed need to do this. I get this bug in Compiz, but I feel it can affect anybody. Maybe the cursor can stick/jump to the border after x seconds? Possibly with added special "accessability" benefit?
-----Original Message-----
Date: Saturday, June 20, 2009 7:00:34 pm
To: <email address hidden>
From: "daniel" <email address hidden>
Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)

Would it be possible to have a different border size depending on the
display's DPI? That would help in this issue without using too much
space on smaller screens.

--
Window Resize Difficult (Window Border Thickness)
https://bugs.launchpad.net/bugs/160311
You received this bug notification because you are a direct subscriber
of the bug.

[daniel (bocardo+u)]

That is an excellent idea, I think I have seen something just like that once (can't remember where though). To enhance the usability of the resizing border it would just need to stick to the border for a couple pixels worth of movement, say 3~5. That would allow one to stop at the border easily without becoming too bothersome during normal use.

[Alden (jason-alden-benoit)]

Either 3 pixels farther out, or 5 across, whichever style lends to better "habits". This should be tested in my opinion to minimize possible side effects. I would be happy to test if needed.
-----Original Message-----
Date: Saturday, June 20, 2009 10:45:26 pm
To: <email address hidden>
From: "daniel" <email address hidden>
Subject: [Bug 160311] Re: Window Resize Difficult (Window Border Thickness)

That is an excellent idea, I think I have seen something just like that
once (can't remember where though). To enhance the usability of the
resizing border it would just need to stick to the border for a couple
pixels worth of movement, say 3~5. That would allow one to stop at the
border easily without becoming too bothersome during normal use.

--
Window Resize Difficult (Window Border Thickness)
https://bugs.launchpad.net/bugs/160311
You received this bug notification because you are a direct subscriber
of the bug.

[daniel (bocardo+u)]

By the way, one decent workaround is to select a theme which has a thick lower border, like the dust ones. That way you can use the lower corner to resize the sides as well.
Attached is a screenshot of the Appearance Preferences window with a modified dust theme I use.

[krona (krona-krona-deactivatedaccount)]

I agree this is a problem, especially with a laptop mousepad, I'm going to try to find as a theme with thicker left, right and bottom edges in the meantime :-(

[naesk (naesk)]

I've got to admit I do find the resizing of windows using the default theme a tad annoying, even more so when multiple windows are over lapped and when using the window autofocus setting.

[core (crkiii)]

I'm YEARS late this time.

Windows has the ability, but I never had to use it.
I recommend window border adjustment feature, pls.

I liked this one by <b>Troy James Sobotka</b> on 2007-11-14:
<i>It is relatively painless to change the dimensions of the surrounding border for themes... To change border widths, <b>simply</b> 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.</i>

Mucking. Plagued. Gnome.
Nice.

[fermulator (fermulator)]

So are we getting any closer to deciding an action to solve this problem?...

What daniel wrote on 2009-06-22 seems like a very good compromise. But, it's more of a "workaround" than a solution. If theme writers don't employ the "thick bottom border", then users still have to muck with it themselves.

An accessibility option sounds like a very good idea. Where if the user moves the mouse cursor +/- 0.15% of the border, the cursor would either "snap to border" or be "virtual border" allowing the user to click and then snap to border.

0.15% Because:
 * 1024x768 --> +/- 2 & 1 pixels
 * 1280x1024 --> +/- 2 & 2 pixels
 * 1680x1050 --> +/- 3 & 2 pixels

Right now I have my borders sized to "5 pixel" thickness on a 1680x1050 resolution. This is a good size IMO to easily grab the border when you need to, and it doesn't look too thick.

This allows a decent (but small enough to not be intrusive) desktop real estate area to be used for border catching. As resolution sizes increase, the number of pixels will also increase, scaling properly with the ever increasing resolution sizes.

Of course, this option in accessibility options should be enabled by default, but anyone who finds it "annoying" can disable it if they like. The reason it should be enabled by default is for the obvious reason that "normal" users won't know to go there to enable it. This is a "helpful" default behaviour to make window management easier.

[fermulator (fermulator)]

NOTE: We must ensure the calculation of 0.15% is of the xrandr output, NOT the Virtual desktop size!

[sebastian-s (sebastian-s)]

Although late I want to pin my name to the list of users who think that resizing windows by grabbing the (any) boarder does turn out the be impractical.
With a 1680x1050 native resolution in my notebook I had this problem since feisty.

I second that the resize handle should be independent of the visual boarder

[Martin Olsson (mnemo)]

I'm so glad you guys are working on fixing this. I've always had problems resizing windows in Ubuntu/GNOME.

[Dilomo (ankere)]

Just my opinion:

The borders should not be modified in the metacity xml file so that you could resize properly. We should not change the designers idea of theme and make it look ugly by making borders from 1px to 5-6px. We could not ask the Average Joe to do this by himself. He just wants to use his PC not configure it one week. The best ideas so far are:
 * making a transparent area that would ease users of large screens (Is it possible Thomas?)
 * make the pointer snap to the border

We could even combine these two and the result would be perfect.

[Neil Broadley (scaine)]

I love the idea of a transparent border, but I despite ANY snapping behaviour. Regardless, however, I'm not convinced that the work being undertaken as a paper-cut will include such complicated solutions. Rather, the patch Thomas submitted upstream, which includes a slider to determine border thickness would seem to be a nice stop-gap solution until a transparent (and/or snap) solution can be implemented.

[Dilomo (ankere)]

I see that this is the only solution but that will harm a lot of themes including mine that has created the window border design for one pixel width. The only winners would be the very generic themes that nobody wants to use anymore, imo.

I suspect all the new changes will come in Mutter and Gnome 3.0 so we should not expect much in the upcoming year about fixing this right now.

[Neil Broadley (scaine)]

Well, the way I understand it is that Thomas' patch doesn't actually change the theme border thickness? It just adds a slider to the theme customisation controls so that those who want a larger border can drag up the width. No "losers" that I can see. I just don't think that there's been any movement upstream on this, so I don't know if Thomas' bug can be applied directly to Ubuntu.

[fermulator (fermulator)]

So there are two separate issues here now:
 1. Border thickness (Thomas' patch)
    --- This introduction of a slider is a great idea. It gives the user some GUI control of his/her theme in GNOME. I think it's certainly a nice perk, and is yet another form of control given to the user via the GUI instead of modifying the XML file. This inadvertently provides an easier workaround for window resizing, but does not solve the underlying problem.
 2. Border resize can be difficult with a "thin" border
    --- So here we have the scenario that if a user wants thin borders (or has chosen a theme with thin borders) for aesthetic reasons, then resizing his/her windows can be difficult. The difficulty to grab 1px of the screen is linearly proportional to the ever increasing resolution sizes on desktop monitors. Two ideas/solutions have been proposed:
    A) Virtual Border -- This would have to be user controllable, float. If the user is using a thick border, they probably would want to disable this, but if the user is using a thin border (1px for example), then they should be able to control the percentage of "virtual border area" +/- around the borders. As I stated previously (https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/160311/comments/82), a good default is 0.15% for this value.
   B) Snap to Border -- This would also have to be user controllable, boolean. Disable/Enable. As some users have pointed out, some people will hate this behaviour, while others might find it useful. Snap to Border would be mutually exclusive to Virtual Border, but follow a similar implementation. If the user is within said 0.15% (user configurable), the cursor would "snap" to the actual border.

[James Schriver (dashua)]

Please test this theme I'm working on and see if the usablility is easier to resize on the right and left edges as well as the bottom. I will port this metacity over to a more human feel, but for testing purposes I have modded the Impression metacity. Let me know what you all think of this. If this works, I will work on porting over the changed to the Human theme.

[Martin (onjvx0z02)]

Right now you resize a window by finding the few pixels on the border that
allow you to drag the window.

I propose that the title bar have resize buttons for vertical, horizontal and
diagonal resize.

+---+---+---+--------------------------------+---+---+---+
| H | D | V | Window Title | _ | - | x |
+---+---+---+--------------------------------+---+---+---+

H = Horizontal resize
D = Diagonal resize
V = Vertical resize

Holding down left mouse button on these buttons and moving the mouse resizes.

[Martin (onjvx0z02)]

It should have look like this =)

+---+---+---+--------------------------------+---+---+---+
| H | D | V | ........ Window Title ........ | _ | - | x |
+---+---+---+--------------------------------+---+---+---+

Alternatively just one resize button?

+---+----------------------------------------+---+---+---+
| R | ................ Window Title ........ | _ | - | x |
+---+----------------------------------------+---+---+---+

Some programs, like Pidgin, doesn't have a status bar, so having resize in the title would resize all programs easy.

[daniel (bocardo+u)]

an alternative to the border snapping behavior could be border resistance (see xfce for an example of this, one of the tweaks allows to change this) It could even be presented together with snapping and selectable with a radio button.

[fermulator (fermulator)]

Interesting idea Martin.

This is just IMHO, but personally I don't see much value in a "resize" (or HDV) button. The same "Resize" (R) button is in the "top left hand corner" button (i don't' know what it's called) on most windows. Also, the usability of the "Resize" in that menu is functional at best ... it's not very intuitive for me.

I guess I don't really think it addresses the problem at hand -- it just makes the existing "Resize" feature one less click away.

[pfrenssen (pieter-frenssen)]

I would prefer invisible drag handles at the insides of the window.

[Kevin Jadin (marcspitz)]

I'm one of those who find window resizing a relatively difficult task on Gnome. The resizing areas are the actual themes border's size.

I think that there should be an optional transparent resizing zone when necessary.
There should be a changeable default size option that would let us adapt this transparent border accordingly to the actual's themes one.

Here's how I think this should be implemented :
AdditionalTransparentBordersSize = DefaultWishedSize - ActualThemesBordersSize and number must be positive only. So that if the themes border is already large enough, the transparent border's size would reduce or even be non-existent.

ex : We would like a constant border's size of 5 px. Given our theme has 3 px large borders. Additional transparent border should be 5-3=2 px.

I really dont know how this could be implemented... It sounds dumb to me as I doubt being the only one thinking about such a solution.

But let's hope it helps...

[Lawren Quigley-Jones (lawrenqj)]

I just switched my theme to "Dust Sand" in karmic and had trouble catching the very slim border to resize windows. It looks like it only has one or two pixels of border. I reverted to human which I'm more used to and it's fine for me.

It seems like there is a better solution here than requiring themes to have large borders, as the thin borders do look nice. I like the idea of expanding the catchable portion of the border, but it might get in the way when you try to select text near the border. Maybe it would be possible to make the border sticky to your mouse like when you move a window to the edge of the screen with compiz enabled.

What I'm doing 99% of the time is widening a terminal window or web browser in order to view wrapped text. it would solve my specific problem to make the entire area of the vertical scroll bar drag-able. When you moved up and down you would move the scroller as usual, and when you drag to the right you would expand the window. Again you could make that action sticky so you don't accidentally resize it when your scrolling.

[Matthew Woerly (nattgew)]

I really like the idea of making the scroll bar resize the window. That would definitely make things more usable. Like you said, though, it should be sticky... preferably quite sticky... because a lot of times especially with my touchpad I get sloppy when scrolling with the bar.

[Manuel R. Ciosici (manuelciosici-deactivatedaccount)]

It's almost impossible for me to resize a window when using the trackpad on my laptop.

[Mistofelees (ptmusta)]

IT IS A BUG !
No use to blame the themes. There should be a resizable border with it's own colour around any window no matter what is the theme.

It is a nuisance as well in large monitors as in small laptops with touchpads.

[vdbergh (michel-vandenbergh)]

Sorry for the spam but I would like to add that this is definitely a problem. I just got a new laptop with a 1600x1000 resolution and resizing windows has become very frustrating.

[Marcus Carlson (0-launchpad-mejlamej-nu)]

Not a fix or anything but i almost always use the alt + middle click to resize windows.

[daniel (bocardo+u)]

In response to Marcus
Actually, there should be something to teach about both that and the alt + primary click to drag feature. They are truly useful, yet many don't know about them. I always miss the dragging one when using MS Windows. Maybe there could be a video to teach new users.

[Alden (jason-alden-benoit)]

@Marcus Carlson - I believe that resizing technique while helpful (what I end up doing when having trouble myself) is specific to Compiz. I guess those without good enough hardware would likely be running XFCE instead of Gnome though.

@daniel - I agree, "video" tutorials could be helpful. Something to assist those (like I was) trying this new Linux thing on their own instead of fumbling through it all and getting discouraged. But we are now getting off-topic. Perhaps you would like to post that idea to the Ubuntu forums where it would get more eyes and ideas on it...

[latimerio (fomember)]

How can a bug like this with so many responses be undecided or low in priority?
Usability is a key factor in modern systems and can not be rated high enough.
With usability I mean pure pragmatic ergonomics, not animations or themes which are merely design which can be argued about.
Usability tests comprise of things like
 * number of clicks to perform a task,
 * mouse movements required
 * hit and miss clicks
 * eye movements required to find the next step in a workflow
  etc.
Usabiltiy is fairly easy to count and meter and to build a testbed for.
When I look a the plethora of themes, color and background settings it seems to me though that ergonomics do not have enough charme for most developers.

[Allan Caeg (allancaeg)]

Big +1

Imagine how many times each day you try to grab window borders and fail.

On Thursday, 10 December, 2009 05:58 PM, latimerio wrote:
> How can a bug like this with so many responses be undecided or low in priority?
> Usability is a key factor in modern systems and can not be rated high enough.
> With usability I mean pure pragmatic ergonomics, not animations or themes which are merely design which can be argued about.
> Usability tests comprise of things like
> * number of clicks to perform a task,
> * mouse movements required
> * hit and miss clicks
> * eye movements required to find the next step in a workflow
> etc.
> Usabiltiy is fairly easy to count and meter and to build a testbed for.
> When I look a the plethora of themes, color and background settings it seems to me though that ergonomics do not have enough charme for most developers.
>
>

[David N. Welton (davidnwelton)]

As laptop resolutions increase (I just got a new dell that's 1900x1200), this problem is only going to get worse, especially working with fiddly trackpads that aren't as precise as mice.

I don't really care about changing the entire theme - the default one is nice - I just want a slightly larger border or some other mechanism that makes click/drag resizing work better.

[gidantribal (aedo999)]

I agree with David. resize shall be theme-independent, maybe even border-width independent. And with my Acer 6920G it's a so painful issue! Imagine a 1920x1080 f-hd resolution in 16 inches... i can only use workarounds to resize windows without swearing!!!

[gidantribal (aedo999)]

and i also agree with @latimerio:
this bug is a huge usability issue. and we all know Ubuntu's interest in usability.

[Oliver Joos (oliver-joos)]

I deeply agree! Perhaps I go and buy one of those 10000dpi gamer mice as workaround ...

[imclean (ipxdesign)]

Just want to register my agreement with those who think this a major usability issue.
While the right click - resize method is a work around, it is one that the majority of users will never find. (I didn't until I read it here). It is also slow and clumsy.
The precision required to select the edge of the window on my 24" 1920x1200 screen is probably in the order of 100 microns movement of my mouse.
I frequently have to move my mouse infintesimally side to side several times before being able to select the edge of a window.
It drives me crazy.
I consider it the biggest interface problem I have encountered in Gnome,just ahead of the broken autohide function on panels.

[Clint Grimsley (oxygen-addict)]

Holding the alt key while using the middle mouse button seems to be the
best way to resize windows.

I agree, tis a pain to try and resize from the edge of a window.

On Fri, 2010-02-19 at 05:42 +0000, imclean wrote:
> Just want to register my agreement with those who think this a major usability issue.
> While the right click - resize method is a work around, it is one that the majority of users will never find. (I didn't until I read it here). It is also slow and clumsy.
> The precision required to select the edge of the window on my 24" 1920x1200 screen is probably in the order of 100 microns movement of my mouse.
> I frequently have to move my mouse infintesimally side to side several times before being able to select the edge of a window.
> It drives me crazy.
> I consider it the biggest interface problem I have encountered in Gnome,just ahead of the broken autohide function on panels.
>

[Alden (jason-alden-benoit)]

  As Siegfried Gevatter first replied "I don't think most users have a problem with that." I have to say that has been shown to now be an issue for many. This is a severe issue in that anyone hampered by it will be hit early on in their experience, and have such a high degree of getting turned off by Ubuntu that they will most likely not bother to file a bug report on their way on/back to another OS. If you can't easily move windows around then you will not use Ubuntu, period. You are downright less productive, besides annoyed.

 Now some of us have been lucky with first experiences on another PC, or just decided perhaps there must be a setting or workaround. But let me assure you that ALT-Middleclick is not obvious (but great feature!), and dragging a window edge is the expected fail-safe since likely the dawn of a resizeable "window". Also, on my laptop I do not have a middle click, and pressing both buttons doesn't work or is too hard. The cursor shakes from my fingertip rolling on the touchpad and while not as bad, it is a bit of an inconvenience hitting the target as it has been on my high resolution desktop.

 In short, this affects many, and turns off many more to Ubuntu. This really needs to be fixed before Lucid, as I had hoped with Karmic, since waiting another 6 months is really killing who knows how many potential users. There is nothing like showing off this slick, new, fast and secure OS and then I can't move the window, right when I had my friend hooked. I almost hear the sad losing sound from the Price is Right! Dun da da duuhhhh, DUUUUUUNNNNNNN!!!! Their faces go from :) to ,:| .

 If anything, I hope I have been constructive in getting the needed attention to this highly underrated issue, for the future of Ubuntu.

[Alexander (asid-mail)]

Just wanted to add that I'd like to leave my windows without titles and borders to use desktop space more efficiently. I do need bigger area around windows sides/ends allowing me to change windows size. As I understand this is what users are asking for, and it can't resolved by adding bigger window borders or some buttons in window title.
Also wondering why desktop oriented Linux distribution ignores this really annoying problem.

[mannheim (kronheim)]

The new Radiance and Ambiance metacity themes in Lucid have left and right border widths of just 1 pixel. (This is different from the default Human metacity theme in earlier versions of Ubuntu, where the width is 3 pixels.) This issue makes Radiance and Ambiance very difficult to use for anyone who is used to resizing windows from the edge.

[Oliver Joos (oliver-joos)]

53 people affected, +3 duplicates, heat=326. Please consider raising importance to Medium at least (especially for OneHundredPaperCuts).

As stated in comment 116 the upcoming light-themes won't shine, if this bug makes it into Lucid.

[gidantribal (aedo999)]

it's still a pain. why didn't they solve this issue? ppl should switch to windows 7 to have a working gui??

[Neil Broadley (scaine)]

Woah! I wouldn't go /that/ far! But at least you'd be able to resize windows, eh? :-)

If you don't change your theme much, I recommend following the instructions I posted way back in comment 58 (https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/160311/comments/58).

It's clunky and manual, but it works and results in a usable theme regardless of which one you choose. And with Lucid in interface freeze, this isn't getting fixed for another 6 months now.

[Mike Durham (mdurhamesq)]

The border is way too thin. Resizing is a very hit and miss affair, this is pathetic.

[Rob Speer (rspeer)]

Does an interface freeze really mean that an obvious bug in the interface has to fester for six more months? Nobody's suggesting changing what the interface looks like (well, not in *this* bug report), just how it acts.

This is a *huge* problem in Ambiance now that the resize target is only a single pixel out of thousands.

[Chris Kenyon (chriskenyon)]

Can someone update the summary of this bug - there is alot of valuable information in the comments that is not reflected in the summary

- 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

[Paddy Launch (paddylaunch-deactivatedaccount)]

On Tue, Mar 30, 2010 at 10:51:26AM -0000, Chris Kenyon wrote:
>
> - The issue appears to have been significantly aggravated in Lucid
> by changing the border width from 3 pixels to 1 pixel

I have to say I've only noticed this problem first with Lucid - I was
happy with the border width on Intrepid. 1 pixel is VERY difficult to
grab in a hurry! I think the problem is perhaps exacerbated for those
of us who have "focus follows mouse" set.

[Chris Kenyon (chriskenyon)]

Just noted that I could have updated the summary. Chris hides head in shame :-)

[dsa42 (davidangulojunk)]

This is VERY annoying and makes use of Ubuntu EXTREMELY difficult. Please fix this.

three comments:

1. you are wrong (Sigfried) when you say that you "don't think that that most users have any problem with" this. We do. Most users just don't know how to report problems.

2. it is disingenuous when you try to blame themes. We end users _do_not_care_ where the problem is. We just want it fixed.

3. In 2005, the original reporter said it had been an issue for years, and it is still not fixed FIVE YEARS LATER.

[krona (krona-krona-deactivatedaccount)]

dsa42

I've got to agree with you. The result of triage showing that this problem has been classified as low shows the Ubuntu team do not really understand how they should proceed to get Linux on the desktop. There is no (or little) commercial pressure for new features, but there should be pressure to ensure that first time users have as little bother as possible with the *basics* like being able to easily position a mouse pointer over a window edge!

One of the first things I noticed when using Ubuntu on my laptop was the thin window borders for manipulation with the mouse. Since I'm an experienced PC user I switched to a Vista style theme, which has the same sized borders as Vista, but the average user is not going to do this, they'll probably just get frustrated, tell other people about the experience, and switch back to Windows.

By all accounts the latest version of Ubuntu makes this problem even *worse*?

If you can't patch or configure the window manager to have 'virtual' borders of at *least* 5 pixels or even better some resolution independent size than you should use a theme that has physical borders of a decent size, and really that's all there is to it.

[Matthew Woerly (nattgew)]

This has been around since before the last LTS and has only gotten worse since then? This is another example of an Ubuntu default with a significant usability issue that has been around for some time. Workarounds are good, but for something as basic and common as being able to resize windows, this seems like a pretty big issue.

[Ricardo Pérez López (ricardo)]

The problem is even worse using Ambiance and Radiance themes, because there's no window menu in the title bar, so the user can't select the "Resize" option easily. The user must know that right-clicking on the window title opens the window menu, which it's very unevident.

[J.A. Sully (justin-sully)]

i have been meaning to ask about this for years. this is among the most annoying failures of ubuntu desktop. what it needs is an invisible border surrounding the visible border that is grab-able, but that doesn't screw up the cleanness of the themes effected by this issue...if that makes sense. can't this just be added to the gconf-editor as an option? a similar option exists for the gnome-panel when in auto-hide, i think. i sort of can't believe this has been bothering me for so long and i've not mentioned it anywhere until now...i suppose i always imagined that such a obvious problem couldn't be widespread or it would have been fixed by now.

please please fix this. thanks!

[Uroš Gaber (uros-gaber)]

Will it be corrected in ubuntu 10.04?

[Gaspard Leon (gaspard.leon)]

@Uroš Gaber

No... should be fixed around 2015 or so

[Mark Lukens (marcus-21)]

I agree with the (MANY) others saying that this is a major problem. I would also mention the "tip of the iceberg" effect -- for every person that goes to the trouble to figure out how and where to complain and does so, there are at least 100 that either assume complaining won't work (and they seem to have a point...), can't figure out how or where to complain, just complain to a friend, stick to Windows, or etc. I have been bugged by this for several years, myself, but am only now going to the trouble to add my voice to the crowd.

I also have a question/possible suggestion for helping to solve the problem: would it be possible to change the way the mouse responds, instead of changing the themes/borders/etc? I agree that really thick borders look unsightly, and it appears that 'invisible' border extensions would be difficult to implement (otherwise they would have already implemented this suggestion). How about, then, changing the mouse pointer so that it has a larger 'hot spot' or the system will recognize the pointer as selecting a border even if it is 3-4 pixels away, instead of requiring it to be within the border? I believe that Windows does something like this, and even allows the 'tolerance' to be adjusted to suit individual users. The 'drag & drop' tolerance (and by extension, the 'grab a window border' tolerance) can be adjusted with a slider so that if you are getting older and have less steady hands, or have your mouse speed cranked up, etc., you can adjust the slider accordingly, making it easier not only to resize windows, but to grab and drag icons, text, etc. Would this be practical to do in Ubuntu? If so, would it be easier to implement, and be a solution people would want?

I'm just putting it forth as a suggestion because there seems to have been little progress for a number of years on this issue, and it is driving me crazy. I just got a new, high-resolution monitor which is making it even worse. What does everyone think?

[John Morris (john-kirsta)]

Just upgraded to Lynx, and this became an issue for me (theme changes)? It's one of those nobody notices when it works, really annoying when it doesn't things.

[The Fiddler (stapostol)]

This bug has become unbelievably frustrating in Lucid/Radiance/Ambiance, to the point where I have edited the theme definition to increase border size from 1 to 5 (diff attached). Yes, this introduces visual glitches, but glitches are vastly preferable to not being able to resize windows using a touchpad.

Can we please have a proper fix to this issue? This is a *real* usability problem, not just a minor "papercut". Steps to reproduce:

1. Install Lucid on a laptop.
2. Remove your mouse.
3. Try to grab a window edge to resize.

Step 3 is way, *way* too difficult to perform reliably.

[SegFault (segfaultmaker)]

I join my voice to this bug. I'm a using a 24" display at 1920x1200.
It's very unpleasant when I want to resize window. I used the tricks to edit theme file and add border... It show a ugly side grip, but i'm happy to have them.

The initial suggestion of "invisible grip area larger than visible border" seems very good to me.

Note: I tried KDE, XFCE and Windows 7, but only gnome/ubuntu desktop let me feel as uncomfortable with window sizing, in default configuration. It's, to my mind, a *really* urgent usability issue.

[Alan Lord (theopensourcerer)]

This is quite annoying. More so even that the missing tooltips!

I've a 2048x1152 23" monitor and grabbing the edge of windows in Lucid + Ambiance is very tricky indeed. I didn't have this problem on Karmic, so for me this is a regression.

I am amazed frankly that this got through QA as it will badly affect many users - especially those with low-resolution mice, touchpads or shaky hands.

[saurabh (faplap)]

Seriously, why even bother having resizable windows? If you're going to make it this annoying/difficult to resize windows, you might as well disable it entirely.

[David Siegel (djsiegel-deactivatedaccount)]

We will be discussing this bug and a solution for it at Ubuntu
Developer Summit next week. Please save your breath, we know it's high
priority and we are going to fix it!

[Melroy van den Berg (webmaster-web-share)]

Clem has a good alternative in the mainwhile:
press "Alt" on the keyboard while pressing the middle click on the mouse to resize the window

[The Fiddler (stapostol)]

Please don't let this workaround dilute the need for a real solution. It is very awkward to perform on laptops touchpads, where you have to press alt+ left click + right click + move a finger on the touchpad surface at the same time.

[Melroy van den Berg (webmaster-web-share)]

Haha so true ><

[Nigel Babu (nigelbabu)]

Thank you for your patch, based on you comments I feel this patch can be improved to a better fix. As per the policy of the Ubuntu Review Team, I'm marking this patch as patch-needswork, please feel free to change to a patch tag when you have a patch ready to be integrated into upstream and/or Ubuntu.

[The Fiddler (stapostol)]

I won't be working on this patch anymore, as I consider it good enough for my needs. If someone familiar with metacity theming wishes to take a look, check the attached image for the artifacts caused by the aforementioned patch: in short, the area left of the "File" menu should be dark instead of light.

After a few of using this modification, this is the only negative thing I have noticed. Everything else seems to work as expected (windows become much easier to resize with this patch applied).

[Guido I (guidoweb)]

@Marcus Carlson, daniel, mcphargus, Alden, Melroy van den Berg, The Fiddler

I agree with you that Alt+click is just a workaround, not a solution, but at least for me it's a really effective workaround.
I almost never bother with window borders or grippies, because I got so used to Alt+Clicking anywhere in the window to move or resize. I really miss that feature when I have to deal with MS Windows.
Some kind of tip or video showing these kinds of features would be great

@The Fiddler,
I am indeed on a laptop, and I too, find it very difficult to press alt + both touchpad buttons + swipe finger on pad.
But clicking just one button (left button to move window, for example) is much easier, and that's what I use all the time.
I've posted a patch in compiz bug #207065 to make windows resizeable with just alt+right click, which makes this feature much more accesible in laptops.
It's been accepted upstream, and fix will be included in compiz 0.9 - i believe that will alleviate many frustrated laptop users trying to resize their windows, that will no longer have to aim for window borders, or entangle fingers by clicking both touchpad buttons ;)

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/207065

[Bigal-sa (bigal-rsa)]

Very irritating bug, especially when working with a smaller touchpad on a netbook.

[Melroy van den Berg (webmaster-web-share)]

@Bigal-sa
It really is, not only on a small touchpad, but even with my mouse :S

Will there soon be an update, from the Update Manager?

[richard (richard-e-morton)]

I have 5 PCs with Lucid installed
 - Thinkpad T41 12"monitor @ 1024x768 predominantly used by kb/touchpad
 - Thinkpad T60 12"monitor @ 1024x768 predominantly used by kb/touchpad
 - Desktop/Server running MythTV back&frontend with secondary 14" monitor @ 1024x768 for administration using keyboard and mouse & PS3 remote for mythcontrol
 - Desktop running MythTV frontend with 14" monitor @ 1024x768 using keyboard and mouse for Myth and administration
 - Desktop running MythTV frontend with 24" monitor @ 1920x1200 using keyboard and trackball for Myth and administration

I have issues grabbing window borders on all these systems and have had similar issues for several releases. I am getting fed up with it as often it is a real distraction from the work you are trying to complete if you have to concentrate on re-sizing a window... it is not currently something which can be completed as a second-nature activity... you have to concentrate on it... Even when grabbing the handle in the bottom left corner. These handle hot-spots need to be made larger; even if they are not drawn larger on screen

[richard (richard-e-morton)]

I am using Chromium and that has a border hot-spot area of 4 pixels across, starting at the edge of the window and continuing outside of the application by a further 3 pixesl (on my 1024x768 monitor).

[KenC (chr-j1)]

@richard

 I did not find Chromium, but I saw 'MetaGrip by Sergio Tocalini Joerg' in the Themes/WindowBorders at art.gnome.org/themes/metacity?page=1

I took the word 'grip' in the title as a hint, and it does seem to have wider borders. Seems much better as a work-around at least.

And I'll add to the chorus, this needs to be resolved in the default distribution. All the great things that Ubuntu/Linux have to offer can get blown away if a new user can't easily do a simple hundreds-of-times-a-day operation like re-size a window.

[zEn (der-eremit)]

the only working "fix" i found so far is installing shiki-colors; they have an extra setting for window borders:
"easy-metacity" which uses thicker borders.

I'd also like to add that from the people i could convince to switch to ubuntu (> 25 so far) almost everyone mentioned that this is really annoying .

[Melroy van den Berg (webmaster-web-share)]

My idea was, in instead of making the border size thicker (which looks less beautiful), you can of source set a kinda of "offset" where you can resize your window and where not.

Hopefully you can use this...

[The Fiddler (stapostol)]

I wouldn't call a thicker border less beautiful. In fact, I have tried increasing the border size in the Ambiance theme and quite like the result from both an aesthetic and a usability standpoint. (The only downside is a minor artifact around the menus, but I'm sure an official solution would be able to solve this).

Was this discussed in Ubuntu Developer Summit last month? Was a decision reached? Can we expect a fix for Lynx or should we just use a different theme?

Come on guys, the silence is deafening!

[Martin Visser (martinvisser99)]

So we are now around 5 weeks since UDS, when this bug was slated to be discussed, but still no fix is apparent. It does almost make using a touchpad equipped notebook (with 2 buttons) unusable. 3 times out of 5 attempts you will mistime your click usually either resulting in a non-event or worse, changing focus to the window underneath, popping it up. Who knows what error you will then make, having a window popup that you didn't expect and then maybe issuing a second click to that one causing all sorts of mayhem. Please, please issue a proper fix.

[Dominik Geyer (datag)]

Even on a normal desktop system I always manage it to grab the wrong window. 1px is ... well, only 1 Pixel for grabbing. One slight movement and you'll click into empty space or grab the wrong window (or even accidently click a button of another window in background). I usually use ALT-click to resize windows, but sometimes I have my hands off the keyboard, so resizing with mouse-only is really annoying.

[Melroy van den Berg (webmaster-web-share)]

@Dominik

I just make a quick patch, see attachment.

Place this *.xml file in:
/usr/share/themes/Shiki-Colors-Metacity/metacity-1

Tt's located in usr/share, so try in terminal:
sudo nautilus
...to have root access to that folder above.

Just select your 'Shiki-Wise' theme with the windowborder 'Shiki-Colors-Metacity'.
You can reselect it to make it work or just reboot.

Again this is a temporary patch.

Kind regards,
Melroy van den berg

[saurabh (faplap)]

This is only one of many problems with this theme; what came out of the discussion?

[fermulator (fermulator)]

@ Melroy van den Berg
[QUOTE]
Clem has a good alternative in the mainwhile:
press "Alt" on the keyboard while pressing the middle click on the mouse to resize the window
[/QUOTE]

This workaround doesn't work on terminal windows (or anything that happens to have an editable text field if you're mouse is over it it wants to quickpaste text instead of resize. heh.)

[fermulator (fermulator)]

@ David Siegel,
[QUOTE]
We will be discussing this bug and a solution for it at Ubuntu
Developer Summit next week. Please save your breath, we know it's high
priority and we are going to fix it!
[/QUOTE]

Indeed, a good question. Was there any verdict/action from the discussion? (willing to help test and such if needed)

[Michał Gołębiowski-Owczarek (mgol)]

@fermulator
What "terminal window" are You talking about? With gnome-terminal [Alt+Middle Click] works as described. I've also checked with gedit which has "editable text field" and it works correct, too.

I don't know where You see the problem.

[fermulator (fermulator)]

Interesting, it didn't work for me at all. The window would basically get "sent to background" behind other windows.

I had to apply the patch in https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/207065. Now, Alt+MiddleClick resize works on any window, and if I so choose, Alt+RightClick resize works on any window.

[Michał Gołębiowski-Owczarek (mgol)]

@fermulator
Well, maybe You don't use 10.04? I didn't think about before. This resizing functionality with an Alt key is working for me in Lucid.

[Oliver Joos (oliver-joos)]

Just tested it on Karmic (9.10): [Alt+Middle Click] works with gnome-terminal and gedit too.

@fermulator: I don't use Compiz. Perhaps it's a Compiz feature to reassign [Alt+Middle Click]?

[Michał Gołębiowski-Owczarek (mgol)]

I use Compiz but not with one of the two default set of settings so it may be it.

[Neil Broadley (scaine)]

There are lots of workarounds in the previous 163 comments, but this 3 year old bug doesn't need workarounds, it needs Ayatana members or others to address the issue before we reach a seventh release of Ubuntu without a fix.

[Neil Broadley (scaine)]

For reference, Ayatana are actually discussing this right now.
https://lists.launchpad.net/ayatana/msg03040.html

As usual, the Ayatana team take a particularly high-level view of issues like this, so instead of discussing how to implement borders that can actually be dragged without ninja-like precision, they are instead discussing why we need to re-size in the first place and wouldn't it be a far better solution if you never had to resize a window...

Still, this might help alleviate the frustration felt by subscribers to this bug - knowing that's it's well known, understood and someone out there cares.

[Marcus Carlson (0-launchpad-mejlamej-nu)]

Compiz 0.9.0 did mention a plugin that would change the resize area of a window.

From http://lists.freedesktop.org/archives/compiz/2010-July/003429.html

* Added edge support to grid plugin so windows can easily be resized by dragging
  to an edge or corner

Could that help?

[Melroy van den Berg (webmaster-web-share)]

I think we should try that indeed!

[mr_step (step-step)]

This bug is excruciating. This is the only thing that is seriously making me consider switching back to mac or windows.

I don't like having to reach for alt, and middle click to perform an exceptionally basic function of a point and click OS. It's not that there aren't alternatives, keyboard short cuts etc. It's that the way I want to resize a window doesn't work.

Perhaps if the mouse just detected "you're within 10 pixels of a window corner, would you like to resize", and showed the resize icon at that point. It could resize the window regardless of if you clicked on it/in it. You don't need to change the visual of the windows, it allows flexibility for different themes. Surely it could just be done in the window manager?

How often do you ever find yourself clicking near the corner of a window when you aren't intending to resize? How often do you find yourself mousing around a corner trying to find that sweet spot where you can resize?

We just need a big fat target (and a dynamically changing cursor would solve that). What happens when our "cursor" is our big fat finger on our new shiny ubuntu tablet? Tablet hardware is set to take off this year, and it's all going to be touch only. This issue will be worse on a touch screen.

Please... whoever has the skills. Help us obiwan kenobi... you're our only hope....

[Melroy van den Berg (webmaster-web-share)]

@mr_step
I totally agree with you!

In the meanwhile you can try my path:
https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/160311/comments/155

But Obiwan need to help us indeed...

[Melroy van den Berg (webmaster-web-share)]

This bug also effects Linux Mint (and Mint Theme's):
https://bugs.launchpad.net/linuxmint

Can somebody please add & confirm this? Thanks.

[Doug Schultz (doug-schultz-mozy)]

Okay, I've read a lot of the comments... here's my 2 cents.

Don't change themes or look and feel. Don't even change how the windows work. (for this problem)

This isn't an issue with resizing windows, it's not an issue with themes. The look and feel is fine and dandy.

What would be nice is a NEW FEATURE. One that is configurable through System Preferences...

Create a configurable (visible/invisible) border around the themed border of a window. Something that doesn't even overlap the window but rather on the outside. Allow the System to tell the window to resize if that feature is turned on.

Think about it... if the window is maximized, this region lies outside the window and is unreachable. It's only something that would be noticed or needed in a non-maximized - non-minimized state. It would allow me to click in a configurable region of space NEAR the border of the window rather than accidentally click off the one pixel border of the window and activate a window sitting behind the window I was attempting to work with... (Personally, I think that's the most annoying part of this problem.)

The other annoying part of the problem is I have to slow down, use surgical precision to make sure I'm on the 1 pixel border, click carefully so I don't accidentally move my mouse off the pixel during the click, then I'm free to move the window, but I'm already in slow mode. (so something that should take 1 second, takes 5-10 seconds -- even more if you miss-click)

And whether or not you consider this a high priority or not, it certainly is a pain and a usability factor. And it's INDEPENDENT of themes.

It's a global system feature that should be configurable... let the window manager tell the window to resize because the user told the window manager it wanted to resize the window by clicking a potentially invisible border as fat as the user wants to make it.

That's my 2 cents. (I get that there are other ways to resize windows... I get that there are work-arounds... I get that some people don't want to create a new feature because of the work involved... And I also get people don't want to modify look and feel of their themes.) So, I think a new global system-wide feature is the correct way to approach this. (And I'm not volunteering to do this...)

But as a new user to linux/ubuntu/gnome or whatever this is about... I'd love to be able to easily click near the edge of a window to resize it.

[Melroy van den Berg (webmaster-web-share)]

@Doug Schultz
I totally agree with you!

So who is going to fix this issue, I don't see any improvements so far nor updates, just nothing?

[Doug Schultz (doug-schultz-mozy)]

Since I'm new to linux, I asked someone who's more season'd if there are any plugins or tools for window resizing... he wasn't aware of anything... So I asked him... how would someone do it... he said you could write a compiz plugin to do it.

[Doug Schultz (doug-schultz-mozy)]

So, I downloaded compiz-config-manager and compiz... it looks like it would be a great addition to either window management or accessibility. Either as a new feature to window resizing or as a new standalone plugin... People with linux GUI design experience should be able to make a good decision about where to put a new feature like this. So, basically it would allow us to resize without using super keys by having an "imaginary" region around the window that allows us to resize it by normal mouse click and drag operations when not over the "official" border of the window.

[Garden Brooks (sbach)]

agree with Scaine (on 2007-11-13: #2): "Resizing windows is cumbersome, frustrating and far too easy to get wrong."

For me, a border/corner click will show the resize icon, then many times stop that operation and switch focus to the window underneath--very annoying. :( It's as if the resize operation has a loose screw.

I don't know GTK, but, from an xlib POV, I imagine one place to look would be in the routine(s) that call XGrabPointer() and perhaps change the "owner_events" argument to False...my 2-cent shot-in-the-dark FWIW.

[Jan Bakuwel (jan-bakuwel-gmail)]

I was wondering why I felt strain in my muscles, then engaged the brain, then discovered this thread :-)
Making the border thicker obviously has undesirable optical effects.
IMHO resizing of windows should always be comfortable and intuitive (Microsoft can do it, can't Ubuntu/Gnome/Metacity??).

[Kai Tamkun (ktamkun)]

Jan, I don't think the border needs to be visually thicker, just the
"invisible" one.

On Thu, Sep 2, 2010 at 5:08 PM, Jan Bakuwel <email address hidden>wrote:

> I was wondering why I felt strain in my muscles, then engaged the brain,
> then discovered this thread :-)
> Making the border thicker obviously has undesirable optical effects.
> IMHO resizing of windows should always be comfortable and intuitive
> (Microsoft can do it, can't Ubuntu/Gnome/Metacity??).
>
> --
> Resizing windows by grabbing window borders is difficult
> https://bugs.launchpad.net/bugs/160311
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Ayatana Design: Confirmed
> Status in One Hundred Paper Cuts: Triaged
> Status in The Metacity Window Manager: In Progress
> Status in “human-gtk-theme” package in Ubuntu: Invalid
> Status in “light-themes” package in Ubuntu: Triaged
> Status in “metacity” package in Ubuntu: Triaged
>
> Bug description:
> 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).
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ayatana-design/+bug/160311/+subscribe
>

--
READ CAREFULLY. By accepting this email into your inbox you agree, on behalf
of your employer, to release me from all obligations and waivers arising
from any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
non-compete and acceptable use policies (“BOGUS AGREEMENTS”) that I have
entered into with your employer, its partners, licensors, agents and
assigns, in perpetuity, without prejudice to my ongoing rights and
privileges. You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

[The Fiddler (stapostol)]

This is still a bug in 10.10 beta-1, unbelievable! Who must we bribe to fix this bug? Or at least review the patch I posted four months ago?

Excuse me for the tone but this is pretty basic stuff. The bug has been reported, patches proposed, what else does it take?

[Dylan McCall (dylanmccall)]

It would be helpful to know what is wrong with the current approach, which has changed considerably from two years ago. The default themes now have a _considerably large_ hotspot for resizing on all four corners of every window. From my perspective, this problem feels like it's solved (though there is a slight learning curve for those coming from Windows).

So, why is that solution insufficient?

[Michał Gołębiowski-Owczarek (mgol)]

@Dylan McCall
> The default themes now have a _considerably large_ hotspot for resizing on all four corners
> of every window.

No, they're not. I checked in gnome-terminal and slightly moving up the mouse pointer from bottom-right corner makes it lose the ability to resize the window.

Besides, if You don't want people to resize by clicking on borders and moving, disable it completely and adapt OS X method here. The current behaviour is unacceptable.

[The Fiddler (stapostol)]

Agree ith Michał. Additionally, the bottom-left corner does not offer an enlarged resize grip.

The current Maverick approach feels rather awkward: ~8x8 resize grips on three out of four corners and 1px resize grips on window edges. Contrast with Dust theme, which may be ugly but gets the right/left resize edges right (but still fails on top/bottom).

My personal preference (which I have patched Ambiance/Radiance with) is to use a uniform 5px resize border, plus the default 15x15(?) resize grip on the bottom-right corner. Works reliably regardless of input method (mouse, touchpad) and system load (try resizing the installer window on Maverick in VirtualBox. Fun, no?)

[Jan Bakuwel (jan-bakuwel-gmail)]

Hi Dylan,

On 05/09/10 04:11, Dylan McCall wrote:
> It would be helpful to know what is wrong with the current approach,
> which has changed considerably from two years ago. The default themes
> now have a _considerably large_ hotspot for resizing on all four corners
> of every window. From my perspective, this problem feels like it's
> solved (though there is a slight learning curve for those coming from
> Windows).
>
> So, why is that solution insufficient?
>

What I think is wrong with the current approach is that it strains
peoples muscles unnecessarily in other words is rather uncomfortable to
use. IMHO it is counter intuitive to only be able to resize windows from
the edges (I for one often want to extend a window in one direction only).

If it can be done for the edges why not for the whole window?

My vote goes towards an invisible area in which the mouse pointer
changes shape (and snaps to the edge of the window if so required) that
remains usable also when high res screens are being used.

I don't understand why the issue needs debating? Haven't you tried to
resize windows with the mouse (not using the edges)? Please do 10
resizes on a high res screen and let us know how your arm feels afterwards!

Jan

PS I'm using the default "New Wave" theme.

[fermulator (fermulator)]

[QUOTE]
It would be helpful to know what is wrong with the current approach, which has changed considerably from two years ago. The default themes now have a _considerably large_ hotspot for resizing on all four corners of every window. From my perspective, this problem feels like it's solved (though there is a slight learning curve for those coming from Windows).

So, why is that solution insufficient?
[/QUOTE]

Hey Dylan,

I just tried using:
 * Ubuntu 10.04
 * Theme: Ambiance
 * terminal window and nautilus window

The corner hotspots are certainly helpful, however, I wouldn't call them "hotspots". With the ambiance theme, it looks like they tried to make things a little easier by increasing the BOTTOM BORDER width to ~5px(?). This gives the illusion of a hotspot, but if you try to increase the height of the window by using the bottom border, you'll realize that those "hotspots" are simply a byproduct of the thicker bottom border.

As everyone has already mentioned numerous times, this bug is a terrible UI bug. It shouldn't be "hard" to maneuver your mouse cursor over that tini tiny right/left border of 1px.

It's been a while since I've used Windows, so I fired up my Virtual WinXP. It would appear that they've simply opted for the "5px(?)" border size all around to ensure users can easily resize. (I don't feel like rebooting into Win7 to see how it is with the latest Windows)

Perhaps, the solution for Ubuntu Linux, would be to force all themes to have a 5px theme (by default). If the user is a aesthetic/power user, then they can change the border size themselves, then suffer through difficulty of resizing (or they'll know to use ALT+resize -- although that in itself has issues).

I truly believe that the default needs to be "user friendly" (i.e. an easy to use UI in this case), rather than an "aesthetically pleasing 1px border".

[fermulator (fermulator)]

[QUOTE]
Think about it... if the window is maximized, this region lies outside the window and is unreachable.
[/QUOTE]

Doug,

A great idea, but how would this work with dual/milti monitors? Or, even, with the "grid" plugin from compiz, (allows you to square off windows with relative ease CTRL+ALT+NUMPAD1 = bottom left, CTRL+ALT+NUMPAD3 = bottom right, etc.).

Certainly an "outside" invisible area would overlap windows, and would have to be considered in implementation.

[Matej Svetlík (matej-svetlik)]

After recent maverick updates the old ubuntu themes disappeared, so i switched to default ambiance theme. Suddenly I noticed i have problems with resizing window.

[Yann Dìnendal (yannbreliere)]

This invisible area could be defined only for the current focused window, this would solve the problem of overlapping windows. It would be a problem with the option "focus on hover", however, but then, if we consider this "outside invisible area" as being part of the window, the focus would not be given to another window by simply hovering on that zone. I hope I'm being understandable...

[mannheim (kronheim)]

As mentioned above, the Ambiance theme in Ubuntu 10.04 has a 5-pixel bottom border; and the corner regions of this border (a region of about 5-by-15 pixels -- I'm not sure) is usable for grabbing to resize the window.

However, the newer version (1.7) of the light-themes package currently in maverick testing gives Ambiance a bottom border of just 1 pixel. So the useful 5-by-15 corner region is now gone, replaced by a 1-by-15 region (unusable by me).

For ubuntu-light-themes, please give this an "Importance" other than "Low". Until window managers change, theme designers have to take into account what the elements of the user interface are for, not just what they look like. Maybe my car would look better without a steering wheel ...

[Jan Bakuwel (jan-bakuwel-gmail)]

+1 for Importance.

I think the usability (or lack thereof) of a user interface should not
depend on how it looks like. For instance we don't expect the theme to
define the pointer speed, double-click time out etc either?

I think it should be possible to use the user interface with straining
ones muscles no matter what a theme does; 1px on high res screen really
is beyond what I consider usable.

If we want it configurable, why not extend the Mouse Preferences with a
slider that specifies the number of pixels for the transparent area that
has been suggested?

[Tim Utschig (tim-tetro)]

I can't resist chiming in...

This bug/issue/behaviour is pretty aggravating. I had forgotten about it after changing the theme on lucid, and was reminded of it after a new maverick install.

Sure it's easy for us to fix, but for the average Joe it's simply yet another reason to switch back to a competitor.
Those who are thinking this should be ignored / pushed back any longer need to find several average Joes/Janes, and ask each to [try to] resize a window under the default theme on maverick using a laptop with a sensitive touchpad.

[Jan Bakuwel (jan-bakuwel-gmail)]

Is there anyone with decision making power regarding this issue out
there willing to respond?
It would be good to know if our suggestion(s) are being seriously
considered, have been rejected, deemed irrelevant, etc?

[Triqui (triqui)]

Resizing a window in 10.04 with Ambiance is a nightmare.

[GonzO (gonzo)]

"Resizing a window in 10.04 with Ambiance is a nightmare."

What *he* said.

I've increased all my borders to 5px. fixes the problem, but makes things look uglier than they should. I'd vote to just fix the appearance of windows with 5px borders, instead of wasting time trying to get in there and change the grab-zone.

[richard (richard-e-morton)]

This is a massively deep 'papercut' issue in the ubuntu project that needs
fixing as nearly every user will come across this issue - even if strictly
speaking it is not a bug.

On 15 Sep 2010 18:37, "GonzO" <email address hidden> wrote:

"Resizing a window in 10.04 with Ambiance is a nightmare."
What *he* said.

I've increased all my borders to 5px. fixes the problem, but makes
things look uglier than they should. I'd vote to just fix the
appearance of windows with 5px borders, instead of wasting time trying
to get in there and change the grab-zone.

--
Resizing windows by grabbing window borders is difficult
https://bugs.launchpad.net/bugs/160311...

[Jan (jancborchardt-deactivatedaccount)]

Everyone knows this is a problem – more comments don’t help more, they actually distract people from doing work on it.

[Andrea Cimitan (cimi)]

https://code.launchpad.net/~cimi/light-themes/rounded-bottom-corners

Mature branch with rounded corners at bottom, from 1px height to 4px.

[Omer Akram (om26er)]

anyone wanting to try light-themes patched with the above branch in Maverick here is the deb

[MarkieB (ubunt-u-markbenjamin)]

How would you customize a hotspot?

I'm seeing - radiance - a kind of V-shaped 'hotspot' for resizing from the corners that is 1 pixel high, possibly 7 pixels wide, at for instance the right-hand side of the top of the window, then 1 pixel wide, possibly 7 pixels high, at the top of the right-hand edge of the window, although my understanding of the word 'hotspot' would seem to suggest it should be a rectangular area?

Aside from the very thin V-shaped 'corner resize' zone, no sign of hotspots whatsoever?

As I'm writing, a comment that the invisible additional grab area sounds workable, should perhaps be a gconf setting, default off, as invisible overlaps could be a source of unpredictable behavior :-)

[Dylan McCall (dylanmccall)]

I have made an error in my comments to this bug report. I would like
to ask the people experiencing this to try what I described (resizing
from the corners) with Metacity ("desktop effects" disabled), not
Compiz. Metacity seems to behave considerably better here than Compiz,
where the extended resize handle on the corners is simply not there.
(The only thing you can resize with is the 1px border).

With that in mind, it seems it would be a good idea to file a bug
against Compiz, not Metacity, given that _Compiz_ is (for the time
being) the default window manager new Ubuntu users must deal with and
it is in fact behaving incorrectly.

[Fabián Rodríguez (magicfab)]

This has been added to the Ubuntu Release Notes.

[Brett Alton (brett-alton-deactivatedaccount)]

Link?

[Dominik Geyer (datag)]

Brett, I randomly stumbled upon this one some minutes ago:
https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview

Knows issues -> Common desktop issues

[Omer Akram (om26er)]

there is a blueprint for Natty.
https://blueprints.edge.launchpad.net/ubuntu/+spec/other-hci-n-resizing-windows

[Vish (vish)]

Release notes task has been committed

[Stian Soiland-Reyes (soiland-reyes)]

Kate - how is "This can be mitigated by switching to the Dust or Clear Looks theme" a fix? If I install Ubuntu 10.10 on a new machine, the default theme is still "Ambience" with 1 px borders. Are users required to just *know* that they need to change a theme to be able to resize windows? No other operating system seems to have this requirement. Fix or change the default theme.

[Melroy van den Berg (webmaster-web-share)]

You are do right.

Kind Regards,

Melroy van den Berg
<email address hidden>

----- Reply message -----
Van: "Stian Soiland-Reyes" <email address hidden>
Datum: wo, okt. 13, 2010 18:39
Onderwerp: [Bug 160311] Re: Resizing windows by grabbing window borders is difficult [please no more comments; patches welcome]
Aan: <email address hidden>

Kate - how is "This can be mitigated by switching to the Dust or Clear
Looks theme" a fix? If I install Ubuntu 10.10 on a new machine, the
default theme is still "Ambience" with 1 px borders. Are users required
to just *know* that they need to change a theme to be able to resize
windows? No other operating system seems to have this requirement. Fix
or change the default theme.

--
Resizing windows by grabbing window borders is difficult [please no more comments; patches welcome]
https://bugs.launchpad.net/bugs/160311
You received this bug notification because you are a direct subscriber
of a duplicate bug (575262).

[Ben Shadwick (benshadwick)]

It would be nice to see some discussion of a theme-independent solution to this issue. Expecting end-users to edit per-theme configuration files is a non-ideal solution at best. This is a huge ease-of-use issue for me and many others: http://brainstorm.ubuntu.com/idea/2571/

[Omer Akram (om26er)]

there is a ppa with a fix to gtk that adds a resize grip to every resize
able gtk window in the bottom right part so that its easy to do resizing.
though there are a few glitches too.
https://edge.launchpad.net/~bratsche/+archive/gtk

On Sun, Oct 17, 2010 at 4:24 AM, Steve Langasek <
<email address hidden>> wrote:

> ** Changed in: metacity (Ubuntu)
> Status: Confirmed => Triaged
>
> --
> Resizing windows by grabbing window borders is difficult [please no more
> comments; patches welcome]
> https://bugs.launchpad.net/bugs/160311
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Ayatana Design: Confirmed
> Status in One Hundred Paper Cuts: Triaged
> Status in The Metacity Window Manager: In Progress
> Status in Release Notes for Ubuntu: Fix Released
> Status in “human-gtk-theme” package in Ubuntu: Invalid
> Status in “light-themes” package in Ubuntu: Triaged
> Status in “metacity” package in Ubuntu: Triaged
> Status in “human-gtk-theme” source package in Maverick: Invalid
> Status in “light-themes” source package in Maverick: Triaged
> Status in “metacity” source package in Maverick: Triaged
>
> Bug description:
> 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).
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ayatana-design/+bug/160311/+subscribe
>

[georgehu (geohuz)]

It seems that with the newest update of ubuntu 10.10, the border is easier to grab. Except for the terminal window, it is still hard to grab the border to do resizing.

[John Baer (j.baer)]

I was unaware of the menu choices presented by "right-clicking" the title
bar. :( That's not a technical issue, that's a training issue.

In my opinion the "resize option" is very usable and makes this bug mute.

Would usability improve if folks were encouraged to "right-click" the title
bar by disabling the window border grab feature?

John

[Alden (jason-alden-benoit)]

I do not think so. Sure, many would get the hint and eventually figure it out, but many would be put-off just trying to figure out how to resize, even if they were successful. By default in Ubuntu with Compiz on you can also control+middle-click to resize. But one thing about Linux and free software is choice to do it how you want. You nor I, could answer for everyone on how comfortable we'd would feel doing it either way.

 But one thing I do know for sure is, resizing a window by grabbing the edge is something that many are currently comfortable with now. That is, unless they have a high resolution monitor, mouse or other issue that makes it difficult to grab said edge. Grabbing the border is just "intuitive". Take that away, and you have just become lazy and made the switch difficult for anyone who has ever used Windows, or even not used a computer at all but seen things grabbed by watching others use a PC. Training could certainly help, but we should I think need to keep according to the usability standards and want anyone to be able to pick it up and use it.

 I don't want to see this fixed because it works that way in Windows. I want to see it fixed because it is logical to want it to work this way. I do not think it is too much to ask for an advanced operating system to be adapted to the way users use it, instead of forcing users to adapt to the way it was programmed. (or deficiency thereof) In this case, it is just the software not keeping up with hardware's advances, and this bug should be able to be remedied instead of the feature "killed off".

[Ben Shadwick (benshadwick)]

georgehu: It's actually currently a per-theme setting in the theme definition files, and there are some themes that are set to provide thicker grab bars than others. In my personal opinion it should be a theme-independent setting that is configurable by end-users via a GUI control.

Alden: I agree 100%, and this is why I think it should be something that can be easily controlled by the end-user rather than dictated by the particular theme. It's a usability issue, not an aesthetic one.

[madbiologist (me-again)]

Ben - thanks for the info. As a temporary workaround, which file do I edit? I'm using the Radiance theme.

[Ben Shadwick (benshadwick)]

madbiologist: Googled around and found a recent forum thread with a post describing how to do the theme file edit: http://ubuntuforums.org/showthread.php?p=9881877#post9881877

[Neil Broadley (scaine)]

Comment #11 already details how to manually work around this bug. Of course, if you change theme thereafter, you'll have to edit that theme's metactiy-1.xml file too.

https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/160311/comments/11

I hate to be doom and gloom, but this metacity bug is upstream on gnome : for a couple of reasons, it's unlikely to be fixed ever. The upstream bug had a patch issued Dec 2008 (!), since ignored and the last comment there was January this year. It's much more likely that this will be addressed in Gnome 3.

To that end, I'd recommend hacking your themes until then. It's been three and a half years now and nominated for every release of Ubuntu since it was raised, so I can't see anyone taking up this torch when a new Gnome and theme engine are just round the corner.

To my mind, the importance (low) of this bug speaks volumes regarding whether it will be fixed. Perhaps Ayatana will make a difference, but sadly Paper Cuts didn't (it was ignored by the last two Paper Cuts attempts).

Sorry if I sound jaded. In my head, this bug was buried a long time ago.

[Jan Bakuwel (jan-bakuwel-gmail)]

Hi all,

> I don't want to see this fixed because it works that way in Windows. I
> want to see it fixed because it is logical to want it to work this way.
> I do not think it is too much to ask for an advanced operating system to
> be adapted to the way users use it, instead of forcing users to adapt to
> the way it was programmed. (or deficiency thereof) In this case, it is
> just the software not keeping up with hardware's advances, and this bug
> should be able to be remedied instead of the feature "killed off".
>

You're right of course, this has nothing to do with how Windows works.
Except perhaps that Windows, Mac and Linux all share the same concepts
of working with a keyboard, mouse and screen.

When touch screens become main stream are we going to say that users
should figure out which theme matches the thickness of their fingers or
else they won't be able to comfortably and intuitively with the system?

I'm surprised to read the debate is still going on. The way it currently
works is simply not ergonomic nor intuitive.

All themes (well especially those that come standard with Ubuntu) should
support easy resizing of windows, ie. it should be fixed independently
of themes. I surely don't consider this "fixed" or "mute" by adding a
hidden option somewhere in 10.10.

I'd also like to suggest that it gets fixed in Ubuntu 10.04 as that is a
LTS release.

thanks,
Jan

[John Baer (j.baer)]

On Mon, Oct 18, 2010 at 8:46 PM, Jan Bakuwel <email address hidden>wrote:

> Hi all,
>
> > I don't want to see this fixed because it works that way in Windows. I
> > want to see it fixed because it is logical to want it to work this way.
> > I do not think it is too much to ask for an advanced operating system to
> > be adapted to the way users use it, instead of forcing users to adapt to
> > the way it was programmed. (or deficiency thereof) In this case, it is
> > just the software not keeping up with hardware's advances, and this bug
> > should be able to be remedied instead of the feature "killed off".
> >
>
> You're right of course, this has nothing to do with how Windows works.
> Except perhaps that Windows, Mac and Linux all share the same concepts
> of working with a keyboard, mouse and screen.
>
> When touch screens become main stream are we going to say that users
> should figure out which theme matches the thickness of their fingers or
> else they won't be able to comfortably and intuitively with the system?
>
> I'm surprised to read the debate is still going on. The way it currently
> works is simply not ergonomic nor intuitive.
>
> All themes (well especially those that come standard with Ubuntu) should
> support easy resizing of windows, ie. it should be fixed independently
> of themes. I surely don't consider this "fixed" or "mute" by adding a
> hidden option somewhere in 10.10.
>
> I'd also like to suggest that it gets fixed in Ubuntu 10.04 as that is a
> LTS release.
>
> thanks,
> Jan
>
> Jan,

I can certainly see your point but it is important to consider there is risk
to any solution implemented.

For example if Metacity is changed to satisfy this requirement how will the
solution work with Compbiz?

Will the border be too large at lower resolutions?

What about Gnome shell?

Cheers,

John

[fermulator (fermulator)]

John, this is why we test the solution. Should someone implement a fix, I will volunteer for testing.

We need to ensure that this fix works across the board for compiz, metacity, popular default themes, etc. single monitor, dual monitor. ATI/nvidia/Intel graphics (if that matters).

This needs to be scoped ASAP for 10.04+.

[Alden (jason-alden-benoit)]

Scaine:
>I can't see anyone taking up this torch when a new Gnome and theme engine are just round the corner.

Perhaps.. Should we need to bring this bug to the attention of the Gnome developers ASAP?

>To my mind, the importance (low) of this bug speaks volumes regarding whether it will be fixed.

Anyone who thinks this bug is low should go without resizing their windows for a few days. Maybe then they will still say it is low. But then the next thing they should do is install of of those prank programs that move your mouse a little bit right as you click. That is what this feels like, a sad joke. I know I CAN grab the edge, but I just can't .... oh FINALLY!!!! It isn't "mission critical", but this is definitely in my mind a medium priority fix.

 Trust me, if it hurts usability, and it does, people will be turned off and give up Linux. This bug honestly did help push me to give up after years and I have just returned in 10.10 hoping it was fixed. (YAY Foursquare Flash!!!) I know I am not the only one. But I am one of the few savvy enough to find Launchpad. But look around, and you will see how many are affected by how many have in fact found launchpad.... . And that is just... so sad. We can do better than this... can't we?

>Sorry if I sound jaded. In my head, this bug was buried a long time ago.
No need to apologize for your feelings. JFK said that "We have nothing to fear, but fear itself." I say he is wrong, we have to and must fear losing our hope. Without Richard Stallman's hope, even as a lone man with an idea, we wouldn't be here discussing this right now. We have the blessing, to be (probably) a part of what makes it right.

>I'd also like to suggest that it gets fixed in Ubuntu 10.04 as that is a
LTS release.
I want to say I agree, but it depends on how LTS is looked at. I say fix it for anything you can, but "generally" new features aren't added, is my understanding. However this is worthy imho if any are. You shouldn't have to be held back because your computer works fine, you upgrade monitors or a mouse because the old one died and your experience is hurt.

>Will the border be too large at lower resolutions?
  As the person below you said, testing will be needed. But I wonder how can you honestly ask this question. Do you mean that between someone having too much and another not having enough, you would rather someone without enough to do without? Perhaps that is what this debate is about, and I completely missed the boat.

 If an "easy" fix would be to just make the borders bigger, then we would in fact be sacrificing usability for aesthetics. Aesthetics are required for optimal usability, but this is just.. well unjust is what it is. But at the same time, I don't want to ruin someone else's experience. That wouldn't be good either. So really, we must figure this out, because I don't know how to put it any other way except it is SUPER_MEGA_FREAKING annoying and people have probably quit using Ubuntu/Meta CIty more than we know because they can't even resize a SUPER_MEGA_FREAKING window... Sorry to be so.... frank. But I sometimes wonder if developers get it... Remember, users are people too! ; ) (We just may do it differentl...

[btmorex (avery-shadypixel)]

I'm a bit surprised at the "low" severity. I would think that a major usability issue in the default theme would be "high".

[Matthew Woerly (nattgew)]

From the huge amount of comments here with people wanting a fix, and the frequency that this bug would be encountered for the average user, I agree, it should be higher. A simple task such as resizing a window should work better.
Yet, we must sit here and "wish" that it would be fixed in Metacity for Ubuntu, and evidently it's more important that a theme look good than be usable. It needs to do both.

[Thibaut Brandscheid (k1au3-is-37)]

This bug is the usability bug no 1 since years!

I don't get why it got not fixed long time ago.

[krona (krona-krona-deactivatedaccount)]

I know you said no more comments, but I just have to add one more.

I don't actually know what Ubuntu's 'mission' is, but I expect it would like to become a popular desktop operating system that can be used and maintained by anyone. Well until you fix your processes I just can't see that even coming close to being true. I'm not being ungrateful, I know and appreciate this amazing free and open software, but I'm trying to help you. You actually made this problem *worse* from one release to the next, the mere fact that you were able to do that doesn't bode well. But anyway, good luck, I hope you get the concentrate on getting basics right however boring that may be.

[Ben Shadwick (benshadwick)]

krona: I think the description for Ubuntu bug #1 ( https://bugs.launchpad.net/ubuntu/+bug/1 ), under "What should happen" point #3 is relevant to this bug.

[Brandon Sussman (brandon-websterridge)]

It is pretty clear that this is an issue and it is also pretty clear that the folks who 'get to say' do not want to fix it.

I seems pointless to continue nominating it for the next release since that tactic has been ineffective since 6.06.

Seems to me it is time to find an alternative to the un-cooperative component.

[Alden (jason-alden-benoit)]

Brandon, I am working on something that should help to prevent issues
like this in the future. We could all donate money and get a patch if
needed, but then again only those lucky enough to know about launchpad
will be the ones to find it. Upstream may not even take it.

 I am not sure how long it will take, but this can't continue to
happen. So much frustration with little alleviation is just not to our
potential in my book. Not to dig on the developers, but we as a
communitty can do better.

On 10/23/10, Brandon Sussman <email address hidden> wrote:
> It is pretty clear that this is an issue and it is also pretty clear
> that the folks who 'get to say' do not want to fix it.
>
> I seems pointless to continue nominating it for the next release since
> that tactic has been ineffective since 6.06.
>
> Seems to me it is time to find an alternative to the un-cooperative
> component.
>
> --
> Resizing windows by grabbing window borders is difficult [please no more
> comments; patches welcome]
> https://bugs.launchpad.net/bugs/160311
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

-- Jason A. Benoit

We engrave upon everyone our image with all action taken and words spoken,
and turn them into molds that shape others, just as they have done to us. -
Villein

[Ben Shadwick (benshadwick)]

Does anyone know if this issue still exists in the current state of Gnome 3?

[Jason Rennie (jrennie)]

Just wanted to say that I too find window resizing to be a pain. I'll be changing the config file to widen the border. In case it matters, I'd vote for the addition of a border width control to the configuration UI. Seems like Appearance/Theme/Customize.../Window Border would be a natural place for it. Maybe something like the Pointer Size control.

[Jason Rennie (jrennie)]

Hmm... I was able to increase border size for left, right, bottom borders by editing the XML config as described by Troy James Sobotka (comment #11). But, like Scaine (comment #58), I was not able to change the top border, even after changing every value in the "normal" frame_geometry block that looked like it might relate to the top border. The 5px width borders on left/right/bottom is a huge improvement, but the thin top border is still a bother. Does anyone know how to change the top border via the XML config? Thx.

[Jaap Haitsma (jaap)]

Seem to be solved in GNOME 3
http://blogs.fedoraproject.org/wp/mclasen/2010/10/09/getting-a-grip/

On Sat, Oct 23, 2010 at 20:48, Ben Shadwick <email address hidden> wrote:
> Does anyone know if this issue still exists in the current state of
> Gnome 3?
>
> --
> Resizing windows by grabbing window borders is difficult [please no more comments; patches welcome]
> https://bugs.launchpad.net/bugs/160311
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (533510).
>
> Status in Ayatana Design: Confirmed
> Status in One Hundred Paper Cuts: Triaged
> Status in The Metacity Window Manager: In Progress
> Status in Release Notes for Ubuntu: Fix Released
> Status in “human-gtk-theme” package in Ubuntu: Invalid
> Status in “light-themes” package in Ubuntu: Triaged
> Status in “metacity” package in Ubuntu: Triaged
> Status in “human-gtk-theme” source package in Maverick: Invalid
> Status in “light-themes” source package in Maverick: Triaged
> Status in “metacity” source package in Maverick: Triaged
>
> Bug description:
> 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).
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ayatana-design/+bug/160311/+subscribe
>

[Ben Shadwick (benshadwick)]

I'm sad to see that a corner grip is the way they've decided to address things, as it's really just a workaround.

[Jan Bakuwel (jan-bakuwel-gmail)]

On 01/11/10 09:20, Ben Shadwick wrote:
> I'm sad to see that a corner grip is the way they've decided to address
> things, as it's really just a workaround.
>

+1.

So no fix for Gnome 2.x - and a half-fix for Gnome 3?

Can't believe the Gnome folks (assuming they're deciding about this)
allow this to continue to cripple the Gnome desktop.

[Lieven Blancke (launchpad-kks36)]

The default ubuntu 10.10 theme has 1px borders. It's resizing hell. This is really driving me crazy!

[Melroy van den Berg (webmaster-web-share)]

@Lieven Blancke

How can that be true? Why itsn't it fix in that Ubuntu release? :S

[Gabriele Calogero (samchok)]

I completely agree, resizing windows in Ubuntu 10.10 (with default theme) is a frustrating experience. And I'm using a *normal* resolution (1366 x 768)...

[George Ryan (george-ryan)]

Whatever solution you people come up with for 11.04 makes no difference to me, but holy heck this needs to be fixed. It's embarrassing to have a 100 Paper Cuts project without this being on it.

If you're going to make a 1 pixel border on your default theme, you'd better figure out a way for people to resize the window.

[Patryk "LeadMan" Benderz (leadman)]

[cut]
> 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
I would suggest creating this resizing area only _inside_ this window, 4
pixels close to 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).
These both are smart ideas.

--
Patryk "LeadMan" Benderz
Linux Registered User #377521
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

Email secured by Check Point

[Martin Spacek (mspacek)]

Sorry for the noise, but as others have pointed out (over the years!), one workaround is using ALT+middle mouse button to resize from anywhere within a window. Just want to add that there's a key in gconf that let's you change that to using ALT+right mouse button instead:

/apps/metacity/general/resize_with_right_button

I find this much more comfortable, plus it works on 2 button touchpads as well. By the way, this workaround isn't exclusive to compiz as some others have suggested.

[Steve Flynn (anothermindbomb)]

On Mon, Dec 13, 2010 at 10:49 PM, Martin Spacek <email address hidden> wrote:
> Sorry for the noise, but as others have pointed out (over the years!),
> one workaround is using ALT+middle mouse button to resize from anywhere
> within a window. Just want to add that there's a key in gconf that let's
> you change that to using ALT+right mouse button instead:

Or, we could just sort out the fundamental problem with resizing a
window by using the time-honoured tradition of grabbing a reasonable
chunk of the bottom left corner and dragging the bugger. Give us a
decent chunk to grab and we will.

I use my laptop with both a trackpad and a logitch thumbwheel
trackball. Both options are painful to use under Ubuntu and utterly
fine under Windows. I don't think it's a lot to ask to give someone
more than 1 or 2 pixels to hit on a 1900 pixel width screen.

In all honesty, I'm utterly stunned that fundamental issues like this
and hundreds of other are complaining about aren't resolved yet...
it's a papercut and STILL we're banging on about it...

--
Steve
When one person suffers from a delusion it is insanity. When many
people suffer from a delusion it is called religion.

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

[hannuko (hannu-kotipalo)]

I'm getting worried. There is this *very* annoying bug that affects every day the usability of the whole OS and this bug has been open and not fixed for 3 years!!! Don't you listen to users at all?!

[Ben Shadwick (benshadwick)]

hannuko: I don't think the One Hundred Paper Cuts project is being taken very seriously. Of all bugs in the project, this one has the highest number of comments and second-highest number of people affected, but is tagged as Low importance.

[Jan Bakuwel (jan-bakuwel-gmail)]

Thanks Vish.

Would it be possible to amend the following sentence so it reads:

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

10.04 is a LTS after all...

thanks,
Jan

On 03/01/11 07:53, Vish wrote:
> ** Description changed:
>
> *************
> - >>> No more comments needed <<<
> + >>>> No more comments needed <<<<
>
> - This should mostly be fixed for Natty and might get backported to earlier releases as well.
> + This should mostly be fixed for Natty and might get backported to
> + earlier releases as well.
> +
> *************
> +
> + *************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: 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 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
> positio...

[Mikel Pérez (mikelpr)]

I thought I was the only one who really had a problem with this. But then I thought that wouldn't make sense, and that probably nobody had filed a bug.

So I searched and found this.

And I'm shocked this HUGE bug has been filed here for around 3 years yet it's low priority.
How can this be low priority if it affects _every_ window? And this is ubuntu, not some distro targeting command-line hackers.

I'm sorry I can't contribute any code to fix it, but I think you should reconsider some of your priorities.

Now, from looking at http://blogs.fedoraproject.org/wp/mclasen/2010/10/09/getting-a-grip/, GTK+3 will include this (hopefully this is mainstream and not only Fedora), but unless GTK+3 is included in natty (AFAIK it is, correct me if I'm wrong. and I hope I'm not… also, this leaves lucid out in the cold, and the latest LTS shouldn't be left suffering this terrible bug) and all existing GTK+2 applications use GTK+3 when ran on a system with GTK+3 (which I doubt, considering how horrendus GTK+1 apps look) the outcome won't be pretty at all...

[Paul Sladen (sladen)]

MikeLoco14: Yes, corner drag functionality is already in natty (which will likely become Ubuntu 11.04 in April 2011).
As the blog post from 9 October 2010 notes: "The credit for this work goes to Cody Russell". Cody is an Ubuntu Member, see Cody's Launchpad page:

  https://launchpad.net/~bratsche (Cody Russell)

Hopefully this serves to demonstrate that window resizing *is* being actively improved! (I appreciate that there has been a couple of years where the situation has regressed as a result of theme changes). I don't currently know how much of the final solution will be able to be backported to previous Ubuntu versions (theme changes will be easier than code changes), but I'm sure others will investigate what is possible work; for example see the note at the top of this bug report:

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

[Neilen Marais (neilenmarais)]

I think a good modification to the "invisible drag handle" proposal would be to rather use "resize border resistance". This is a solution that won't require more than 1 px of UI space to work well. How I envisage it working is:

1) keep your arbitrarily small window border resize
2) Define a resize-resistance size, say 5 px
3) Once the user moves the pointer over the resize edge, the resize cursor will appear
4) The resize cursor will remain active until the user moves the pointer at lease 'resize-resistance' many pixels away from the resize edge
5) Click-and-hold while the resize cursor is active will result in window resizing.

This seems to me like it should have 100% backward compatibility, require only changes to the window manager, will be theme independent and will still be easy to use.

[The Fiddler (stapostol)]

2011/1/24 Neilen Marais <email address hidden>

> I think a good modification to the "invisible drag handle" proposal
> would be to rather use "resize border resistance". This is a solution
> that won't require more than 1 px of UI space to work well. How I
> envisage it working is:
>
> 1) keep your arbitrarily small window border resize
> 2) Define a resize-resistance size, say 5 px
> 3) Once the user moves the pointer over the resize edge, the resize cursor
> will appear
> 4) The resize cursor will remain active until the user moves the pointer at
> lease 'resize-resistance' many pixels away from the resize edge
> 5) Click-and-hold while the resize cursor is active will result in window
> resizing.
>

This wouldn't solve the issue, since most the difficulty lies in positioning
the cursor over the 1px resize edge (once you manage that, initiating a
resize is simple).

In any case, this is being worked on for Natty, apparently. Hopefully we'll
be notified when the fix lands, so we can alpha-/beta-test the solution and
provide any necessary feedback.

[Launchpad Janitor (janitor)]

This bug was fixed in the package light-themes - 0.1.8.5

---------------
light-themes (0.1.8.5) natty; urgency=low

  [ Sam Spilsbury ]
  * New Ambiance properties for <shadow> and <padding> added to
    metacity theme files (for invisible window grip support).
    These are read by libmetacity-private so that they can be
    exported by new functionality and picked up by
    'unity-window-decorator' which was introduced in compiz-gnome
    1:0.9.2.1+glibmainloop4. Partial solution to (LP: #160311).

  [ Paul Sladen ]
  * Apply Ambiance/.../metacity-theme-1.xml changes to Radiance.
  * Add Breaks: metacity (<< 1:2.30.3-0ubuntu2) since the introduction
    of new parsing support will prevent backporting to maverick unless
    the corresponding patch to Metacity is backported first.
 -- Paul Sladen <email address hidden> Thu, 27 Jan 2011 10:22:00 +0000

[Paul Sladen (sladen)]

Solution applied in Natty (will be in Ubuntu 11.04).

[Paul Sladen (sladen)]

metacity (1:2.30.3-0ubuntu2) natty; urgency=low

  * debian/patches/06_Add_UXD_shadows_and_borders.patch:
    - patch for a new key in the ubuntu theme for shows and borders

 -- Didier Roche <email address hidden> Thu, 13 Jan 2011 17:55:35 +0100

[Rocko (rockorequin)]

The fix works marvellously in the Ubuntu classic desktop! Thanks!

[Neilen Marais (neilenmarais)]

In reply to #245 by The Fiddler:

I'm not sure if our experience differs or if I did not explain my proposed solution well enough. I find that I have no difficulty getting the resize pointer to appear momentarily while moving across the window border, the problem lies in actually clicking while the resize pointer is active. The proposed solution would fix that, since the resize pointer will remain active for several pixels once activated.

In any case, so long as a working solution if shipped in Natty I guess I'm satsified!

[Neilen Marais (neilenmarais)]

In reply to #245 by The Fiddler:

I'm not sure if our experience differs or if I did not explain my proposed solution well enough. I find that I have no difficulty getting the resize pointer to appear momentarily while moving across the window border, the problem lies in actually clicking while the resize pointer is active. The proposed solution would fix that, since the resize pointer will remain active for several pixels once activated.

In any case, so long as a working solution if shipped in Natty I guess I'm satisfied!

[The Fiddler (stapostol)]

#245:

Our experience is indeed different. I simply cannot make the pointer appear using a trackpad. It often takes me upwards of 5'' to find the correct pixel.

Funnily enough, I've had four separate Ubuntu users comment on this behavior independently, just during the last week. I'm glad to see this being fixed in Natty but a backport would be nice indeed.

[richard (richard-e-morton)]

Its fixed in natty alpha2
R

[Brent Thompson (docbrent2000)]

Thanks for getting it fixed for Natty. Please backport that fix to 10.04LTS and 10.10.

I know it says "no more comments needed," but I'm not certain that is totally accurate. With one hand having a small tremor, and the other not, I guess I qualify under both usability and accessibility. So I add my voice to others who have signalled this as a problem.

I love the default theme, but every time I get near a window border to resize, it's an exercise in frustration, carpal tunnel, and vocabulary building. Now I see I'm not alone in having this problem. Sometimes it makes me ready to go back to KDE or to fire up my Redmond windowing machine. And it doesn't help sell the Meerkat to my wife, and help to bring her from the dark side of that OS which must not be named.

Speaking of which, just because Windows XP or 7 or whatever has a certain feature as part of its user interface, that does not automatically make it a bad thing. They've thrown a gazillion dollars into developing their OS versions, and with that much money and staffing, they are bound to get some things right.

[Brent Thompson (docbrent2000)]

Sorry, I meant to repeat my thanks at the end of that last post. Bug tracking, fixing, testing, and finally deploying the associated patch(es) is often a thankless and unglamorous set of tasks. Rest assured, this fix will be noticed and appreciated!

[demilord (demilord)]

I agree that this should be backported, especialy to 10.04 LTS

[Peter (arugam)]

thanks to scaine #58 for something that works
can't believe it took 4 years for some to realise windows that are extremely difficult to grab the sides of is not the intention of a Graphical User Interface

[Sam Spilsbury (smspillaz)]

We can't backport it unless we backport compiz too since it is
dependent on the reparenting feature of compiz which was introduced in
the unstable version in Natty.

On Tue, Apr 5, 2011 at 12:01 AM, Taco Fortgens
<email address hidden> wrote:
> I agree that this should be backported, especialy to 10.04 LTS
>
> --
> 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 “human-gtk-theme” package in Ubuntu:
>  Invalid
> Status in “light-themes” package in Ubuntu:
>  Fix Released
> Status in “metacity” package in Ubuntu:
>  Fix Released
> Status in “human-gtk-theme” source package in Maverick:
>  Invalid
> Status in “light-themes” source package in Maverick:
>  Triaged
> Status in “metacity” source package in Maverick:
>  Triaged
>
> Bug description:
>  *************
>  >>>> No more comments needed <<<<
>
>  This should mostly be fixed for Natty and might get backported to
>  earlier releases as well.
>
>  *************
>
>  *************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:  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 b...

[Paul Sladen (sladen)]

Peter (#257): you are correct to note "[I] can't believe it took 4 years .. to". The problem itself has had been known about for three years (as evidenced by this bug report filed in December 2007) before designs were done, those designs tested, and ultimately deployed.

The word "realisation" can mean both in English: realising (knowing about) and realisation (developing, designing, deploying, testing a proposed solution). It's only in the last year or so that the Ayatana project has started to design and push the more radical ideas and code changes necessary to complete a solution.

I hope the solution in Ubuntu 11.04 is useful (but it has required some pretty extensive code changes so is not easily backported to previous versions of Ubuntu without backporting the whole lot).

[UeB (moritz-nadler)]

It says in this thread that a fix was commited. I upraded to Ubuntu 11.04 using the classic gnome desktop and still my window borders in the ambiance and radiance themes are only 1 pixel wide, so resizing windows with the mouse alone is still a pain in the ass. I thought it was fixed now. Is there still a problem on my pc do I have a wrong understanding of what "fixed" means in this case. Any enlightenment is very appreciated. Thanks in advance.

[Sam Spilsbury (smspillaz)]

On Sat, Jul 16, 2011 at 10:56 PM, UeB <email address hidden> wrote:
> It says in this thread that a fix was commited. I upraded to Ubuntu
> 11.04 using the classic gnome desktop and still my window borders in the
> ambiance and radiance themes are only 1 pixel wide, so resizing windows
> with the mouse alone is still a pain in the ass. I thought it was fixed
> now.  Is there still a problem on my pc do I have a wrong understanding
> of what "fixed" means in this case. Any enlightenment is very
> appreciated. Thanks in advance.

Are you running unity-window-decorator?

ps aux | grep unity-window-decorator

IT could also be that you have those themes installed locally and they
are conflicting with the themes that specify the new borders.

>
> --
> 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 “human-gtk-theme” package in Ubuntu:
>  Invalid
> Status in “light-themes” package in Ubuntu:
>  Fix Released
> Status in “metacity” package in Ubuntu:
>  Fix Released
> Status in “human-gtk-theme” source package in Maverick:
>  Invalid
> Status in “light-themes” source package in Maverick:
>  Triaged
> Status in “metacity” source package in Maverick:
>  Triaged
>
> Bug description:
>  *************
>  >>>> No more comments needed <<<<
>
>  This should mostly be fixed for Natty and might get backported to
>  earlier releases as well.
>
>  *************
>
>  *************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:  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 ...

[Melroy van den Berg (melroyvandenberg)]

Well, I got Ubuntu 11.04 (Unity) up-to-date, but still this border grip problem isn't fixed.

[richard (richard-e-morton)]

Worked for me with a fresh install. Extra grab space is on the outside of
the window in the shadow area

Please excuse brevity and pistakes this email was composed on a mobile
phone.

Thanks and best regards,

Richard

[Melroy van den Berg (melroyvandenberg)]

That is strange.... I just use Unity 3d and unity 2d (no classic) with the default Ambiance theme, I didn't change a thing.

I also did a fresh Ubuntu 11.04 install, so what do I wrong?

[Paul Sladen (sladen)]

Melroy: perhaps you've found a new issue, which we'll have to debug with your assistance. Please could you file a /new/ bug report (and post the bug number here) so we can keep what you're seeing separate from the original fix for this which was tested and applied many months ago.

[UeB (moritz-nadler)]

@Sam Spilsbury
unity-window-decorator is not running
my themes are in:
/usr/share/themes/
And do not remember installing any theme manually. I always used just the ones that came with Ubuntu.

[Patryk "LeadMan" Benderz (leadman)]

[cut]
> Are you running unity-window-decorator?
>
> ps aux | grep unity-window-decorator
On one of my machines I have similar issue. unity-window-decorator is
not running. After:
$ compiz --replace &
$ unity-window-decorator --replace &
border is more than 1px. Which package should I re/install to make it
work by default after restart?
[cut]
--
Patryk "LeadMan" Benderz
Linux Registered User #377521
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

Email secured by Check Point

[RussianNeuroMancer (russianneuromancer)]

Now it's again issue in Oneiric.

[The Fiddler (stapostol)]

2011/8/21 RussianNeuroMancer <email address hidden>

> Now it's again issue in Oneiric.
>
> In both unity and unity2d.

[Sam Spilsbury (smspillaz)]

Invisible borders are not implemented in unity-2d

On Sun, Aug 21, 2011 at 4:43 PM, The Fiddler <email address hidden> wrote:
> 2011/8/21 RussianNeuroMancer <email address hidden>
>
>> Now it's again issue in Oneiric.
>>
>> In both unity and unity2d.
>
> --
> 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 “human-gtk-theme” package in Ubuntu:
>  Invalid
> Status in “light-themes” package in Ubuntu:
>  Fix Released
> Status in “metacity” package in Ubuntu:
>  Fix Released
> Status in “human-gtk-theme” source package in Maverick:
>  Invalid
> Status in “light-themes” source package in Maverick:
>  Triaged
> Status in “metacity” source package in Maverick:
>  Triaged
>
> Bug description:
>  *************
>  >>>> No more comments needed <<<<
>
>  This should mostly be fixed for Natty and might get backported to
>  earlier releases as well.
>
>  *************
>
>  *************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:  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 >
>  Preference...

[The Fiddler (stapostol)]

2011/8/21 Sam Spilsbury <email address hidden>

> Invisible borders are not implemented in unity-2d
>
>
Are they technically infeasible or could they be implemented with some
effort? If so, where should they be implemented?

[doeus (doeus)]

I have experienced the same problem with a fresh installation of Ubuntu 11.04 natty.
I have fixed it with the following:

*************
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"/>
*************

[Fabien Tassin (fta)]

yep, it regressed for me too. and to make the matter worse, the gtk resize grip in the bottom-right corner is gone too (or at least it's gone when using gnome-shell, not sure about unity)

[Sam Spilsbury (smspillaz)]

On Sun, Aug 21, 2011 at 8:05 PM, The Fiddler <email address hidden> wrote:
> 2011/8/21 Sam Spilsbury <email address hidden>
>
>> Invisible borders are not implemented in unity-2d
>>
>>
> Are they technically infeasible or could they be implemented with some
> effort? If so, where should they be implemented?

They can be implemented with some effort, but its difficult when
you're not compositing because its another set of windows to be
tracking (you can't reparent an InputOutput window into an InputOnly
window, which means that you can't abuse reparenting like we do in
compiz in order to do this easily)

They'd belong in metacity in that case.

>
> --
> 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 “human-gtk-theme” package in Ubuntu:
>  Invalid
> Status in “light-themes” package in Ubuntu:
>  Fix Released
> Status in “metacity” package in Ubuntu:
>  Fix Released
> Status in “human-gtk-theme” source package in Maverick:
>  Invalid
> Status in “light-themes” source package in Maverick:
>  Triaged
> Status in “metacity” source package in Maverick:
>  Triaged
>
> Bug description:
>  *************
>  >>>> No more comments needed <<<<
>
>  This should mostly be fixed for Natty and might get backported to
>  earlier releases as well.
>
>  *************
>
>  *************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:  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 "mi...

[Sam Spilsbury (smspillaz)]

On Mon, Aug 22, 2011 at 9:22 PM, Fabien Tassin <email address hidden> wrote:
> yep, it regressed for me too. and to make the matter worse, the gtk
> resize grip in the bottom-right corner is gone too (or at least it's
> gone when using gnome-shell, not sure about unity)

They will be back once we work out what caused the performance
problems in the unity decorator (xrender is really really slow on
intel recently)

>
> --
> 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 “human-gtk-theme” package in Ubuntu:
>  Invalid
> Status in “light-themes” package in Ubuntu:
>  Fix Released
> Status in “metacity” package in Ubuntu:
>  Fix Released
> Status in “human-gtk-theme” source package in Maverick:
>  Invalid
> Status in “light-themes” source package in Maverick:
>  Triaged
> Status in “metacity” source package in Maverick:
>  Triaged
>
> Bug description:
>  *************
>  >>>> No more comments needed <<<<
>
>  This should mostly be fixed for Natty and might get backported to
>  earlier releases as well.
>
>  *************
>
>  *************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:  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
>  t...

[Nacnud Nosmoht (clymbon)]

Broken on Oneiric. And I still haven't seen a fix. And I don't care if this is or isn't a bug, and all the other nuances, I just want a way to be able to resize windows. I can make it work if I have a mouse plugged in, but using the touchpad, with my calloused fingers, it's completely impossible to grab the window border to resize the window. COME ON GUYS - THIS SHOULDN'T BE THAT HARD!

[Melroy van den Berg (melroyvandenberg)]

No offense, but I also agree with Nacnud.

[Jan Bakuwel (jan-bakuwel-gmail)]

On 21/12/11 11:32, Nacnud Nosmoht wrote:
> Broken on Oneiric. And I still haven't seen a fix. And I don't care if
> this is or isn't a bug, and all the other nuances, I just want a way to
> be able to resize windows. I can make it work if I have a mouse plugged
> in, but using the touchpad, with my calloused fingers, it's completely
> impossible to grab the window border to resize the window. COME ON GUYS
> - THIS SHOULDN'T BE THAT HARD!
>

Amazing eh?

Microsoft folks are laughing their heads off: can't get this simply
thing right?

+1 (for the 10th time?)

Jan

[John Lea (johnlea)]

@jan-bakuwel-gmail; in what way is the current Ubuntu window resizing behaviour different from the Microsoft window resizing behaviour? In both Windows and Ubuntu we have several px on the left, right and bottom of the windows that is dragable, in fact I think the dragable area in Ubuntu is slightly larger. We *do* have a bug with the dragable area at the top of a window, but are there any other issues you are aware of?

[The Fiddler (stapostol)]

2011/12/21 John Lea <email address hidden>

> @jan-bakuwel-gmail; in what way is the current Ubuntu window resizing
> behaviour different from the Microsoft window resizing behaviour? In
> both Windows and Ubuntu we have several px on the left, right and bottom
> of the windows that is dragable, in fact I think the dragable area in
> Ubuntu is slightly larger. We *do* have a bug with the dragable area at
> the top of a window, but are there any other issues you are aware of?
>
>
1. It doesn't work in Unity2d.
2. The draggable area is ~half the size of that in Windows. (IIRC, Windows
is 10px, Ubuntu is 5 or 6px).

[John Lea (johnlea)]

@stapostol; thanks for your response, I've marked the bug as also affects unity2d. Re. the sizing of the dragable area, in WindowsXP the dragable area is 5px (but it may well be larger in Windows 7). So yes the size could be increased, but 5px also seems workable. For those who need * significantly* larger grabable areas for accessibility reasons, another options is to use the love handles with a key combination, see http://linux-software-news-tutorials.blogspot.com/2011/06/activate-fantastic-grab-handles-in.html for details.

[The Fiddler (stapostol)]

2011/12/21 John Lea <email address hidden>

> @stapostol; thanks for your response, I've marked the bug as also
> affects unity2d. Re. the sizing of the dragable area, in WindowsXP the
> dragable area is 5px (but it may well be larger in Windows 7). So yes
> the size could be increased, but 5px also seems workable.

Indeed, WinXP had 5px draggable areas - but WinXP is 10 years old now and
it might not be the most suitable point of reference for modern design
topics. The draggable area was increased in Vista (same as Win7) and I
think I recall a msdn blog mentioning this was based on usability tests
(but it's been half a decade since then and my google-fu is letting me
down, so don't quote me on that).

In any case, the drag area is invisible in Unity, so a potential size
increase should be a relatively safe change.

> For those who
> need * significantly* larger grabable areas for accessibility reasons,
> another options is to use the love handles with a key combination, see
> http://linux-software-news-tutorials.blogspot.com/2011/06/activate-
> fantastic-grab-handles-in.html for details.
>

These are indeed fantastic, maybe they merit more attention than currently
given. (I love them on my laptop, but I cannot find a way to use them on my
desktop).

[u-foka (ufooka)]

Hy!

I'm a little bit afraid of a larger resize area.. If I click 10px far
from a window, I probably want to raise the window below. 5-6px is ok,
but more is risky, especially because that area is invisible.

Eisenberger Tamás <email address hidden>

On 12/21/2011 03:56 PM, The Fiddler wrote:
> 2011/12/21 John Lea<email address hidden>
>
>> @stapostol; thanks for your response, I've marked the bug as also
>> affects unity2d. Re. the sizing of the dragable area, in WindowsXP the
>> dragable area is 5px (but it may well be larger in Windows 7). So yes
>> the size could be increased, but 5px also seems workable.
>
>
> Indeed, WinXP had 5px draggable areas - but WinXP is 10 years old now and
> it might not be the most suitable point of reference for modern design
> topics. The draggable area was increased in Vista (same as Win7) and I
> think I recall a msdn blog mentioning this was based on usability tests
> (but it's been half a decade since then and my google-fu is letting me
> down, so don't quote me on that).
>
> In any case, the drag area is invisible in Unity, so a potential size
> increase should be a relatively safe change.
>
>
>> For those who
>> need * significantly* larger grabable areas for accessibility reasons,
>> another options is to use the love handles with a key combination, see
>> http://linux-software-news-tutorials.blogspot.com/2011/06/activate-
>> fantastic-grab-handles-in.html for details.
>>
>
> These are indeed fantastic, maybe they merit more attention than currently
> given. (I love them on my laptop, but I cannot find a way to use them on my
> desktop).
>

[Jan Bakuwel (jan-bakuwel-gmail)]

Hi John,

On 22/12/11 01:59, John Lea wrote:
> @jan-bakuwel-gmail; in what way is the current Ubuntu window resizing
> behaviour different from the Microsoft window resizing behaviour? In
> both Windows and Ubuntu we have several px on the left, right and bottom
> of the windows that is dragable, in fact I think the dragable area in
> Ubuntu is slightly larger. We *do* have a bug with the dragable area at
> the top of a window, but are there any other issues you are aware of?
>

This issue has been dragging on for so long I've grown tired of it.

Have you ever tried using a touchpad to resize a window with a default
Ubuntu 11.10 installation on a laptop with a high resolution screen?
I've given up on it on Ubuntu 10.04 and have gotten used to Alt - Right
Click to resize windows until I have time to write a program that can
read my mind as I don't think this will ever be fixed on Ubuntu 10.04.

I can't use Ubuntu 11.10 as yet as Unity is buggy and even if it would
not be buggy it still is a much lesser fit to my needs than Gnome 2. I
might be forced to stay with Ubuntu 10.04 for a few more years as I
think Unity need a lot more work before it's usable for anything more
than occasional desktop work. Fortunately support for 10.04 has been
extended - I assume for obvious reasons?

The point many people are trying to make is that resizing windows needs
to be intuitive.
Dare I say that something that is intuitive should no more depend on the
selected theme as it would on the selected background image?

It has been intuitive on Windows since 3 (can't remember Windows <3
sorry :-P), as well as on any incarnation of Mac OS but somehow we seem
to continue to have to debate and explain something that I would
consider really really obvious.

Perhaps the developers should simply use a laptop with a touchpad and
high resolution screen and see if they can resize windows without
inflicting RSI on themselves. If they can't, it's not fixed, no matter
what technical arguments are put forward.

regards,
Jan

[David N. Welton (davidnwelton)]

> Perhaps the developers should simply use a laptop with a touchpad and
high resolution screen and see if they can resize windows without
inflicting RSI on themselves.

Bingo! My laptop has a very high resolution screen, and this bug drives me batty. Don't the developers ever test on a system with a high resolution screen and a trackpad?

[Steve Flynn (anothermindbomb)]

On 21 December 2011 20:54, David N. Welton <email address hidden> wrote:

> Bingo!  My laptop has a very high resolution screen, and this bug drives
> me batty.  Don't the developers ever test on a system with a high
> resolution screen and a trackpad?

Try using a trackball. Absolute nightmare.

--
Steve

When one person suffers from a delusion it is insanity. When many
people suffer from a delusion it is called religion.

[u-foka (ufooka)]

Hy!

I can grab the 5px areas easily with trackball or touchpad on my T61
(14,1" 1440x900), on the other hand, the 1px area is nearly impossible
to catch with any display and pointing device.

Eisenberger Tamás <email address hidden>

On 12/21/2011 10:53 PM, Steve Flynn wrote:
> On 21 December 2011 20:54, David N. Welton<email address hidden>
> wrote:
>
>> Bingo! My laptop has a very high resolution screen, and this bug drives
>> me batty. Don't the developers ever test on a system with a high
>> resolution screen and a trackpad?
>
> Try using a trackball. Absolute nightmare.
>

[Steve Flynn (anothermindbomb)]

On 21 December 2011 22:27, u-foka <email address hidden> wrote:
> Hy!
>
> I can grab the 5px areas easily with trackball or touchpad on my T61
> (14,1" 1440x900), on the other hand, the 1px area is nearly impossible
> to catch with any display and pointing device.

Alienware m15x, 1900 * 1200. If I hit the grab area first time using
the touchpad it's a fluke. If I hit it with the trackball, it's only
with a degree of concentration. Same laptop, same trackball and
touchpad, Windows at the same rez - no problem.

/shrug

Been complaining about this for getting one for 2 years and it
actually got resolved. Then Oneric came out and it was back to square
one.

--
Steve

When one person suffers from a delusion it is insanity. When many
people suffer from a delusion it is called religion.

[Paul Sladen (sladen)]

Steve Flynn: are you on Unity 2D or Unity 3D?

[u-foka (ufooka)]

Maybe the best would be a configurable size for the hidden grab area :)
Currently it's difficult to change, how I seen the size is hardcoded
into the theme right?

Eisenberger Tamás <email address hidden>

On 12/22/2011 01:26 AM, Steve Flynn wrote:
> On 21 December 2011 22:27, u-foka<email address hidden> wrote:
>> Hy!
>>
>> I can grab the 5px areas easily with trackball or touchpad on my T61
>> (14,1" 1440x900), on the other hand, the 1px area is nearly impossible
>> to catch with any display and pointing device.
>
> Alienware m15x, 1900 * 1200. If I hit the grab area first time using
> the touchpad it's a fluke. If I hit it with the trackball, it's only
> with a degree of concentration. Same laptop, same trackball and
> touchpad, Windows at the same rez - no problem.
>
> /shrug
>
> Been complaining about this for getting one for 2 years and it
> actually got resolved. Then Oneric came out and it was back to square
> one.
>

[The Fiddler (stapostol)]

2011/12/22 u-foka <email address hidden>

> Maybe the best would be a configurable size for the hidden grab area :)
> Currently it's difficult to change, how I seen the size is hardcoded
> into the theme right?
>
>
But is this really necessary?

Three options:
- review feedback and pick a sensible default value
- add a new option to ccsm
- link the actual radius with some other element that makes sense, e.g. the
shadow decoration.

KDE has a configurable border size somewhere in its theme options (option
#2). Gnome 2 used to link the radius with the theme border (option
#3). Windows and MacOS (Lion) don't have a configurable size, same as Unity
(option #1). I am not sure about Gnome Shell (but the default size seems to
be slightly larger than Unity).

This is on of those cases where a sensible default, well, makes sense. A
size of 8px or 10px would be easier to hit than 5px, without impacting
usability negatively (i.e. it still falls within the visible shadow
decoration, where you are unlikely to click to raise a window). It should
be a relatively simple change with a negligible chance of regressions.

[u-foka (ufooka)]

Actually the size of the shadow sounds as a good starting point!

--
Eisenberger Tamás <email address hidden>

On Thu, Dec 22, 2011 at 10:07 AM, The Fiddler <email address hidden>wrote:

> 2011/12/22 u-foka <email address hidden>
>
> > Maybe the best would be a configurable size for the hidden grab area :)
> > Currently it's difficult to change, how I seen the size is hardcoded
> > into the theme right?
> >
> >
> But is this really necessary?
>
> Three options:
> - review feedback and pick a sensible default value
> - add a new option to ccsm
> - link the actual radius with some other element that makes sense, e.g. the
> shadow decoration.
>
> KDE has a configurable border size somewhere in its theme options (option
> #2). Gnome 2 used to link the radius with the theme border (option
> #3). Windows and MacOS (Lion) don't have a configurable size, same as Unity
> (option #1). I am not sure about Gnome Shell (but the default size seems to
> be slightly larger than Unity).
>
> This is on of those cases where a sensible default, well, makes sense. A
> size of 8px or 10px would be easier to hit than 5px, without impacting
> usability negatively (i.e. it still falls within the visible shadow
> decoration, where you are unlikely to click to raise a window). It should
> be a relatively simple change with a negligible chance of regressions.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (638709).
> https://bugs.launchpad.net/bugs/160311
>
> Title:
> Resizing windows by grabbing window borders is difficult
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ayatana-design/+bug/160311/+subscriptions
>

[Steve Flynn (anothermindbomb)]

On 22 December 2011 02:21, Paul Sladen <email address hidden> wrote:
> Steve Flynn: are you on Unity 2D or Unity 3D?

3D.

--
Steve

When one person suffers from a delusion it is insanity. When many
people suffer from a delusion it is called religion.

[renbag (renbag)]

Are there any plans to address this bug for unity-2d, after having marked it as critical? Recently the resize grips in the bottom right corner have been entirely removed from precise, leaving the resize process of windows very difficult in unity-2d.
I use the attached script (50_light-themes-borders) in /etc/X11/Xsession.d to copy the Ambiance and Radiance themes to the $HOME/.themes user directory and then modify the border width to 3 pixels, for normal frame geometry. The modifications are made only if unity-2d session is used and are reverted for other sessions. However the script may break if changes are made to the original themes. There must be surely a better way to do this...

[Yann Dìnendal (yannbreliere)]

Renzo: In precise (ubuntu 12.04), you can resize the window by grabbing the
overlay scrollbar, which is much larger than the border, and available
regardless of the session type (unity-2d or anything else).

Yann Dìnendal

On Fri, Mar 9, 2012 at 16:42, Renzo Bagnati <email address hidden>wrote:

> Are there any plans to address this bug for unity-2d, after having marked
> it as critical? Recently the resize grips in the bottom right corner have
> been entirely removed from precise, leaving the resize process of windows
> very difficult in unity-2d.
> I use the attached script (50_light-themes-borders) in /etc/X11/Xsession.d
> to copy the Ambiance and Radiance themes to the $HOME/.themes user
> directory and then modify the border width to 3 pixels, for normal frame
> geometry. The modifications are made only if unity-2d session is used and
> are reverted for other sessions. However the script may break if changes
> are made to the original themes. There must be surely a better way to do
> this...
>
> ** Attachment added: "50_light-themes-borders"
>
> https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/160311/+attachment/2840420/+files/50_light-themes-borders
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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 “human-gtk-theme” package in Ubuntu:
> Invalid
> Status in “light-themes” package in Ubuntu:
> Fix Released
> Status in “metacity” package in Ubuntu:
> Fix Released
> Status in “human-gtk-theme” source package in Maverick:
> Invalid
> Status in “light-themes” source package in Maverick:
> Triaged
> Status in “metacity” source package in Maverick:
> Triaged
>
> Bug description:
> *************
> >>>> No more comments needed <<<<
>
> This should mostly be fixed for Natty and might get backported to
> earlier releases as well.
>
> *************
>
> *************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<https://launchpad.net/%7Ebratsche/+archive/gtk>
>
> *************
>
> 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"/>
>
> **********...

[renbag (renbag)]

Using the overlay scrollbar to resize is not very intuitive and can be used only to drag horizontally. Moreover the scrollbar is visible only if the window has a scrollable content, hence is not a general solution.

[Patryk "LeadMan" Benderz (leadman)]

I agree with Renbag. I use terminal windows without scroll bar all the time. Thi is not a solution. The only reasonable solution is to restore invisible grabbing area of size~5 pixels within all long window's borders.

[Ben Shadwick (benshadwick)]

I guess the work done here https://blueprints.launchpad.net/ubuntu/+spec/packageselection-dx-n-resizing-windows was not ported to Unity?

It's sad that this basic usability bug affecting all users is over 4 years old, and people just keep trotting out workarounds.

Fortunately, the problem is not nearly as pronounced in Xubuntu.

[renbag (renbag)]

In unity the bug has been fixed using invisible window grip support through compiz and unity-window-decorator.
See: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/160311/comments/246
The resize difficulties remains only when using unity-2d.

[Martin Pool (mbp)]

I don't think this really is actually fixed in Unity in Precise, or rather, bizarrely, it seems intermittently fixed. This morning, it was working ok, but now I have to be exactly over the very narrow border to resize the windows.

[Martin Pool (mbp)]

demonstration

[Martin Pool (mbp)]

hm, launchpad isn't linking it, but https://bugs.launchpad.net/unity-2d/+bug/160311/+attachment/2879264/+files/recording.ogv shows that it's actually still hard to grab the window border in precise.

[renbag (renbag)]

I confirm that in precise the invisible window borders are no more present and the resize process is again difficult.
Maybe this is because unity-window-decorator has been replaced by gtk-window-decorator?

[tekstr1der (tekstr1der)]

+1 confirmation that invisible borders are no longer active on 03/19/2012 daily build of Precise 12.04.

This behavior is extremely frustrating and brings back bad memories from this old bug. A temporary regression let's hope!

[Ingo Gerth (igerth)]

Oh my god I can not believe this bug returned recently in 12.04. What a regression! It's like a nightmare!

[Jan Bakuwel (jan-bakuwel-gmail)]

On 22/03/12 09:45, Ingo Gerth wrote:
> Oh my god I can not believe this bug returned recently in 12.04. What a
> regression! It's like a nightmare!
>

I am starting to think there must be an evil force trying to make the
Ubuntu desktop harder to use! First this really annoying persistent bug,
then Unity... :-P

[Martin Pitt (pitti)]

I am told that the next Unity release (due today or tomorrow) will fix this again.

[renbag (renbag)]

The bug affecting unity was really in compiz and is now marked as fixed:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/953839

[cmcginty (casey-mcginty)]

12.04 ... not fixed here. I think the devs must be all running MacOS.

[Martin Spacek (mspacek)]

Inexplicably, I think Canonical wants to clone MacOS as much as possible, without getting sued. Worst....interface......ever.

[cmcginty (casey-mcginty)]

I need to vent. The #1 comment in this thread, has at least a semi-valid workaround that requires 3 line changes, but it hasn't been released in 5 years? Somethign is really wrong with Cannonical that this is a lower priority than all the new UI "features"? Some people might not agree, I just hope Ubuntu gets back on track moving forward.

[Derrick Coetzee (o-dc)]

This problem or some related problem has come back for me after the 12.04 upgrade. On my 1920 x 1080 screen I am unable to click and drag on the lower-left, bottom, lower-right, left, or right resize handles at all, even if the resize mouse cursor is displayed. I can click and drag on the top-left, top, top-right handles with no trouble. This problem occurs when running in VMware but I don't remember having the same issue when running in native - might have to do with Unity2D vs Unity.

[Eric Feliksik (milouny)]

This is also confirmed at my system; the window resize area at the border is 1 pixel wide.
Ubuntu 12.04 with Gnome classic, no effects.
With the Unity mode, the borders are grabbable but the corner resize area is way too small.

[Bird (sbird)]

Same here. Impossible to resize by grabbing windows borders on 12.04 - 64-bit - 1920x1080 screen. Using the workaround seems to have fixed it.

[Greg Smolyn (smolyn)]

+1 on this problem. Running in VMware with Unity2D, Ubuntu 12.04.

[Lars Hansson (romabysen)]

In my experience this is only a problem in unity 2d and not in unity. Grabbing window borders and resizing is easy in Unity but a pain in Unity 2d.

[Michael Kraxner (michael-kraxner)]

This is 2012, usability is rated as minor important, seriously?

Seeing that this problem is known since 2007 drives me mad.

In the end these small things decide if a Ui supports you in doing your work, or make it a real pain.
I am glad that I found the work around - but editing some xml- config-file is not an option for most of the users. (why don't fix these themes?)

And don't get me wrong - I like Ubuntu, but it are the little things like this problem which prevent "common" users to use it, and that is really sad!

(Ubuntu 12.04, with Gnome classic, no effects.)

[John Lea (johnlea)]

@michael-kraxner; are you seeing this issue in Unity2d or Unity3d? thanks!

[nixomose (spamme-deadpelican)]

I recently installed xubuntu 12.04 and the 1px thing makes it impossible for me. I've always had problems with window borders, I'm spazzy with the mouse, but until now I've always been able to configure it larger.
But with 12.04, I've tried everything. I've changed the metacity-theme-1.xml file, somebody told me the size was based on the actual png image, so I changed all of those. Others have said try a different theme. I've done that plenty too. I'm a programmer, I get it, I'm willing to do whatever, but how can I actually go about changing the border width? I don't need you guys to change the defaults or make a pretty UI to make it configurable (though that would be nice) just tell me the byte offset in what file I need to make it bigger and I will be happy to do it myself, but nothing I do works. Help?

[Jonathan Reed (jdreed)]

The workaround in the first comment (editing the theme XML) works great. Is there any chance of seeing this in Quantal, or is Metacity considered dead in favor of Compiz as far as Canonical is concerned?

[Colin Law (colin-law)]

As I understand it unity-2d is to be removed in Quantal(12.10), emulation of 3d being provided by llvmpipe for hardware that does not support it, so that Unity (3d) will run. From that point of view it appears that this bug becomes irrelevant from 12.10. That is unless there are other use cases.

[Steve Flynn (anothermindbomb)]

On 21 August 2012 20:51, Colin Law <email address hidden> wrote:
> As I understand it unity-2d is to be removed in Quantal(12.10),
> emulation of 3d being provided by llvmpipe for hardware that does not
> support it, so that Unity (3d) will run. From that point of view it
> appears that this bug becomes irrelevant from 12.10. That is unless
> there are other use cases.

My laptop (Alienware m15x) has always ran Unity 3d and I've always
been presented with a touchpad that was unusable for consistently
being able to resize a window. Why is removing Unity 2d going to make
this any better?

--
Steve

When one person suffers from a delusion it is insanity. When many
people suffer from a delusion it is called religion.

[Colin Law (colin-law)]

Steve: because this bug is only about unity 2d with metacity. If you have an issue on unity (3d) then it is a different bug.

[sztomi (szelei.t)]

Is there a bug open for Unity3D?

[Ben Shadwick (benshadwick)]

Launchpad supports tracking a bug affecting multiple packages/projects, including tracking state and unique fixes for each of them. I don't see why Unity3D could not be tagged as affected if it indeed is.

[Pere Orga (pereorga)]

Same problem with Ubuntu 12.10

[Pere Orga (pereorga)]

I meant 10.12 :)

[Colin Law (colin-law)]

@Pere, I presume in fact you /did/ mean 12.10 as there was no 10.12. Since this bug is only for Unity-2d and there is no Unity-2d then this bug is not applicable to 12.10. If you are seeing it in the latest Unity then it is a different bug.

[Pere Orga (pereorga)]

Sorry for that, and yes, it's a different bug.

[Otus (jan-varho)]

Where's the bug for 12.10? Google doesn't find it, and the top border is still almost impossible to grab in Unity (3D).

[Alex (alecsandru-g)]

I'm using 12.10 and resizing windows is very very hard.

I find it a pity because it's such a basic usability problem.

[Aleve Sicofante (sicofante)]

Hey, five years and a half and grabbing handlers (not just windows resizers) is still buggy in Ubuntu.

What puzzles me is, why is it easy to grab the left, right and bottom edges of the screen and it's almost imposible to grab the top edge, pane borders in some apps and many other handlers? Isn't there a single way for grabbing a handler? Shouldn't it be? What's so difficult about it that it's taking those many years for such a basic feature on a GUI?

[Dan Kegel (dank)]

I suspect it's because they want to emulate how the Mac UI works, and the Mac only lets you grab the lower right corner.

[axel (x.)]

just seems to follow the trend of our time that others seem to know better whats good for you and use their power and ignorance to stick to their conviction ;)
contrary to aleve (#333) i find it harder to grab any edge other than the top one (i'm on unity-2d).
often having to use the touchpad of my notebook and resizing windows though it has been a pain for a long time now and its sad that the situation has not really improved.
at least this issue seems to have got some attention as hundredpapercuts seems to have this on their list. i just wonder where their fix (status released) will become visible...

[Sam Spilsbury (smspillaz)]

Unity-2D is not supported in never versions and does not have the same fix.

On Fri, Jan 4, 2013 at 2:17 PM, axel <email address hidden> wrote:
> just seems to follow the trend of our time that others seem to know better whats good for you and use their power and ignorance to stick to their conviction ;)
> contrary to aleve (#333) i find it harder to grab any edge other than the top one (i'm on unity-2d).
> often having to use the touchpad of my notebook and resizing windows though it has been a pain for a long time now and its sad that the situation has not really improved.
> at least this issue seems to have got some attention as hundredpapercuts seems to have this on their list. i just wonder where their fix (status released) will become visible...
>
> --
> 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 “human-gtk-theme” package in Ubuntu:
> Invalid
> Status in “light-themes” package in Ubuntu:
> Fix Released
> Status in “metacity” package in Ubuntu:
> Confirmed
> Status in “human-gtk-theme” source package in Maverick:
> Invalid
> Status in “light-themes” source package in Maverick:
> Triaged
> Status in “metacity” source package in Maverick:
> Triaged
>
> Bug description:
> *************
>
> 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: 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 t...

[axel (x.)]

> Unity-2D is not supported in never versions and does not have the same fix.

ah, thanks for that hint which explains while this bug is still on confirmed & critical for unity-2d.
lets see then if unity-2d ever will be fixed =)

[Sam Spilsbury (smspillaz)]

Not likely. Adding the invisible window borders to metacity's
non-composited mode is likely a nontrivial affair.

On Fri, Jan 4, 2013 at 2:59 PM, axel <email address hidden> wrote:
>> Unity-2D is not supported in never versions and does not have the same
> fix.
>
> ah, thanks for that hint which explains while this bug is still on confirmed & critical for unity-2d.
> lets see then if unity-2d ever will be fixed =)
>
> --
> 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 “human-gtk-theme” package in Ubuntu:
> Invalid
> Status in “light-themes” package in Ubuntu:
> Fix Released
> Status in “metacity” package in Ubuntu:
> Confirmed
> Status in “human-gtk-theme” source package in Maverick:
> Invalid
> Status in “light-themes” source package in Maverick:
> Triaged
> Status in “metacity” source package in Maverick:
> Triaged
>
> Bug description:
> *************
>
> 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: 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 ...

[James (morris-570)]

just want to say for those still stuck with this bug, and I'm not sure it's an option for you all. But I moved to lxde, and you might want to try a different window manager. This bug has been so persistent for so long I'm you might want to try and just find your own workround, i.e. a different window manager.

[Ben Shadwick (benshadwick)]

Yeah, my ultimate fix was to switch to Xubuntu.

[jono (jmackey)]

This bug is really annoying. Sufficiently annoying that I registered an account on launchpad just to post this comment.

I just got upgraded to ubuntu 12.04 on a machine where have no root access, so I can't hack any of the settings. It seems my only real option is to abandon gnome and use a different window manager.

[Melroy van den Berg (melroyvandenberg)]

Funny to see this bug is still not fixed sinds 2007 (6 YEARS AGO!!!)

[Sam Spilsbury (smspillaz)]

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
2. It isn't worth fixing in Unity-2D, since it would require extensive
patching to metacity's frame display code
3. Comments like these are not helpful.

>
> --
> 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 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 ...

[latimerio (fomember)]

I wonder who ever decided to have the window borders not configurable.

I work on a large screen and easily get RSI problems when I use the mouse too much.
Thus I use a wacom tablet with a stylus pen additionally as a mouse enhancement.
I always work with multiple windows and frequently rearrange them to suite my needs.

I also use focus follows mouse WITHOUT autoraise as I want to be able to cut and paste from a lower window to a top window without windows changing their order. I also want to type in a terminal which is half covered from firefox withouth the terminal coming to top and burying the browser text.

That said I want to resize my windows at ANY border not just in the corners or from the title bar.

On KDE 2 which I used for years this was no problem but with latest desktops the ergonomics seem to be overruled by designers.
I wish every GUI designer be at least 50 years of age so that eyesight degrading and parkinsons symptoms are on the verge :(

[Sam Spilsbury (smspillaz)]

Hi.

On Thu, Jan 31, 2013 at 3:21 PM, latimerio <email address hidden> wrote:
>
> That said I want to resize my windows at ANY border not just in the
> corners or from the title bar.

You already can.

There's a small amount of invisible padding on every side of the
window in Unity3D. This has been the only desktop installed since
12.10, and is the default desktop since 11.04.

Click and drag around the edges to resize the window.

Done.

--
Sam Spilsbury

[renbag (renbag)]

I use the attached script to increase the window borders to 4 pixels in ubuntu-2D and gnome-fallback. It must be placed in /etc/X11/Xsession.d/ and works in precise by writing configuration files in the directory $HOME/.themes of the current user.

[renbag (renbag)]

It seems that the attachment was not included in the previous message.

[Aleve Sicofante (sicofante)]

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)]

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...

[Aleve Sicofante (sicofante)]

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).

[Andrea Corbellini (andrea.corbellini)]

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.

[John Lea (johnlea)]

@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.

[MC Return (mc-return)]

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)]

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)]

Just added Unity as a project affected by this bug.

[Andrea Corbellini (andrea.corbellini)]

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.

[madbiologist (me-again)]

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)]

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.

[Andrea Corbellini (andrea.corbellini)]

> 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)]

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)]

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)]

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...

[Sam Spilsbury (smspillaz)]

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...

[Sam Spilsbury (smspillaz)]

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...

[Sam Spilsbury (smspillaz)]

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
>
> ...

[MC Return (mc-return)]

> 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. :)

[Melroy van den Berg (melroyvandenberg)]

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)]

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)]

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)]

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...

[Aleve Sicofante (sicofante)]

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)]

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...

[Aleve Sicofante (sicofante)]

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)]

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?

[Not Janet (u-need-xmpp+launchpad)]

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)]

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)]

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)]

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)]

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)]

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)]

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)]

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)]

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)]

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)]

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

[Aleve Sicofante (sicofante)]

> "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)]

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
>

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Melroy van den Berg (melroyvandenberg)]

After 7 years it is finally confirmed! :O

[JLuc (jluc-q)]

The 2010-04-24, gaspard.leon wrote that this bug would be fixed in 2015.

How are the newer 15.04 and 15.10 versions going relatively to this bug ?

[Colin Law (colin-law)]

@Jluc I believe it has been long fixed and is not seen in 15.04 or later. As in the first paragraph of the bug description it will not be fixed in Unity-2D.

[Ben Shadwick (benshadwick)]

Adding ubuntu-mate, as its window manager also suffers from 1-pixel wide resize grab areas.

This is one of the most immediately frustrating issues of any window manager, and it only gets worse as display pixel densities increase.

[Ben Shadwick (benshadwick)]

Here's a video recording of why 1-pixel grab bars are frustrating: https://www.youtube.com/watch?v=OeOldGSrsOg

[jedie (launchpad-net-jensdiemer)]

I tested 15.04 "Ubuntu MATE", "Lubuntu" and "Xubuntu"...

e.g.: the file managers:

* Xubuntu with thunar
* Lubuntu with PCManFM
* Ubuntu MATE with Caja

The problem with the small "resize area" exist on all :(

But the right/bottom area is big and good to grab on all three. (This is the "special" resize area)

Only MATE has also a little bigger areas on top left and top right corners...

[Martin Wimpress  (flexiondotorg)]

Alt + F8 on MATE will activate resize for the currently selected window.

[Rocko (rockorequin)]

Alt-F8 triggers resizing windows in compiz/Unity as well! That's good to know.

[vedavata (vedavrata)]

On XUbuntu (XFCE Ubuntu) 14.10 and 15.04 this bug is still has place. :-(

[Colin Law (colin-law)]

@vedavrata this bug applies to Unity, and is effectively closed. If you are seeing a problem on Xubuntu then I suggest you file a new bug.

[Jeremy Sequoia (jeremyhu)]

@colin-law no, this bug does not apply to Unity. This bug was filed years before Unity even existed. If it is "fixed" by changing to Unity, that's great for Unity users, but simply sweeping an issue under the rug because you changed window systems doesn't change the fact the the bug continues to exist in the windowing systems that the issue was reported against.

[Colin Law (colin-law)]

@Jeremy Huddleston, I see you are right, apologies (except that the fix appeared only in Unity-3D, it was worse in Unity-2D than it was before Unity-2D appeared). Does Xubuntu use Metacity? If not then my point is still valid, that it would be best to file a new bug for Xubuntu if the problem exists there, describing in detail exactly what the problem is.

[JohnWashington (ubuntu-johnwash)]

I don't even accept that it's adequately fixed in Unity (unless there's been significant progress since 14.04, for I only use LTS releases).

I teach elderly users with little or no experience of computers. Naturally many don't have good hand/eye coordination, so they need to be able to adjust settings easily to make the system fit their needs. One would expect this to be found under Settings / Universal Access, but there is nothing there that addresses this issue.

If you look at Windows XP (I'm not familiar enough with later versions to speak from memory) you can go into the control panel and set window borders to whatever width you want. After adjustment the result may not be as pretty, but when you're over 70 and unlikely to have a career in Hollywood, 'pretty' isn't high on your wish list, accessibility IS.

Please consider addressing this. It would be a boon if you can get it done before 16.04.

[cossio (cossio-0)]

Using Xubuntu here too. This bug makes it VERY hard to resize windows. It is also very hard to resize other draggable items, such as bars dividing panes inside windows.

[JohnWashington (ubuntu-johnwash)]

Seth, when you say 'Fix Released', does this mean that in System Settings there is now a means (using GUI tools only) for the user to modify the border width?

Anything less than that is, to my mind, not a 'fix'. And I suspect many others with hand/eye coordination problems would agree it's not a fix. Ubuntu has traditionally aimed at inclusiveness, it should be striving to meet the needs of many, not just young people who are fortunate to have full health. Making the border width easily modifiable would be a step towards making it more inclusive.

[madbiologist (me-again)]

JohnWashington - This bug is about the default resize grab handle at window borders being too small (1 pixel, or 4 pixels by some accounts) to be easily usable. This has been fixed with the implementation of a larger default resize grab handle (10 pixels I think). The mouse pointer does not show up when I take a screenshot.

If you want a user-configurable resize grab handle it is probably best to open a new bug report.

[vedavata (vedavrata)]

22/09/2015 17:21 "madbiologist" <email address hidden> :
>
> JohnWashington - This bug is about the default resize grab handle at
> window borders being too small (1 pixel, or 4 pixels by some accounts)
> to be easily usable. This has been fixed with the implementation of a
> larger default resize grab handle (10 pixels I think).

Why I cannot note this?
It seems to me, that it's still needed to try to catch 4 pixels, not 10 or
wider?..

[Colin Law (colin-law)]

@vedavata I imagine that it is because (according to comment #397 you are using Xubuntu. This bug is about Unity, where it has been fixed. If you have a problem on Xubuntu you should file a bug for that or extend this bug to Xubuntu. I don't know what the appropriate package on Xubuntu would be.

[JohnWashington (ubuntu-johnwash)]

Madbiologist: you write "This bug is about the default resize grab handle at window borders being too small".

Can I gently suggest you read the title of this problem report?

"Resizing windows by grabbing window borders is difficult"

Window borders. Nothing about a resize grab handle (which I assume is the region in the lower right of some desktop's windows, is that so?). And also read the substance of post #1. It's about window borders.

I'm sorry, but if you think the solution to a request for set-ability of window borders is to provide a feature in one corner of the window, I feel you've misunderstood. No doubt that feature is indeed a useful fix for some bugs and feature requests, but not, I believe, this one.

So I would request this bug's status be changed. Fixed is not correct.

[madbiologist (me-again)]

I am sorry for being unclear. I was referring to the entire edges of the window, not just the lower right corner. I didn't use the word "border" because now the area available for grabbing extends outside of the admittedly narrow border. All window borders are now surrounded by an invisible/transparent grabbable area, which is larger than it was when this bug was reported. I was hoping to demonstrate this with a screenshot but the mouse pointer does not show in screenshots. I agree that it would be even better if the size of this area was user-configurable, but that will probably receive more attention if filed as a new bug.

[JohnWashington (ubuntu-johnwash)]

Madbiologist: thanks for clarifying. So I agree filing it as a new bug would be good. I'm not an appropriate person to do that, since I'm using Unity less and less, and even in the past I've only used LTS releases. I hope someone will pick this up.