Shows all emoji in categories, it will save the new emoji into the
clipboard.
Details
- Reviewers
davidedmundson - Group Reviewers
Plasma VDG - Commits
- R119:1449633fccfa: Include an emoji picker
Manual testing; run ibus-ui-emojier-plasma
Diff Detail
- Repository
- R119 Plasma Desktop
- Branch
- arcpatch-D24454_1
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 17568 Build 17586: arc lint + arc unit
Cool beans.
Can you make the drawer/sidebar more narrow like we do in Discover? The width is hardcoded in Kirigami to something that's just way too high for this application IMO.
Also an "all" category on top would be nice too. Many smartphone implementations also have a "recently/frequently used" category that's quite user-friendly.
From my POV, +1, though it would be worth outlining your longer term plans after this initial step.
Right now it doesn't really use the applet nor really do anything useful with IBUS, but I assume that's due to change.
applets/kimpanel/backend/ibus/emojier/ui/emojier.qml | ||
---|---|---|
30 | needs a title, otherwise it has something technical in the screenshot |
What I did was to implement an interface equivalent to /usr/lib/ibus/ibus-ui-emojier but with our tech and look & feel, so it can be summoned in a number of ways. I can consider integrating it tighter to the plasmoid, for now biggest asset ibus is offering is the emoji data and API (which is pretty good I'd say).
You just need to make sure it's installed, here we're only using it as a library. Then run the ibus-ui-emojier-plasma executable.
- For the first-run use case, show the All category instead of Recent, or any other time when "Recent" is empty
- How does it work? When I click on an emoji, the window disappears but nothing appears to happen. Its not in the clipboard either?
- Every time I move the cursor over an emoji, file:///usr/lib/qt/qml/QtQuick/Controls.2/org.kde.desktop/ToolTip.qml:48:5: Unable to assign [undefined] to bool is printed to the console
A few more:
- List the categories in a more common order rather than alphabetical (i.e. first smilies, then nature, then food & drink, etc. Basically copy the mobile emoji pickers)
- The window needs a proper icon, not the generic X11 icon
- This might be in Kirigami, but the header text jumps around when I click on the X button to hide the drawer entirely:
Great, that's fixed the ampersand.
I still see this:
Every time I move the cursor over an emoji, file:///usr/lib/qt/qml/QtQuick/Controls.2/org.kde.desktop/ToolTip.qml:48:5: Unable to assign [undefined] to bool is printed to the console
...and all the observations in D24454#545454.
The list isn't hardcoded, I get it from the ibus dictionaries. By default there I get them in a random order.
- The window needs a proper icon, not the generic X11 icon
Fixing
- This might be in Kirigami, but the header text jumps around when I click on the X button to hide the drawer entirely:
I actually don't understand why I get an X at all
Oh one final thing I just thought of: it would be great if the search field could be in the main toolbar rather than in the sidebar, because this makes it inaccessible when the sidebar is collapsed, as it is by default. People might mistakenly assume that there's no search.
The new button in the toolbar should hide the search field if it's visible (i.e. it should be a toggle action), and the search field should be inside its own background or toolbar with appropriate padding, not just floating there in space.
But is there no way to integrate the search field into the main toolbar itself? There's plenty of room.
If I understand right, the emoji workflow this implements is via copy-paste, it can't directly insert into the text fields via the IME bus. Do you have a plan for that?
It has the exact same behaviour as ibus emoji. I did it like this because we first should reach the status quo before improving on it.
Hmm, that seems kind of like a sledgehammer solution to the problem. Why isn't it managing to send the paste data to klipper before quitting?
Why isn't it managing to send the paste data to klipper before quitting?
How?
- We announce "I have some new data" to X.
- Then klipper sees that, then asks for the data
- Then (via X) we get that request and send the data.
It would be technically possible to tell when 2 has happened (nativeEventFilter for XCB_SELECTION_REQUEST) not sure of a feasible wayland equivalent. I can't see a hook for after stage 3.
Staying alive seems the most practical solution...but maybe we can make it stay alive for only 30s after the line emoticon copy event or something.
Given that on Wayland we don't really have any klipper integration yet, I'd suggest thinking of alternatives later. In the end, this will also improve the startup time on subsequent runs.
It's exactly how krunner works, for example.