KScreenGenie moved to KDE Review
thomas.luebking at gmail.com
Mon Jun 29 15:00:32 BST 2015
On Montag, 29. Juni 2015 11:58:29 CEST, Boudhayan Gupta wrote:
> Hi Thomas,
> It's a standard QDialogButtonBox. I haven't set the button ordering
> manually at all. Maybe it's a QDialogButtonBox bug then.
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.
> A tooltip is already set that says "Quicksave screenshot in your
> Pictures directory and exit".
Indeed - sorry for the noise. It simply didn't show up here (the tbh. only time i tried ;-)
> 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 ;-)
>> 4. No idea whether I miss some plugin, but "Send to..." is "Open with..."
>> here (+copy to clipboard)
> Same deal with KSnapshot
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 =)
> 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" ;-)
> Alright, I'll revert to KSnapshot behaviour and relabel to Window
> Under Mouse, but I cannot guarantee we can have the same behaviour in
If this will be done by talking to KWin, I'd say: "yes".
> 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)
> 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.
>> 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 ;-)
> 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".
> 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)
More information about the kde-core-devel