GNOME Bugzilla – Bug 344515
serialising/deserialising page setup & print settings
Last modified: 2007-04-29 06:22:31 UTC
To store page setup and print settings between program invocations, there should be a way to serialise/deserialise GtkPageSetup and GtkPrintSettings.
I believe gtk_print_settings_foreach is meant to be that way. It will be hard to come up with a less generic one-size-fits-all serialization solution. Keyfile ? XML ? Binary ? separate file ?
Yes, I was thinking about a keyfile, maybe gtk_{print_settings,page_setup}_{from,to}_key_file. If we leave this to the programmer to do himself, this will lead to code duplication and everyone will do it subtly differently wrt. corner cases...
*** Bug 345128 has been marked as a duplicate of this bug. ***
So I'm working on a patch for this. The question is which API we want: like this: +GtkPrintSettings *gtk_print_settings_new_from_data (const gchar *data, + gsize length, + GError **error); + +GtkPrintSettings *gtk_print_settings_new_from_file (const gchar *filename, + GError **error); + +GtkPrintSettings *gtk_print_settings_new_from_key_file (GKeyFile *key_file, + GError **error); + +gchar *gtk_print_settings_to_data (GtkPrintSettings *settings, + gsize *length); + +gboolean gtk_print_settings_to_key_file (GtkPrintSettings *settings, + GKeyFile *key_file, + GError **error); + and the same for GtkPageSetup, or something combined that would save a GtkPrintSettings and GtkPageSetup to the same keyfile? gchar *gtk_print_utils_settings_and_setup_to_data (GtkPrintSettings *, GtkPageSetup *, GError **); gboolean gtk_print_utils_settings_and_setup_from_data (const gchar *data, gsize length, GtkPrintSetting **, GtkPageSetup **, GError **); (and maybe from_file and {from,to}_key_file) ?
Btw, IMHO we should also document the encoding to use for a GtkPrintSettings setting, so you can reliably serialise/deserialise them. For use with keyfiles, it would be simplest to simply declare keys to have to be gkeyfile keys, and the data to be utf-8 ?
keys should be ascii without whitespace really values should be utf-8
So that rules out storing the output filename as a filename, since that'll be in filename encoding :)
Created attachment 67726 [details] [review] document key/value requirements I think we should exclude = and ; in key names to we can actually use gkeyfile to store them as-is. Should the functions actually g_return_if_fail-check those requirements (I can make a patch for that too) ?
re comment #7: I already admitted that in the other bug...
Re comment #4, whether to store GtkPrintSettings and GtkPageSetup separately or together... I have a slight preference for storing them separately. (but only because it feels "logically prettier" to have a one-to-one mapping <g>). As for whether to store as GKeyFile or gchar *data (or both), I don't think it matters either way, as long as a GKeyFile isn't some huge thing - I am just going to be storing GtkPrintSettings and GtkPageSetup temporarily so that I can recreate the user's dialog choices after the dialog is destroyed. Smaller is better in this case - I don't need to do any lookups on it or anything. I see that you are talking about wanting to freeze printing api for the endgame. I hope this api will still be considered?
Carolyn, even if we decide to not include this in 2.10, it is not very hard to write those serialization functions yourself.
True, but I'd want to pull the code out as soon as the 'real' api went in.
Matthias, I am still hoping that this api will be in 2.10. The serialize/deserailize code I wrote works, but it feels like a hack - I'd love to pull it out before I ship (and replace it with 4 lines of api code <g>). It's not too bad for print_settings because of the foreach, and because the set/get methods work with strings. But the page_setup object is a little bit uglier - that and its paper_size object are best serialized/deserialized by you. I am currently guessing a little bit for paper_size recreation. Here's what I do: - serialize name, display_name, ppd_name, width, height, is_custom - deserialize all of that, and then: - if is_custom and it has a ppd_name, use gtk_paper_size_new_from_ppd - if is_custom and ppd_name is null, use gtk_paper_size_new_custom - otherwise (not is_custom), use gtk_paper_size_new Also note that my code won't see any future changes to page_setup or paper_size, so I would always have to watch out for those.
This will be useful for the external previewer too. The preview could serialize the settings and pass them to evince through the command line. I will implement such a command line option in evince, so that it could be called in this way: evince --preview --print-settings=/tmp/<file> It would be nice to have it for G2.16 :-P
chpe, any progress on this one? It blocks #349102 and probably others.
uws: I wrote code in epiphany to do that, lib/ephy-print-utils.[ch]. Feel free to copy them into evince.
Yes, and I wrote it for eclipse, too, and it's a hack - see comment 13 for details. It feels like code that should be in the base. We're going to have copies of it all over the place, and then someone will add a field to one of the classes and a bunch of people will be broken. It would be better to make it api.
Created attachment 77646 [details] [review] proposed patch
Any chance of getting this into GTK+?
2007-04-29 Matthias Clasen <mclasen@redhat.com> * gtk/gtkprintoperation.h: Add a new error code * gtk/gtk.symbols: * gtk/gtkpagesetup.[hc]: * gtk/gtkpapersize.[hc]: * gtk/gtkprintsettings.[hc]: Add functions to serialize and deserialize page setups and print settings to files and key files. (#344515, Christian Persch) * gtk/gtkpagesetupunixdialog.c: Adapt to the new functions. * tests/print-editor.c: Use the new functions to persist page setup and print settings.