Re: [Bug 160311] Re: Resizing windows by grabbing window borders is difficult
2011/12/22 u-foka ta...@eisenberger.hu 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 a member of Ubuntu Desktop Bugs, which is subscribed to metacity in Ubuntu. 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 160311] Re: Resizing windows by grabbing window borders is difficult
2011/12/21 John Lea 160...@bugs.launchpad.net @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). -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in Ubuntu. 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 160311] Re: Resizing windows by grabbing window borders is difficult
2011/12/21 John Lea 160...@bugs.launchpad.net @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). -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in Ubuntu. 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 811689] Re: gnome-panel crashed with SIGSEGV in g_closure_invoke()
I can confirm the issue with gnome-shell. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-panel in Ubuntu. https://bugs.launchpad.net/bugs/811689 Title: gnome-panel crashed with SIGSEGV in g_closure_invoke() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/811689/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 160311] Re: Resizing windows by grabbing window borders is difficult
2011/8/21 RussianNeuroMancer 160...@bugs.launchpad.net Now it's again issue in Oneiric. In both unity and unity2d. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in Ubuntu. 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 160311] Re: Resizing windows by grabbing window borders is difficult
2011/8/21 Sam Spilsbury smspil...@gmail.com 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? -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in Ubuntu. 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 160311] Re: Resizing windows by grabbing window borders is difficult
#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. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. https://bugs.launchpad.net/bugs/160311 Title: Resizing windows by grabbing window borders is difficult -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 160311] Re: Resizing windows by grabbing window borders is difficult [please no more comments; patches welcome]
2011/1/24 Neilen Marais launch...@chatsubo.lagged.za.net 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. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. https://bugs.launchpad.net/bugs/160311 Title: Resizing windows by grabbing window borders is difficult [please no more comments; patches welcome] -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 160311] Re: Resizing windows by grabbing window borders is difficult
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? -- Resizing windows by grabbing window borders is difficult https://bugs.launchpad.net/bugs/160311 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 160311] Re: Resizing windows by grabbing window borders is difficult
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?) -- Resizing windows by grabbing window borders is difficult https://bugs.launchpad.net/bugs/160311 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 558327] Re: Window close button is clickable anywhere in the corner
Personally speaking, I cannot think of any application that will destroy data if you accidentally hit the close button. They will either prompt you whether you wish to save first (OpenOffice, Gimp, Gedit, Evolution, the scan app, ...) or they will be able to resume from where you left (Firefox, Chromium, ...) The too easy to lose data argument is a strawman at best. 2010/7/23 inane inane...@gmail.com There are at least as many people that think this fix is a bug itself: https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/564749 Let me express my logic here: 1. Button is too easy to hit. Ok, why is this a bug? The only possible reason I could think of is that it's too easy to hit and lose your data. So the question should be, why is it so easy to lose your data when you close an application? So the real but here should look like this: 1. Too easy to lose data when closing application. The solution for this is to make it so that applications PROTECT THE DATA BETTER. -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a direct subscriber of the bug. Status in “light-themes” package in Ubuntu: Fix Released Status in “metacity” package in Ubuntu: Fix Released Bug description: Binary package hint: light-themes The close button, now that it is in the corner, is too clickable because it is possible to click anywhere to the left of it and still activate it. That makes the close button quite a bit larger than the other two buttons, when it should be the same size. The space to the left of the button, between the button and the edge of the window, should not be clickable. To unsubscribe from this bug, go to: https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/558327/+subscribe -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 558327] Re: Window close button is clickable anywhere in the corner
Why would you click above or to the side of the close button on a maximized window, if not by mistake? What would you expect to happen in that case? 2010/7/23 David Stansby dstan...@gmail.com For me the problem isn't too easy to close. If I press the close button I expect the window to close. But if I press an area near to the close button which looks like part of the application bar I don't expect the application to close, I expect it to do whatever clicking on the application bar elsewhere would do. Personally I think that is the reason behind the original bug, and why I think it is a valid bug that needed a fix. -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a direct subscriber of the bug. Status in “light-themes” package in Ubuntu: Fix Released Status in “metacity” package in Ubuntu: Fix Released Bug description: Binary package hint: light-themes The close button, now that it is in the corner, is too clickable because it is possible to click anywhere to the left of it and still activate it. That makes the close button quite a bit larger than the other two buttons, when it should be the same size. The space to the left of the button, between the button and the edge of the window, should not be clickable. To unsubscribe from this bug, go to: https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/558327/+subscribe -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 558327] Re: Window close button is clickable anywhere in the corner
Of course it makes sense to have different behavior when the window is maximized. The use case is completely different. Anyway, this is not a forum so I'm bailing out. 2010/7/23 David Stansby dstan...@gmail.com I wouldn't in that case, but I would when my window wasn't maximized, and it wouldn't really make much sense to have different behavior when the window was maximized -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a direct subscriber of the bug. Status in “light-themes” package in Ubuntu: Fix Released Status in “metacity” package in Ubuntu: Fix Released Bug description: Binary package hint: light-themes The close button, now that it is in the corner, is too clickable because it is possible to click anywhere to the left of it and still activate it. That makes the close button quite a bit larger than the other two buttons, when it should be the same size. The space to the left of the button, between the button and the edge of the window, should not be clickable. To unsubscribe from this bug, go to: https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/558327/+subscribe -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 558327] Re: Window close button is clickable anywhere in the corner
I am afraid you are slightly mistaken. In the default configuration, you used to be able to throw the mouse to the right edge of the screen and only aim vertically for the close button. While this is more difficult than throwing the mouse to the corner, it is significantly easier than aiming a 16x16 area as we currently must. Please note that this issue is less apparent the smaller the screen area is. It is (almost) a non-issue on a 1280x800 laptop monitor but it is most definitely an issue on a 1920x1200 or 2560x1600 monitor - and doubly so when using multiple monitors. For what it's worth, the New Wave theme does not suffer from this issue, so a simple, temporary workaround exists. 2010/7/22 Mark Shuttleworth 558...@bugs.launchpad.net On 21/07/10 23:29, inane wrote: Ok, I'd like to chime in here a moment, this whole not being able to throw my mouse into the corner is amazing asinine, this is a behavior that I have come to know and love for YEARS now with GNOME, and it's gone without even the option to set it back. I take it then that you've been using a custom panel configuration? Because in the default Ubuntu config, the top left corner has the Applications menu in it, and the top right corner has the Session menu in it. In other words, the throw it in the corner and click to close the window capability is not a feature of Ubuntu pre 9.10. Our position on this is that the corner is reserved for access to applications, or shutting down the machine. If you want to close the window you need to click on the button for closing the window. Mark -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a direct subscriber of the bug. Status in “light-themes” package in Ubuntu: Fix Released Status in “metacity” package in Ubuntu: Fix Released Bug description: Binary package hint: light-themes The close button, now that it is in the corner, is too clickable because it is possible to click anywhere to the left of it and still activate it. That makes the close button quite a bit larger than the other two buttons, when it should be the same size. The space to the left of the button, between the button and the edge of the window, should not be clickable. To unsubscribe from this bug, go to: https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/558327/+subscribe -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 160311] Re: Resizing windows by grabbing window borders is difficult
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! -- Resizing windows by grabbing window borders is difficult https://bugs.launchpad.net/bugs/160311 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 160311] Re: Resizing windows by grabbing window borders is difficult
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). ** Attachment added: ambience-5px-bug.png http://launchpadlibrarian.net/48033272/ambience-5px-bug.png -- Resizing windows by grabbing window borders is difficult https://bugs.launchpad.net/bugs/160311 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 160311] Re: Resizing windows by grabbing window borders is difficult
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. -- Resizing windows by grabbing window borders is difficult https://bugs.launchpad.net/bugs/160311 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 160311] Re: Resizing windows by grabbing window borders is difficult
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. ** Patch added: Patch file to increase border size from 1 to 5. Attempts to work around the resulting visual glitches (glitch around menubar unfortunately remains). http://launchpadlibrarian.net/47045357/metacity-theme-1.xml.diff -- Resizing windows by grabbing window borders is difficult https://bugs.launchpad.net/bugs/160311 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 558327] Re: Window close button is clickable anywhere in the corner
One possible compromise is to enable infinite width only for maximized windows. This is very useful for us with touchpads. Attached patch implements infinite width and height for maximized windows. ** Patch added: Implement infinite width/height for maximized windows. http://launchpadlibrarian.net/47045997/metacity-theme-1.xml.diff -- Window close button is clickable anywhere in the corner https://bugs.launchpad.net/bugs/558327 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 508632] Re: Toggle button for Nautilus location field gone
The issue with Ctrl-L is that *it is not a toggle*. Once you enter text mode, you cannot press Ctrl-L again to move back to button mode. Yes, this was a very useful feature: enter text mode to navigate to some distant path, then go back to buttons when you reach that. A common use case: 1. say you are in ~/Desktop and wish to go to /etc/apt. With buttons, this is 3 cilcks (go up to root) and 2 double clicks (etc and apt). With text mode, it's one click (toggle text mode) and 8 letters (/etc/apt). 2. once you reach /etc/apt, say you wish to navigate forward and backward in directories that are close togethere (say, under /etc). Button mode is superior here, because it acts as a visual, short-term history (it shows the last few locations you visited under your current path, which is very useful when e.g. copying files or looking for something specific). This was yet another regular part of my daily workflow, now removed. Way to go, I guess. ( Troll mode on: Alt-F4 closes the window, plus we have a menu entry for Close. Why triplicate the functionality with a close button? It's superfluous. Troll mode off: in some cases, duplication is significantly more efficient. Removing the toggle button effectively removes any hint of this feature's existence from the majority of Gnome's user base. ) Do note that Windows Vista/7 has a more efficient implementation of this very feature: the address bar doubles up as a button bar (default mode) and a text bar (when clicked on the left or right). No button, similar functionality. In fact, this was one of the major improvements over the older, text-only address bar on Windows XP. -- Toggle button for Nautilus location field gone https://bugs.launchpad.net/bugs/508632 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 537286] [NEW] Very slow login after disabling gnome-panel
Public bug reported: Binary package hint: gnome-panel System information: Karmic amd64, 2.5GB RAM, Intel 80GB SSD, Nvidia binary drivers (195.36.08). Users of 3rd party docks, like AWN, docky or cairo-dock, frequently disable gnome-panel completely. Unfortunately, this results in a strange bug, where subsequent gdm logins become significantly slower. How to reproduce: 1. Run gconf-editor, head to desktop/gnome/session/required_components and rename gnome-panel to something else (e.g. gnome-panel.disabled). 2. Log out and log in again. The log in takes at least 5x longer than before. 3. Re-enable gnome-panel (follow step 1 and rename gnome-panel.disabled to gnome-panel). 4. Log out and log in again. The log in takes the normal amount of time. This is reproducible without installing AWN, docky or any other dock application, which means it is a bug in gnome-panel or something else in the login sequence that relies on gnome-panel. I have tried disabling startup applications in case one of those was causing the issue, but this didn't change anything. The only variable is gnome-panel: disable it and login is slow, enable it and login is fast. As a measure of the change in login performance, fast translates into 3 bar movements in the ubuntu logo, while slow translates into 15.5 bar movements. ** Affects: gnome-panel (Ubuntu) Importance: Undecided Status: New -- Very slow login after disabling gnome-panel https://bugs.launchpad.net/bugs/537286 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-panel in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 537286] Re: Very slow login after disabling gnome-panel
Thanks for the prompt reply, I can confirm that the issue disappears after uninstalling xsplash. -- Very slow login after disabling gnome-panel https://bugs.launchpad.net/bugs/537286 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-session in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 478219] Re: libgtk1.2 missing on karmic
I've also managed a similar solution on amd64, by unpacking the jaunty packages with dpkg -x and manually copying then files to /usr/lib. (This is very evil and I wouldn't recommend it in the general case.) -- libgtk1.2 missing on karmic https://bugs.launchpad.net/bugs/478219 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gtk+1.2 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 478219] Re: libgtk1.2 missing on karmic
This issue prevents me from installing my printer drivers. Are there any known workarounds? -- libgtk1.2 missing on karmic https://bugs.launchpad.net/bugs/478219 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gtk+1.2 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 400888] Re: Extreme Memory Leak in gnome-panel
I am also experiencing this issue (Jaunty amd64, 2.5GB of RAM *without* swap file as I am running from a USB stick). Memory consumption after 2 days is 138MB and growing. I have my panel set to autohide, which *might* have something to do with the issue. -- Extreme Memory Leak in gnome-panel https://bugs.launchpad.net/bugs/400888 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 190227] Re: ia32 apps look for libs on the wrong place
/usr/lib32/gtk-2.0/modules/libgail.so was removed from ia32-libs for some reason I can confirm this - anyone knows why? -- ia32 apps look for libs on the wrong place https://bugs.launchpad.net/bugs/190227 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gtk+2.0 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 54024] Re: WIN key SUPER_L should be mapped to Applications menu
On Thu, 2009-06-25 at 21:27 +, Sam Stenvall wrote: Currently I have it set up so that when I press the Super key, all windows are minimized. This is ONLY because it is not possible to create a keyboard shortcut like Super+D (which would be the Windows equivalent to minimizing all windows and focusing on the desktop). You can do this by mapping Super_L to Meta in your keyboard layout options. This is the very first thing I do when I install any Linux distro. -- WIN key SUPER_L should be mapped to Applications menu https://bugs.launchpad.net/bugs/54024 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48671] Re: Cannot rename by clicking on a file
Most rookie users I know, rename files by right clicking and selecting 'rename' (both on WIndows and on Ubuntu). More savvy ones press F2. The click, wait, then click again pattern falls somewhere in between - I personally find it annoying and avoid it (hence like Gnome), but others swear by it. Maybe a usability study would shed some light here. Adding more options is somewhat like saying we don't know, decide yourself, which clashes somewhat with Gnome standards. -- Cannot rename by clicking on a file https://bugs.launchpad.net/bugs/48671 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54024] Re: WIN key SUPER_L should be mapped to Applications menu
Right now, is there a way to map Super_L to open the application menu *and* be usable in two-key shortcuts (e.g. Super_L+D to minimize windows), *without* modifying source code? If so, it would make sense to make this default in Ubuntu. -- WIN key SUPER_L should be mapped to Applications menu https://bugs.launchpad.net/bugs/54024 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
