See below. On 19/04/15 20:26, Boudhayan Gupta wrote: >> 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.
This has to done in KIPI itself, I think. The KIPI people should be involved in this matter. > There's no difference on start-up time on my machine between KSnapshot > and KScreenGenie now. Is it really slower at your computer? Yes it is on mine. Startup time KSnapshot: instantly, KScreenGenie: 1 second. And it actually does not capture an image. The result is a white rectangle. The mouse cursor is included when the checkbox is checked, though. But note that my KF5 build is about 1 - 2 weeks old if this matters. >> 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? You have to ask for a project in the playground section. You can do this with a sysadmins ticket on https://sysadmin.kde.org/tickets. This is an example of how I did it: http://wstaw.org/m/2015/04/19/move_to_playground.png >> 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 I have a slighly different location where I want the screenshots to go into... ;-) >> 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. Sure, it does not have to be a separate button. It could be done with menu sections like this: -- Send To -- [menu section] Editor: -- kolourpaint -- gimp -- ... -- ... -- [menu section] Send to: -- Export to Imgur... -- ... -- ... -- [menu section] Printer: -- Print images -- Print assistant... Or have the Print button separately as you said. Each section could have its own "More" menu if KMoreTools is used. > 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. I thought about starting the file monitor as soon as the screenshot was taken. Everytime ANY program edits the file kscreengenie picks it up. The monitoring stops as soon as kscreengenie is closed or another screenshot is taken. This implies that when one of the other "Send To" or "Print" commands are used the file has to copied to a temporary location each time before passing the filename. But that's no problem, is it? >> What is your IRC nick by the way? :-) >> > > BaloneyGeek. Yours? gregormi > 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 Gregor >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
