Sebastien,
I'd like to point out that, as I said in comment #3, even if we sidestep
the question regarding the sanity of the specification itself, it's
definitely a bug that the Rhythmbox package in Ubuntu currently
implements the specification only partially, leading to inconsistent
behaviour.
** Attachment added: Screenshot illustrating truncation of window contents
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/662787/+attachment/1761474/+files/gnome-disk-utility-window-truncation.png
** Changed in: gnome-disk-utility (Ubuntu)
Status: New = Confirmed
I can reproduce the bug, so I'm confirming.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-disk-utility in ubuntu.
https://bugs.launchpad.net/bugs/662787
Title:
Palimpsest Gnome Disk Utility window is always truncated
--
This is caused by the patch to bug #414107. Prior to the patch the
window would get resized to fit the contents. However, the patch
prevents resizing and adds scrollbars instead. It makes the UI workable
on small screens but also forces everyone even with a large enough
screen to scroll or to
Valentin,
I already have the status icon set to own the main window, so that
doesn't appear to work for me as a workaround.
To me, both the bug and specification to which I linked appear to pretty
clearly indicate that the behaviour of quitting when not playing is an
intentional change. I simply
This is apparently intentional. See bug #526552 about compliance with
the sound menu specification. The specification itself (
https://wiki.ubuntu.com/SoundMenu#Music%20player%20section ) says:
A compliant player should also keep playing if you close its window
while it is playing; exit if you
I'm now at about about 3½ days of uptime and a little under 200 MiB of
RSS (a little under 300 MiB virtual) for each of the processes mentioned
in the report. I haven't noticed this kind of behaviour earlier but I
usually don't have particularly long uptimes. Since this looks pretty
similar to the
This is definitely a File Roller bug. It doesn't affect the command-line
tools. They can be used for the task just fine assuming that the file
names are properly escaped.
Looks like File Roller, on the other hand, does not properly escape the
file names when using 7z. Upstream bugzilla claims [1]
According to a quick test, the patch attached to the upstream bug seems
to fix the issue. I'm willing to test more thoroughly if someone decides
that this is worth fixing.
--
Can't compress to .7z with a space in there name
https://bugs.launchpad.net/bugs/132884
You received this bug
I guess this is just a duplicate of that bug in that case, because this
probably isn't really a bug in p7zip either. It seems to be purely a
File Roller issue.
--
Can't compress to .7z with a space in there name
https://bugs.launchpad.net/bugs/132884
You received this bug notification because
Still occurs in Gutsy.
The upstream bug report
(http://bugzilla.gnome.org/show_bug.cgi?id=429816) says that the bug has
been fixed in SVN but I don't know about any releases.
--
Can't compress to .7z if path contains whitespace
https://bugs.launchpad.net/bugs/106575
You received this bug
Public bug reported:
In Rhythmbox 0.9.8, included in Feisty, there's a typo in the Finnish
translation. On line 1203 of fi.po:
msgstr DAAP-musiikkojako
Should be:
msgstr DAAP-musiikkijako
As far as I know, this also affects upstream (probably also svn), but I
haven't reported it there yet. I
12 matches
Mail list logo
