KScreenGenie moved to KDE Review

Burkhard Lück lueck at hube-lueck.de
Sat Jul 4 08:38:20 BST 2015


Am Donnerstag, 2. Juli 2015, 21:47:16 schrieb Boudhayan Gupta:
> 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 <me at baloneygeek.com> wrote:
> > Hi Thomas,
> > 
> > On 29 June 2015 at 19:30, Thomas Lübking <thomas.luebking at 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

Some minor nitpicking:
Docbook:
Afaik Alt+Space is default kf5 shortcut for KRunner, wrong in docbook
Shortcut Ctrl+C and Esc missing in docbook
Resizable Window, where resizing the window ends up resizing the screenshot in 
it missing in docbook

Functionality:
KSnapshot gives feedback about the size of the taken screenshot (tooltip on 
hoovering the screenshot), that is missing for me.

Thanks. 

-- 
Burkhard Lück





More information about the kde-core-devel mailing list