GNOME Bugzilla – Bug 566793
Support Drop And Drag Into Nautilus As PDF File
Last modified: 2020-09-10 06:03:37 UTC
Right now when you drop and drag from an Evolution folder into Nautilus, it writes out a mbox file which is basically worthless for more people. We desire the ability to have a PDF file written instead. gconf key would toggle between the two settings. Initially, it would be fine to have this gconf setting hidden and I can set it on the command line. The resulting file should have no spaces or special characters and end with .pdf. Other information:
Ultimately it should prompt the user for the format (with an "always" option). We also need to get printing of multiple messages working so we can also render several messages to a single PDF document. For that reason I'm tagging this bug with the "printing" keyword.
I would be very willing to take an interim patch which did single messages, with no GUI for testing of the work flow and how cleanly the files are created. Multiple message merge would be wonderful, but isn't required for us to being using this. This would be a strong Outlook killer for us.
Created attachment 130916 [details] First Draft Scope Of Work The first draft of scope of work for drop and drag improvements.
I'm trying to find a balance here between future design, and getting this feature at least minimally deployed and working. I can set gconf keys on the command line for the users to get around massive string and UI changes. But I want the work to include all of the required gconf keys for later upgrades.
Created attachment 132460 [details] Patch Adds initial support for PDF drop and drag.
Created attachment 132465 [details] [review] Improved patch (debug trace removed, ...) (note : patch built against evolution-2.24.1.1)
Patch is missing a GConf schema for the new keys, for starters. I'll try to do a more thorough review over the weekend.
Created attachment 132480 [details] [review] Additionnal patch for gconf schema
(In reply to comment #7) > Patch is missing a GConf schema for the new keys, for starters. > I'll try to do a more thorough review over the weekend. I talked to pepp about this and I decided to not include it, as dconf doesn't support schemas (yet).
Finally got around to a more thorough review. Looks like a pretty good first cut. Comments are in increasing order of severity. 1) In em_utils_selection_set_urilist() after fetching the "save_file_format" key, instead of simply checking for NULL I'd like to see: if (exporttype == NULL) exporttype = g_strdup ("mbox"); This will prevent NULL from creeping into a g_ascii_strcasecmp() call. 2) The "save_file_name" key is misnamed. Instead of a file name string, it instead holds some integer value that controls the date used in dragged file names. Why is this setting necessary? If it must be kept, pick a more accurate key name. I'd also like to see self-explanatory enum values defined to clairfy mysterious expressions like "if (exportname==2)". 3) The synchronous option in EMFormatHTMLPrint concerns me, because the code path involves a call to em_utils_contact_photo() which can and infact -did- block on me, resulting in a stuck grab during the drag. Only solution for that is to switch VTs and kill Evolution. Can you explain why the synchronous option is necessary?
#2) My idea was to allow for future changes by setting a gconf key for variations in the file name. From my scope of work: /apps/evolution/mail/save_file_name The naming convention to use when files are saved with dropanddrag. 1 YYYYMMDDhhmmssms_<name> (Date of email used) 2 YYYYMMDDhhmmssms_<name> (Date of drop and drag used) I didn't see a way to put a physical string name into that key that would make sense. 1 being for the date the email was received, and 2 being for the date of the drop and drag. In this case, if we tried to put in something with Y's and M's, they would match. I don't care about the exact names used, as long as we have the functionality of both.
That's fine to use an integer key, it just needs to be explained more clearly in the source code. Also, "save_name_format" might be a better key name. I'm still curious why the setting is needed to begin with. I would think the small fraction of users that care would prefer the sent date.
Actually, when I met with the users they felt strongly that they want it to saved in Sent Date format :) I added the other one because I felt they might regret that choice later.
Hmm, I'd prefer not to overengineer this right off the bat. Can we strike that setting until we have a real use case for it? We can always restore it later if there's demand.
About the synchronous option : the problem is that when a drag and drop event occurs the source application (Evolution) is notified via a Gtk signal (drag-data-get) so there is 2 solutions : - asynchronous with a flag blocking the drag-get-data signal handler to wait for the job begin done (ie : the pdf file created) - try to find a way to make the pdf formatting + printing synchronous. I tried the 1st way but the problem is : some work inside the HtmlFormat part is done in gtk main thread (g_timeout_add is used). As the signal handler is also in gtk main thread _and_ is blocked waiting the job completion the functions queued with g_timeout_add are nether called (at least until the signal handler ends). So I've gone with the 2nd way (and at least it's working on my test cases :-))
Created attachment 133523 [details] [review] re-improved patch New patch including corrections related to Matthew Barnes' review : #1 exporttype is set to mbox if null #2 gconf key name changed to save_name_format + enum use to clarify the possible values #3 add a workaround to disable photo integration in case of drag and drop (using existing EMFormat attribute 'show_photo')
Created attachment 138413 [details] [review] Adapted to Evolution 2.27.4 Pepp's patch bit rotted a bit so I've updated it to apply cleanly to Evolution 2.27.4. I think disabling the photo lookup did the trick; I haven't had a single stuck grab yet with this patch. Seeing some weird behavior on the Nautilus side, though. Doesn't always accept my drag the first time and I have to try again. Not sure what's going on there. I'd say the patch is at least ready for Dave's users. I'd still like to investigate prompting for a preferred format at drop-time before we land this in master.
Marking the patch as "needs-work" to get it off our unreviewed list.
@chen: Ping, can you merge the patch from SLED into upstream so we can close this issue? This is working beautifully and is very useful.
Absorbed in master. Commits - http://git.gnome.org/browse/evolution/commit/?id=d300de403de5b9b2d3c2c2f9d371f59859eeaf8c http://git.gnome.org/browse/evolution/commit/?id=c01655aa3ffed339cf485d162b24fad88b116b30 The gconf settings should be translated into mail preference items. Create a new bug for it and close this ?
(In reply to comment #20) > The gconf settings should be translated into mail preference items. Create a > new bug for it and close this ? Up to you, the change is relatively simple, maybe it could be done immediately.
Here is what I remembered from online conversations: On first drop and drag of email to a folder, dialog would appear and ask which format to use: PDF or MBOX. This would happen if the gconf key is set to null Under Preferences there would have to be a place to toggle this from PDF and MBOX (dropdown widget?). There is a secondary gconf key that indicates the naming convention to use when it's a PDF. The Preferences UI should allow this to be changed too.
(In reply to comment #22) > On first drop and drag of email to a folder, dialog would appear and ask which > format to use: PDF or MBOX. This would happen if the gconf key is set to null Having researched this a little, I don't think the sending side of drag-and-drop can trigger such a dialog. Evolution can only advertise available formats to the drop target. Such a dialog would have to be implemented on the Nautilus side, perhaps as a Nautilus plugin. I think I'd defer the dialog for now and just add a couple radio buttons to Preferences with MBOX selected by default. (Not a checkbox -- we might want to support additional formats in the future like PostScript.) Also, less important but I'd prefer to store the save format in GSettings as a full MIME type string. So "application/mbox" or "application/pdf" instead of just "mbox" or "pdf".
As Milan wrote on evolution-list@: Since 3.4.x you can set evolution to export messages as PDF when you drag&drop them to Nautilus (or such), instead of dropping them as mbox. You can do that with command: $ gconftool-2 --set --type=string /apps/evolution/mail/mail/save_file_format pdf This key had been moved to gsettings for 3.6.x, thus the command is: $ gsettings set org.gnome.evolution.mail drag-and-drop-save-file-format 'pdf'
Let's close this one, even without the dialog and with the hidden option.