[Bug 507799] Re: Ctrl-Fn shortcuts for switching windows sometimes have to be pressed twice

2012-07-02 Thread David Fraser
I'm no longer using Gnome; for what it's worth, the above behaviour doesn't occur in XFCE on Ubuntu 12.04 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-settings-daemon in Ubuntu. https://bugs.launchpad.net/bugs/507799 Title:

[Bug 36812] Re: Keyboard layout change on hotkeys press instead of release and do not work well with shortcuts

2010-02-11 Thread David Fraser
Ah, my problem was misunderstanding the SCIM config See http://www.scim-im.org/forums#nabble-td4554222|a4554222 Basically I found that in the SCIM Global Setup I had Shift-Control-KeyRelease-Shift_L, Shift-Control-KeyRelease-Shift_R, Shift-Control-KeyRelease-Control_L, and

[Bug 507799] Re: Ctrl-Fn shortcuts for switching windows sometimes have to be pressed twice

2010-02-11 Thread David Fraser
I have also tested with SCIM entirely disabled, and the bug remains ** Changed in: scim Status: New = Invalid -- Ctrl-Fn shortcuts for switching windows sometimes have to be pressed twice https://bugs.launchpad.net/bugs/507799 You received this bug notification because you are a member

[Bug 507799] Re: Ctrl-Fn shortcuts for switching windows sometimes have to be pressed twice

2010-02-11 Thread David Fraser
Added log from xev of the problem ** Attachment added: Log of xev from pressing and releasing Control http://launchpadlibrarian.net/39058734/xev-ctrl-F2-507799.log -- Ctrl-Fn shortcuts for switching windows sometimes have to be pressed twice https://bugs.launchpad.net/bugs/507799 You

[Bug 36812] Re: Keyboard layout change on hotkeys press instead of release and do not work well with shortcuts

2010-02-10 Thread David Fraser
I've tried the patch and it allows me to use my Ctrl-Shift shortcuts, but the SCIM dialog still pops up when I release one of Ctrl or Shift despite having pressed keys in between. Is this expected? How can I find where the Ctrl-Shift mapping is defined (it's not in GNOME shortcuts or SCIM

[Bug 507799] [NEW] Ctrl-Fn shortcuts for switching windows sometimes have to be pressed twice

2010-01-14 Thread David Fraser
Public bug reported: Binary package hint: gnome-settings-daemon Since upgrading from karmic to jaunty, my Ctrl-F1 to Ctrl-F5 keyboards that are defined for switching workspaces aren't working consistently I have checked that they are still defined in the Keyboard Shortcuts window, and tried

[Bug 203782] Re: Support low color depth to improve speed

2009-12-18 Thread David Fraser
Backported @bojo42's build from #30 to jaunty in my ppa: https://launchpad.net/~davidf/+archive/ppa -- Support low color depth to improve speed https://bugs.launchpad.net/bugs/203782 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to

[Bug 312126] Re: Custom browser does not receive URL at %s

2009-08-03 Thread David Fraser
Yes this is still an issue in jaunty, I can reproduce exactly as described above -- Custom browser does not receive URL at %s https://bugs.launchpad.net/bugs/312126 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to libgnome in ubuntu. --

[Bug 312126] Re: Custom browser does not receive URL at %s

2009-08-03 Thread David Fraser
Ah, looking at the source, apparently it's meant to have a %u or %U, not a %s. In that case it gets substituted OK, but with extra 'quotes' which prevents firefox from parsing it OK: firefox -P default -remote openurl('http://google.com/', new-tab) -- Custom browser does not receive URL at %s

[Bug 203782] Re: Support low color depth to improve speed

2009-07-24 Thread David Fraser
** Also affects: gtk-vnc Importance: Undecided Status: New -- Support low color depth to improve speed https://bugs.launchpad.net/bugs/203782 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vinagre in ubuntu. -- desktop-bugs

[Bug 203782] Re: Support low color depth to improve speed

2009-07-24 Thread David Fraser
My bad - gtk-vnc does support various lossy encoding options ** Changed in: gtk-vnc Status: New = Invalid -- Support low color depth to improve speed https://bugs.launchpad.net/bugs/203782 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is

[Bug 203782] Re: Support low color depth to improve speed

2009-07-24 Thread David Fraser
Started working on a patch that I attached to the upstream bug. -- Support low color depth to improve speed https://bugs.launchpad.net/bugs/203782 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vinagre in ubuntu. -- desktop-bugs

[Bug 342436] Re: Ctrl-End and End are indistinguishable on gnome-terminal

2009-03-18 Thread David Fraser
However evilvte and xfce4-terminal both show the same problem as gnome- terminal: ^[OF 27 0033 0x1b 79 0117 0x4f 70 0106 0x46 ^[OF 27 0033 0x1b 79 0117 0x4f 70 0106 0x46 This indicates that the bug is in vte -- Ctrl-End and End are indistinguishable on gnome-terminal

[Bug 342436] Re: Ctrl-End and End are indistinguishable on gnome-terminal

2009-03-18 Thread David Fraser
Switching to vte as that's where the underlying bug must be ** Changed in: vte (Ubuntu) Sourcepackagename: gnome-terminal = vte -- Ctrl-End and End are indistinguishable on gnome-terminal https://bugs.launchpad.net/bugs/342436 You received this bug notification because you are a member of

[Bug 342436] Re: Ctrl-End and End are indistinguishable on gnome-terminal

2009-03-18 Thread David Fraser
** Bug watch added: GNOME Bug Tracker #375652 http://bugzilla.gnome.org/show_bug.cgi?id=375652 ** Also affects: vte via http://bugzilla.gnome.org/show_bug.cgi?id=375652 Importance: Unknown Status: Unknown -- Ctrl-End and End are indistinguishable on gnome-terminal

[Bug 342436] Re: Ctrl-End and End are indistinguishable on gnome-terminal

2009-03-17 Thread David Fraser
On xterm: dav...@golg:~$ showkey -a Press any keys - Ctrl-D will terminate this program ^[[F 27 0033 0x1b 91 0133 0x5b 70 0106 0x46 ^[[1;5F 27 0033 0x1b 91 0133 0x5b 49 0061 0x31 59 0073 0x3b 53 0065 0x35 70 0106 0x46

[Bug 96676] Re: [feisty] function keys don't work in gnome-terminal

2009-03-13 Thread David Fraser
Ctrl-End also has a problem; it seems to produce exactly the same codes as End using showkey -s -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug

[Bug 96676] Re: [feisty] function keys don't work in gnome-terminal

2009-03-13 Thread David Fraser
Indeed; filed bug 342436 - showkey only seems to work as root, which probably deserves another bug -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug

[Bug 342436] [NEW] Ctrl-End and End are indistinguishable on gnome-terminal

2009-03-13 Thread David Fraser
Public bug reported: Binary package hint: gnome-terminal In gnome-terminal, there seems to be no difference between pressing End and Ctrl-End (see the showkey results below; as a separate bug, showkey only seems to work when running as root) r...@golg:~# showkey -a Press any keys - Ctrl-D will

[Bug 128947] Re: could not find encoding profile cdlossy im Musikplayer

2009-02-27 Thread David Fraser
The bug is actually quite clear, and I've had it too: If you try and extract files from a CD, you get the message: could not find encoding profile cdlossy If you go to Preferences/Music the preferred format is listed as something else (ogg in my case) If you then Edit the list of formats (next

[Bug 312126] [NEW] Custom browser does not receive URL at %s

2008-12-29 Thread David Fraser
Public bug reported: I have used the Preferred Applications dialog to set up a custom browser function, so that I can tell firefox to open the URL in a new tab in a particular profile (I always have two firefox instances open with different profiles): firefox -P default -remote openurl(%s,

[Bug 312126] Re: Custom browser does not receive URL at %s

2008-12-29 Thread David Fraser
This seemed to start after the upgrade to Intrepid -- Custom browser does not receive URL at %s https://bugs.launchpad.net/bugs/312126 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to libgnome in ubuntu. -- desktop-bugs mailing list

[Bug 312126] Re: Custom browser does not receive URL at %s

2008-12-29 Thread David Fraser
This also happens with xdg-open, and I'm not sure which calls which... ** Also affects: xdg-utils Importance: Undecided Status: New -- Custom browser does not receive URL at %s https://bugs.launchpad.net/bugs/312126 You received this bug notification because you are a member of Ubuntu

[Bug 312126] Re: Custom browser does not receive URL at %s

2008-12-29 Thread David Fraser
Looked in the source and gnome-open just calls the glib g_app_info_launch_default_for_uri function, which I suspect ends up forwarding to g_desktop_app_info_launch_uris which does the actual paremeter expansion, so adding Glib package... ** Also affects: glib Importance: Undecided

[Bug 242713] Re: Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

2008-09-20 Thread David Fraser
Here's my pm-suspend.log. The only problem mentioned is: * Reconfiguring network interfaces... ppp0: ERROR while getting interface flags: No such device ** Attachment added: pm-suspend from resume with beeps http://launchpadlibrarian.net/17787235/pm-suspend.log -- Suspends that are longer

[Bug 242713] Re: Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

2008-09-19 Thread David Fraser
Got exactly the same symptoms after last night's suspend... -- Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail https://bugs.launchpad.net/bugs/242713 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is

[Bug 242713] Re: Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

2008-09-19 Thread David Fraser
No but I have dmesg and kern.log and messages - I've added pm- suspend.log to my capture script so I should have one soon... -- Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail https://bugs.launchpad.net/bugs/242713 You received this bug notification

[Bug 242713] Re: Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

2008-09-18 Thread David Fraser
Bother, I've just seen it looks like I've got the wrong version. Unfortunately that's what I got from hardy-proposed (and apt-get upgrade -t proposed doesn't show anything else)... -- Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

[Bug 242713] Re: Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

2008-09-18 Thread David Fraser
I've tested this. Normal (short-term) suspend and hibernate work normally. However, on my first overnight (9 hour) suspend and resume, I still got the beeping sound and the message saying suspend failed to work properly. I can attach any relevant log files if that would help (just tell me what,

[Bug 242713] Re: Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

2008-09-18 Thread David Fraser
OK, I've investigated and I was wrong about the version; 2.22.1-1ubuntu4.1 looks like it does have the fix (I'm on hardy). I've looked at /var/log/kern.log and it seems bizarrely as though some of the suspend code ran after the resume (although I could see that the machine had a flashing light

[Bug 242713] Re: Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

2008-09-18 Thread David Fraser
** Attachment added: /var/log/kern.log from the time of the suspend till resume is completed (this reported failure) http://launchpadlibrarian.net/17716864/kern.log-relevant -- Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail