[Fedora-i18n-bugs] [Bug 490381] New: another ui detail
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: another ui detail
https://bugzilla.redhat.com/show_bug.cgi?id=490381
Summary: another ui detail
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: ibus
AssignedTo: phuang(a)redhat.com
ReportedBy: mclasen(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: phuang(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
I did complain about "engine" appearing in the tabs, but I overlooked the
"Next/Previous engine" labels for the keys. Those should be replaced by
"Next/Previous input method", imo, to get rid of the term "engine" in the ui.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 2 months
[Fedora-i18n-bugs] [Bug 490009] New: Deleting Next Engine shortcuts doesn't work
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Deleting Next Engine shortcuts doesn't work
https://bugzilla.redhat.com/show_bug.cgi?id=490009
Summary: Deleting Next Engine shortcuts doesn't work
Product: Fedora
Version: 10
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: ibus
AssignedTo: phuang(a)redhat.com
ReportedBy: wtogami(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: phuang(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Blocks: 446452,481098
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
ibus-0.1.1.20090203-1.fc10.x86_64
My ibus configuration has Next Engine shortcuts defined because I began using
it before it became disabled by default in a later update for non-Chinese
languages.
Quite often I accidentally activate the IM by hitting Ctrl-Shift. I tried to
delete the Next Engine hotkeys from the ibus Preferences menu, but deleting
those hotkeys fails to stay deleted.
Please fix for F-10 and F-11.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 2 months
[Fedora-i18n-bugs] [Bug 490347] use sane mount options
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=490347
--- Comment #14 from Michael J Gruber <mjg(a)fedoraproject.org> 2009-03-27 14:32:14 EDT ---
(In reply to comment #13)
> (In reply to comment #12)
> > You're breaking existing installations through update!
> > As pointed out before, during upgrade this is a non-issue (in the sense that
> > there are no guarantees) but during update it should a big no-no. (I'm getting
> > the impression the F10 updates cycle is pretty bad at this, compared to earlier
> > versions.)
>
> FWIW, I disagree with using the word "breakage" for this change.
>
If, for example, I rsync memory cards over and suddenly all files are in upper
case instead of lower, keeping rsync from detecting duplicates, it's hard not
to call it breakage.
> FYI, this change only happens when updating to F11 so everything is fine. I
> agree if a change like this were to affect people on a stable release like F10
> it would be bad (we generally don't rev or swap out major subsystems in a
> stable series). But that is not the case.
I have an F10 with updates and no rawhide packages. The behaviour with respect
to shortname=lower/mixed changed about a week ago through updates. Otherwise I
wouldn't complain.
Michael
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 2 months
[Fedora-i18n-bugs] [Bug 490347] use sane mount options
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=490347
--- Comment #13 from David Zeuthen <davidz(a)redhat.com> 2009-03-27 14:18:33 EDT ---
(In reply to comment #12)
> You're breaking existing installations through update!
> As pointed out before, during upgrade this is a non-issue (in the sense that
> there are no guarantees) but during update it should a big no-no. (I'm getting
> the impression the F10 updates cycle is pretty bad at this, compared to earlier
> versions.)
FWIW, I disagree with using the word "breakage" for this change.
FYI, this change only happens when updating to F11 so everything is fine. I
agree if a change like this were to affect people on a stable release like F10
it would be bad (we generally don't rev or swap out major subsystems in a
stable series). But that is not the case.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 2 months
[Fedora-i18n-bugs] [Bug 490347] use sane mount options
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=490347
--- Comment #12 from Michael J Gruber <mjg(a)fedoraproject.org> 2009-03-27 14:10:34 EDT ---
(In reply to comment #11)
> First, this bug is really about DeviceKit-disks choosing non-sensical mount
> options. As it turns out this is fixed in upstream git
>
>
> http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=5c82f144...
>
> already and this fix will be in Rawhide shortly. The problem, in a nutshell,
> was that the kernel people (for reasons unbeknownst to me) decided to remove
> the utf8 flag. So now we pass sane defaults (including utf8) and everything
> will work just fine in Fedora. As such, I'm moving this bug back to
> DeviceKit-disks and will close it with resolution RAWHIDE once the fix is in.
>
> The other part of this bug a discussion of whether exposing mount options to
> end users is an useful thing to do. My view is that it is not. So the
> replacement for gnome-mount/HAL, namely gvfs/DeviceKit-disks, will not support
> that.
>
> Either way, if people want mount options the DeviceKit-disks interface supports
> that. There are two ways to go about this
>
> 1. use /etc/fstab
> - to cope with removable media, use the /dev/disk/by-* symlinks
>
> 2. modify the user of the DeviceKit-disks API to pass the mount options
> you want
>
> If you think gvfs and GNOME should support mount options the same way
> gnome-mount did (e.g. with gconf keys and UI dialogs), the best place to state
> your case about it is the upstream bug tracker
>
> http://bugzilla.gnome.org/enter_bug.cgi?product=gvfs
>
> and we can have a discussion about it there. Please include a clear rationale
> why you think mount options for block devices are useful.
>
> What is not going to help your cause is
>
> - complaining that gnome-mount/HAL used to support this and gvfs/DeviceKit-
> disk don't; we simply don't guarantee that kind of interface stability
> between major releases of Fedora
You're breaking existing installations through update!
As pointed out before, during upgrade this is a non-issue (in the sense that
there are no guarantees) but during update it should a big no-no. (I'm getting
the impression the F10 updates cycle is pretty bad at this, compared to earlier
versions.)
>
> - filing enhancement requests in a downstream bugzilla
>
> Thanks.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 2 months
[Fedora-i18n-bugs] [Bug 490347] use sane mount options
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=490347
David Zeuthen <davidz(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|gvfs |DeviceKit-disks
Summary|gvfs doesn't use |use sane mount options
|/system/storage/default_opt |
|ions/vfat/mount_options |
--- Comment #11 from David Zeuthen <davidz(a)redhat.com> 2009-03-27 13:20:14 EDT ---
First, this bug is really about DeviceKit-disks choosing non-sensical mount
options. As it turns out this is fixed in upstream git
http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=5c82f144...
already and this fix will be in Rawhide shortly. The problem, in a nutshell,
was that the kernel people (for reasons unbeknownst to me) decided to remove
the utf8 flag. So now we pass sane defaults (including utf8) and everything
will work just fine in Fedora. As such, I'm moving this bug back to
DeviceKit-disks and will close it with resolution RAWHIDE once the fix is in.
The other part of this bug a discussion of whether exposing mount options to
end users is an useful thing to do. My view is that it is not. So the
replacement for gnome-mount/HAL, namely gvfs/DeviceKit-disks, will not support
that.
Either way, if people want mount options the DeviceKit-disks interface supports
that. There are two ways to go about this
1. use /etc/fstab
- to cope with removable media, use the /dev/disk/by-* symlinks
2. modify the user of the DeviceKit-disks API to pass the mount options
you want
If you think gvfs and GNOME should support mount options the same way
gnome-mount did (e.g. with gconf keys and UI dialogs), the best place to state
your case about it is the upstream bug tracker
http://bugzilla.gnome.org/enter_bug.cgi?product=gvfs
and we can have a discussion about it there. Please include a clear rationale
why you think mount options for block devices are useful.
What is not going to help your cause is
- complaining that gnome-mount/HAL used to support this and gvfs/DeviceKit-
disk don't; we simply don't guarantee that kind of interface stability
between major releases of Fedora
- filing enhancement requests in a downstream bugzilla
Thanks.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 2 months
[Fedora-i18n-bugs] [Bug 489611] New: New libgxim breaks Qt4 applications
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: New libgxim breaks Qt4 applications
https://bugzilla.redhat.com/show_bug.cgi?id=489611
Summary: New libgxim breaks Qt4 applications
Product: Fedora
Version: 10
Platform: i386
OS/Version: Linux
Status: NEW
Severity: high
Priority: low
Component: libgxim
AssignedTo: tagoh(a)redhat.com
ReportedBy: mark(a)qtrac.eu
QAContact: extras-qa(a)fedoraproject.org
CC: jfrieben(a)hotmail.com, klmitch(a)mit.edu, jlb17(a)duke.edu,
tagoh(a)redhat.com, bugzilla-redhat-2008(a)martins.cc,
hestyp(a)gmail.com, mef(a)computer.org,
cpanceac(a)gmail.com, windsor(a)digital-realms.eu,
mark(a)qtrac.eu, domingobecker(a)gmail.com,
bjorge(a)solli.priv.no, fedora-i18n-bugs(a)redhat.com,
dallan(a)redhat.com, bobpoljakov(a)gmail.com
Estimated Hours: 0.0
Classification: Fedora
Clone Of: 488223
+++ This bug was initially created as a clone of Bug #488223 +++
After today's updates keyboard input is once again broken in Qt4 applications.
I now have intermittent keyboard errors---either no response or wrong keys
processed---in both my own applications and supplied ones, e.g., KMail.
The errors are such that I am pretty well unable to work with Fedora (since I
use KMail all day and write and test Qt4 apps all the time). Please could you
include a test for Qt4 apps when you next "fix" libgxim (or whatever is causing
the bug)?
I originally reported this in 488411.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 2 months
[Fedora-i18n-bugs] [Bug 488976] New: Keystrokes appear to be delayed and repeatable.
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Keystrokes appear to be delayed and repeatable.
https://bugzilla.redhat.com/show_bug.cgi?id=488976
Summary: Keystrokes appear to be delayed and repeatable.
Product: Fedora
Version: 10
Platform: i386
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: libgxim
AssignedTo: tagoh(a)redhat.com
ReportedBy: nikitis(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: tagoh(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Description of problem: While in a WINE Game, keystrokes seem to be buffering.
What's really happening though is, if I were to type text in-game. I get
problems. ex. If I type the word "Anyone" no text shows up until I type the 'y'
and then the 'A' shows up, and when I type the 'o' the first 'n' shows up.
Another problem is when I go to turn my character in game by pressing 'd' to
turn right, nothing happens, but once I press 'd' again it starts to turn, but
when I let go of 'd' it continues to turn and never stops as if the key depress
is never registered. Also, 'esc' is supposed to bring up the menu, but doesn't
unless pressed twice. But it's even worse if I have already become stuck
turning in a direction. I have to press 'esc' multiple times to get it to
register. This happens in World of Warcraft, as well as in Counter-strike.
And it only happens in games. notepad emulated in WINE works fine. As well as
all Fedora applications such as xterm. So far it only seems to happen in WINE
Games. I have tried 3 different WINE versions, (1.1.14, 1.1.15, 1.1.16) and I
have deleted my .wine directory to start fresh. It always happens. WINE devs
think it has to do with libgxim. I yum updated yesterday 03-05-2009. This is
when the problem started.
Version-Release number of selected component (if applicable):
libgxim-0.3.2-4.fc10.i386
How reproducible: 100%
Steps to Reproduce:
1.Load up Game via command 'wine /home/<user>/Games/World\ of\
Warcraft/Wow.exe'
2.Log into character.
3.Start to play, keystrokes are delayed and causing errors.
Actual results: See description
Expected results: For there to have no delays in keystrokes.
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 2 months