Bug 107319

I would find this very cool too! I just wanted to report the same wish. Funny!

Junior Job?

I really would like this  button too! I think, it is a great idea, to directly mail the screen. This could be done by a temporary image or whatsever.

I contacted Matthias Ettrich about this wishlist item and am trying to get the bug reassigned to him, too. Let's see what comes from it :)

RichiH

*** This bug has been confirmed by popular vote. ***

As a follow-up, i did not know who Matthias Ettrich was and he told me that him being listed as maintainer was an error he would correct. But it seems our votes got that wishlist item rolling, anyway :)

As nobody has coded this so far and I wanted to learn programming KDE I simply coded this feature. The attachment contains a diff against the kdegraphics source from kde 3.5.5.

Dennis

Created attachment 18386 [details]
A patch for this feature applied against KDE 3.5.5

Update: The last patch contains a race condition. The problem is that the tempfile must IMHO be deleted from ksnapshot. The question where to do it. I've now decided to clean up everything when ksnapshot is closed. This has the handicap that you get an error if you close ksnapshot before kmail is started. But this seems the best way to me. Leaving all the temp stuff undeleted isn't a solution in my opinion.

Created attachment 18388 [details]
The latest version of the patch

I tried this patch for KDE 3.5.1 and it works too! Although it is not very fancy, it greatly enhances usability. Thanx for your work!

You could have ksnapshot warn against closing unless the mail handler is open. Problem is that it does not have to be kmail which is handling the sending of mail..

@Richard: I already thought about watching the mail program. But the user should have the option to quit ksnapshot before the mail program. It's furthermore only important that kmail is started because it then copies the temp file into the open unfinished mail. Afterwards you can safely delete the temp file. But at the moment I don't see any possibility to get the information that the mail program is opened. Maybe somebody can give me a hint. After reading the documentation I still don't see how the startup_id parameter can be used.

I also found a bug in the latest patch if you click more than once on the mail button ksnapshot will crash, it's due to closing the file in the button handler code. I will take a review on this later.

Maybe it's better to just leave the temp files and let the user clean the temp directory from time to time. I saw many temp files in this location from different KDE apps which don't seem to clean up. Is there any policy in KDE regarding temp files?

Now I have found a solution: The files are deleted when closing ksnapshot, and the first time you use the mail button an information box appears, which warns about closing ksnapshot too fast. Furthermore I fixed the crash when you click the mail button more than once.

Can somebody check this into the svn Repository? Because this is the first time I code something for KDE, I haven't a svn account yet.

Created attachment 18415 [details]
The hopefully last patch :-)

If you were to use a specific subdirectory in /tmp, you could just check on running instances of ksnapshot on each startup and if you do not find any delete all tempfiles.

Another idea is to have ksnapshot disappear into the background instead of closing and waiting for either a reading file access or a timeout. Also, are you sure all mail programs will create a local copy once they open a new mail?

Thanks for your suggestions. Checking for one instance of ksnapshot may be a solution. But it means that temp is polluted till you start ksnapshot the next time.

With the mail program part I'm not 100% sure, but if one program doesn't make a local copy it's wrong by design IMHO. Just imagine you send a mail, add an attachment to this mail, then you decide to save it as draft until you send it the next day. So the mail program can't be sure, that the attachment exists under that location at some time in the future. So it has to keep a local copy from the point you add the attachment.

I think if there are such mail programs we simply have to ignore that. Furthermore keeping the temp files and deleting them at startup doesn't help against such programs. Imagine the following situation: A mail application is accessing the temp file when sending the mail. So the user begins take a snapshot and the mail app with the attachment is started. He doesn't send the mail. He quits ksnapshot and starts it later on a second time. After that he decides to send the mail and the file is gone.

The background idea isn't that good IMO. There are two question:
1. How to background (Tray or complete invisible to the user) ?

I would say the tray solution here. Otherwise you may get many concurrent ksnapshot instances which fill up the system resources without being noticed by the user.
But with the tray solution you get the next question:

2. What if it's backgrounded into tray an the user quits it there?

In this case you have reached the same point as without backgrounding

So finally I think deletion at the beginning is another possible solution, but to me it doesn't show any advantage to the current behavior. On my side I see the disadvantage of the message box and on your side I see the disadvantage of polluting the temp directory until the next start of ksnapshot. But maybe I've overlooked some point, so please convince me ;-)

In light of the impeding KDE4 release, I am going through all bug reports I am involved in. To the best of my knowledge, this issue is still open.

> ------- Additional Comments From richih-kde richih org  2007-12-18 19:22 -------
> In light of the impeding KDE4 release, I am going through all bug reports I am involved in. To the best of my knowledge, this issue is still open.


Isn't this dealt with by the new 'Send to...' functionality?

Rich.

Maybe naive question but what is wrong with running KMail and sending mail (with ksnapshot image) from it?

Kmail "solution" requires one shortcut more -- everything else is the same, user also has to specify subject, to, from, send, etc.

AFAIK this is dealt with by the new open with button in 4.0.

AFAYK or did you confirm with current HEAD? I can't, as I don't have a current trunk build anywhere :/

What I mean is that if my understanding of the problem description is
correct then 4.0 has functionality requested.

Cheers

Rich.

If ksnapshot 4 can send the screenshot per email at the press of a button then yes :)

On 31 Jan 2008 17:31:34 -0000, Richard Hartmann <richih-kde@richih.org> wrote:
> If ksnapshot 4 can send the screenshot per email at the press of a button then yes :)


Well, if that's all you want then the answer is probably no, it can't.
Instead we've tried to balance various desires such as the "I'd like
to be able to open the file in XXX" or "I'd like to be able to send it
directly to a specific contact in Kopete" with the ability to send the
image to any application that says it can handle it. This allows us to
avoid cluttering the UI with a button for each feature request. Try it
and see if it meets the need that was expressed.

Sounds extremely interesting and very likely solves the issue in an Even Better Way (tm). I will try to get my hands on a current build asap :)

Out of interest: How can a program opt into this scheme? I assume it is some magic with the new backends of KDE?