Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
Le 04/05/2011 23:00, Enrico Tröger a écrit : Hi, any objections in increasing the GTK minimum requirement of Geany to GTK 2.12 (and GLib 2.16)? [...] Any new on the subject? Should we go on an start moving? Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
On Mon, 13 Jun 2011 16:45:38 +0200, Colomban wrote: Le 04/05/2011 23:00, Enrico Tröger a écrit : Hi, any objections in increasing the GTK minimum requirement of Geany to GTK 2.12 (and GLib 2.16)? [...] Any new on the subject? Should we go on an start moving? Yeah, I'd say let's go! Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgppdG1mATM3R.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
On Mon, 13 Jun 2011 17:26:06 +0200 Enrico Tröger enrico.troe...@uvena.de wrote: On Mon, 13 Jun 2011 16:45:38 +0200, Colomban wrote: Le 04/05/2011 23:00, Enrico Tröger a écrit : Hi, any objections in increasing the GTK minimum requirement of Geany to GTK 2.12 (and GLib 2.16)? [...] Any new on the subject? Should we go on an start moving? Yeah, I'd say let's go! I second this. Cheers, Frank -- http://frank.uvena.de/en/ pgpwuJ2pgUSyN.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
Le 13/06/2011 18:55, Frank Lanitz a écrit : On Mon, 13 Jun 2011 17:26:06 +0200 Enrico Tröger enrico.troe...@uvena.de wrote: On Mon, 13 Jun 2011 16:45:38 +0200, Colomban wrote: Le 04/05/2011 23:00, Enrico Tröger a écrit : Hi, any objections in increasing the GTK minimum requirement of Geany to GTK 2.12 (and GLib 2.16)? [...] Any new on the subject? Should we go on an start moving? Yeah, I'd say let's go! I second this. Okay, let's do then :) However, I just realized that GTK 2.12 [1] depends on GLib 2.14, not 2.16 [2] as you suggested so... do we depend on GLib 2.14 (as GTK 2.12) or 2.16 (to get GIO in)? Cheers, Colomban PS: Also just for the record, [3]. [1] GTK+ 2.12.0, 2007-09-14 (bebbf23f22645b2b2c44da1a52da31cc076fcd21) [2] GLib 2.16.0, 2008-04-10 (e2a4ed3287671f498d6ab87337ad31b13d781fcb) [3] GTK+ 2.14.0, 2008-09-04 (10b98d572c2007a7aef19b9c74b4c97bc17a9ac3) ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
On Mon, 13 Jun 2011 19:38:23 +0200, Colomban wrote: Le 13/06/2011 18:55, Frank Lanitz a écrit : On Mon, 13 Jun 2011 17:26:06 +0200 Enrico Tröger enrico.troe...@uvena.de wrote: On Mon, 13 Jun 2011 16:45:38 +0200, Colomban wrote: Le 04/05/2011 23:00, Enrico Tröger a écrit : Hi, any objections in increasing the GTK minimum requirement of Geany to GTK 2.12 (and GLib 2.16)? [...] Any new on the subject? Should we go on an start moving? Yeah, I'd say let's go! I second this. Okay, let's do then :) However, I just realized that GTK 2.12 [1] depends on GLib 2.14, not 2.16 [2] as you suggested so... do we depend on GLib 2.14 (as GTK 2.12) or 2.16 (to get GIO in)? I wanted GLib 2.16 because of GIO to get rid of #ifdefs. And based on Debian Lenny's GTK/Glib versions, I suggested the combination of GTK 2.12 and GLib 2.16 although they were not released in the same cycle. Btw, Nick is using GTK 2.12, so unless there is a super cool fancy feature in GTK 2.14 we cannot miss, I'd say 2.12 is ok for now. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpWZ6NyJ315c.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
Le 13/06/2011 19:45, Enrico Tröger a écrit : On Mon, 13 Jun 2011 19:38:23 +0200, Colomban wrote: Le 13/06/2011 18:55, Frank Lanitz a écrit : On Mon, 13 Jun 2011 17:26:06 +0200 Enrico Tröger enrico.troe...@uvena.de wrote: On Mon, 13 Jun 2011 16:45:38 +0200, Colomban wrote: Le 04/05/2011 23:00, Enrico Tröger a écrit : Hi, any objections in increasing the GTK minimum requirement of Geany to GTK 2.12 (and GLib 2.16)? [...] Any new on the subject? Should we go on an start moving? Yeah, I'd say let's go! I second this. Okay, let's do then :) However, I just realized that GTK 2.12 [1] depends on GLib 2.14, not 2.16 [2] as you suggested so... do we depend on GLib 2.14 (as GTK 2.12) or 2.16 (to get GIO in)? I wanted GLib 2.16 because of GIO to get rid of #ifdefs. And based on Debian Lenny's GTK/Glib versions, I suggested the combination of GTK 2.12 and GLib 2.16 although they were not released in the same cycle. Fine for me, just wanted to check what you meant exactly. An I agree that having GIO in is one of the important thing to get rid of many #ifedfs. Btw, Nick is using GTK 2.12, so unless there is a super cool fancy feature in GTK 2.14 we cannot miss, I'd say 2.12 is ok for now. No, I don't know of anything special that would make depending on 2.14 so much better. 2.12's fine. I'll then do the bump soon. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Plugins: Bump dependencies also to GTK 2.12 / GLIB 2.16?
Hi developers, As currently the dependencies for Geany are getting bumped to GTK 2.12 and GLIB 2.16 I'm wondering whether we should also bump dependencies of current devel version of geany-plugins to Geany 0.21 and with this step also to this versions of GTK/glib? Cheers, Frank -- http://frank.uvena.de/en/ pgpPVec5dntwF.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] GIO saving made configurable?
Hi,
During the phase of removing code that is not relevant anymore since the
dependency bump, I fatally came out to write_data_to_disk(). Now we can
assume we have GIO, it may seem sensible to drop completely the C API
file saving code...
...However, GIO saving seems to cause some problems on some complex
situations:
https://sourceforge.net/tracker/?func=detailatid=787791aid=3220784group_id=153444
https://sourceforge.net/tracker/index.php?func=detailaid=3184594group_id=153444atid=787791
https://sourceforge.net/tracker/index.php?func=detailaid=3126535group_id=153444atid=787791
(and maybe more -- at least one on IRC).
So I'm wondering: do we really want to drop the C API-using code path,
or do we want to make it configurable (like safe file saving)?
Well, since I'm not completely sure of what causes the problems and what
are the downsides (either I don't remember or I did not participate to
the discussion...), I prefer to ask you what do you
think/know/remember/whatever about this.
I join a sample patch that make GIO saving configurable (just like safe
file saving) with it enabled by default, if anybody wants to check it out.
So, what's your opinion?
Cheers,
Colomban
diff --git a/doc/geany.txt b/doc/geany.txt
index 161d8ae..334d81c 100644
--- a/doc/geany.txt
+++ b/doc/geany.txt
@@ -4425,6 +4425,10 @@ use_safe_file_saving Defines the mode how Geany saves files tof
break things seriously.
The better approach would be to ensure your
disk won't run out of free space.
+use_gio_unsafe_file_savingWhether to use GIO as the unsafe filetrue
+ saving backend. It is better on most
+ situations but is know not to work
+ correctly on some complex setups.
gio_unsafe_save_backupMake a backup when using GIO unsafe file false
saving. Backup is named `filename~`.
**Search related**
diff --git a/src/document.c b/src/document.c
index 4c1b8b5..df1ec2c 100644
--- a/src/document.c
+++ b/src/document.c
@@ -1603,17 +1603,29 @@ static gchar *write_data_to_disk(const gchar *locale_filename,
{
GError *error = NULL;
- if (! file_prefs.use_safe_file_saving)
+ if (file_prefs.use_safe_file_saving)
{
+ /* Use old GLib API for safe saving (GVFS-safe, but alters ownership and permissons).
+ * This is the only option that handles disk space exhaustion. */
+ if (g_file_set_contents(locale_filename, data, len, error))
+ geany_debug(Wrote %s with g_file_set_contents()., locale_filename);
+ }
#ifdef HAVE_GIO
+ else if (file_prefs.use_gio_unsafe_file_saving)
+ {
GFile *fp;
- /* Use GIO API to save file (GVFS-safe) */
+ /* Use GIO API to save file (GVFS-safe)
+ * It is best in most GVFS setups but don't seem work correctly on some complex setups
+ * (saving from a VM to its host, over some SMB shares, etc.) */
fp = g_file_new_for_path(locale_filename);
g_file_replace_contents(fp, data, len, NULL, file_prefs.gio_unsafe_save_backup,
G_FILE_CREATE_NONE, NULL, NULL, error);
g_object_unref(fp);
-#else
+ }
+#endif
+ else
+ {
FILE *fp;
int save_errno;
gchar *display_name = g_filename_display_name(locale_filename);
@@ -1668,14 +1680,6 @@ static gchar *write_data_to_disk(const gchar *locale_filename,
}
g_free(display_name);
-#endif
- }
- else
- {
- /* Use old GLib API for safe saving (GVFS-safe, but alters ownership and permissons).
- * This is the only option that handles disk space exhaustion. */
- if (g_file_set_contents(locale_filename, data, len, error))
- geany_debug(Wrote %s with g_file_set_contents()., locale_filename);
}
if (error != NULL)
{
diff --git a/src/document.h b/src/document.h
index cc5de7c..5fb4f7b 100644
--- a/src/document.h
+++ b/src/document.h
@@ -61,6 +61,7 @@ typedef struct GeanyFilePrefs
gboolean use_safe_file_saving;
gboolean ensure_convert_new_lines;
gboolean gio_unsafe_save_backup;
+ gboolean use_gio_unsafe_file_saving; /* whether to use GIO as the unsafe backend */
}
GeanyFilePrefs;
diff --git a/src/keyfile.c b/src/keyfile.c
index 636b992..52a9928 100644
--- a/src/keyfile.c
+++ b/src/keyfile.c
@@ -196,6 +196,8 @@ static void init_pref_groups(void)
use_safe_file_saving, FALSE);
stash_group_add_boolean(group, file_prefs.gio_unsafe_save_backup,
gio_unsafe_save_backup, FALSE);
+ stash_group_add_boolean(group, file_prefs.use_gio_unsafe_file_saving,
+ use_gio_unsafe_file_saving, TRUE);
/* for backwards-compatibility */
stash_group_add_integer(group, editor_prefs.indentation-hard_tab_width,
indent_hard_tab_width, 8);
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GIO saving made configurable?
Hi Columban. On 14 June 2011 08:54, Colomban Wendling lists@herbesfolles.org wrote: Hi, During the phase of removing code that is not relevant anymore since the dependency bump, I fatally came out to write_data_to_disk(). Now we can assume we have GIO, it may seem sensible to drop completely the C API file saving code... ...However, GIO saving seems to cause some problems on some complex situations: https://sourceforge.net/tracker/?func=detailatid=787791aid=3220784group_id=153444 https://sourceforge.net/tracker/index.php?func=detailaid=3184594group_id=153444atid=787791 https://sourceforge.net/tracker/index.php?func=detailaid=3126535group_id=153444atid=787791 (and maybe more -- at least one on IRC). So I'm wondering: do we really want to drop the C API-using code path, or do we want to make it configurable (like safe file saving)? Well, since I'm not completely sure of what causes the problems and what are the downsides (either I don't remember or I did not participate to the discussion...), I prefer to ask you what do you think/know/remember/whatever about this. Having been involved in some of the previous discussions here is what I remember. The methods of saving files are: 1. g_file_set_contents, saves to a temporary file and renames, our safe file saving setting. Safe, but permissions can change. On windows has to close the old file and delete it before renaming the temporary, on Unix just renames. Thus won't work if running on Unix and accessing Windows files. 2. g_file_replace, tries to do the same as g_file_set_contents but checks if it can change the permissions first and, if it can't, falls back to copying the old file to a temporary then truncating the old file and writing over it. On slow remote filesystems this gives lousy performance as it transfers data three times not just once (subject of several complaints). Because it has better knowledge of which filesystems are which, can work on windows files from Unix. Not safe, unless set to provide a permanent backup, will still delete the temporary file even if writing the new file fails. Option for keeping the backup is in Geany SVN version only. 3. c library write, unsafe but works fast on all filesystems. At the moment the c library option is only available if compile time determines GIO is not available or the user configures to not use GIO. Looking at these methods, they each address differing situations. As Enrico once said, 'who knew it was so hard to just write a file' :-). So I would say that all three need to stay, and the choice between GIO and the c library needs to be made a preference not a compile time option. So your patch looks good to me (by inspection only). Cheers Lex I join a sample patch that make GIO saving configurable (just like safe file saving) with it enabled by default, if anybody wants to check it out. So, what's your opinion? Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
