-
Notifications
You must be signed in to change notification settings - Fork 27k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option to move toprow to settings - alternative design #12691
Conversation
ahhh 2023-08-20.18_32_08_758.chrome.mp4 |
Oh yeah, the built-in |
738ccc2
to
b411e83
Compare
Fixed now. |
@w-e-w
|
this is not my PR I'm just pointing out that the UI would sporadically change if you change the window size |
Hm, you make a fair point about the generate button. Maybe something can be done to make that sticky instead (like #12645). I personally don't want it on the right because then the image preview loses more vertical space. |
I know. However, in this PR(Screenshots), the generate button and the preview are separated, so when the user sets the settings at the bottom, they have to scroll back up every time to press the generate button. So, this is a display bug, but I commented that it would be ideal if the generate button and the preview were not separated. Sorry to disturb you. |
@elistys Is this a good compromise? |
I think it would be useful as an option. but, "image preview loses more vertical space" I think that's why you put the generate button on the left, but what kind of inconvenience will happen due to the space (about 2 cm on my screen) of the generate button when it is placed on the right side? Currently v1.5.1 layout already uses space in generate button. Rather, personally, the right side is empty, so I think it's okay to pack more other function. So, for the above reasons and also from the perspective of not changing the current layout significantly, I think it's ideal to have it on the right side. Thank you for your trial and error. I'm sorry for writing impertinent things even though I'm not a collaborator. *Because I'm not a native English speaker, my writing may be slow and my expressions may be rude. sorry. |
No worries, it doesn't come across as rude at all. The right side will only ever be empty when an image isn't visible. #12648 implements the ability to change the gallery height which would essentially allow for a defined height that could fill the user's screen. I plan to eventually figure out a nice solution to make it fit the available height at all times. There's still some possible merit to putting the generate button on the |
imo sticking is not necessary for a computer users |
Outside of prompting, all operations are basically done with a mouse currently, so I still think there's value in it. Anyways, unless there's any issues with this, I'm just going to leave this PR as-is for now until voldy reviews it. |
fair point |
@catboxanon I wrote that there is merit in placing it on the [right] side. I think it's a typo, but just in case... @w-e-w |
Not asked but my conclusion^^; The code might be complicated, but it would be nice if there were both options for the user to choose whether to place the generate button left or right, depending on their needs. Users who value the size of the preview will choose the left side, and those who like the same layout as now will choose the right side. Easy to say, hard to do...sorry... |
The rationale for having the prompt above the main UI is that other tabs - lora, textual inversion - interact with it, placing things to where the cursor is in the prompt, and location matters. I started the work on moving UI generation to scripts with the seed section. I'd like to release the version with just seed section to see if any problems arise, and then I'd continue to work on moving a large amount of UI to scripts, allowing, among others, this to be done by scripts. |
@AUTOMATIC1111 The second half of your explanation is too technical for me to understand exactly what happens, but it probably makes for a smart and flexible interface. Thanks for thinking. I'm looking forward to it. |
Description
Closes #12681, alternative to #12688 (see description there for more info)
In addition to the other PR, this adds an option to make the generate button sticky.
I personally prefer this layout over the other PR. However, this does introduce much more code refactor, with a lot of usage of
if
andnullcontext
to determine component layout. One thing in particular this has to do now is create the prompt components outside thegr.Blocks
scope so we can manually invokerender
of them where we want.I think ideally everything should be created outside the
gr.Blocks
scope to begin with and then invoked with a single function, as this would make doing a few more refactor jobs simpler and open up more possible layout changes, but that's for a separate PR.Screenshots/videos:
Layout
Sticky generate button
Checklist: