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
