[Bug 39363] Re: Arrow keys do not open and close threads
I still have this problem in Ubuntu 10.04, Evolution 2.28.3. The only way I can collapse/expand threads is Shift-- and Shift-+. This is pretty useless for quick navigation. -- Arrow keys do not open and close threads https://bugs.launchpad.net/bugs/39363 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 39363] Re: Arrow keys do not open and close threads
Still a problem in 10.04, improved but not actually fixed. ** Changed in: evolution (Ubuntu) Status: Fix Released = New -- Arrow keys do not open and close threads https://bugs.launchpad.net/bugs/39363 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 39363] Re: Arrow keys do not open and close threads
I looked at the upstream bug, it seems like they wanted to enable Shift- Left and Shift-Right, whereas the standard in all other applications I've used is Left and Right. The shortcuts of Shift-Left, Shift-Right, Shift-+, and Shift-- are not discoverable. It took me a substantial amount of googling to even find this page. Upstream needs to fix this to be Left/Right. -- Arrow keys do not open and close threads https://bugs.launchpad.net/bugs/39363 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 651611] [NEW] Cannot disable Evolution mail notification bubble
Public bug reported: Binary package hint: evolution 1) Go into Edit-Plugins and uncheck the box next to Mail Notification 2) Restart Evolution 3) Wait to get some new mail Result: You will still see an annoying notification bubble in the right-hand corner of the screen Expected: No notification bubble. Workaround: 1) gconf-editor /apps/evolution/eplugin/mail-notification/ 2) Remove checkbox next to status-notification ** Affects: evolution (Ubuntu) Importance: Undecided Status: New -- Cannot disable Evolution mail notification bubble https://bugs.launchpad.net/bugs/651611 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to evolution in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 651611] Re: Cannot disable Evolution mail notification bubble
Actually, even the gconf-editor steps did not help. I tried disabling most all the other gconf checkboxes, to no avail. Also tried Broadcast Preferences in System - Settings, no effect. I doubt it's the mail-notification plugin, because I tried this too: 1) sudo mv /usr/lib/evolution/2.28/plugins/liborg-gnome-mail-notification.so ~/ 2) Restart Evolution Still get notifications. Tried: killall evolution-alarm-notify Nothing. Tried: removing Indicator Applet from the panel. No change. I like the indicator applet. It's unobtrusive. Same goes for Indicator Session Applet. Tried: killall update-notifier. Still nothing. Tried: 1) sudo mv /usr/lib/indicator* ~/ 2) killall indicator-*-service That breaks the indicator applet, which is kind of sad. Still get the bubbles, though. Tried: 1) mv /usr/lib/notify-osd/ ~/ 2) killall notify-osd The infernal annoyance is gone! *victory dance* Try working with this stuff when you get 60 messages an hour. An interruption every minute? No thanks. According to this page, https://wiki.ubuntu.com/NotifyOSD#evolution this bubble is supposed to be controlled by the plugin, which I deleted a while back. What gives? -- Cannot disable Evolution mail notification bubble https://bugs.launchpad.net/bugs/651611 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to evolution in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 490704] Re: suspend keyboard shortcut does not work
You're right. I see exactly the same behavior when running metacity -- screen blanks momentarily (something like DPMS force off), and everything comes back. ** Package changed: compiz (Ubuntu) = gnome-settings-daemon (Ubuntu) -- suspend keyboard shortcut does not work https://bugs.launchpad.net/bugs/490704 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-settings-daemon in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 229465] Re: Wide text in wide VTE windows is extremely slow
I'm getting more and more convinced that this is is an fglrx issue. I'll post the details once I have a better idea of what's going on. -- Wide text in wide VTE windows is extremely slow https://bugs.launchpad.net/bugs/229465 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 229465] Re: Wide text in wide VTE windows is extremely slow
Thanks for the link to the upstream bug. I don't think it's the same. However, I did find one that seems related, except that it was fixed a major release ago. http://bugzilla.gnome.org/show_bug.cgi?id=410534 I also have the fglrx driver, and it seems like the analysis and symptoms are very close to mine. I'm going to see whether this is a regression. Do you want me to move my bug report upstream? Another piece of evidence pointing in the same direction: on an system with NVIDIA drivers, this bug does not happen. -- Wide text in wide VTE windows is extremely slow https://bugs.launchpad.net/bugs/229465 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 229465] [NEW] Wide text in wide VTE windows is extremely slow
Public bug reported:
Binary package hint: libvte9
This refers to the Ubuntu 7.10 Gutsy version of vte (0.16.9). However, I
just built vte 0.16.13 (hardy), and the bug remains (I made sure it was
using the right library using strace). I refer to gnome-terminal in the
rest of the bug, but I get the exact same behavior in xfce4-terminal,
and in the vte test app.
Here's an experiment, done on an idle system (Pentium M 2 Ghz, 1GB RAM),
with gnome-terminal in the foreground, maximized. My font setup is
monospace 12, with subpixel antialiasing. My scrollback is 5000 lines.
$ resize
COLUMNS=191;
LINES=57;
export COLUMNS LINES;
$ date XXX; time (for ((i=0;i1000;++i)); do echo
{a,b}{b,c}{c,a}{d,a}{q,f,e}{z,c,s}; done; echo _all_)
[snip]
_all_
real1m30.833s
user0m0.596s
sys 0m0.012s
$ date
Mon May 12 02:33:08 EDT 2008
$ cat XXX
Mon May 12 02:31:26 EDT 2008
I typed date while it was scrolling, and as soon as it finished, I hit
Enter. As you can see, time lies about the wall time a bit, because
the rendering is so horrendously slow. According to my date
measurement, the wall time is actually 1:42. My reaction time is not
that slow (see konsole experiment below).
Timings of the same experiment (I report the time value because it's
easier): 80x24 -- 1.2s, 80x59 -- 3s, 130x24 -- 1.8s, 191x24 -- 35s,
181x24 -- 2.5s, 186x24 -- 2.5s, 190x24 -- 30s.
But, if I change the string being printed (e.g. by replacing echo ...
with echo $i ...), then 189x24 suddenly becomes slow again (16s).
Maybe it depends on the pattern of spaces/newlines in the text being
displayed?
This manifests itself when I edit wide files, or cat a wide file, and
page through it. In both cases, refreshes can sometimes take as long as
5-7 seconds, even when I'm simply paging through the scrollback with
Shift-PageUp and Shift-PageDown. It seems to depend quite a bit on the
data -- again, I'm surmising something having to do with newlines or
spaces?
In fact, on the various wide data files on my disk, I feel slowness down
to terminal width 120, at which point it abruptly disappears.
I repeated the above experiments a couple of times -- the times are
fairly consistent. It did not seem to matter whether I used gnome-
terminal --geometry, or resized the window after startup.
Now, for the really weird thing. On my screen, 191x24 is almost the full
width of the screen. If I change to 6 point font, and maximize the
window to 383x112, none of these problems occur. The widest files feel
snappy, and messing with newline/space patterns doesn't change that.
Keeping the window maximized, 8pt -- still snappy, 10pt -- slight hint
of slowness, but perfectly usable, 11pt -- noticeable slowness in some
cases, but still under a second per refresh, 12pt -- catastrophically
bad.
Repeating the original 191x57 experiment in konsole (I set it up so that
it renders pixel-identical to the gnome-terminal):
real0m1.799s
user0m0.588s
sys 0m0.020s
$ date
Mon May 12 02:38:35 EDT 2008
$ cat XXX
Mon May 12 02:38:32 EDT 2008
Moreover, none of this slow refresh behavior is reproducible in konsole.
It's not as fast as gnome-terminal at its fastest, but it is very
consistent.
No other applications that display text have these sorts of issues.
So this is sort of a puzzler... I think it would be fascinating to know
the cause. And even better to have it fixed :)
** Affects: vte (Ubuntu)
Importance: Undecided
Status: New
--
Wide text in wide VTE windows is extremely slow
https://bugs.launchpad.net/bugs/229465
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to vte in ubuntu.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 229465] Re: Wide text in wide VTE windows is extremely slow
Clarification: 189x24 with the initial printout was fast -- about 2.8s.
Changing the printout to include the line number made it slow.
** Description changed:
Binary package hint: libvte9
This refers to the Ubuntu 7.10 Gutsy version of vte (0.16.9). However, I
just built vte 0.16.13 (hardy), and the bug remains (I made sure it was
using the right library using strace). I refer to gnome-terminal in the
rest of the bug, but I get the exact same behavior in xfce4-terminal,
and in the vte test app.
Here's an experiment, done on an idle system (Pentium M 2 Ghz, 1GB RAM),
with gnome-terminal in the foreground, maximized. My font setup is
monospace 12, with subpixel antialiasing. My scrollback is 5000 lines.
$ resize
COLUMNS=191;
LINES=57;
export COLUMNS LINES;
$ date XXX; time (for ((i=0;i1000;++i)); do echo
{a,b}{b,c}{c,a}{d,a}{q,f,e}{z,c,s}; done; echo _all_)
[snip]
_all_
real1m30.833s
user0m0.596s
sys 0m0.012s
$ date
Mon May 12 02:33:08 EDT 2008
$ cat XXX
Mon May 12 02:31:26 EDT 2008
I typed date while it was scrolling, and as soon as it finished, I hit
Enter. As you can see, time lies about the wall time a bit, because
the rendering is so horrendously slow. According to my date
measurement, the wall time is actually 1:42. My reaction time is not
that slow (see konsole experiment below).
Timings of the same experiment (I report the time value because it's
easier): 80x24 -- 1.2s, 80x59 -- 3s, 130x24 -- 1.8s, 191x24 -- 35s,
181x24 -- 2.5s, 186x24 -- 2.5s, 190x24 -- 30s.
But, if I change the string being printed (e.g. by replacing echo ...
with echo $i ...), then 189x24 suddenly becomes slow again (16s).
Maybe it depends on the pattern of spaces/newlines in the text being
displayed?
This manifests itself when I edit wide files, or cat a wide file, and
page through it. In both cases, refreshes can sometimes take as long as
5-7 seconds, even when I'm simply paging through the scrollback with
Shift-PageUp and Shift-PageDown. It seems to depend quite a bit on the
data -- again, I'm surmising something having to do with newlines or
spaces?
In fact, on the various wide data files on my disk, I feel slowness down
to terminal width 120, at which point it abruptly disappears.
I repeated the above experiments a couple of times -- the times are
fairly consistent. It did not seem to matter whether I used gnome-
terminal --geometry, or resized the window after startup.
Now, for the really weird thing. On my screen, 191x24 is almost the full
width of the screen. If I change to 6 point font, and maximize the
window to 383x112, none of these problems occur. The widest files feel
snappy, and messing with newline/space patterns doesn't change that.
Keeping the window maximized, 8pt -- still snappy, 10pt -- slight hint
of slowness, but perfectly usable, 11pt -- noticeable slowness in some
cases, but still under a second per refresh, 12pt -- catastrophically
bad.
Repeating the original 191x57 experiment in konsole (I set it up so that
it renders pixel-identical to the gnome-terminal):
real0m1.799s
user0m0.588s
sys 0m0.020s
- [EMAIL PROTECTED]:~/pain-genotyping$ date
+ $ date
Mon May 12 02:38:35 EDT 2008
- [EMAIL PROTECTED]:~/pain-genotyping$ cat XXX
+ $ cat XXX
Mon May 12 02:38:32 EDT 2008
Moreover, none of this slow refresh behavior is reproducible in konsole.
It's not as fast as gnome-terminal at its fastest, but it is very
consistent.
No other applications that display text have these sorts of issues.
So this is sort of a puzzler... I think it would be fascinating to know
the cause. And even better to have it fixed :)
** Description changed:
Binary package hint: libvte9
This refers to the Ubuntu 7.10 Gutsy version of vte (0.16.9). However, I
just built vte 0.16.13 (hardy), and the bug remains (I made sure it was
using the right library using strace). I refer to gnome-terminal in the
rest of the bug, but I get the exact same behavior in xfce4-terminal,
and in the vte test app.
Here's an experiment, done on an idle system (Pentium M 2 Ghz, 1GB RAM),
with gnome-terminal in the foreground, maximized. My font setup is
monospace 12, with subpixel antialiasing. My scrollback is 5000 lines.
$ resize
COLUMNS=191;
LINES=57;
export COLUMNS LINES;
$ date XXX; time (for ((i=0;i1000;++i)); do echo
{a,b}{b,c}{c,a}{d,a}{q,f,e}{z,c,s}; done; echo _all_)
[snip]
_all_
real1m30.833s
user0m0.596s
sys 0m0.012s
$ date
Mon May 12 02:33:08 EDT 2008
$ cat XXX
Mon May 12 02:31:26 EDT 2008
I typed date while it was scrolling, and as soon as it finished, I hit
Enter. As you can see, time lies about the wall time a bit, because
the rendering is so horrendously slow. According to my date
measurement, the wall time is actually 1:42. My reaction time is not
that
