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



On Sun, Dec 08, 2013 at 07:53:00PM +0100, Sébastien Wilmet wrote:
Here are my thoughts on how to implement the file loading and saving in 
GtkSourceView (currently available in GeditDocument).

After discussion on IRC, here are more thoughts, and nice-to-have 
things. It's more a note to myself, instead of losing the information in 
IRC logs.

-----

<pbor> 1 - the current loader/saver are nice because they give you 
progress during an operation, but it kind of suck that they block 
editing, I think it would be nice to just quickly mirror a snaphot of 
the content into the sourcefile and let save happen without blocking 
edit

<pbor> what I mean could simply be
<pbor>  - freeze the doc from any modification
<pbor>  - push data to a buffered stream big enough for common cases
<pbor>  - if all the content was streamed, thaw the doc
<pbor> at that point the user can go on editing
<pbor> and the saving can happen async
<pbor> obviously for a 100 MB log it would not work
<pbor> but I do not care about that case
<pbor> that case can still block

Taking a real snapshot of the buffer would be too complicated. Text 
insertions and deletions should be recorded, and cancelled when reading 
the buffer. It's probably also feasible, but pbor's solution is easier, 
and sufficient for our use cases.

One thing to also remember: really big files are generally generated 
(logs, code documentation, …), so they are more read-only.

-----

<pbor> 2 - it is a bit of a pipe dream, since it never materialized, but 
it would be cool to keep in mind how the proposed api would fit with an 
out of process loader/saver
<pbor> (think a "suid" helper or something to let you edit root files if 
you are authorized by polkit)

It's complicated to predict how the GIO API would look like (if it is 
implemented in GIO). Ideally it should works transparently, GIO handles 
automatically all the polkit stuff when the process is owned by a user 
who doesn't have write permissions to the file.

With polkit, file writing or reading are asynchronous, since we should 
wait the permission (dialog window with password to enter, typically, or 
the permissions are configured beforehand). So I think as soon as we use 
asynchronous GIO API, there won't be major problems.

And anyway, for gsv, it's always possible to add a property, or 
something to handle this case. Worst case is to deprecate all the API 
and create a new one… But I think it won't be necessary.

And if nobody works on that feature, we can still wait 10 years without 
having the feature, and if the current API is more complicated to use 
just because "maybe in the future we can support this and this", without 
certainty that the API flexibility we made fulfill those features.

So for me it is a bit out of scope for the moment, unless you have a 
precise idea how it would be implemented in GIO.

-----

<pbor> 3 - even more pipedream, how would it fit with a git backend?  
think of an editor where every operation is mapped to a git commit etc

What can be reused for that purpose is the GtkSourceBufferInputStream.  
If needed, we can make this class public.

-----

Sébastien


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]