Hi, I've fixed up the UI as per the above mail thread, and pushed to master. Download and test!
Copy to clipboard has UI feedback now with a KMessageBox, On 29 June 2015 at 19:51, Boudhayan Gupta <m...@baloneygeek.com> wrote: > Hi Thomas, > > On 29 June 2015 at 19:30, Thomas Lübking <thomas.luebk...@gmail.com> wrote: >> It's because eg. you use the "Apply" role for "Save & Exit" (would rather be >> "Ok" role) and "Discard" for "Discard", while the latter actually acts as >> "Cancel" ("reject", not "reset and exit" - there's nothing to reset in the >> first place) - the different roles cause different positions in different >> GUI layouts. > > Right, I'll fix that. > >>> I don't understand. "Direct mass shooting"? >> >> Take a shot, click save. Take another shot, click save. Take yet another >> shot, save once more. Ideally with filename patterns such as >> bug123456_%n.png ;-) >> > > This could be done, yes. > >> >> I thought the idea was to improve ksnapshot :-P >> If this does actually only allow you to open the image in another >> application (the copy to clipboard thing doesn't belong there, we'll have to >> find a better way to save a button) the button should say so =) > > Point taken :-) > >> >>> Would you prefer I swap the Clipboard option in the Send To menu with >>> Print, and put Clipboard on the buttons? >> >> >> At least I think the Print button is too prominent regarding its usage >> frequency (and compared to the need to copy to clipboard) >> >> Brainfart: "Save..." "...to paper" ;-) > > That is actually a brilliant idea. > >> >>> Is that much better than the current solution? >> >> I'll boldly claim: yes. >> >>> IMO the way KSnapshot merges delay and on-click into one spinbox is bad >> >> "Suboptimal" - yes (and not what I meant) >> >> Two alternative approaches: >> >> [ ] Delay | Capture on click >> [x] Delay | ( n.m seconds ) >> >> ("capture on click" label and "n,m seconds" spinbox being in a stacked >> layout) >> >> [ ] Capture on click | (n.m senconds delay) >> >> > > Say I want a shot taken instantly when I click Take New Screenshot. > Then I'll have to tick delay, then input 0.0, which makes no sense > because there's no delay. > > The third option doesn't suffer that problem, but visually the current > solution IMHO looks better because of the way the input fields are > lined up right now. > >> >>> I've made it so that the entire right hand side of the window is >>> dedicated to options and buttons, and the entire left hand side is >>> dedicated to the preview. >> >> >> I don't question that approach at all. >> What worries me is the grouping *inside* the right hand column, which >> visually ties the "Take new screenshot" button to the "Capture Options", >> therefore I'd suggest to combine the two righthand rows and add a horizontal >> below them, that sets off the "Take new screenshot" button visually. >> > > Point taken. Adding a horizontal bar makes things ugly (I've tried it > before). Let me see if I can play with the spacing. > > The idea is to have the Edit Image (when the basic editor is added) > button right next to the Take New Screenshot button. > >> >>>> g) pressing "Escape" should abort the screenshot. >>> >>> It already does. >> >> >> No, doesn't :) >> To be clear, I do *not* mean QDialog should reject on pressing escape, but >> when I say "Take new screenshot" and press "escape", I'd like to see the >> kscreengenie abort taking the screenshot and its window re-appear without >> new screenshot (and the mousgrab restored in case) - there's no xcb_grab_key >> in the code, so this cannot work ;-) >> > > Ah you meant during the delay / click wait. Yeah, that needs to be added. > >>> There's a mini-editor feature planned yes, but I wasn't aware >>> KSnapshot already does it. >> >> No, does not - kscreengenie lacks it "like ksnapshot does lack it". >> > > Go ahead, write the patch! I'd be delighted to add it in then! > >>> If the usability team wants larger steps, I guess I have to do it. But >>> personally I've set even 0.2 sec timeouts, although they may have >>> been for special reasons. >> >> >> That's not the problem - even with a single step size of "10" you could >> still enter "0.1 seconds" - it's about how the box reacts to the mousewheel >> and the spinbox buttons (and atm, going from 0.0 to 5.0 takes 50 wheel >> clicks) >> > > Ah if that's possible I'll set the step size to 1.0 then! > >> Cheers, >> Thomas > > Thanks, > Boudhayan