Comment 364 for bug 160311

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Re: [Bug 160311] Re: Resizing windows by grabbing window borders is difficult

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 older codebases, but actively supporting older releases,
especially for a product that is free of charge wouldn't be a large
part of any corporate strategy. Think staff training costs, patch
burdens over multiple releases etc.

In any case, I didn't meant to offend, and I apologize if my frank
tone was offensive. What I meant to cover with my third point was
stuff like this (which you will notice my comment was in direct reply
to):

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

Having a nagging tone with developers doesn't actually promote your
bug in the queue. In fact, its a real turn off for most developers,
and will likely cause them to ignore or mentally reduce the importance
of the bug or reporter in question. As the person who spent a few
weeks perfecting the implementation of this fix, I find it offensive
that others would comment on bug reports with such ignorance. Its a
continual theme across multiple bug reports on multiple open source
projects and I can assure you its a very common cause of developer
de-motivation, burnout, frustration, depression and eventually
departure.

Commentators should keep this in mind when posting. Developers thrive
from co-operation and common enthusiasm. They don't thrive in
environments when someone tries to tell them that item #217 out of 480
on their list if apparently more important than anything else.

--
Sam Spilsbury