[Fedora-i18n-bugs] [Bug 1847347] New: gnome-terminal and xfce4-terminal get surrounding text from previous application
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1847347
Bug ID: 1847347
Summary: gnome-terminal and xfce4-terminal get surrounding text
from previous application
Product: Fedora
Version: 32
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: mfabian(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
I made the following screenshots and video by testing on Gnome-Xorg, but the
problem occurs on Gnome-Wayland as well.
How to reproduce (see also attached screenshots and video):
- To show what happens with the surrounding text, I first opened the
setup tool of ibus-typing-booster and set the debug level in the
options tab to 3.
When the debug level is high, the auxiliary text above the candidate
list shows what context has been obtained by using surrounding text
(if surrounding text is available, if it is not available like when
using xterm, the context is just remembered from what was typed
last).
- I opened 3 windows: gedit, firefox, and gnome-terminal.
- I focus on gedit and type "a b c d e"
On top of the candidate list one can see: "Context: b c d"
This is because when the letter "e" was typed, ibus-typing-booster
got the surrounding text at the cursor position and parsed the last
3 tokens left of the cursor out of the result. And these
last 3 tokens left of the cursor are "b c d".
- Now I focus on firefox and type "f g h i j"
On top of the candidate list one can see: "Context: g h i"
I.e. the correct context "g h i" to the left of the just typed "j"
(which is still in preedit) has been found using surrounding text.
- Now I focus on gnome-terminal and type "k l m"
On top of the candidate list one can see: "Context h i j"
This comes from the surrounding text left of the cursor in
*firefox*, *not* from gnome-terminal.
Although gnome-terminal reports that surrounding text is supported, i.e.
self.client_capabilities & IBus.Capabilite.SURROUNDING_TEXT
is True (see the code to get the context at:
https://github.com/mike-fabian/ibus-typing-booster/blob/master/engine/hun...
)
gnome-terminal does not really seem to support surrounding text.
The surrounding text comes from the previous client which really supported
surrounding text.
If the previous client was firefox, one still gets the surrounding text from
firefox while typing in gnome-terminal.
Same with gedit, if the previous client before focussing on gnome-terminal
was gedit, one still gets the surrounding text from gedit while typing in
gnome-terminal.
- The same problem occurs when using xfce4-terminal instead of gnome-terminal.
- When using xterm, the problem does *not* occur because when using xterm
self.client_capabilities & IBus.Capabilite.SURROUNDING_TEXT
is False and then the get_context() immediately returns and the context
remembered from the last text typed is used as a fallback.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 months, 2 weeks
[Bug 2109358] New: emacs fails to start: Cannot open load file: No
such file or directory, comp
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2109358
Bug ID: 2109358
Summary: emacs fails to start: Cannot open load file: No such
file or directory, comp
Product: Fedora
Version: 36
Status: NEW
Component: emacs-common-ddskk
Assignee: dueno(a)redhat.com
Reporter: nicku(a)nicku.org
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Description of problem: emacs fails to start if emacs-ddsdk is installed
Version-Release number of selected component (if applicable):
16.2-12.fc36
How reproducible:
Always
Steps to Reproduce:
1.Install emacs, it runs
2.install emacs-ddsdk
3. Emacs refuses to start, with message, "Cannot open load file: No such file
or directory, comp"
Actual results:
Emacs refuses to start, with message, "Cannot open load file: No such file or
directory, comp"
Expected results:
emacs runs.
Additional info:
strace shows emacs looking iin so many places other than the right one.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2109358
4 months, 2 weeks
[Bug 2094689] New: [abrt] ibus-setup: dictkeys_decref(): python3.10
killed by SIGSEGV
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2094689
Bug ID: 2094689
Summary: [abrt] ibus-setup: dictkeys_decref(): python3.10
killed by SIGSEGV
Product: Fedora
Version: 36
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:5384a2084d3e5a0a50d73ac1d0f6702b6679e8e1;VAR
IANT_ID=workstation;
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: mfabian(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Version-Release number of selected component:
ibus-setup-1.5.26-8.fc36
Additional info:
reporter: libreport-2.17.1
backtrace_rating: 4
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/app.slice/dbus-:1.2-com.redhat.imsettings@0.service
cmdline: python3 /usr/share/ibus/setup/main.py ibus-setup
crash_function: dictkeys_decref
executable: /usr/bin/python3.10
journald_cursor:
s=f4b06a7c90514868a0ecb24aa4a3d53e;i=66eb;b=3fc2379dae1240f58971d2cf0885b326;m=40d6d7d5;t=5e0eabf35c54a;x=e9d6ba44ac336a36
kernel: 5.17.13-300.fc36.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1000
Truncated backtrace:
Thread no. 1 (10 frames)
#0 dictkeys_decref at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/dictobject.c:336
#1 dict_merge at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/dictobject.c:2588
#2 dict_update_common at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/dictobject.c:2428
#3 dict_update at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/dictobject.c:2446
#4 method_vectorcall_VARARGS_KEYWORDS at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/descrobject.c:344
#5 _PyObject_VectorcallTstate at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/cpython/abstract.h:114
#6 PyObject_Vectorcall at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/cpython/abstract.h:123
#7 call_function at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:5867
#8 _PyEval_EvalFrameDefault at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:4198
#9 _PyEval_EvalFrame at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/internal/pycore_ceval.h:46
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2094689
4 months, 2 weeks
[Bug 2061664] New: IBus candidate panel show up at wrong positions
for QT apps
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2061664
Bug ID: 2061664
Summary: IBus candidate panel show up at wrong positions for QT
apps
Product: Fedora
Version: 36
Hardware: x86_64
OS: Linux
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: vtq-gnome(a)outlook.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Link ID: Red Hat Bugzilla 2060988
Classification: Fedora
Description of problem:
When I trying to input chinese text with ibus-libpinyin in QT apps (tested
texworks, okular, kwrite, konsole, fedora mediawriter, seemingly all QT apps),
the candidate character panel shows up not below the cursor but at a wrong
position, sometimes outside the window. This happens in both Wayland and Xorg
sessions, although the position is different for the two environments.
Version-Release number of selected component (if applicable):
Fedora-Workstation-Live-x86_64-36-20220307.n.0.iso image running on bare metal.
ibus-1.5.25-13.fc36
ibus-libpinyin-1.12.1-2.fc36
qt5-qtbase-5.15.2-33.fc36
How reproducible:
Always
Steps to Reproduce:
1. Boot from the live image
2. Add Intelligent Pinyin IME from Settings-Keyboard-Input Sources
3. Install some QT apps (e.g. kwrite)
4. Open kwrite, click the text field, use Super-Space to switch to Pinyin
input, and try to input some text
Actual results:
The candidate character panel shows up at a wrong position, sometimes outside
the window.
Expected results:
The candidate character panel should show up just below the text cursor.
Additional info:
Bug 2060988 for Wayland seems to be related. But this is happening in Xorg
session too.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2061664
4 months, 3 weeks
[Bug 2123720] New: Noto Sans Thai to default for Thai
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2123720
Bug ID: 2123720
Summary: Noto Sans Thai to default for Thai
Product: Fedora
Version: rawhide
Status: NEW
Component: google-noto-fonts
Keywords: FutureFeature
Assignee: tagoh(a)redhat.com
Reporter: tagoh(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com,
pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
As we have changed most languages default to Noto, it may be good to consider
updating Thai to Noto as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2123720
4 months, 4 weeks