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: Tue, 10 Dec 2013 18:22:21 +0100
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]