Emote window position isnt saved after restarting Chatterino

[makedir]

Checklist

• I'm reporting a problem with Chatterino
• I've verified that I'm running the most recent nightly build or stable release
• I've looked for my problem on the wiki
• I've searched the issues and pull requests for similar looking reports

Describe your issue

Emote window position isnt saved afer restarting Chatterino, always spawns on left top corner. Please give option to make it always spawn left or right next to Chaterino window.

Screenshots

No response

OS and Chatterino Version

2.5.1 Windows 11

[Felanbird]

Cannot replicate on windows 10

[CaptainFlint]

I have the same issue on Windows 10. I open Chatterino, click the emotes button to open the dialog. Move it to some place, change its size; the resulting position is like this:

Full size image

Then I restart Chatterino, open the emotes dialog again, and it appears like this:

Full size image

Neither position, nor size are remembered. The dialog is not even fully visible, part of it is hidden beyond the lower border of the screen (if I pull the dialog up without changing its size, there will be two extra lines of emotes visible).

I had this behavior for as long as I can remember, even when I was working in Windows 7. I just never got around to reporting it.

[Nerixyz]

I noticed the emote window moves by 8 pixels every time it's reopened. For me on Windows 10, the following change fixes this: Nerixyz@391111a

However, I can't replicate the emote window moving more than 8px. It might be good to mention if you're using any high-DPI scaling or change your monitor layout frequently.

[CaptainFlint]

My display configuration is a single monitor 2560x1440 resolution, default 100% scaling.

I also noticed that the windows:emotePopup:x/y in window-layout.json are used for restoring the position, but these values are never saved by Chatterino. No matter where I move the dialog over the screen, those x/y coordinates in the json file are never updated. But if I edit them manually, next time I open the emote dialog its position reflects the change. (And, of course, there are no issues with write access or anything stupid like that, I checked; other data in the same file are updated properly.)

Also, indeed, there is a shift in those coordinates. I made a screenshot of the whole display and measured the 0-based coordinates of the top left corner after moving the dialog, wrote them into the json, and next time the dialog is opened it's displaced by (-8, -1) compared to what is written in the JSON.

[Nerixyz]

I also noticed that the windows:emotePopup:x/y in window-layout.json are used for restoring the position, but these values are never saved by Chatterino. No matter where I move the dialog over the screen, those x/y coordinates in the json file are never updated.

Chatterino doesn't record the position of the emote popup until it's closed, and doesn't save it until the main app is closed, or a window is moved/resized. I've added that in my branch.

[CaptainFlint]

Of course, I was checking the JSON file only after closing the application, not while it was running. Sorry, should have mentioned it, but thought it was obvious.

Also, while we're at it, why is only the position of the emotes dialog processed and not the size? For the main window size is also stored. It would make sense to keep/restore the emotes dialog size too.

[Nerixyz]

Also, while we're at it, why is only the position of the emotes dialog processed and not the size? For the main window size is also stored. It would make sense to keep/restore the emotes dialog size too.

That's a good idea. I've done that in the PR. Ideally, we'd do that for more windows (e.g. the settings window - #2583) in the future. It also resolves the invisible-bounds issue.

[makedir]

Please give an option you can set where to auto open the emji window:

• left, right, top, bottom

and then auto attach to main window.

[makedir]

Not totally fixed. Still is buggy and wont save / attach emoji wndow when you use standalone client start option -c channel. @pajlada