Closed patrickas closed 1 year ago
That seems to make sense. I also guess that we should still process CTRL + mouse wheel normally when hovering a generation
This kind of generates some incompatibilities with #89, actually.
Maybe avoiding overlaps altogether for multiple generations would be better.
I would also suggest making the "S" option (Download Image To Computer) download the whole canvas instead of just saving the generated image part
Or just add an "E" next to the "S" which means export whole canvas
I would also suggest making the "S" option (Download Image To Computer) download the whole canvas instead of just saving the generated image part
Or just add an "E" next to the "S" which means export whole canvas
Could you create an issue for this request? Just so we can keep these functionality requests more organized!
Will probably do the second option (E button).
@patrickas, If you could give the testing branch a look (git checkout testing
)
It works great.
There are two minor things, but I think it can be merged as is and it is already extremely practical.
Amazing work!
- Middle clicking the wheel did not do anything, I thought it might be useful to produce a new batch as if we clicked on [+]
This will be quick to implement. No worries on that.
- The Wheel direction is opposite to my expectations. I expected to scroll down to go to the next and up to go to the previous
Strangely, for me it's the opposite! But I don't really have a preference. What do you think, @zero01101?
yeah, to be honest i just assumed that scrolling up would increment the index and move to the next image :|
i agree with you guys (seijihariki and zero011101) that scrolling up should mean going to the next image. Makes perfect sense that way imo
No problem at all for the scrolling it is such a minor thing not worth worrying about.
I guess for me I expected it to work the same as reading... When I want to read the next think I scroll down, so when I wanted to view the next image I scrolled down.
But it does make sense that up increments and down decrements the counter.
Makes sense if you think of it that way. I will then add the middle mouse button functionality, but keep the scroll as is because it seems the most intuitive option for most people.
Changes relating to this request seem to be working fine. Camera pan was refactored to require the Ctrl Key (Ctrl Key + Mouse middle click - drag) to allow for middle click image generation and better consistency (all camera moves now require Ctrl to be pressed).
If anything is working strangely, we can reopen this issue or open another one.
After a dream completes and the new controls [<] [>] [+] [Y] [N] are displayed under the reticle, I think it makes sense that when the mouse is placed inside the reticle in questions the mouse buttons / wheel interact with the controls.
Scrolling should move between possibilities as if we pressed the left right arrows. Clicking the mouse wheel should generate a new set Left click should accept Right click should cancel.
This change should only happen when the mouse is over a reticle that has the controls displayed. The reason is that the normal controls are not too useful in this situation and it makes sense to do the next logical steps (select the picture we want) with the mouse controls without having to hunt for the tiny controls and click them.
Once the image is selected or cancelled or once the user wanders outside of the reticle the controls go back to behaving normally. Maybe a change in the cursor shape can indicate that we are in a special mode, in case we want to give visual indication of that.
I think the flow described is much more practical than the current one when working with big images