On Thu, Jan 31, 2013 at 8:36 PM, madbiologist <160...@bugs.launchpad.net> 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 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to light-themes in Ubuntu. 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 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 manage notifications about this bug go to: https://bugs.launchpad.net/ayatana-design/+bug/160311/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
