Move Popup Option

[robertmaxton42]

Rikai... -kun or -chan, I don't remember which, had a keyboard shortcut to move the popup dialog to other parts of the screen -- top left or bottom right or a few others. It'd be cool if Rikaichamp could get something similar; on some sites - most critically Google Translate, I often like to MTL some article and then hover over and manually translate where needed/interested - the original site creates its own popup over the Rikaichamp one, making it unreadable.

[harerod]

Hi Brian, first of all - thank you for your effort. I have used this tool ever since Firefox switched to the new plugin format. Having said that, I see this as a critical issue as well. When when hovering over the bottom lines of window, the pop-up sometimes shows above the line, but quite often, invisibly, below the line. This is especially an issue for learners using sites like imabi.net, which use formatting like this:
->
コンサートに行かないですか。
Why not go to a/the concert?
<-
A learner, ok, I admit it, I might make the window half the screen height and scroll as to only show the Japanese text, translate it and then check.

A simple repositioning (used to be 'a' in the predecessors, AFAIR) of the pop-up over or below the respective line might already do the trick. The old tool even allowed moving the pop-up around the window, in its corners etc., though. I'd like to pledge 5000Yen, payable via Paypal friends-transfer, if at least simple above/below repositioning could be done before XMAS2019.

In the meantime - a work-around: if the distance between the bottom of the screen (not only the Firefox-window) and the line in question is smaller than the pop-up-height, the pop-up will appear above the line.

[birtles]

In the meantime - a work-around: if the distance between the bottom of the screen (not only the Firefox-window) and the line in question is smaller than the pop-up-height, the pop-up will appear above the line.

It should already do that. Do you have a screenshot where it is not doing that? Or do you mean that you keep the window full height, and move half of it off the screen?

I would love to fix this situation for you but I should try to understand the problem better first.

[robertmaxton42]

It does already do that; thus, it's an existing workaround for the the problem of "can't move the box".

[birtles]

Ok, so what are we thinking here, perhaps something like:

Vertical positions:

1. Top of screen
2. Above text
3. Below text
4. Bottom of screen

Behavior:

• (3) is default, except when there is not enough room, then it goes to (2). [Existing behavior]
• Pressing ↑ / k and ↓ / j moves between the different positions, skipping (2)/(3) when there is not enough vertical space.
• When you reach (1)/(4) the setting is sticky?
  • Could be confusing if you accidentally press one of the keys and don't know how you got stuck in the state you are. That seems quite likely to happen so I'd probably prefer either it is never sticky, or that you have to enable these controls explicitly.

I'm also concerned that overriding arrow keys would interfere with regular page scrolling so probably just j / k is enough. We could possibly make these keys configurable as a later step.

For positions (1) and (4) putting the window on either the left or right probably makes more sense. We could add left/right commands for this but I suspect it might be better to just revise the list of positions to:

1a. Top of screen (left)
1b. Top of screen (right)
2. Above text (aligned to selection)
3. Below text (aligned to selection)
4a. Bottom of screen (left)
4b. Bottom of screen (right)

[harerod]

Hi Brian, thank you for reacting so quickly.
While collecting screenshots on Win7pro, Firefox 70.0.1(64bit), I finally figured out what triggers the hiding of the pop-up.
For better readability I usually view pages at 130%. If there is not enough headroom to the top of the window to display all the information, the pop-up will be forced below the line under investigation.

On a letterbox window, we will quite often come to a situation when there is more information than can be displayed.

As possible remedies, two approaches come to mind:

• changing the zoom factor of rikaichamp independent of Firefox
• moving the pop-up to various positions on the screen

Looking at your excellent list of suggestions:

1a. Top of screen (left)
MAH->Yes, please
1b. Top of screen (right)
MAH->Yes, please
2. Above text (aligned to selection)
MAH->Current standard? Might run into issues with the window borders. But we have the other positions to chose from.
3. Below text (aligned to selection)
MAH->Current standard? Might run into issues with the window borders. But we have the other positions to chose from.
4a. Bottom of screen (left)
MAH->Yes, please
4b. Bottom of screen (right)
MAH->Yes, please

Regarding position control, I would suggest sticking with an alphabet character key. AFAIR pressing 'a' cycled the older variant's pop-up position. 6 different positions, as seen in your list, might already be the limit of how many positions one might want to cycle through. A second key, for cycling backwards, might be a nice feature at one point. Actually j/k might be a nice combo, since they are next to each other on the keyboard.

Again, I appreciate your effort. Thinking more thoroughly about the whole issue gave me further insight into what the actual problem is. People who do not use large zoom ratios might never run into this.

marcus

[robertmaxton42]

A note -- as noted, my use case is in Google Translated pages. Zoom ratio doesn't matter there; the popups are generated long after the page finishes loading.

... It occurs to me that that particular problem might be solved simply by increasing the z-value of the created prompt to, say, 69105, so that it would be always-on-top of everything else. That wouldn't solve the general problem, but it'd be an easy workaround?

At any rate, mostly I agree that being able to move character keys with 'a' or 'j/k' would be ideal for this problem and the generalized problem of "sometimes the computer choose a bad place for the popup."

[shmibs]

would like to add to this discussion the topic of vertical text. it would be nice to have (can it be queried?) text with writing-mode: vertical-rl; trigger the popup displaying left-right of the text rather than below-above, to avoid this:

a key to switch modes would work as well though, obvs

[birtles]

Excellent ideas. For what it's worth, this is fairly high up on my list of priorities. I've spent most of December just trying to fix problems with the new kanji dictionary setup but that seems to be mostly fixed now so I hope to get on to this before too much longer.

[Esoppant]

Has this been implemented yet? I too, would like to be able to move the pop-up with a hotkey, since it often tends to appear below the bottom of my browser when the text I hover over is near the bottom.

[canadian-ultra]

It seems when the definitions are quite long they will have a tendency to appear beneath the screen. Very frustrating when trying to use this combined with subs since even on longer words it can have tons of shortened guesses to give a long window. Otherwise fantastic extension that is invaluable and I really appreciate.

[birtles]

Thanks for the feedback here -- sorry I still haven't got to this. I really do appreciate people chiming in with this feedback though as it helps me to prioritize work. I've re-added it to my list.

[birtles]

In the latest trunk version I've made some fairly significant changes to the default popup positioning. Hopefully vertical text works a lot better now.

@canadian-ultra Can you point me to the link for that video so I can check how popup positioning looks there now?

(For what it's worth, I still hope to implement the j/k positioning feature but I wanted to fix vertical text first.)

[canadian-ultra]

https://www.animelon.com/video/58d9bbba35f2a63e86dafc89 thanks!

[birtles]

https://www.animelon.com/video/58d9bbba35f2a63e86dafc89 thanks!

Thanks! I think the updated positioning is slightly better. Maybe. I'll release a new version today and see how it goes. The manual positioning will come in a separate release.

[birtles]

I did some work on this today and so far it seems straightforward.

Two things I'd like to check, though, if anyone has any input:

1. I've made it so that it cycles between the following positions:

   • top-left
   • top-right
   • auto (current behavior)
   • bottom-left
   • bottom-right

   But I wonder, would top-left, auto, bottom-right be enough? Assuming the primary use case is just getting the popup out of the way, that seems like enough?

2. I've made it so that once you move the mouse to select some new text, it resets to "auto" positioning. Is that ok?

   (My concern with making the setting sticky is that it's almost guaranteed that some users will accidentally press the keys to position the pop-up and then not know how to fix it. I guess I could add a caption to the pop-up explaining what to do but that's a bit complicated because it would change the size of the pop-up meaning we would have to re-position it.)

[harerod]

Hi Brian, that sounds promising. At the moment Firefox doesn't pull the update, so I am stuck with the version from April 8th. However, from what I've read:

• item 2. the automatic reset: I understand your concerns, but I would prefer the setting to be sticky. My preferred way of reading (advanced beginner) is positioning Rikaichamp into the lower right corner and scanning the topmost lines on a website or textfile.
• with older versions there was an issue with large popups, which span the whole height of the screen. I wonder how the new positioning will perform. The large popups were caused by higher zoom-factors due to my eyesight and several active data sources.
  I will give this a check, once the update is done.
  Thanks,
  marcus

[birtles]

Hi Brian, that sounds promising. At the moment Firefox doesn't pull the update, so I am stuck with the version from April 8th.

Oh, I'm sorry. I haven't yet released a new version -- I am just experimenting locally. The version from April 8th is the latest version.

• item 2. the automatic reset: I understand your concerns, but I would prefer the setting to be sticky. My preferred way of reading (advanced beginner) is positioning Rikaichamp into the lower right corner and scanning the topmost lines on a website or textfile.

I see. In that case, I can think of two possible ways to approach this:

a. Add a setting, "Use the same popup position for all words". i.e. make the sticky setting opt-in.
b. Add explanatory text to the bottom of the popup when it has been manually positioned saying, e.g. "Popup position changed. Press j to reset."

I don't really like adding more and more settings so I'd probably prefer to avoid (a). The downside for (b) is that for users such as yourself, that "Popup position changed..." text would be always visible. Would that be ok?

• with older versions there was an issue with large popups, which span the whole height of the screen. I wonder how the new positioning will perform. The large popups were caused by higher zoom-factors due to my eyesight and several active data sources.

I made some improvements to this. Now sometimes you will see the bottom of the popup fade-out. Long-term we probably need something like the ideas discussed in #555.

[Esoppant]

   But I wonder, would top-left, auto, bottom-right be enough? Assuming the primary use case is just getting the popup out of the way, that seems like enough?

I think it should be enough, for the reason you stated.

2. I've made it so that once you move the mouse to select some new text, it resets to "auto" positioning. Is that ok?
   (My concern with making the setting sticky is that it's almost guaranteed that some users will accidentally press the keys to position the pop-up and then not know how to fix it. I guess I could add a caption to the pop-up explaining what to do but that's a bit complicated because it would change the size of the pop-up meaning we would have to re-position it.)

I'd prefer it to be sticky too, for when you have to look up multiple words at the same horizontal position.
Perhaps repositioning could be turned off by default to avoid the issue you mention? Or the default key binding for repositioning could be a "key A + key B" combo so you wouldn't accidentally press it.

[birtles]

Perhaps repositioning could be turned off by default to avoid the issue you mention?

Thank you! That is an excellent idea. I think you've solved it.

[birtles]

One more question: If you move the popup in one tab, do you expect it to apply to other tabs too? Or is this a strictly tab-local thing?

[birtles]

This should mostly work now. The main caveat is that it is not only tab-local but also page-local. That is, if you navigate to a new page, the setting will be reset. Let me know if that's suitable or not.

I think we have a whole spectrum of possibilities:

• Word/dictionary-local: Resets when you look up a new word or change dictionary
• Word-local: Resets when you look up a new word
• Page-local: Resets when you navigate to a new page
• Tab-local: Sticky within a particular tab but resets for any new tab you open (incl. when you restart)
• Session-local: Set for all tabs but resets when you restart the browser (or probably re-install the add-on)
• Device-local: Persists between restarts but is not synced to other devices
• User-local: Synced between all your devices and basically never resets

Of those, I think tab-local could be tricky to implement but the others should be possible. I've gone with page-local for now.

[birtles]

Oh, and I need @SaltfishAmi to check the Chinese translation Google gave me for this:

https://github.com/birtles/rikaichamp/blob/3cfb04e79815e0e7972be24b6b1c86e9da78a449/_locales/zh_hans/messages.json#L1448-L1451

It's tricky because it seems that Chinese, like Japanese, really wants to write "up-down" (上下) rather than "down or up" but the keys in the options page are listed in the order down then up and I wasn't sure how to convince Google to give me that. For reference, here is a screenshot:

[SaltfishAmi]

I suggest changing the · (middle dot) into / (slash) or 、 (acts as comma in Japanese but separates several homogenous terms in S-Chinese) to comply with S-Chinese writing habits. Besides that, no problem.SaltfishAmiSent from phone---- On Fri, 16 Apr 2021 13:01:44 +0800 ***@***.******@***.***> wrote ---- Oh, and I need @SaltfishAmi to check the Chinese translation Google gave me for this: https://github.com/birtles/rikaichamp/blob/3cfb04e79815e0e7972be24b6b1c86e9da78a449/_locales/zh_hans/messages.json#L1448-L1451 It's tricky because it seems that Chinese, like Japanese, really wants to write "up-down" (上下) rather than "down or up" but the keys in the options page are listed in the order down then up and I wasn't sure how to convince Google to give me that. For reference, here is a screenshot: —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[SaltfishAmi]

Oh, and I think it's OK to put 下 before 上 because of the order of the keys listing. We're not that strict about this.SaltfishAmiSent from phone---- On Fri, 16 Apr 2021 13:01:44 +0800 ***@***.******@***.***> wrote ---- Oh, and I need @SaltfishAmi to check the Chinese translation Google gave me for this: https://github.com/birtles/rikaichamp/blob/3cfb04e79815e0e7972be24b6b1c86e9da78a449/_locales/zh_hans/messages.json#L1448-L1451 It's tricky because it seems that Chinese, like Japanese, really wants to write "up-down" (上下) rather than "down or up" but the keys in the options page are listed in the order down then up and I wasn't sure how to convince Google to give me that. For reference, here is a screenshot: —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[birtles]

I suggest changing the · (middle dot) into / (slash) or 、 (acts as comma in Japanese but separates several homogenous terms in S-Chinese) to comply with S-Chinese writing habits.

Great, thank you! I've changed it to 向上、下移动弹出窗口. I hope that's right!

[birtles]

Ok, I've just released 0.5.0 with this feature. Please give it a try and let me know how it goes.

It's disabled by default and I'm not publicizing it on twitter, so hopefully if we decide to change its behavior we can still do so without disrupting too many people.

In particular, it only supports three possible positions: top-left, auto, bottom-right, and it's page-local for now. I'd be interested in hearing any feedback on the feature.

[Esoppant]

Seems to be working fine, thanks for implementing this.
One suggestion would be: since there are only three possible locations, I feel a single key for cycling through them would be simpler. I feel like I'd forget which key is up and which is down every time I decide to move the popup (which is not very often); but that's personal, of course. People who'd use it often might prefer more controller-like keys rather than a toggle-like key.

[birtles]

Thanks! I guess we could support both by simply making j / k cycle. i.e. once you reach the bottom-most position with j it cycles around to the top-most. Then you just need to remember either j or k?

[Esoppant]

Thanks! I guess we could support both by simply making j / k cycle. i.e. once you reach the bottom-most position with j it cycles around to the top-most. Then you just need to remember either j or k?

Oh yeah, that's the best of both worlds. That'd be great.

[birtles]

Ok, I've added the wrap-around behavior in d46a1b7 and released it in version 0.5.1.

I haven't heard any other feedback on this feature so I'm going to go ahead and close this issue.

Thanks everyone for your patience and help with this!