cycle on the edge to move from left to right in the icon history

[Sylvain303]

Hello,

👌 Congratulation very nice job. I love your tool. Using under xubuntu.

A feature request:

Allow to move from left / right on the edge with the key to save keystroke.

I may submit a PR. Should be easy to implement. 😁

[tom-james-watson]

If you can create a PR, that would be great!

[Sylvain303]

I'm just looking at emote/picker.py

I'm not used on Gtk programming in Python, could you point me which part of code would be involved?

I found:

https://github.com/tom-james-watson/Emote/blob/054bbb54862afa5c10f3403fd330dce620b943b4/emote/picker.py#L308C5-L308C49

But, it doesn't look like the motion in the picker is handled here?

Any hint?

[Sylvain303]

🤔 hum may be more on:

on_emoji_btn_event ?

    def on_emoji_btn_event(self, btn, event):

I suppose Gtk.Box object some what offer key motion for free?

May be not. I also found which create a Gtk.Grid which much more look like what is involved:

    def create_emoji_results(self, emojis, for_category=False):

[tom-james-watson]

The selection is not something I've written explicity myselef. It's part of Gtk.Grid. My initial reaction was that it would be difficult to change, honestly.

[Sylvain303]

Chat GPT gave me some hints. Still wrong, but brings me the basics to figure out what to call.

Here follow a sample code (verbatim) that popup a small 5x5 grid, that somewhat implement cycle by driving focus.

We may need to add a property to keep track of the current row/col or something to compute the edge behavior.

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, Gdk

class GridExample(Gtk.Window):

    def __init__(self):
        super(GridExample, self).__init__()
        self.connect("destroy", Gtk.main_quit)

        self.grid = Gtk.Grid()
        self.add(self.grid)

        self.buttons = [[None for _ in range(5)] for _ in range(5)]
        for i in range(5):
            for j in range(5):
                button_label = str(i * 5 + j + 1)
                self.buttons[i][j] = Gtk.Button(label=button_label)
                self.grid.attach(self.buttons[i][j], j, i, 1, 1)

        self.current_row = 0
        self.current_column = 0
        self.buttons[self.current_row][self.current_column].grab_focus()

        self.connect("key-press-event", self.on_key_press)

    def on_key_press(self, widget, event):
        keyval = event.keyval
        if keyval == Gdk.KEY_Right:
            self.current_column = (self.current_column + 1) % 5
        elif keyval == Gdk.KEY_Left:
            self.current_column = (self.current_column - 1) % 5

        self.buttons[self.current_row][self.current_column].grab_focus()

if __name__ == "__main__":
    win = GridExample()
    win.show_all()
    Gtk.main()

I stop my exploration for today. I will setup a my dev copy of Emote, in the next days.

[tom-james-watson]

Alright - good luck!

[waldyrious]

Cross-linking #82, and taking the opportunity to suggest considering the behavior proposed there: instead of jumping back to the start of the same line, it would be nice to go to the end of a line and jump to the start of the next line.

[Sylvain303]

Alright - good luck!

Done:

I probably have much more (lib and package installed)

git clone [email protected]:tom-james-watson/Emote.git
cd Emote
python -m venv emote_venv
. ./emote_venv/bin/activate
pip install pipenv
make install
export PIPENV_VERBOSITY=-1
pip install PyGObject
make dev

I also played with some version of the Gtk.Grid loop modulo from the sample above ⬆️.

Now I've to figure out the code path in picker.py to make my way to store and manage col,row persistance and modify on_emoji_btn_event() (🤔 probably) and keep track of col, row watching (Left,Right,Up,Down) event.
And probably also storing emoji Gtk.Button in a 2 dimensions list to access by [row][col] or something.

See next episode. 😁

[tom-james-watson]

Cross-linking #82, and taking the opportunity to suggest considering the behavior proposed there: instead of jumping back to the start of the same line, it would be nice to go to the end of a line and jump to the start of the next line.

I agree with @waldyrious. I had misunderstood the original post here. I think treating the grid as a single continous line makes more sense than looping round the same row.

[Sylvain303]

it would be nice to go to the end of a line and jump to the start of the next line.

I agree with @waldyrious. I had misunderstood the original post here. I think treating the grid as a single continous line makes more sense than looping round the same row.

I actually disagree. Because on my use-case See my post here

This would make-me -think: how to go to the end of the first history row?
(row,col)
answer:

1. ⬇️(1,1) from search to first item of the grid
2. ⬇️(2,1) (continuous grid)
3. ⬅️(1,10) going back to the end of previous

Instead of just ⬇️ + ⬅️ (without thinking because it's brain friendly 🧠)

But please, give use-case where it would benefit to go next continuous instead of cycling. On TV virtual keyboard for example (which is painful to move) it's cycling on the same row. 🤷‍♀️

As the issue #82 is closed we can continue discussing here, no problem. 😉

Note: The code to produce between the two behaviors is trivial, though.

[tom-james-watson]

I think for a vertical scrolling grid of items, the wrapping on to next behaviour is the norm. I'm on macOS right now and the system emoji picker works how I describe.

I also wouldn't want to support an option for this - adding options for everything is tempting but leads to a confusing ux and much more complex maintenance.

[Sylvain303]

I think for a vertical scrolling grid of items, the wrapping on to next behaviour is the norm. I'm on macOS right now and the system emoji picker works how I describe.

🤔 I see. It's kind of brain already trained, but for mac user. 😉 I didn't have any emoji picker before using Emote. So I've my own biases me it's Linux and keyboard habit from Vim.

Do you use Emote on macos too?

I need to have use-cases in order to figure out corner case, in term of number of keystroke needed to reach an emoji. Mostly in recently used I would say. 😕 (will be described in use-case dedicated post ⬇️)

I will create a new reply in the issue to sum-up use-cases mentioned with visual help (screeshot) and number of keystroke, etc. (then I will edit this new post and maintain the proposed alternatives)

I also wouldn't want to support an option for this - adding options for everything is tempting but leads to a confusing ux and much more complex maintenance.

🤔 Not sure to follow, here. It's not exactly the purpose of having settings?
And also having free software and do things the way it more suite our personal need. So settings or config file permits to have a personal driven behavior.

For example, in this video 📽️ macos system emoji selector (if I found the good one 🤷) you can see a sample of usage of "skin tone" selector. By long clinking on the icon may be.

If your user experience is based on this feeling and you like it, you will tend to reproduce it. But if a user is coming from an alternative background, and you change from old "skin tone" selector to a new "macos like" may it will confuse user.

In closed source code, obviously you cannot change anything. 😉

[tom-james-watson]

Do you use Emote on macos too?

Nope, Emote is linux only. The macOS emoji selector is already great, so there's not really any need for a 3rd party selector.

The question about how arrows work in the grid is not just a question of minimizing keystrokes to get to a given coordinate, it's more about the UX doing what the user expects. For me, that is that pressing right at the end of a row should go to the first entry on the next row.

🤔 Not sure to follow, here. It's not exactly the purpose of having settings?

As a maintainer of open source software, you receive A LOT of opinions on how things should or should not work. There are a lot of feature requests and often these contradict the feature requests of other people. If you added every single thing that people asked for and added options where there was disagreement, the app would end up being a bit of a mess. Sometimes you just need to have someone make a decision and stick to it.

Obviously also the less branching paths/behaviours there are in the app, the easier it is to maintain.

Happy for you to keep looking at this and submit a PR, of course, but IMO it should be for the next row behaviour, with no additional preferences.

The benefit of open source is that anybody can take the code and do whatever they want with it - tweak it, fork it, anything. It doesn't necessarily mean that every feature request gets to make it into the software, though.

[Sylvain303]

⚠️ collector post, will be edited to contain collected use-cases

use-cases

1️⃣ cycling stay on the same line (row) ↔️

2️⃣ continuous walk row are considered to be folded ↙️ (after the end it's beginning of the next row)

Note: row, col are counted from top, left: 1..n (first is 1, 1)

recently used emoji

Minimizing keystroke in order to reach an emoji

• 10 emojis in a row (or less)
• 6 lines of history max visible (or less)
• may be not needed to scroll down in the history, only using visible emoji
• mostly the first row (locality access)

If looping trough edges: keystroke Left Right should be at most 5 to reach an emoji on a line.

first emoji (1, 1)

• 1️⃣ Left ==> go to last item in the same row (cycling)
• 2️⃣ Left ==> nothing? (continuous)
• Up ==> go "nearby" category button (leaving the grid)
  

first emoji not on first row (>1, 1)

• 1️⃣ Left ==> go to last item in the same row (cycling)
• 2️⃣ Left ==> go to last item of previous row (continuous)
• Up ==> go to the row above (default Grid move)

last item of row (except last row)

• 1️⃣ Right ==> go to fist item in the same row (cycling)
• 2️⃣ Right ==> go to first item of next row (continuous)
• Up ==> go to the row above (default Grid move)
• Down ==> go to the row under (default Grid move)

last row of the grid

• Down ==> nothing

last item of the Grid

(right most item of the row)

• 1️⃣ Right ==> Go to first item of the last row (cycling)
• 2️⃣ Right ==> nothing?

Category emoji

less chance that the keystroke will be important because the chance the emoji we are looking for can't be reached in fewer keystroke than typing it in search or going to use visual scroll (mouse or key)

search result

Same a most recently used.

[Sylvain303]

it's more about the UX doing what the user expects.

🤔 it could be a very personal feeling, right? The User eXperience.

As a maintainer of open source software, you receive A LOT of opinions on how things should or should not work.
[...]

I agree! 😁

Let's move on, today I crafted a draft prototype (recall I'm not used in Gtk programming)

So I got some result, first implementing (cycling ↔️).

I also posted the famous use-case ⬆️ (version 1). I need it to handle extra behavior in corner cases. 😉 So producing the algorithm.

So what about my draft:

• it contains draft code that should be removed (window move, extra print, extra message in show_emoji_preview(), etc.)
• almost minimal code for the PoC has been produced (some tests are probably missing None object or corner cases)
• I added some extra properties to handle grid position detection on edges and to also be able to detect incomplete rows (less than 10 items EMOJIS_PER_ROW)
• most of the job is accomplished in on_key_press_event()

The Draft PR in order to compare code change. 😉