= Proposed Self Contained Change: IBus Emoji Typing = https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing
Change owner(s): * Takao Fujiwara <tfujiwar [at] redhat [dot] com>
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
----- Original Message -----
= Proposed Self Contained Change: IBus Emoji Typing = https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing
Change owner(s):
- Takao Fujiwara <tfujiwar [at] redhat [dot] com>
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/ ?
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
Cheers
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 <tfujiwar [at] redhat [dot] com>
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/ ?
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
Cheers
Bastien Nocera bnocera@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 <tfujiwar [at] redhat [dot] com>
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.
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
Cheers
devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 07/08/16 00:25, Mike FABIAN-san wrote:
Bastien Nocera bnocera@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 <tfujiwar [at] redhat [dot] com>
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
Takao Fujiwara tfujiwar@redhat.com さんはかきました:
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
Yes, it would be a desktop font setting. It would be nice if we have a emoji font with colour available in Fedora which works everywhere.
----- Original Message -----
On 07/08/16 00:25, Mike FABIAN-san wrote:
Bastien Nocera bnocera@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 <tfujiwar [at] redhat [dot] com>
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.
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.
A separate input method that's automatically added to the default list of "keyboard layouts" would be much better suited to our use case, and matches the way people are used to enter emojis on Android and iOS, with a separate keyboard layout.
Bastien Nocera bnocera@redhat.com さんはかきました:
----- Original Message -----
On 07/08/16 00:25, Mike FABIAN-san wrote:
Bastien Nocera bnocera@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 <tfujiwar [at] redhat [dot] com>
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.
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.
A separate input method that's automatically added to the default list of "keyboard layouts" would be much better suited to our use case, and matches the way people are used to enter emojis on Android and iOS, with a separate keyboard layout.
----- Original Message -----
Bastien Nocera bnocera@redhat.com さんはかきました:
<snip>
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.
On 07/08/16 19:54, Bastien Nocera-san wrote:
----- Original Message -----
Bastien Nocera bnocera@redhat.com さんはかきました:
<snip> >> 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.
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.
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.
----- Original Message -----
On 07/08/16 19:54, Bastien Nocera-san wrote:
----- Original Message -----
Bastien Nocera bnocera@redhat.com さんはかきました:
<snip> >> 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.
Bastien Nocera bnocera@redhat.com さんはかきました:
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.
Are you talking about something like ibus-gucharmap?
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.
----- Original Message -----
Bastien Nocera bnocera@redhat.com さんはかきました:
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.
Are you talking about something like ibus-gucharmap?
Something similar to: https://github.com/lalomartins/ibus-uniemoji
ibus-gucharmap is far too wide a use-case.
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 bnocera@redhat.com さんはかきました:
<snip> >> 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.
----- 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.
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.
They do.
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.
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
Takao Fujiwara tfujiwar@redhat.com さんはかきました:
On 07/11/16 20:25, Bastien Nocera-san wrote:
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.
I also see Emoji input in Android using the SwiftKey keyboard. There is an option in the SwiftKey keyboard to enable emoji input which is useful in my opinion.
Using Googles japanese input on Android one can also input emoji nicely.
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 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
----- Original Message -----
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.
Fair enough. Where's the design work for this functionality?
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.
A radio button somewhere in ibus doesn't make it discoverable.
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
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.
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
On 11 July 2016 at 16:55, Bastien Nocera bnocera@redhat.com 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.
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.
They do.
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.
I feel minor confusion here. (Hoping i am correct) This feature is similar to what we are using presently to type U+XXXX characters. Its global setting. Example: Control+Shift+u followed by unicode character code. control+shift+u + 0915 gives me क Please note, there is already ibus ime available for this.. ibus-rawcode [1] which does this thing. You need to install this, i normally do this when i need to type more unicode characters.
Same way: For typing emoji, we are planning as follows: Example: Control+shift+e followed by 'english word related to emoji' [2] It has bit more complexity compare to Unicode character. User need to type whole word and single word gives you more options of emoji. From users perspective: If we want to type single Emoji, we can simply type control+shift+e enter emoji and resume typing with current IME. If user want to type many Emoji at a time. Then good to switch (ibus-uniemoji) IME type all characters and switch back to previous IME.
So both control+shift+e and ibus-uniemoji has there own importance and uses.
I am more inclined and use control+shift+e, since normally with one sentence i use one emoji.
Hope it helps :)
Thanks, Pravin Satpute
1. https://github.com/pravins/ibus-rawcode 2. http://unicode.org/emoji/charts/emoji-annotations.html#frown
----- Mail original ----- De: "pravin d s" pravin.d.s@gmail.com
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)
On 07/12/16 17:05, nicolas.mailhot@laposte.net-san wrote:
----- Mail original ----- De: "pravin d s" pravin.d.s@gmail.com
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.
-
Bastien Nocera -
Jaroslav Reznik -
Mathieu Bridon -
Mike FABIAN -
Nicolas Mailhot -
pravin.d.s＠gmail.com -
Takao Fujiwara