Re: [gedit-list] File loading and saving in GtkSourceView
- From: Sébastien Wilmet <swilmet gnome org>
- To: gedit-list gnome org
- Subject: Re: [gedit-list] File loading and saving in GtkSourceView
- Date: Sat, 14 Dec 2013 14:37:17 +0100
Hi,
Here are more analyze.
With the GIO conventions, there is by nature more flexibility than the
signals system in GeditDocument. With the async functions, it is
possible to call the save or load function while a previous call is not
finished. For example the user clicks two times on the save button (if
the sensitivity is not updated). The desirable flexibility: parallel
loading into several buffers, from one or several files; parallel saving
into several files, from one or several buffers. The desirable
restrictions: (1) at most one load at a time per buffer, (2) at most one
save at a time per file.
The GIO conventions allow the two restrictions. For the first one, it is
possible to cancel the operation. If load_async() is called two times,
the second cancels the first one. I think it is better to cancel the
first one because the reason for calling load_async() a second time may
be to fix a property (encoding, newline-type, etc). The second call has
more chances to be the correct one.
The first load operation can be in another GtkSourceFile (and thus
another location). To be able to cancel it from another SourceFile, the
buffer should keep a list of attached SourceFiles. When a SourceFile is
created (with the buffer construct-only property), the SourceFile is
registered in the buffer, and the buffer keeps a weak ref to the
SourceFile.
For the second restriction, it is not really possible to prevent it in
gsv. It is not a big problem though, because GIO will normally not mix
the contents. For g_file_replace(), we can read:
This will try to replace the file in the safest way possible so
that any errors during the writing will not affect an already
existing copy of the file. For instance, for local files it may
write to a temporary file and then atomically rename over the
destination when the stream is closed.
=====
I don't know if it's better in GtkSourceFile to have the location
property construct-only or not. If it is construct-only, another
SourceFile can be created with another GFile. A clone() function can be
useful, to clone a SourceFile by being able to change the construct-only
properties (the buffer and the location).
Anyway, it is too early to say which solution is the better.
=====
The nice thing with the save, saving, saved, … signals in GeditDocument
is that GeditTab connects to these signals to show the progress bar,
error messages with choices for the user, and maybe other features. When
an error occurs, the user can ignore the error, and the operation is
relaunched with one more flag. And by reading the code, I think if a
plugin calls gedit_document_save_as() with some flags, and if an error
occurs, GeditTab will show the error, and if the operation is
relaunched, the flags can be screwed up (because the main save as button
in gedit doesn't call directly gedit_document_save_as(), it calls a
private GeditTab function that saves the flags).
With the GIO conventions, there is no signals, and it's better like
that. If a plugin wants to save the buffer to another file, there won't
be unexpected behavior handled by gedit. The plugin will receive the
errors and must handle them independently of gedit.
On the other hand, the progress bar and the error messages are nice. It
is useful for any text editor. In the future, we can integrate these
features in gsv, with a GtkSouceTab containing high-level functions to
load, save and save as (only with the default buffer location).
In the short term we should decide what to do with the GeditDocument API
wrt file loading and saving. With a rapid grep in gedit plugins, the API
seems to be used by quite a lot of plugins, unfortunately. For example
the spell plugin connects to the loaded and saved signal to load and
save spell settings stored in the metadata.
A solution is to keep the API, and write an adapter to use
GtkSourceFiles. By doing this, we don't break plugins, and we test the
gsv work.
=====
My e-mail is long enough. Time for hacking!
Sébastien
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]