Hi Gregor, Reply is inline.
> > Loading SendTo menu in a thread > ------------------------------- > I tried that also in KSnapshot. See [ksnapshot: Fill SendTo menu async to fix > Bug > 312495](https://git.reviewboard.kde.org/r/120920/) but at that time this was > not possible > for some reason. I think the tread approach is a good idea as long as there > is no penalty > on startup time. > This isn't technically possible at all. Qt doesn't allow creating GUI elements in a non-GUI thread. Previously I was able to get around it by enumerating the KService::Ptr for every KService in a thread and sending it back to the GUI thread where the actual QAction is created. WIth KIPI, even this isn't possible (KIPI returns a QAction directly, which can't even be cloned). I really wanted the thread approach, but it didn't work out. There's no difference on start-up time on my machine between KSnapshot and KScreenGenie now. Is it really slower at your computer? > > More menu > --------- > Sure, I can do that as done here (https://git.reviewboard.kde.org/r/123342/). > When do you > plan to enable reviewboard for kscreengenie? > I don't know how to. Wasn't able to find anything on Techbase. Anybody? > > Save & Exit > ----------- > I see your new "Save & Exit" button. I did not see what exactly it does right > now but I > like the direction. I assume it will save the image to some default location. > > Here is a suggestion for later: Make that a drop-down button and add a > "Configure..." > entry to it which will open a configure dialog like this one: > http://feinstaub.github.io/kreenshot-editor/img/2014-07-05-prefs.png. This > dialog is > currenly part of the playground project > [kreeenshot-editor](http://feinstaub.github.io/kreenshot-editor/). Here the > user can > define the default output directory, placeholders for the filename like date, > time, user > name, machine name, and window title (if available). Also some "after save > action" can be > defined, e.g. open with image viewer or copy filename top clipboard. > I don't want to introduce too much configurability, but this does seem like a good idea. The current default Quicksave filename is ~/Pictures/Screenshot_YYYYMMDD_HHMMSS.png > > SendTo / Edit with... > --------------------- > I see that you put some thoughts into the structure of the SendTo menu. > > Suggestion for a dedicated "Edit with..." menu: Currently, in ksnapshot, if > you use "Send > To" the control over the image file is passed from ksnapshot to the invoked > application or > plugin. The idea is to have a "Edit..." menu that contains only applications > which are > capable of editing image files. As soon as the external application saves the > image file > to disk the preview in ksnapshot will be updated accordingly. This way you > can easily edit > the image with some other tool and in the last step send it away or print it > with the > original SendTo menu. > This I have issues with. There are already too many buttons; I don't want to introduce more (there will be a Print button also). Maybe a possible scenario would be to put editors in an Edit With submenu in Send-To. As for returning the edited image to KSG, that would involve putting a file monitor on the temporary file that was saved and passed to the new app, and updating the screenshot every time it is saved. What if the user presses Ctrl-S multiple times while he's editing? When do we know not to watch for any more save events? We can know when KService apps have terminated (KRun::runService returns a PID), but we have no way of knowing the same for KIPI. Not un-doable, but this kind of complexity I'd like to only introduce once I've made a stable release. > > What is your IRC nick by the way? :-) > BaloneyGeek. Yours? I'm also not subscribed to kde-devel (yet) - could anyone replying to this thread please reply to me explicitly (in addition to the list, of course), or does this have adverse effects on the mailing list? -- Boudhayan Gupta >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
