Re: KScreenGenie moved to KDE Review
El Dimarts, 7 de juliol de 2015, a les 21:41:36, Boudhayan Gupta va escriure: On 4 July 2015 at 21:09, Boudhayan Gupta m...@baloneygeek.com wrote: Hi Burkhard, 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 The docbook is very inconsistent, I'll change a whole lot of things at one go. Functionality: KSnapshot gives feedback about the size of the taken screenshot (tooltip on hoovering the screenshot), that is missing for me. Fixed it in latest commit :-) -- Boudhayan Gupta 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. I would personally feel safer if you did a more limited release this cycle and joined KDE Applications for 15.12. Anyone else? Cheers, Albert -- Boudhayan Gupta
Re: KScreenGenie moved to KDE Review
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. I would personally feel safer if you did a more limited release this cycle and joined KDE Applications for 15.12. Anyone else? 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. Cheers, Albert -- Boudhayan Gupta
Re: KScreenGenie moved to KDE Review
On 4 July 2015 at 21:09, Boudhayan Gupta m...@baloneygeek.com wrote: Hi Burkhard, 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 The docbook is very inconsistent, I'll change a whole lot of things at one go. Functionality: KSnapshot gives feedback about the size of the taken screenshot (tooltip on hoovering the screenshot), that is missing for me. Fixed it in latest commit :-) -- Boudhayan Gupta 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
On 4 July 2015 at 14:56, Thomas Lübking thomas.luebk...@gmail.com 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) 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
On 4 July 2015 at 15:15, Burkhard Lück lu...@hube-lueck.de wrote: Am Samstag, 4. Juli 2015, 15:00:48 schrieb Boudhayan Gupta: 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. Is this already mentioned in the docbook? 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
2015-07-04 12:43 GMT+03:00 Boudhayan Gupta m...@baloneygeek.com: 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 style. 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 header. 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] http://programmers.stackexchange.com/a/262020 [2] http://stackoverflow.com/a/15420950 -- Alexander Potashev
Re: KScreenGenie moved to KDE Review
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 m...@baloneygeek.com wrote: 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 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
Re: KScreenGenie moved to KDE Review
Am Samstag, 4. Juli 2015, 15:00:48 schrieb Boudhayan Gupta: 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. Is this already mentioned in the docbook? -- Burkhard Lück
Re: KScreenGenie moved to KDE Review
On Donnerstag, 2. Juli 2015 18:17:16 CEST, Boudhayan Gupta wrote: Hi, I've fixed up the UI as per the above mail thread, and pushed to master. Download and test! 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) Cheers, Thoomas
Re: KScreenGenie moved to KDE Review
On 4 July 2015 at 05:30, Alexander Potashev aspotas...@gmail.com wrote: 2015-07-04 0:53 GMT+03:00 Albert Astals Cid aa...@kde.org: For some reason /usr/include/x86_64-linux-gnu/qt5/QtX11Extras is not in the include path. Any idea why? Fixed in http://commits.kde.org/kscreengenie/ace898e614d612a84ee12f22562d6d7365ee24bc 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. 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 style.
Re: KScreenGenie moved to KDE Review
Hi Alexander, 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] http://programmers.stackexchange.com/a/262020 [2] http://stackoverflow.com/a/15420950 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
Hi Burkhard, 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 The docbook is very inconsistent, I'll change a whole lot of things at one go. Functionality: KSnapshot gives feedback about the size of the taken screenshot (tooltip on hoovering the screenshot), that is missing for me. Fixed it in latest commit :-) -- Boudhayan Gupta
Re: KScreenGenie moved to KDE Review
2015-07-04 13:11 GMT+03:00 Boudhayan Gupta m...@baloneygeek.com: [1] http://programmers.stackexchange.com/a/262020 [2] http://stackoverflow.com/a/15420950 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. Boudhayan, 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 it? 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. -- Alexander Potashev
Re: KScreenGenie moved to KDE Review
Hi Alexander, 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.) 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. 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 it? 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. 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. 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
Boudhayan, Please find my comment below. 2015-07-04 14:29 GMT+03:00 Boudhayan Gupta m...@baloneygeek.com: 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 it? 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. 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. 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. Sorry, I didn't expect the #include change to be questionable. Will try to make my future commits more atomic. -- Alexander Potashev
Re: KScreenGenie moved to KDE Review
Hi Alexander, 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. 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. 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. 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. Sorry, I didn't expect the #include change to be questionable. Will try to make my future commits more atomic. 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
2015-07-04 0:53 GMT+03:00 Albert Astals Cid aa...@kde.org: For some reason /usr/include/x86_64-linux-gnu/qt5/QtX11Extras is not in the include path. Any idea why? Fixed in http://commits.kde.org/kscreengenie/ace898e614d612a84ee12f22562d6d7365ee24bc 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. -- Alexander Potashev
Re: KScreenGenie moved to KDE Review
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 m...@baloneygeek.com wrote: 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
Re: KScreenGenie moved to KDE Review
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 Wayland. 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) Cheers, Thomas
Re: KScreenGenie moved to KDE Review
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
Re: KScreenGenie moved to KDE Review
On 28 June 2015 at 15:06, Martin Koller kol...@aon.at wrote: It is now at Send To - Clipboard. Wow, that's mega ugly. Another click for the (my) most common action used. In ksnapshot Send To is very inconvenient, since it seems to load all kipi plugins and is awfully slow (it takes some seconds to even show the popup). If that's also the case here, then it's even worse to have the copy action hidden in the popup. If you don't like to add the button back to the main window, what about just putting the grabbed image ALWAYS automatically into the clipboard ? Then I would not even need to click anywhere. Well, there's no time lag when you press Send To now (that's done in the background, right after the GUI is shown). So that's fixed. Secondly, (I've forgotten to add this; I'll do it and push out the code tonight) - I'll add a Ctrl+C keyboard shortcut to copy the image to the clipboard. If you think ALWAYS copying to the clipboard is a good idea, I could do that, but consider this: I'd be mighty confused if I copied some text to the clipboard, then took a screenshot, then opened up a word processor to paste the text first and instead found an image being pasted without any Copy action in KScreenGenie on my part.
Re: KScreenGenie moved to KDE Review
On 28 Jun 2015 14:28, Martin Koller kol...@aon.at wrote: On Thursday 18 June 2015 15:03:27 Boudhayan Gupta wrote: Here's an Imgur album with some more screenshots, including how Rectangle Selection works: http://imgur.com/a/1peZa I miss the copy button to be able to copy the captured image to the clipboard It is now at Send To - Clipboard -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: KScreenGenie moved to KDE Review
On Thursday 18 June 2015 15:03:27 Boudhayan Gupta wrote: Here's an Imgur album with some more screenshots, including how Rectangle Selection works: http://imgur.com/a/1peZa I miss the copy button to be able to copy the captured image to the clipboard -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: KScreenGenie moved to KDE Review
On Tuesday 16 June 2015 02:45:56 Boudhayan Gupta wrote: 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. 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. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KScreenGenie moved to KDE Review
On 06/28/2015 06:40 PM, Hugo Pereira Da Costa wrote: On 06/28/2015 10:58 AM, Martin Koller wrote: On Thursday 18 June 2015 15:03:27 Boudhayan Gupta wrote: Here's an Imgur album with some more screenshots, including how Rectangle Selection works: http://imgur.com/a/1peZa I miss the copy button to be able to copy the captured image to the clipboard Two regressions that I've spotted running with latest KSG from master branch: 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. Another one: the delay spinbox is in 1/10 seconds unit. What use is a delay of 100 milliseconds ? KSnapshot uses seconds, which IMHO makes more sense Best regards, Hugo
Re: Re: KScreenGenie moved to KDE Review
On Sunday 28 June 2015 16:37:31 you wrote: 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 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 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. This worries me. I think we should be happy with few users at the start for a new product. 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. 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. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KScreenGenie moved to KDE Review
On 06/28/2015 10:58 AM, Martin Koller wrote: On Thursday 18 June 2015 15:03:27 Boudhayan Gupta wrote: Here's an Imgur album with some more screenshots, including how Rectangle Selection works: http://imgur.com/a/1peZa I miss the copy button to be able to copy the captured image to the clipboard Two regressions that I've spotted running with latest KSG from master branch: 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, Hugo
Re: KScreenGenie moved to KDE Review
On 28 June 2015 at 14:40, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 16 June 2015 02:45:56 Boudhayan Gupta wrote: 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. 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. 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: KScreenGenie moved to KDE Review
On 06/28/2015 11:10 AM, Martin Gräßlin wrote: In opposite KSnapshot is a very mature application with a decade of development behind it. 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. Cheers Martin Cheers, Eike
Re: KScreenGenie moved to KDE Review
Hi, Two regressions that I've spotted running with latest KSG from master branch: 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. 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. 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. 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. Another one: the delay spinbox is in 1/10 seconds unit. What use is a delay of 100 milliseconds ? KSnapshot uses seconds, which IMHO makes more sense I've found use in setting half-second delays many times. Thanks, Boudhayan
Re: KScreenGenie moved to KDE Review
On Sun, Jun 28, 2015 at 7:27 PM, Eike Hein h...@kde.org wrote: On 06/28/2015 11:10 AM, Martin Gräßlin wrote: In opposite KSnapshot is a very mature application with a decade of development behind it. 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. Cheers Martin Cheers, Eike 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 packages. It looks and works rather well! I haven't spotted any issues yet. Besides the ones that Hugo mentioned.
Re: Re: KScreenGenie moved to KDE Review
On 28 June 2015 at 21:17, Martin Gräßlin mgraess...@kde.org 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. 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. 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. This worries me. I think we should be happy with few users at the start for a new product. 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 out. 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. 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. Cheers Martin Thanks, Boudhayan
Re: KScreenGenie moved to KDE Review
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. Cheers, Thomas PS: +1 for keeping ksnapshot - it's familiar and simpler to vocalize. But ultimately I don't care =)
Re: KScreenGenie moved to KDE Review
On 18 June 2015 at 09:51, Yuri Chornoivan yurc...@ukr.net 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. Hi, Actually, there is a documentation in the sources with a screenshot: http://quickgit.kde.org/?p=kscreengenie.gita=blobh=4c52ef9037f7a61e49bb6b8e12713b6c97429d6cf=doc%2FMainWindow.pngo=plain Hope this helps. Best regards, Yuri Here's an Imgur album with some more screenshots, including how Rectangle Selection works: http://imgur.com/a/1peZa Thanks, Boudhayan Gupta
Re: KScreenGenie moved to KDE Review
написане Thu, 18 Jun 2015 03:40:48 +0300, Sebastian Kügler se...@kde.org: On Tuesday, June 16, 2015 02:45:56 Boudhayan Gupta wrote: 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. 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. Hi, Actually, there is a documentation in the sources with a screenshot: http://quickgit.kde.org/?p=kscreengenie.gita=blobh=4c52ef9037f7a61e49bb6b8e12713b6c97429d6cf=doc%2FMainWindow.pngo=plain Hope this helps. Best regards, Yuri
Re: KScreenGenie moved to KDE Review
On Tuesday, June 16, 2015 02:45:56 Boudhayan Gupta wrote: 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. 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. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: KScreenGenie moved to KDE Review
On 15 June 2015 at 22:15, Boudhayan Gupta m...@baloneygeek.com wrote: 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. Fine with me. Rich.
