KScreenGenie moved to KDE Review

[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