Re: [gedit-list] File loading and saving in GtkSourceView



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]