Hello list,
I was not following this list but the discussion was interesting, so I am
adding my opinion/personal mumblings/etc. to this topic.
For entering Korean texts, the expectations and requirements of IMs are
different from Chinese/Japanese. As most multilingual IM cores are designed by
On 04/07/17 22:46, Martin Gräßlin-san wrote:
Am 2017-04-07 07:56, schrieb Takao Fujiwara:
Due to that: no chance for IM controlling part of our stack. We control the IM.
Probably I think this way would not work with IBus.
Each IBus IME are called by IBus dbus method. You hardly ask each IME
On 04/09/17 01:46, Martin Gräßlin-san wrote:
Am 2017-04-08 17:26, schrieb Weng Xuetian:
You're wrong about the QT_IM_MODULE stuff. To make application to use the
wayland protocol to type (text-input), the implementation must be done with
QT_IM_MODULE=wayland. I don't mind if it is set to
On Sunday, 9 April 2017 00:38:06 PDT，Martin Gräßlin wrote：
> Am 2017-04-09 03:49, schrieb Weng Xuetian:
> >> I don't want to base any decisions on 5 year old numbers. 30 msec
> >> would
> >> be bad, but if it is with modern hardware just 10 it wouldn't be that
> >> bad.
> >
> > 30ms is almost the
Am 2017-04-09 10:19, schrieb Eike Hein:
Martin, how would you see this done? Some sort of abstract interface in
kwin and a plugin-based implementation that makes the actual calls into
the fcitx lib?
That would be an option if we want to support multiple IM
implementations.
But if we want to
Personally I do see the appeal of making kwin the daemon - simplicity
and definitely delivers on the "make IM not be an afterthought" goal.
If it's in the kwin core it can't be not installed.
It'd also make the System Settings side easier if we can code against
a native interface we control -
Am 2017-04-09 03:49, schrieb Weng Xuetian:
I don't want to base any decisions on 5 year old numbers. 30 msec
would
be bad, but if it is with modern hardware just 10 it wouldn't be that
bad.
30ms is almost the maximum time that I found it would be accepted by
the user.
It's too much
On Saturday, 8 April 2017 12:43:54 PDT，Martin Gräßlin wrote：
> Am 2017-04-08 21:21, schrieb Weng Xuetian:
> > On Saturday, 8 April 2017 09:46:17 PDT，Martin Gräßlin wrote：
> >
> >> Am 2017-04-08 17:26, schrieb Weng Xuetian:
> >> > You're wrong about the QT_IM_MODULE stuff. To make application to
Am 2017-04-08 21:21, schrieb Weng Xuetian:
On Saturday, 8 April 2017 09:46:17 PDT，Martin Gräßlin wrote：
Am 2017-04-08 17:26, schrieb Weng Xuetian:
> You're wrong about the QT_IM_MODULE stuff. To make application to use
> the
> wayland protocol to type (text-input), the implementation must be
On Saturday, 8 April 2017 09:46:17 PDT，Martin Gräßlin wrote：
> Am 2017-04-08 17:26, schrieb Weng Xuetian:
> > You're wrong about the QT_IM_MODULE stuff. To make application to use
> > the
> > wayland protocol to type (text-input), the implementation must be done
> > with
> > QT_IM_MODULE=wayland.
Am 2017-04-08 17:26, schrieb Weng Xuetian:
You're wrong about the QT_IM_MODULE stuff. To make application to use
the
wayland protocol to type (text-input), the implementation must be done
with
QT_IM_MODULE=wayland. I don't mind if it is set to certain application
but set
it in general won't
On Friday, 7 April 2017 23:18:37 PDT，Martin Gräßlin wrote：
> Am 2017-04-08 01:04, schrieb Weng Xuetian:
> > On Friday, 7 April 2017 06:46:03 PDT，Martin Gräßlin wrote：
> >
> >> Am 2017-04-07 07:56, schrieb Takao Fujiwara:
> >> >> Due to that: no chance for IM controlling part of our stack. We
> >>
Am 2017-04-08 01:04, schrieb Weng Xuetian:
On Friday, 7 April 2017 06:46:03 PDT，Martin Gräßlin wrote：
Am 2017-04-07 07:56, schrieb Takao Fujiwara:
>> Due to that: no chance for IM controlling part of our stack. We
>> control the IM.
>
> Probably I think this way would not work with IBus.
> Each
On Friday, 7 April 2017 06:46:03 PDT，Martin Gräßlin wrote：
> Am 2017-04-07 07:56, schrieb Takao Fujiwara:
> >> Due to that: no chance for IM controlling part of our stack. We
> >> control the IM.
> >
> > Probably I think this way would not work with IBus.
> > Each IBus IME are called by IBus dbus
Am 2017-04-07 07:56, schrieb Takao Fujiwara:
Due to that: no chance for IM controlling part of our stack. We
control the IM.
Probably I think this way would not work with IBus.
Each IBus IME are called by IBus dbus method. You hardly ask each IME
maintainer to change the protocol.
IBus daemon
On Thursday, 6 April 2017 19:16:14 CEST Eike Hein wrote:
> Hi,
>
> In the aftermath of D5301, Martin asked to compile a document on the
> requirements for complex text input in Plasma, especially with the
> opportunities provided by the Wayland transition. It makes sense to
> s
On 04/07/17 14:13, Martin Gräßlin-san wrote:
Am 2017-04-06 22:18, schrieb Eike Hein:
On 04/07/2017 04:58 AM, Weng Xuetian wrote:
gnome-shell's kimpanel equilvalent stuff is bundled in gnome-shell, which make
it be able to access the windows position. Input method server send the offset
Am 2017-04-06 21:50, schrieb Eike Hein:
Weng as both a fcitx and Plasma developer is at a critical
intersection here: You and Martin will need to work together on
how fcitx can fit into a kwin_wayland world.
may I suggest a name change here: please replace Martin by Eike :-)
I think you are
Am 2017-04-06 22:18, schrieb Eike Hein:
On 04/07/2017 04:58 AM, Weng Xuetian wrote:
gnome-shell's kimpanel equilvalent stuff is bundled in gnome-shell,
which make
it be able to access the windows position. Input method server send
the offset
received from client (which is not global), and the
IBus emoji typing is updated day by day.
IBus 1.5.15 moved the emoji function in IBus XKB engine to IBus panel, which means the UI is now available from pane GUI menu and the shortcut key can
be customizable with ibus-setup:
https://desktopi18n.wordpress.com/2017/03/15/ibus-1-5-15-is-released/
On 04/07/2017 04:58 AM, Weng Xuetian wrote:
> gnome-shell's kimpanel equilvalent stuff is bundled in gnome-shell, which
> make
> it be able to access the windows position. Input method server send the
> offset
> received from client (which is not global), and the gnome-shell move the
>
On Thursday, 6 April 2017 10:27:40 PDT，Eike Hein wrote：
> > = Screenshots =
>
> Here's an example of the emoji IME mentioned earlier:
>
> https://fedoramagazine.org/using-favorite-emoji-fedora-25/
>
>
> Cheers,
> Eike
As a side note, I used to implment a ugly imchooser for KDE around KDE4
On Thursday, 6 April 2017 10:16:14 PDT，Eike Hein wrote：
> Hi,
>
> In the aftermath of D5301, Martin asked to compile a document on the
> requirements for complex text input in Plasma, especially with the
> opportunities provided by the Wayland transition. It makes sense to
> s
On 04/07/2017 04:21 AM, Martin Gräßlin wrote:
> that's actually also a feature of the keyboard daemon we have on X11.
> Only on wayland KWin takes care of it.
Aye, I kind of used KWin as an insert for our whole amalgamation of
shell infra there.
> Ideally we would build up on this. We must
Am 2017-04-06 19:16, schrieb Eike Hein:
Hi,
In the aftermath of D5301, Martin asked to compile a document on the
requirements for complex text input in Plasma, especially with the
opportunities provided by the Wayland transition. It makes sense to
share this document with all of you
> = Screenshots =
Here's an example of the emoji IME mentioned earlier:
https://fedoramagazine.org/using-favorite-emoji-fedora-25/
Cheers,
Eike
On 04/07/2017 02:16 AM, Eike Hein wrote:
>
> Hi,
>
> In the aftermath of D5301, Martin asked to compile a document on the
> requirements for complex text input in Plasma, especially with the
> opportunities provided by the Wayland transition. It makes sense to
> share t
Hi,
In the aftermath of D5301, Martin asked to compile a document on the
requirements for complex text input in Plasma, especially with the
opportunities provided by the Wayland transition. It makes sense to
share this document with all of you, to
= I. What Input Methods do =
Basically
28 matches
Mail list logo
