Add shortcuts to scroll image viewer up/down

[windymilla]

Shouldn't need focus to be in the viewer, but should be shortcuts that are unused in the main text

[windymilla]

Would it also be good to have next/prev image buttons in the image viewer. They would just change the image, not move the text window at all. They would also need to turn off Auto Img.
One possible use case would be where, for whatever reason, there is no text between one page break and the next, so you can't click in that gap and then See Img.

[rtonsing]

Not a big deal, but I would like it. I'm not 100% confident the buttons on the status bar will not skip non-text pages. In any case, I would like, at least sometimes, to go to next or previous page in the viewer without moving the text window.
This is helpful when one or more images have been moved to a paragraph break and no longer match the page number. I just want to see the image caption, not jump around in the text window.

Update: I have a case where the buttons on the status bar do indeed skip images. Full page images have been moved to paragraph breaks, now when I am on Img: 12, and I click '>', it goes to Img: 15. So I can't verify the captions that are in the text file.

[srjfoo]

Going out on a limb here -- would it be better to pop a subordinate image viewer? I really don't want to add more vertical space to the control block for the image pane. It's already significantly shorter than the text pane.

For instance, one other image control it might be nice to have is the ability to rotate an image.

[windymilla]

pop a subordinate image viewer

Do you mean a second viewer with the next/previous image in? Not sure I would like that, but I take your point about the control block. There may be room on the right of the existing control block, to the right of "Fit to height".
If we did have a rotate, it could maybe go next to Invert Image?

[windymilla]

Another possible idea for whoever works on this:
Add an "Enter" and "Leave" event binding. On Enter, show < and > buttons on the left & right edges halfway down, and on Leave, hide the buttons.
Several apps do something like that:

[tangledhelix]

I think with judicious use of Unicode (or image buttons), there's room to condense this entire control system while still having it make sense to humans. I made a PoC of a single-row control strip. There's room to improve this; it's just a mockup I threw together. If this is interesting, I'm happy to play with it more and turn it into a PR.

I didn't play much with weighting the various columns, but you can see the buttons have empty space, so they could be narrower than this to fit another couple of buttons (which might be ← and → or ❮ and ❯ or similar).

If there are concerns about clarity, we can always add tooltips on hover.

For me this reduced the control height from 71 pixels to 28 (60% reduction).

Before:

After:

Branch: https://github.com/tangledhelix/guiguts-py/tree/condense-img-ctrl

[windymilla]

That looks promising in terms of addressing @srjfoo's concern. I don't know how much success you'll have making the buttons narrower on macOS, as it's sometimes a bit opinionated about sizes of widgets, but it might be OK.

1. I'm happy with losing the word "Zoom", and the two occurrences of "image".
2. The + and - look fine.
3. I'd prefer to avoid the red cross for Close. It doesn't fit the style of other dismissing crosses, at least on Windows. A small monochrome cross in a square button in the top right hand corner might be OK, or I think I'd prefer the word "Close"
4. Another possibility for the "fit" might be to replace the word "Fit" in your buttons with a Unicode "page" character, either text or image (assuming font availability is OK), e.g. ⬅︎🖻➡︎ or ⬅︎🗎➡︎ . Possibly up/down arrow for vertical fit, 🗎↕. Unfortunately "combining left right arrow below" doesn't look too hopeful: 🗎͍ but maybe a regular left right arrow would be OK: 🗎↔. The double headed arrow gives me more of the idea of "fit", where the separate arrows perhaps imply moving the image left & right?
5. Arrows (or </>) would be fine for prev/next image.
6. Would rotate have to have 4 (or at least 3) settings as checkbuttons: ↺, ⟲ and ↻ (the potential 4th being not-rotated, if they were implemented as radio buttons instead of checkbuttons. Just a single button to rotate by 90 degrees would leave the question of how persistent the rotation would be (e.g. go forwards a page - would the new page be rotated) where a checkbutton is like the invert button - it means the current image will be transformed according to the checkbox settings.

What do y'all think? Would it all become too cluttered, trying to squeeze it onto one line, bearing in mind we are only likely to want to add buttons in the future, not take any away. Also, we need to consider how narrow a user might want the image viewer to be, given that it takes width away from the text area.
We could reduce the vertical padding somewhat, to gain a little bit, even with the current 2-line layout. Or we could consider "floating" controls appearing when the mouse is over the image similar to what I mentioned earlier. I'm not sure what's best.

[tangledhelix]

That looks promising in terms of addressing @srjfoo's concern. I don't know how much success you'll have making the buttons narrower on macOS, as it's sometimes a bit opinionated about sizes of widgets, but it might be OK.

If I get the relative weights right it might be; I didn't really try yet. I literally threw this together in 15 minutes while waiting for a kid to get ready for school 😄

3. I'd prefer to avoid the red cross for Close.

I would too; it was good enough for the mockup. I'll look for a monochrome X type of symbol.

Tkinter also supports using images as buttons, which is another option so long as we can find legally available images, or someone who can make some. I've used copyleft-licensed icon sets on web sites before, they're out there.

Possibly up/down arrow for vertical fit, 🗎↕.

I tried that one, but due to the compressed height it was almost illegible. The left-to-right double arrow looked fine, but I didn't want to use a double-arrow in one button and two arrows in the other...

The double headed arrow gives me more of the idea of "fit", where the separate arrows perhaps imply moving the image left & right?

FWIW, I agree, but I'm not sure any of the Unicode arrows will be legible. But I can experiment, and see above about images.

6. Would rotate have to have 4 (or at least 3) settings as checkbuttons: ↺, ⟲ and ↻ (the potential 4th being not-rotated, if they were implemented as radio buttons instead of checkbuttons. Just a single button to rotate by 90 degrees would leave the question of how persistent the rotation would be (e.g. go forwards a page - would the new page be rotated) where a checkbutton is like the invert button - it means the current image will be transformed according to the checkbox settings.

I would go with only one or two. That is, either a single rotate button that goes 90º at a time, or else two for the two directions of rotation. (Two buttons is more convenient, but one would save UI space.)

IMHO, it makes sense to memorize the rotation per image in the JSON, and not assume that the next image should be affected by the rotation of the current image. In my experience, almost all of the time you want the image as-is, and only once in a while you will want to rotate one, e.g. a full-page image printed sideways. (Perhaps there are outlier projects, books with mostly images, that go against my own experience.) If we memorize the rotation of each image, when the user comes back to a specific image, it will be as they left it. I think that would be the best user experience and follows the principle of least surprise.

We would only need to store a rotation for those images that have been rotated, and assume 0º as a default.

What do y'all think? Would it all become too cluttered, trying to squeeze it onto one line, bearing in mind we are only likely to want to add buttons in the future, not take any away. Also, we need to consider how narrow a user might want the image viewer to be, given that it takes width away from the text area.

It would be best if we figure out how to make this work well at a narrow width, even if the buttons must somehow wrap. (Can frame rows wrap? I actually don't know...)

We could reduce the vertical padding somewhat, to gain a little bit, even with the current 2-line layout. Or we could consider "floating" controls appearing when the mouse is over the image similar to what I mentioned earlier. I'm not sure what's best.

Floating could be interesting. I don't know what options are available in tkinter to do that. Having no controls in the way when you're just working on the text with Auto Img on, and having them appear if you hover over the image pane, might be the best outcome. It would also leave a bit more vertical height for image display.

I suppose there's a risk users wouldn't understand the controls are there and have to accidentally discover the floating controls, but we could solve that with a subtle tip in small text at the top of the frame or something? "Move mouse over image to reveal controls" or something along those lines.

[windymilla]

6. Would rotate have to have 4 (or at least 3) settings as checkbuttons: ↺, ⟲ and ↻ (the potential 4th being not-rotated, if they were implemented as radio buttons instead of checkbuttons. Just a single button to rotate by 90 degrees would leave the question of how persistent the rotation would be (e.g. go forwards a page - would the new page be rotated) where a checkbutton is like the invert button - it means the current image will be transformed according to the checkbox settings.

I would go with only one or two. That is, either a single rotate button that goes 90º at a time, or else two for the two directions of rotation. (Two buttons is more convenient, but one would save UI space.)

IMHO, it makes sense to memorize the rotation per image in the JSON, and not assume that the next image should be affected by the rotation of the current image. In my experience, almost all of the time you want the image as-is, and only once in a while you will want to rotate one, e.g. a full-page image printed sideways. (Perhaps there are outlier projects, books with mostly images, that go against my own experience.) If we memorize the rotation of each image, when the user comes back to a specific image, it will be as they left it. I think that would be the best user experience and follows the principle of least surprise.

We would only need to store a rotation for those images that have been rotated, and assume 0º as a default.

Sounds like a good solution - I'd be happy with either 1 or two buttons as you describe. The PPer wouldn't need to use it often, so 3 clicks to rotate 270 degrees isn't too much of a problem.

It would be best if we figure out how to make this work well at a narrow width, even if the buttons must somehow wrap. (Can frame rows wrap? I actually don't know...)

Frame rows can't wrap AFAIK (at least without additional code to do something like detecting configuration change, and comparing width with widget positions, and then manually wrapping. A (disabled) Text widget can have other widgets added, which can then wrap, but without other code, the Text widget wouldn't get taller to show the wrapped widgets. So, in short, I don't think that's easy.

Another possible option if button widths seem to be awkward is to use labels, which can definitely be narrow, and then have Leave/Enter events to make them look/behave like buttons. The "buttons" in the status bar in GG1 are in fact labels IIRC.

ETA: Actually, that reminds me - the "<" and ">" buttons in the GG2 status bar are buttons with width set to 1. So, if they are narrow on macOS, there's perhaps no problem.

Floating could be interesting. I don't know what options are available in tkinter to do that. Having no controls in the way when you're just working on the text with Auto Img on, and having them appear if you hover over the image pane, might be the best outcome. It would also leave a bit more vertical height for image display.

I don't think there's any in-built support to "float". You'd have to say "if mouse enters relevant area, then show a frame containing buttons on top of the image, and if mouse leaves then hide it" - not sure how well it would work, but I think it's very similar behavior to the way I did tooltips.

I suppose there's a risk users wouldn't understand the controls are there and have to accidentally discover the floating controls, but we could solve that with a subtle tip in small text at the top of the frame or something? "Move mouse over image to reveal controls" or something along those lines.

Or just make the controls come up anywhere in the frame, not just over the image, i.e. instead of the tooltip you suggested, just show the controls.

[tangledhelix]

ETA: Actually, that reminds me - the "<" and ">" buttons in the GG2 status bar are buttons with width set to 1. So, if they are narrow on macOS, there's perhaps no problem.

They are narrower, yes.

These label buttons are interesting; nice and compact. I will look at that first, I think.

[srjfoo]

OS dark with GG2 default:

OS dark with GG2 dark:

I agree -- the red X is a bit too prominent 😁

I assumed one rotate button that would rotate either sunward or widdershins by 90° with each click.

I need to respond later to the above comments, but I'll leave these for now.