Bug 1658174 - ibus emoji chooser should not change size dynamically
Summary: ibus emoji chooser should not change size dynamically
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: ibus
Version: 43
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: fujiwara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-11 12:46 UTC by Jens Petersen
Modified: 2025-11-11 05:47 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jens Petersen 2018-12-11 12:46:05 UTC
Description of problem:
When using `ibus emoji` and scrolling or moving over the grid of emoji
the size of the window changes depending on the description annotation etc.
I think the size of the window should be fixed (maybe resizable) but
the size should not change when moving the mouse over or scrolling through.

Version-Release number of selected component (if applicable):
ibus-1.5.19-9.fc29

How reproducible:
100%

Steps to Reproduce:
1. $ ibus emoji
2. Select a category
3. Move mouse over emoji grid or scroll through list.

Actual results:
Window size changes depending on annotation.

Expected results:
Window size should be constant.

Additional info:
If the window is nearly an edge it may get moved because of the resizing.

Comment 1 fujiwara 2018-12-12 10:03:53 UTC
> Window size should be constant.

How can the size be constant?

> If the window is nearly an edge it may get moved because of the resizing.

My suggestion was not to move the window when the cursor is moved in the same page even if the resize happens. But seems you found a case the window is moved.
Could you give an example of a category and which emojis your cursor is over?

Comment 2 Ben Cotton 2019-10-31 20:19:50 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Priyam Gupta 2020-08-25 04:47:58 UTC
Its still reproducible in Fedora 33, moving to Fedora 33.

Comment 4 Jens Petersen 2021-09-08 10:11:06 UTC
(In reply to fujiwara from comment #1)
> > Window size should be constant.
> 
> How can the size be constant?

Maybe by eliding some text if it is too long?
It could be shown in a tooltip say.

Comment 5 Ben Cotton 2023-02-07 14:51:12 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 6 Aoife Moloney 2024-11-08 10:40:00 UTC
This message is a reminder that Fedora Linux 39 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '39'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 39 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 7 fujiwara 2025-05-27 03:15:09 UTC
(In reply to fujiwara from comment #1)
> > If the window is nearly an edge it may get moved because of the resizing.
> 
> My suggestion was not to move the window when the cursor is moved in the
> same page even if the resize happens. But seems you found a case the window
> is moved.
> Could you give an example of a category and which emojis your cursor is over?

Probably I think this is the main issue for you.
I think now the position of the candidate popup is better fixed in Xorg and the position is always center in GNOME Wayland so this can be closed?

(In reply to Jens Petersen from comment #4)
> Maybe by eliding some text if it is too long?
> It could be shown in a tooltip say.

The concept is to handle the popup with the keyboard shortcut only and the popup also includes the tooltip function.
I think how to elide the number of the annotations is hard. E.g. the "crying" annotation is located at the last order.

Comment 8 Jens Petersen 2025-11-10 10:32:02 UTC
In general it is better on a large screen than a small vm.

(In reply to fujiwara from comment #1)
> Could you give an example of a category and which emojis your cursor is over?

Choose "Flags" and go to the 2nd page (starts with Greece) and move to the right with cursor key.

The window width jumps larger (because of the wider description).

For the vertical case: most emoji selection changes cause vertical window size to shrink or grow.

I also don't really understand the wrapping algorithm: take this example 🩱 (2nd row of Objects).
(Why does it wrap after "swimsuit"?)

Comment 9 fujiwara 2025-11-11 01:07:41 UTC
Probably I agree with the fixed width of the Emoji candidate popup for any annotations.
This first issue would be a similar issue to order non-glyph emoji chars as you reported previously. I.e. checking the max width of the wrapped description, wrapped annotations and emoji 2 dimensions.

Probably I need to think more thoughts how to enhance the longer annotation list for the height of the Emoji candidate popup.
One idea to have the "⏮⏴ partial annotation list ⏵⏭" with shortcut keys but some shortcut keys are already bound, Rf. ibus-emoji(5),

Comment 10 fujiwara 2025-11-11 01:14:12 UTC
(In reply to Jens Petersen from comment #8)
> I also don't really understand the wrapping algorithm: take this example 🩱
> (2nd row of Objects).
> (Why does it wrap after "swimsuit"?)

It just wraps with 30 chars.
https://github.com/ibus/ibus/blob/main/ui/gtk3/emojier.vala#L1740-L1744

Comment 11 Jens Petersen 2025-11-11 05:47:53 UTC
How about just letting gtk wrap the text?

Also I think the window should have fixed width.


Note You need to log in before you can comment on or make changes to this bug.