from:"Takao Fujiwara"

Re: F39 Change Proposal: IBus 1.5.29 (System-Wide)

2023-07-27 Thread Takao Fujiwara

Sorry, I missed the reply.
Currently the default input method is the Qt IBus IM module by setting 
QT_IM_MODULE=ibus environment variable with imsettings module in Plasma Wayland 
and this Change is to make another IBus Wayland IM module and users switch the 
input method by manual using systemsettings5 utility because the new module 
will be under the testing in Fedora 39. I'd like to make another Change to 
change the system default change in Fedora 40.
So this change would be enough as Self-Contained for Fedora 39.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 34 Change proposal: ibus-anthy for default Japanese IME (System-Wide Change)

2020-11-30 Thread Takao Fujiwara


On 2020/12/01 5:07, Andy Mender-san wrote:

If it's important to keep the anthy addon, that's also an option: 
https://github.com/fcitx/fcitx5-anthy 



Currently I wish to obsolete anthy in the future and it would be great to 
migrate for fcitx5-anthy to use anthy-unicode in Fedora too.
https://github.com/fcitx/fcitx-anthy/issues/12

Fujiwara



~Andy

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: IBus 1.5.23 - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Takao Fujiwara


On 2020/07/01 4:47, Igor Raits-san wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-30 at 15:20 -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/IBus_1.5.23

== Summary ==
IBus 1.5.23 will replace the allowlist of XKB engines with the
blocklist of XKB ones.

== Owner ==
* Name: [[User:Fujiwara| Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com

== Detailed Description ==
IBus currently provides the allowlist of XKB engines in
`/usr/share/ibus/component/simple.xml` and `ibus-setup` utility can
show the XKB engines indicated in only that file in most desktops.
(gnome-control-center shows XKB list from gnome-desktop3 in GNOME
desktop instead.) The allowlist includes the limited XKB layouts and
variants. E.g. 'gb(dvorak)' is included but 'gb' is not. And the
allowlist has been supported to customize by sysadmin localy since
the
simple.xml is a simple text file and the default list has been
updated
upon the request.

IBus 1.5.23 will replace the allowlist with the blocklist which
includes the disabled XKB engines and `ibus-setup` will shows all the
XKB engines which are '''not''' indicated in that file.  The
blocklist
will includes 'cn' layout, 'cn' layout + any variants, 'nec_vndr/jp'
layouts at the moment.

I.e. the change won't effect GNOME desktop.


So I do not fully understand this change. Is it actually breaking
something or not? If so, I am surprised it happens when bumping micro
version (.23). If not, does it have to be System-Wide change?


The Change effects non-default desktops.
I put this Change to System-Winde because IBus is enabled by the default 
installation.
I'm not sure whether SystemWide/SelfContain criteria is applied by Change or 
package.




== Benefit to Fedora ==
The users don't have to request the desired XKB layouts and variants
in IBus upstream and most XKB keymaps will be shown in ibus-setup.

== Scope ==
* Proposal owners:
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/9563 #9563]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
If a keymap is shown in ibus-setup in the previous version, it will
be
shown in the new one.

== How To Test ==
# Log into XFCE desktop
# Run ibus-setup

It will show 'English (UK)' keymap by default.

== User Experience ==
If a user customize `/usr/share/ibus/component/simple.xml` in the
previous version, the file will be replaced with new one.


I think it is pretty much expected that if you modify something in
/usr, it will be overriden by an update, no?


Right. probably I think it's better to delete the experience here.




== Dependencies ==
The change effects XKB engines only but does not input method engines
(E.g. libpinyin, hangul, and so on.)

== Contingency Plan ==
* Contingency mechanism: Drop the feature in Fedora 33 and postpone
it
to Fedora 34
* Contingency deadline: Beta freeze
* Blocks release? No

== Documentation ==
TBD


--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to
devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
- -- 
Igor Raits 

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77lt4ACgkQEV1auJxc
Hh7vKA//VigWO3Dx/Aj52Nb1zVUY6CluDKLwaYEJ1c3j6LYwNhH6LVYMLQUPRlw2
gNUHe5n7k2C1kiFP2s1+u/MEQXGxZwjzGgPxwVLNl9bOFfk8HnXrwHuTquucDC3T
0amg4G0x3LynbhCrzrzBxfOSy/GnlElUGKY66izaTMPnsHtGjrmHzb0eCOsaIYvl
D4TxBJ7pTqJh6XG41UFHsyT82yuMAwjeS8mow7XsQY3a29wWN7A9cxyNBpv0Uhtb
rXbN9ti5pk3qmc+XjSbbqNvS3ufVAOLGv9FOXmkOG3iY0uhSjLJXkSPesDkJdzYp
EQR+W5nmFFsUEKKFUb4fwTJ5TEz1OjNtUYW09Ahuqq5S6xJv6IA7rMPkU05rxeMM
Qac7q3LJ+cQM0vk9HKVIDfXmqX47tqCNpcrC5uDLb6MwBGvz7A9WJWdu71shuTAi
Bmya4/yISh7C/5+pfpO4y2h+z7RYiA2visNdp3oYRWQ7o+8SMUjPHGzyIvX3TcF5
pZlmKrYsoyEiltyMoyhJTosOZ+wWpMhZQhjVNT3vq3nUYnSe3xAX7aGUoIF750O9
HOvjyDcpptCMjVr/b2pcQt7usLG+ISzta8LxZkm38RkFGSG3aewRTJGSTK+K7XQQ
iUCRYGKePePPxtYZwNT212Hft1vBaN7hGzA7P3oXdYOblWuk9w4=
=9bCf
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to deve

Re: F30 Self-Contained Change proposal: Ibus-typing-booster default for Indian languages

2019-02-11 Thread Takao Fujiwara


Hi folks,

If it's not a single input source, I'd think it could be an idea to implement 
the languages tag besides language tag in that ibus compose file.

Fujiwara

On 2019/01/29 15:33, Mike FABIAN-san wrote:

Owen Taylor  さんはかきました:


Currently, ibus-m17n is the default input method for Indian languages
in Fedora.  ibus-typing-booster uses the same libm17n used by
ibus-m17n to support input for Indian languages and thus it can do
everything ibus-m17n can do. But on top of that, ibus-typing-booster
supports predictive input by remembering user input and by using words
from dictionaries.  Therefore, ibus-typing-booster is a more useful input method
for these languages.

== Benefit to Fedora ==
A better input experience for users of Indian languages.


How would I try this out in Fedora 29?

I see that I have ibus-typing-booster installed, but I don't see any
sign of it in the GNOME "Region & Language" panel input source
selection. Does ibus-typing-booster look like one input support for
each supported language, or does it look like a single input source?


It looks like a single input source. Here are some
screen shots how to add it using the GNOME "Region & Language" panel:

http://mike-fabian.github.io/ibus-typing-booster/documentation.html#adding-gnome

It is listed under “Other” in the GNOME "Region & Language" panel input
source selection.

That is because it use “t” here:

 $ /usr/libexec/ibus-engine-typing-booster --xml
 
 
 typing-booster
 Typing Booster
 t
 GPL
 Mike FABIAN mfab...@redhat.com, Anish Patil 
anish.develo...@gmail.com
 
/usr/share/ibus-typing-booster/icons/ibus-typing-booster.svg
 default
 A completion input method to speedup 
typing.
 
 /usr/libexec/ibus-setup-typing-booster
 InputMode
 
 

At the moment, ibus supports only one language in the
“t” tag. And as ibus-typing-booster supports many
languages, “en” does not seem right, it would look
like it supports only English. So only “t” for “Other” seems appropriate
at the moment. But it is a bit hard to find in “Other” in the GNOME
"Region & Language" panel.

When ibus-typing-booster is first used, it defaults to dictionaries
and m17n-input-methods appropriate to the locale it is first started in.

/usr/share/ibus-typing-booster/engine/itb_util.py contains the defaults,
for example for Marathi it has:

LOCALE_DEFAULTS = {
 ...
 'mr_IN': {'inputmethods': ['mr-inscript2', 'NoIme'], 'dictionaries': 
['mr_IN', 'en_GB']},
 ...

So when the locale is mr_IN.UTF-8 while ibus-typing-booster is first
started, it defaults to the two input methods 'mr-inscript2' (a Marathi
input method) and 'NoIme' (that is direct keyboard input, useful for
English) and the dictionaries for mr_IN and for en_GB.

This can be changed in the setup tool of ibus-typing-booster, one can
choose up to 10 input methods and 10 dictionaries at the same time.


Thanks!
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F28 System Wide Change: IBus Unicode Typing

2018-01-11 Thread Takao Fujiwara


On 01/11/18 09:47, Christopher-san wrote:

On Tue, Jan 9, 2018 at 9:08 AM Jan Kurik <jku...@redhat.com 
<mailto:jku...@redhat.com>> wrote:

= System Wide Change: IBus Unicode Typing =
https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing

Change owner(s):
* Takao Fujiwara 

IBus core provides an Emoji dialog which users can type emoji
annotations and output the emoji character using IBus (E.g. Typing
"football" shows U+26BD). The proposal is the dialog also supports to
type Unicode names (E.g. Typing "copyright sign" shows U+00A9).


== Detailed Description ==
IBus core provides an Emoji dialog and it can be launched with
Ctrl-Shift-e shortcut key in non-GNOME desktop and `ibus emoji`
command is available for GNOME desktop [1]. Users can select an emoji
in emoji lists on the emoji dialog or type an emoji annotation in an
input entry on the emoji dialog and output the selected emoji using
IBus.

The proposal is that emoji dialog also supports to type Unicode names
in the input entry and output the selected Unicode character.

E.g. Typing "copyright sign" shows U+00A9

[1] because gnome-shell has its owned keyboard indicator instead of
/usr/libexec/ibus-ui-gtk3 and GTK itself also has the similar emoji
dialog and the emoji implementation is under the consideration in
GNOME.



== Scope ==
* Proposal owners:
IBus core will include the dictionary of Unicode names

* Other developers:
N/A

* Release engineering:
https://pagure.io/releng/issue/7255

* List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71 
<https://maps.google.com/?q=Purkynova+99/71=gmail=g>, 612 45 Brno, 
Czech Republic


With regards to [1], that was a very unfortunate regression[2] of a widely 
advertised[3] feature of F25 that was immediately broken in F26. :(
I don't really see the value of unicode entry when I can't easily type unicode characters on a standard US keyboard. I'm sure it will be useful to 
some, but restoring GNOME functionality for ibus-typing-booster would be a much more useful feature, so that unicode characters (including emojis) can 
be searched for using a standard US keyboard layout in a convenient interface.


It's still under considerable for GNOME integration.
Of course, you can use ibus-typing-booster and this purpose is not for US 
layout only.

Fujiwara



[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1430501
[3]: https://fedoramagazine.org/using-favorite-emoji-fedora-25/



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: IBus Unicode Typing

2018-01-11 Thread Takao Fujiwara


On 01/11/18 09:47, Christopher-san wrote:

On Tue, Jan 9, 2018 at 9:08 AM Jan Kurik <jku...@redhat.com 
<mailto:jku...@redhat.com>> wrote:

= System Wide Change: IBus Unicode Typing =
https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing

Change owner(s):
* Takao Fujiwara 

IBus core provides an Emoji dialog which users can type emoji
annotations and output the emoji character using IBus (E.g. Typing
"football" shows U+26BD). The proposal is the dialog also supports to
type Unicode names (E.g. Typing "copyright sign" shows U+00A9).


== Detailed Description ==
IBus core provides an Emoji dialog and it can be launched with
Ctrl-Shift-e shortcut key in non-GNOME desktop and `ibus emoji`
command is available for GNOME desktop [1]. Users can select an emoji
in emoji lists on the emoji dialog or type an emoji annotation in an
input entry on the emoji dialog and output the selected emoji using
IBus.

The proposal is that emoji dialog also supports to type Unicode names
in the input entry and output the selected Unicode character.

E.g. Typing "copyright sign" shows U+00A9

[1] because gnome-shell has its owned keyboard indicator instead of
/usr/libexec/ibus-ui-gtk3 and GTK itself also has the similar emoji
dialog and the emoji implementation is under the consideration in
GNOME.



== Scope ==
* Proposal owners:
IBus core will include the dictionary of Unicode names

* Other developers:
N/A

* Release engineering:
https://pagure.io/releng/issue/7255

* List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71 
<https://maps.google.com/?q=Purkynova+99/71=gmail=g>, 612 45 Brno, 
Czech Republic


With regards to [1], that was a very unfortunate regression[2] of a widely 
advertised[3] feature of F25 that was immediately broken in F26. :(
I don't really see the value of unicode entry when I can't easily type unicode characters on a standard US keyboard. I'm sure it will be useful to 
some, but restoring GNOME functionality for ibus-typing-booster would be a much more useful feature, so that unicode characters (including emojis) can 
be searched for using a standard US keyboard layout in a convenient interface.


It's still under considerable for GNOME integration.
Of course, you can use ibus-typing-booster and this purpose is not for US 
layout only.

Fujiwara



[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1430501
[3]: https://fedoramagazine.org/using-favorite-emoji-fedora-25/



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2017-05-09 Thread Takao Fujiwara


On 05/09/17 18:06, Mathieu Bridon-san wrote:

On Tue, 2017-05-09 at 17:17 +0900, Takao Fujiwara wrote:

As I explained in Fedora 25, now the emoji typing is available in
IBus panel menu.
ibus-1.5.15-8.fc26 is now available in koji or copr.
I moved the emoji function in IBusEngineSimple to a panel component.
The UI is designed to work as an extended IBus lookup window which
can commit an emoji without mouse using Space, Enter and Arrow keys
and expected to be useful for both CLI and GUI users.
The shortcut key Ctrl-Shift-e is customizable with ibus-setup
utility.
If this is comfortable for you, I'd like to implement the similar UI
for gnome-shell.


Ctrl+shift+e might already be used in applications. (for example in
Gimp it fits the image to the window, in the Firefox Tab Groups
extension itopens the group management page, etc...)

I think for GNOME Shell the shortcuts are usually with the super key,
(e.g super+space to switch input sources), to avoid clashing with
application shortcuts.


I agree with you however probably I think the discussion about the shortcut key 
can be done when the settings are implemented in gnome-control-center.
The UI also supports Control-f, Control-b, Control-n, Contrl-p to move the 
cursor on the emoji candidate window.

Fujiwara





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2017-05-09 Thread Takao Fujiwara

As I explained in Fedora 25, now the emoji typing is available in IBus panel
menu.
ibus-1.5.15-8.fc26 is now available in koji or copr.
I moved the emoji function in IBusEngineSimple to a panel component.
The UI is designed to work as an extended IBus lookup window which can commit an emoji without mouse using Space, Enter and Arrow keys and expected to
be useful for both CLI and GUI users.

The shortcut key Ctrl-Shift-e is customizable with ibus-setup utility.
If this is comfortable for you, I'd like to implement the similar UI for
gnome-shell.
Finally I'd also move the feature of Ctrl-Shift-u in GtkIMContextSimple to the
emoji UI since the shortcut key is also not customizable.

https://desktopi18n.wordpress.com/2017/03/15/ibus-1-5-15-is-released/

Any feedback is welcome.

Thanks,
Fujiwara

On 07/11/16 21:41, Takao Fujiwara-san wrote:

On 07/11/16 20:25, Bastien Nocera-san wrote:

- Original Message -

On 07/08/16 20:41, Bastien Nocera-san wrote:

I think that the emoji input method should be a separate input method, so
that most users would have the choice between inputting using the keyboard
layout that matches their keyboard, and a separate input method for
emojis.

I think the emoji typing does not depend on XKB but is used frequently and I
don't think it should be separated.

It is on every other platform I can think of.

I don't think so.
I can see Emoji input on MS-IME in MS-Windows without switching engines in
Japanese.
I can see Emoji input on Mac without switching engines with
Command-Control-Space key.
I can see Emoji input on Xperia keyboard in Android without switching engines.

The IBus XKB engine is not discoverable (it's not listed in GNOME's Region
& Language settings) and the keyboard shortcut to input emojis is also not
discoverable. Having a separate input method is likely the better way to
implement this.

I replied this.

You haven't. You're implementing this without any regards for prior art and
design work that's been done. You certainly can implement this internally
however you want, but the end result has to match certain expectations, and
designs. Your implementation won't, and as a result won't be discoverable.

What do you mean in the certain expectations and designs.
As I explained, a radio button would be a idea to resolve your disacoverable
way because I think you mean the GUI access.

Fujiwara
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-20 Thread Takao Fujiwara

Probably I need to clarify some points.

nodejs-emojione is required by build only but not installation. ibus converts
emoji.json in nodejs-emojione to a GHashTable during the package build.

The current plan is to integrate the CLI with Ctrl-Shift-u for Fedora 25 and the next plan is to move the implementation in IBus XKB engines to a
modal dialog with GtkSearchBox which is called by both the shortcut key and IBus panel icon menu and the shortcut key will be customizable by
gsettings or ibus-setup but I'm not sure if that next plan is on time for Fedora 25.

Fujiwara

On 07/11/16 21:41, Takao Fujiwara-san wrote:

On 07/11/16 20:25, Bastien Nocera-san wrote:

- Original Message -

On 07/08/16 20:41, Bastien Nocera-san wrote:

I think the emoji typing does not depend on XKB but is used frequently and I
don't think it should be separated.

It is on every other platform I can think of.

I replied this.

What do you mean in the certain expectations and designs.
As I explained, a radio button would be a idea to resolve your disacoverable
way because I think you mean the GUI access.

Fujiwara
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-12 Thread Takao Fujiwara


On 07/12/16 17:05, nicolas.mail...@laposte.net-san wrote:



- Mail original -
De: "pravin d s" 


I am more inclined and use control+shift+e, since normally with one
sentence i use one emoji.


It is tricky to implement since ctrl(gr)+shift+letter is already used in some 
layouts, so the emoji shortcut must avoid stomping on this and only trigger on 
ctrl when ctrl ≠ ctrl(gr)


If there is a duplicated shortcut of C-S-e, I will think the better shortcut.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-11 Thread Takao Fujiwara


On 07/11/16 20:25, Bastien Nocera-san wrote:



- Original Message -

On 07/08/16 20:41, Bastien Nocera-san wrote:

I think that the emoji input method should be a separate input method, so
that most users would have the choice between inputting using the keyboard
layout that matches their keyboard, and a separate input method for
emojis.


I think the emoji typing does not depend on XKB but is used frequently and I
don't think it should be separated.


It is on every other platform I can think of.


I don't think so.
I can see Emoji input on MS-IME in MS-Windows without switching engines in 
Japanese.
I can see Emoji input on Mac without switching engines with 
Command-Control-Space key.
I can see Emoji input on Xperia keyboard in Android without switching engines.


The IBus XKB engine is not discoverable (it's not listed in GNOME's Region
& Language settings) and the keyboard shortcut to input emojis is also not
discoverable. Having a separate input method is likely the better way to
implement this.


I replied this.


You haven't. You're implementing this without any regards for prior art and
design work that's been done. You certainly can implement this internally
however you want, but the end result has to match certain expectations, and
designs. Your implementation won't, and as a result won't be discoverable.



What do you mean in the certain expectations and designs.
As I explained, a radio button would be a idea to resolve your disacoverable 
way because I think you mean the GUI access.

Fujiwara
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-10 Thread Takao Fujiwara

On 07/08/16 20:41, Bastien Nocera-san wrote:

I think that the emoji input method should be a separate input method, so that
most users would have the choice between inputting using the keyboard layout
that matches their keyboard, and a separate input method for emojis.

I think the emoji typing does not depend on XKB but is used frequently and I
don't think it should be separated.
If the engine should be enabled by default for any languages, I think it would make sense that the XKB engines also enable emoji and switching engines
would be more cost than switching input modes.

Once this feature is implemented, the translatable annotations also can be
implementable for input method engines.
I think other platforms does not separate engines for emoji typing.

The IBus XKB engine is not discoverable (it's not listed in GNOME's Region &
Language settings) and the keyboard shortcut to input emojis is also not
discoverable. Having a separate input method is likely the better way to implement
this.

I replied this.

Fujiwara

- Original Message -

On 07/08/16 19:54, Bastien Nocera-san wrote:

- Original Message -

Bastien Nocera さんはかきました:

Except that the way that you'll be implementing this means it's
completely
undiscoverable. I know no one other than those that already use an IBus
method to input a non-latin language that use things like typing booster.

Oh, sorry, I wrote mistakenly "typing booster" above, that was just
a typo. What Fujiwara San is implementing has nothing to do with typing
booster, it is for the IBus XKB engine.

Same applies to the IBus XKB engine. This engine doesn't seem to be listed
in GNOME's Region and Language panel, the shortcut isn't discoverable, and
the
UI for it doesn't match what users expect from their use of emoji on mobile
platforms.

If the implementaion will satisfy users, I also wish to implement to
GtkIMContextSimple.
I agree the undiscoverable point should be considered later.
Maybe a switching radio menu item is an idea?
I don't wish the lookup table by default against the mobile.
I'm not clarified that you pointed the UI which does not match mobile users.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-08 Thread Takao Fujiwara


On 07/08/16 19:54, Bastien Nocera-san wrote:



- Original Message -

Bastien Nocera  さんはかきました:



Except that the way that you'll be implementing this means it's completely
undiscoverable. I know no one other than those that already use an IBus
method to input a non-latin language that use things like typing booster.


Oh, sorry, I wrote mistakenly "typing booster" above, that was just
a typo. What Fujiwara San is implementing has nothing to do with typing
booster, it is for the IBus XKB engine.


Same applies to the IBus XKB engine. This engine doesn't seem to be listed
in GNOME's Region and Language panel, the shortcut isn't discoverable, and the
UI for it doesn't match what users expect from their use of emoji on mobile
platforms.



If the implementaion will satisfy users, I also wish to implement to 
GtkIMContextSimple.
I agree the undiscoverable point should be considered later.
Maybe a switching radio menu item is an idea?
I don't wish the lookup table by default against the mobile.
I'm not clarified that you pointed the UI which does not match mobile users.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-07 Thread Takao Fujiwara


On 07/08/16 00:25, Mike FABIAN-san wrote:

Bastien Nocera <bnoc...@redhat.com> さんはかきました:


Re-send to the change owner

- Original Message -

= Proposed Self Contained Change: IBus Emoji Typing  =
https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing

Change owner(s):
* Takao Fujiwara 

The IBus core will provide the Emoji Unicode typing with the IBus XKB
engines.

== Detailed Description ==
IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now
we
think the similar implementation for the Emoji typging. With IBus XKB
engines,
Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
Shift-e.

== Scope ==
* Proposal owners:
 - IBus core provide the dictionary of the Emoji typing.
 - IBus XKB engines load the Emoji dictionary.

* Other developers: N/A

* Release engineering: N/A
 - List of deliverables: N/A

* Policies and guidelines: N/A

* Trademark approval: N/A

[1] http://unicode.org/emoji/charts/index.html#col-annotations


Will this use:
https://github.com/lalomartins/ibus-uniemoji/
?


I don’t think so, it is supposed to work in all xkb engines of
ibus-typing booster, this is not a seperate engine like ibus-uniemoji.


Sorry, I missed the email.
I expect to use emoji not to switch the IBus engines.
Actually ibus-anthy already implements emoji typing in Japanese.

This implementation enables emoji typing in English with any IBus XKB engines.
I also evaluated ibus-uniemoji:
http://unicode.org/pipermail/unicode/2016-June/003781.html
http://unicode.org/pipermail/unicode/2016-July/003786.html

Now IBus XKB engine uses both en.xml for annotations and emoji.json for 
categories and ascii aliases.




It would be great if this feature used the emoji fonts directly, so we
can use colour icons:
http://www.hadess.net/2016/05/blog-backlog-post-1-emoji.html


The font shown in this blog seems to be one the fonts contained in the
nodejs-emojione package which Fujiwara San is packaging for this change
request.

There seem to be some problems with the font though:

https://bugzilla.redhat.com/show_bug.cgi?id=1350700#c2

But freetype nicely displays it in colour:

https://bugzilla.redhat.com/show_bug.cgi?id=1350700#c3
https://bugzilla.redhat.com/attachment.cgi?id=1176850


I think it would be a desktop font setting?
It would be strange for me if IBus lookup table and text applications show the 
different fonts.

Fujiwara




Cheers
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F39 Change Proposal: IBus 1.5.29 (System-Wide)

Re: Fedora 34 Change proposal: ibus-anthy for default Japanese IME (System-Wide Change)

Re: IBus 1.5.23 - Fedora 33 System-Wide Change proposal

Re: F30 Self-Contained Change proposal: Ibus-typing-booster default for Indian languages

Re: F28 System Wide Change: IBus Unicode Typing

Re: F28 System Wide Change: IBus Unicode Typing

Re: F25 Self Contained Change: IBus Emoji Typing

Re: F25 Self Contained Change: IBus Emoji Typing

Re: F25 Self Contained Change: IBus Emoji Typing

Re: Re: F25 Self Contained Change: IBus Emoji Typing

Re: F25 Self Contained Change: IBus Emoji Typing

Re: F25 Self Contained Change: IBus Emoji Typing

Re: F25 Self Contained Change: IBus Emoji Typing

Re: F25 Self Contained Change: IBus Emoji Typing

14 matches

Site Navigation

Mail list logo

Footer information