KScreenGenie moved to KDE Review


KScreenGenie has been moved to KDE Review, with the final intended
location being kdegraphics.

KScreenGenie is intended to replace KSnapshot as the the KDE
Screenshot Utility. It has been written from scratch as a KF5 app,
although portions of core code has been imported from KSnapshot. The
actual image capture code is handled by a platform-specific native
backend. Currently only an X11 backend exists, written in pure xcb and
using libkscreen for proper multi-monitor handling. This design makes
supporting Wayland (when an API becomes available) extremely easy, as
only an image capture backend (which is a class with 4 overridden
methods) needs to be written.

The app actually starts on Wayland in Wayland mode, but since it uses
the Dummy backend on Wayland there is no image capture functionality
on that platform yet.

Features lost over KSnapshot is the ability to grab areas of the
screen defined by freeform selections (Freehand Region), which is just
plain weird in its current form (but I'm willing to add a feature,
something like GIMP's Free Select Tool, if there's demand, at a later
version), and the ability to capture individual widgets in an
application (which will not work at all on Wayland due to its
architecture and does not work properly in X11 these days because Qt
and GTK no longer create X11 subwindows for every widget, preferring
to handle widget interaction manually).

The other thing I'd like to mention here is that there was talk on IRC
and the kde-community list a few months back that if KScreenGenie does
end up passing review and replacing KSnapshot, that it should take the
KSnapshot name and just become KSnapshot 2.0. I'd be grateful if
someone could tell me how to proceed for this.

Boudhayan Gupta


Re: KScreenGenie moved to KDE Review

By Albert Astals Cid at 07/03/2015 - 17:53

El Dimarts, 16 de juny de 2015, a les 02:45:56, Boudhayan Gupta va escriure:
Can't build it

[ 15%] Building CXX object src/CMakeFiles/kscreengenie.dir/Main.cpp.o
cd /home/kdeunstable/build/kscreengenie/src && /usr/bin/c++ -DKCOREADDONS_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_QML_LIB -DQT_QUICK_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -fPIE -I/home/kdeunstable/build/kscreengenie/src -I/home/kdeunstable/kscreengenie/src -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtQuick -isystem /usr/include/x86_64-linux-gnu/qt5/QtQml -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtDBus -isystem /usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /home/kdeunstable/instalado/include/KF5/KCoreAddons -isystem /home/kdeunstable/instalado/include/KF5 -isystem /usr/include/KF5/KNotifications -isystem /usr/include/KF5 -isystem /home/kdeunstable/instalado/include/KF5/KConfigGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtXml -isystem /home/kdeunstable/instalado/include/KF5/KConfigCore -isystem /usr/include/KF5/KI18n -isystem /usr/include/KF5/KIOWidgets -isystem /usr/include/KF5/KIOCore -isystem /usr/include/KF5/KService -isystem /usr/include/KF5/KJobWidgets -isystem /usr/include/KF5/KCompletion -isystem /usr/include/KF5/KWidgetsAddons -isystem /usr/include/KF5/KWindowSystem -isystem /usr/include/KF5/KXmlGui -isystem /usr/include/KF5/KConfigWidgets -I/usr/include/KF5/KCodecs -I/usr/include/KF5/KAuth -o CMakeFiles/kscreengenie.dir/Main.cpp.o -c /home/kdeunstable/kscreengenie/src/Main.cpp
In file included from /home/kdeunstable/kscreengenie/src/KSCore.h:62:0,
from /home/kdeunstable/kscreengenie/src/Main.cpp:30:
/home/kdeunstable/kscreengenie/src/PlatformBackends/X11ImageGrabber.h:24:20: fatal error: QX11Info: No such file or directory
#include <QX11Info>

For some reason /usr/include/x86_64-linux-gnu/qt5/QtX11Extras is not in the include path.

Any idea why?


Re: KScreenGenie moved to KDE Review

By Alexander Potashev at 07/03/2015 - 20:00

2015-07-04 0:53 GMT+03:00 Albert Astals Cid < ... at kde dot org>:
Fixed in <a href="" title=""></a>

Because when XCB_FOUND is not set, Qt5::X11Extras is not added to
target_link_libraries(), see src/CMakeLists.txt.
target_link_libraries() implicitly also adds respective include
directories. When there is no target_link_libraries(...
Qt5::X11Extras), [...]/QtX11Extras is not added as include path.

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/04/2015 - 05:43

On 4 July 2015 at 05:30, Alexander Potashev < ... at gmail dot com> wrote:
You've gone ahead and moved all the includes from the header file to
the .cpp file? I'm going to revert that commit, since the decision to
keep all the #includes in the header is a coding style decision I
consciously made. I know this extends build times, but this keeps
things tidy - I can see exactly which components a single cpp file
depends on my looking at the headers, I don't have to look through
both the cpp and the header file. The cpp file should include one and
only one header file, and that's it's own header.

I appreciate you fixing the build without XCB very much. However,
before making major coding style changes, please use the Review Board
or ask over e-mail. KScreenGenie does *not* use the kdelibs coding

Re: KScreenGenie moved to KDE Review

By Alexander Potashev at 07/04/2015 - 05:54

2015-07-04 12:43 GMT+03:00 Boudhayan Gupta < ... at baloneygeek dot com>:
Hi Boudhayan,

A good practice is to not rely on the headers pulled transitively, see
[1,2]. So, the .cpp file should have all these includes anyway; and
when it does, there is no reason to keep unnecessary includes in the

Projects use different coding styles because each has its pros and
cons. But regarding this #include thing the solution recommended in
the links below is much more advantageous than what you decided to do.

[1] <a href="" title=""></a>
[2] <a href="" title=""></a>

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/04/2015 - 06:11

Hi Alexander,

I'd seen both of these topics before. I'd obviously use minimal
headers in libraries and other projects where the headers could be
used by the public to build their own software, since cumulative
headers pull in headers that might be completely unnecessary to the
aforesaid software.

However here, where all headers are private, it makes much more sense
from an organization point of view to have cumulative headers, at
least for me.

Re: KScreenGenie moved to KDE Review

By Alexander Potashev at 07/04/2015 - 06:48

2015-07-04 13:11 GMT+03:00 Boudhayan Gupta < ... at baloneygeek dot com>:

It doesn't seem right to apply different rules to headers that are
exported and not exported. Are you going to rewrite the includes
if/when the class ImageGrabber becomes a public library? (E.g. when
someone wants to incorporate a screen grabber into his application.)

You said "I can see exactly which components a single cpp file depends
on my looking at the headers". If you follow the recommendation in the
links [1,2], all the dependent components will be included in the .cpp
file, so you can see exactly what you want there. Any other issue with

And finally, why using distinct coding style while there's established
Kdelibs coding style? Is your coding style documented somewhere? If
not, then I'm sure KSG will become a mix of different coding styles in
a while because people don't know what coding style to follow.

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/04/2015 - 07:29

Hi Alexander,

Nothing in KScreenGenie will ever become a public library.

If someone wants a screen grabber in his application, the correct way
to do it is by interfacing with KSG via DBus (which, btw, it lacks
currently, but will have in the future).

In a public library, things are much more strict - no extra includes,
dpointers etc., filenames are lowercase, and so on. It doesn't have to
be so strict here.

No, some of them stay over in the header file. "Everything in one
place", for a small application such as this, which is not a public
library, takes precedence over minorly increased build times.

It's kdelibs, with two exceptions: Cumulative headers, and all the
access modifiers (public, private etc) stay aligned with the function
definitions in the class (i.e., 1 level indented).

BTW I've gone ahead and reverted the commit and parts of your other
commits. The only thing that was required, was to make sure in every
place X11ImageGrabber is included, that it should be included only if
XCB_FOUND is defined.

I realise that you have been a KDE developer for far longer than I
have, but I would still like to refer you to the KDE Commit Policy
[1], sections 1.8 and 1.13. Personally I make it a rule to use Review
Board if I submit even one-liners, because I believe the maintainer
should be made aware, in advance, of every single change other devs
are making to his code, and be given a chance to approve/reject that.
However, I do not require that for KScreenGenie (in fact, quite a few
other devs have made minor changes, both to code and to the docs, and
I have nothing but sincere thanks for them for fixing these issues).
That said, having to go through the commitdiffs for *four* unannounced
commits, two of which were major, to find the *one* location where the
real fix was and isolating that, is a huge waste of time which I could
have otherwise used to make important pending fixes to the UI and
program behaviour.

-- Boudhayan

Re: KScreenGenie moved to KDE Review

By Alexander Potashev at 07/04/2015 - 07:59


Please find my comment below.

2015-07-04 14:29 GMT+03:00 Boudhayan Gupta < ... at baloneygeek dot com>:
Again, if you follow the links [1,2], then Foo.cpp should have
#include <QString> even if Foo.h already contains it, in order to
account for possible removal of that #include from Foo.h in the
future. In this way, Foo.cpp acts like "one place for everything", the
header #including only a minimal set files and minimal forward
declarations to make it compile.

Sorry, I didn't expect the #include change to be questionable. Will
try to make my future commits more atomic.

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/04/2015 - 08:11

Hi Alexander,

I read through that part. I just find it more comfortable to make
Foo.h the "one place for everything". I can guarantee that <QString>
will never be removed from Foo.h, so I don't see this being a problem.

I'm also sorry for going ballistic in the last mail :-) That was
probably uncalled for.

When I first pushed the project from GitHub into KDE, I asked on one
of the IRC channels whether the placement of includes is going to be a
problem, since all other KDE projects seem to be placing the includes
in the cpp files. I don't recall there being any negative comments,
which is why I didn't change it. This is how I've been doing it since
middle school (headers in the headers), and I find it natural this
way, like every header is a self-contained module, with the cpp file
being the supporting actual code.

I should also make clear that I didn't revert the commit because it
was unannounced or because of spite, but because I genuinely wanted
the cumulative headers.

I apologise again for the hot-headedness,

-- Boudhayan

Re: KScreenGenie moved to KDE Review

By Martin =?ISO-88... at 06/28/2015 - 05:10

I suggest to not do this that early. Let's first move it to extragear and give
it time to prove itself. Right now it's a new application which has hardly got
any testing. In opposite KSnapshot is a very mature application with a decade
of development behind it. So let's keep KSnapshot as it is and evaluate in
half a year/year.


Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 06/28/2015 - 07:07

On 28 June 2015 at 14:40, Martin Gräßlin < ... at kde dot org> wrote:
That's not a bad idea, in principle.

I'm still going to present a few arguments for pushing straight to KDE
Graphics though:

1) I went through the KSnapshot code line-by-line (my original
objective was to improve KSnapshot, not make a new program) and while
yes it's a mature program with a decade of development behind it,
KScreenGenie not only copies a lot of the good and usable code from
KSnapshot, I've also actively tried to improve the design of the
program so that a few bugs with KSnapshot are fixed. One of them is
the huge wait that happens after clicking Send To before the menu
appears (this is done in the background now, so no perceptible wait)
and better multi-monitor granularity by integrating with libkscreen.

2) I'm home for the holidays and practically free with nothing else to
do until the first week of August. Even after college starts again,
the workload isn't so much that I'm unable to fix bugs within hours or
at most 1-2 days (in rare circumstances) of being reported. Feature
requests might take a while though.

This said, moving to extragear for the purposes of extra real-world
testing is a good idea, except that unless we can give users a huge
incentive to eschew using KSnapshot (which is in kdegraphics and hence
released with the KDE apps, and receives preferential treatment from
distro packagers over extragear apps), and install KScreenGenie
instead, very few users are actually going to use KScreenGenie.
There's also the fact that once KScreenGenie makes it out in public
using the KSG name, it'll be difficult to change the name to KSnapshot
again, because we end up doubly confusing users.

Re: Re: KScreenGenie moved to KDE Review

By Martin =?ISO-88... at 06/28/2015 - 11:47

On Sunday 28 June 2015 16:37:31 you wrote:
This worries me a little bit. Not the fact of how much time is available, but
the fact that you do a rather short term thinking. Let's put it simple: there
won't be any bug reports prior to October when the first large distros start
to ship it. And then it's too late to go back. We need to be sure that the new
solution is not giving our users a hard time.

Thus first in extragear to roll it out to some users for testing. Once we see
that it's a good solution we can roll it out to all users by making it
replacing KSnapshot.

This worries me. I think we should be happy with few users at the start for a
new product.

names are well just names. If we rename it later on to ksnapshot it's no
problem. For the users it will just look like a new ui. I doubt that our users
know it's called "KSnapshot" at all. They use the print key on their keyboard.


Re: Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 06/28/2015 - 14:33

On 28 June 2015 at 21:17, Martin Gräßlin < ... at kde dot org> wrote:
My point was that the moment we get any bug reports (even in October),
I'm free enough to roll out bugfixes in a very short time.

You may think I'm thinking short-term, but I've budgeted a lot of
active development time for this at least to the middle of the next
year. I have feature-addition plans, and of course there's a Wayland
backend that has to be made and tested. While the KSnapshot code is
taken to be "complete", I'm going to say that KSG's development state
is "highly active", and we're practically at feature-parity with
KSnapshot. KSG has a future. KSnapshot's current codebase, at least in
the Wayland era, does not.

Also, I've been using KSG instead of KSnapshot ever since I started
building it, and I take a *lot* of screenshots. I know I come with
confirmation bias, but I'm more than confident that showstopper bugs
are not there. I can guarantee that you will be able to take
screenshots, that you will be able to send them to other applications,
that you will be able to save them (even to KIO remote locations -
I've tested with mtp), that copy-to-clipboard works, etc etc. I've
even tested running it on Weston with a do-nothing backend, and it
starts and I can use the program (without taking an image) just fine,
so I know that the Wayland/X11 backend decoupling is working just like
it should.

We'd want to start with a small userbase, if this was huge program
with lots of new stuff. However, it's not. Most of the core
functionality (KSCore.cpp) is just copied from KSnapshot and
refactored. The native XCB-based X11 backend (which I take credit for
writing) has been tested to death, and it works just fine.

Things already work. The screenshot capture program is a core part of
the desktop and also a thankless utility. No one pays much attention
to it, but if it doesn't work people get very unhappy. I've taken
extra care to make sure there are no "I can't take screenshots and
save it" bugs. There are none. Whatever bug reports are expected are
feature requests.

Why I want a big user base is that I expect bugs that happen only on
esoteric systems, and bugs that happen only on one system per every
thousand installed. This kind of bugs I'm anxious to find and stomp


Re: KScreenGenie moved to KDE Review

By Eike Hein at 06/28/2015 - 13:27

On 06/28/2015 11:10 AM, Martin Gräßlin wrote:
It's also a rather stagnant one, and a new developer with
the desire to improve upon the status quo is a high-value
community asset much in the same way as a mature application
can be, and both should be treated with equal care.

One way to have our cake and eat it, too, i.e. assure that
users receive a quality even if new product from us, is to
do as asked and participate in the review process. I pointed
out a few small bugs on IRC recently, but overall walked
away with a favorable impression of the code.


Re: KScreenGenie moved to KDE Review

By Mark at 06/28/2015 - 13:38

This "KSnapshot V2" stuff sparked my interest. I installed it :)
Granted, only because it's fairly in easy in archlinux since aur(4) has the

It looks and works rather well! I haven't spotted any issues yet. Besides
the ones that Hugo mentioned.

Re: KScreenGenie moved to KDE Review

By Sebastian =?utf... at 06/17/2015 - 20:40

On Tuesday, June 16, 2015 02:45:56 Boudhayan Gupta wrote:
Perhaps you could point us all to some screenshots? One requirement for
passing review and an eventual replacement of ksnapshot should be a successful
review by our usability crew, maybe it can also be made prettier with some
help from the VDG. Since not everybody is able to, or has the time to compile
kscreengenie's sources, screenshots would be really helpful.


Re: KScreenGenie moved to KDE Review

By Yuri Chornoivan at 06/18/2015 - 00:21

написане Thu, 18 Jun 2015 03:40:48 +0300, Sebastian Kügler < ... at kde dot org>:


Actually, there is a documentation in the sources with a screenshot:

<a href=";a=blob&amp;h=4c52ef9037f7a61e49bb6b8e12713b6c97429d6c&amp;f=doc%2FMainWindow.png&amp;o=plain" title=";a=blob&amp;h=4c52ef9037f7a61e49bb6b8e12713b6c97429d6c&amp;f=doc%2FMainWindow.png&amp;o=plain">;a=blob&amp;h=4c52ef9037f7a61e49b...</a>

Hope this helps.

Best regards,

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 06/18/2015 - 05:33

On 18 June 2015 at 09:51, Yuri Chornoivan < ... at ukr dot net> wrote:
Here's an Imgur album with some more screenshots, including how
Rectangle Selection works:

<a href="" title=""></a>

Boudhayan Gupta

Re: KScreenGenie moved to KDE Review

By Martin Koller at 06/28/2015 - 04:58

I miss the "copy" button to be able to copy the captured image to the clipboard

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 06/28/2015 - 05:01

On 28 Jun 2015 14:28, "Martin Koller" < ... at aon dot at> wrote:
It is now at Send To -> Clipboard

Re: KScreenGenie moved to KDE Review

By Hugo Pereira Da... at 06/28/2015 - 12:40

On 06/28/2015 10:58 AM, Martin Koller wrote:
1/ as far as I can tell, the window is non resizable. KSnapshot is, and
resizing the window ends up resizing the screenshot in it, which I find
really useful.
2/ once you have selected Active Window + Take a new snapshot, the
application waits for you to "click" somewhere, but as far as I can
tell, the window on which you click does not matter, what you get in the
screenshot is the window that was active *before* you click on "take a
new snapshot".
This is very impractical: if you want to change active window you need
first to select it (away from the ksg window, which is in fact the
active one (hum: does that mean that the button is actually ill-named) ?
, select an "active" window, then click back on kscreengenie (making
this window the active one), then take a new snapshot.

Ksnapshot behaves differently: you select "take a new snapshot", you
click on a window, the window becomes "active" and this is the one that
gets a screenshot.

I have not tested how it works when you use a "delay".

Best regards,


Re: KScreenGenie moved to KDE Review

By Hugo Pereira Da... at 06/28/2015 - 12:47

On 06/28/2015 06:40 PM, Hugo Pereira Da Costa wrote:

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 06/28/2015 - 14:45


I'll take a look at this. Yes, I had made the KSG window explicitly
non-resizable, but the resizing the screenshot to make it bigger as
the window grows sounds like a very good idea.

The way I've always used it, and how I find natural, is to just set a
delay and after KSG disappears select the window I want to click and
wait. Also, I'm going to add a new global keyboard shortcut
(Alt+PrintScreen or Shift+PrintScreen or something) that takes a
screenshot of the active window and saves it, so you won't even have
to call up the GUI in the future.

With the current code, intercepting a mouse-press meant for another
window, in X11, will mean installing another native event filter.
It'll be difficult, but not impossible. In Wayland though it *will* be
impossible, because Wayland doesn't allow taking over the mouse. So
the choices now are - inconsistent behaviour between X11 and Wayland,
or a different way of doing things, which gives consistent behaviour
in both X11 and Wayland.

I've found use in setting half-second delays many times.


Re: KScreenGenie moved to KDE Review

By =?utf-8?Q?Thoma... at 06/28/2015 - 18:14

Did a functional test only.

a) The button role assignment seems wrong (you tried to arrange buttons in a certain order that suits either the KDE or windows order? They end up totally weird other orders eg. GTK or OSX)

b) Buttons
1. While I like the "Save & Exit" idea, it leaves uncertainity about what happens. Eg. there could be a tooltip that says *where* the file is saved. Bonus points for allowing to set a pattern (location + filename)
2. There're two "Save" buttons, "Save As..." could maybe be moved into a popup of "Save & Exit" (which could also access a dialog to set the quicksave pattern)
3. There's no way for direct mass shooting (ie. "Save & Exit" minus "Exit") - some sort of "Set filename pattern for this session" feature ("Set pattern..." vs. "Set default pattern..."?) could turn "Save & Exit" into "Save"
4. No idea whether I miss some plugin, but "Send to..." is "Open with..." here (+copy to clipboard)
5. "Discard" should turn "Exit" after the file is saved in any way (but not to clipboard, w/o klipper the file would be lost) since the image isn't discared at all.
6. There's a "Print..." button but no "Copy to clipboard" button... ;-)
I don't yet know how to finally resolve this, but printing is rare and copy to clipboard is ... less rare, but it does not fit into "Send to", esp. not if that's actually "Open with"

c) I agree with Hugo that "Active window" is totally weird. It captures the window that kwin passes the focus after kscreengenie closed, what depends on two kwin settings.... (if the WM is KWin)
The difference to ksnapshot is however not the behavior, but that ksnapshot doesn't have that feature in the GUI at all (since it doesn't make any sense - the active window is kscreengenie at the time of usage) - ksnapshot allows to capture the "Window under the mouse" which is actually "pick window" - kscreengenie even clicks the window KWin will automagically activate if using "On Click" what is totally confusing. At least in this mode, kscreengenie should definitively shoot the picked window, not the active one. In doubt by activating it before.

d) "Capture Area | Active Window" - *cough* ;-)
My suggestion would be to label the combobox "Mode" reverse the "On click" checkbox and label it "Delay" (omitting the extra label)

e) Technically "Capture Mode" and "Capture Options" are capture options - "Capture Options" are actually "Content Options" and delay/onclick are "Trigger options", though I don't know whether there needs to be a horizontal structure at all since

f) because of the flat grouboxes (?) and the splitter of the buttongroup, the "Take New Screenshot" buttons looks like it belongs to the "Capture Options".
Maybe combine all options, put a splitter below and the "Take New Screenshot" button below that? (So it's visually isolated between options and buttonbox)

g) pressing "Escape" should abort the screenshot.

h) It's not like I could find it, but afair the rule is "Take new screenshot", not "Take New Screenshot" - at least in labels.

i) A feature that kscreengenie imo lacks (like ksnapshot does) is some basic annotation features (ellipsis, arrow, labelbox) - I'd volunteer to write a patch for that ;-)

j) > I've found use in setting half-second delays many times.
While I actually cannot think of a reason for this precision, the single step width should then be 0.5 seconds - otherwise it's nasty to change the value with the mouse wheel or the spinbox buttons.


+1 for keeping "ksnapshot" - it's familiar and simpler to vocalize. But ultimately I don't care =)

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 06/29/2015 - 05:58

Hi Thomas,

On 29 June 2015 at 03:44, Thomas Lübking <thomas. ... at gmail dot com> wrote:
It's a standard QDialogButtonBox. I haven't set the button ordering
manually at all. Maybe it's a QDialogButtonBox bug then.

A tooltip is already set that says "Quicksave screenshot in your
Pictures directory and exit".

This is planned.

I don't understand. "Direct mass shooting"?

Same deal with KSnapshot, except for "Copy To Clipboard", which I
moved there to save a button.

This is a good idea. Will implement.

In KSnapshot, the printing was handled by KIPI. Here I've got explicit
code to handle printing manually, and I've done stuff to make it
render the image at high DPI (which wasn't being done in KSnapshot).

Would you prefer I swap the Clipboard option in the Send To menu with
Print, and put Clipboard on the buttons?

Alright, I'll revert to KSnapshot behaviour and relabel to Window
Under Mouse, but I cannot guarantee we can have the same behaviour in

Is that much better than the current solution? IMO the way KSnapshot
merges delay and on-click into one spinbox is bad, there's no way to
set a zero-delay no-onclick mode. This is why I did it this way. If I
want to wait for a click, I want to say that explicitly.

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. Makes more sense given 90% of displays are
widescreen nowadays, and it's not so wide so as to be a nuisance on
the 4:3 displays.

It already does.

There's a mini-editor feature planned yes, but I wasn't aware
KSnapshot already does it. It must be a new addition, since it wasn't
there in the code two months ago.

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.


Re: KScreenGenie moved to KDE Review

By =?utf-8?Q?Thoma... at 06/29/2015 - 10:00

On Montag, 29. Juni 2015 11:58:29 CEST, Boudhayan Gupta 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.

Indeed - sorry for the noise. It simply didn't show up here (the tbh. only time i tried ;-)

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..." " paper" ;-)

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 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.

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 ;-)

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)


Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 06/29/2015 - 10:21

Hi Thomas,

On 29 June 2015 at 19:30, Thomas Lübking <thomas. ... at gmail dot com> wrote:
Right, I'll fix that.

This could be done, yes.

Point taken :-)

That is actually a brilliant idea.

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.

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.

Ah you meant during the delay / click wait. Yeah, that needs to be added.

Go ahead, write the patch! I'd be delighted to add it in then!

Ah if that's possible I'll set the step size to 1.0 then!


Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/02/2015 - 12:17


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 < ... at baloneygeek dot com> wrote:

Re: KScreenGenie moved to KDE Review

By =?utf-8?Q?Thoma... at 07/04/2015 - 05:26

On Donnerstag, 2. Juli 2015 18:17:16 CEST, Boudhayan Gupta wrote:
"Window under mouse" actually shoots the active window what makes it ipossible to shoot eg. floating docks (*unrelated* to hiding inactive utility windows) or mainwindows with a modal transient (ie. kwrite while there's a fileopen dialog) or windows which do not accept focus from the WM.

=> Regardless of the behavior on click, this would require to be labeled "Active window", but that's a regression compared to ksnapshot (since several windows cannot be shot)


Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/04/2015 - 05:30

On 4 July 2015 at 14:56, Thomas Lübking <thomas. ... at gmail dot com> wrote:
This has been fixed in the latest commit I did last night. There's
also a new mode which allows you to shoot Transients along with the
parent window in the same image.

-- Boudhayan

Re: KScreenGenie moved to KDE Review

By =?utf-8?q?Burkh... at 07/04/2015 - 05:45

Am Samstag, 4. Juli 2015, 15:00:48 schrieb Boudhayan Gupta:
Is this already mentioned in the docbook?

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/04/2015 - 05:49

On 4 July 2015 at 15:15, Burkhard Lück <> wrote:
No. The docbook is highly inconsistent atm because there have been a
lot of changes after incorporating feedback from this list and
elsewhere. There will be more changes to the GUI, after which I'll
update the docbook all at one go.

-- Boudhayan

Re: KScreenGenie moved to KDE Review

By =?utf-8?q?Burkh... at 07/04/2015 - 03:38

Am Donnerstag, 2. Juli 2015, 21:47:16 schrieb Boudhayan Gupta:
Some minor nitpicking:
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

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


Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/04/2015 - 11:39

Hi Burkhard,

The docbook is very inconsistent, I'll change a whole lot of things at one go.

Fixed it in latest commit :-)

-- Boudhayan Gupta

Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/07/2015 - 12:11

On 4 July 2015 at 21:09, Boudhayan Gupta < ... at baloneygeek dot com> wrote:
I've fixed up the docs, and added functionality where anything other
than a left-click in On-Click mode aborts the screenshot. I've also
tagged a new release.

Is there any chance KSG can make it into kdegraphics in time for
15.08? The freeze is pretty soon, and I don't plan on adding any new
features for this cycle.

-- Boudhayan Gupta

Re: KScreenGenie moved to KDE Review

By Albert Astals Cid at 07/13/2015 - 16:09

El Dimarts, 7 de juliol de 2015, a les 21:41:36, Boudhayan Gupta va escriure:
I would personally feel "safer" if you did a more limited release this cycle
and joined KDE Applications for 15.12.

Anyone else?


Re: KScreenGenie moved to KDE Review

By Boudhayan Gupta at 07/13/2015 - 16:32

I'll concur too.

For proper integration khotkeys also needs to be patched with the
shortcut details for this. There's more than one (PrintScreen to bring
KSG up, Alt+PrintScreen to take a shot of the active window and
autosave without showing the GUI, Ctrl+PrintScreen to take a shot of
the whole screen and autosave without showing the GUI). They'll pop up
a KNotification though.

I would personally prefer if khotkeys exported a CMake macro or
variable that I could use to install my own hotkey files, and I tried
to do that but I know too little about CMake to make that happen.

-- Boudhayan Gupta

Re: KScreenGenie moved to KDE Review

By Richard Moore at 06/16/2015 - 17:38

​Fine with me.