Towards gvfs-fuse independence #963

techee · 2016-03-13T22:56:26Z

Based on the discussion here #921 I tried what is still missing to support opening remote files without gvfs-fuse. As I suspected, there wasn't much missing - mostly some g_file_test() calls which didn't work remotely, file name validation which didn't allow URIs, getting filenames instead of URIs from file dialogs etc.

What works after these patches:

opening links like https://developer.gnome.org/gio/stable/GFile.html both from command-line and file open dialog
browsing remote locations in file browser
opening/saving ftp/ssh/etc. locations when mounted - I guess they need to be mounted to work - even gedit needs them mounted (it would probably be possible to use g_file_mount_enclosing_volume () to pop up dialog to make user mount them, not sure if we want it or not)
opening/saving remote projects

What doesn't work:

TM parsing - the only reason here's the g_stat() in tm_source_file_init(), after commenting it out it works but TM at the moment doesn't know about Geany's file operation method used so it's not possible to implement this properly (I plan moving the TM - without ctags - into src making it effectively part of Geany after which it will have access to Geany's definitions)
File->Properties - I simply have been lazy to implement it
of course things like find in files, build commands etc. which we cannot run remotely

elextr · 2016-03-14T01:05:20Z

@techee nice!!!

Two questions:

what does the file dialog show and what do we get for IRIs, a pretty UTF-8 version or the uglyfied punycode or percent encoded version?
Does the save-actions plugin need adjusting too?

[Edit: 3. when the settings are not set to GIO does this mix GIO and non-GIO calls? (remembering that gave us problems with stat in the past) ]

techee · 2016-03-14T13:52:47Z

what does the file dialog show and what do we get for IRIs, a pretty UTF-8 version or the uglyfied punycode or percent encoded version?

Could you provide an example of such an URI pointing to some text file so I can try opening it in Geany?

Does the save-actions plugin need adjusting too?

From what I can see the backup saving code would have to be updated to work remotely.

[Edit: 3. when the settings are not set to GIO does this mix GIO and non-GIO calls? (remembering that gave us problems with stat in the past) ]

Since I fixed this one I took care not to mix GIO/non-GIO for files which could be opened remotely. Now with local files like various Geany config files it shouldn't matter and these typically still use the non-GIO variants all the time. The exception will be the various g_file_test() calls I replaced in the first patch and which might use GIO on local files . There are quite many of them and I wanted to avoid evaluating every single case whether it needs GIO or not. But again, since they are local and since they have nothing to do with file updates there's no danger there would be some kind of race like there was in the mtime case.

b4n · 2016-03-19T22:42:35Z

src/utils.c

+/**
+ *  Tests file existence using the configured IO method in Geany.
+ *
+ *  @param fname File name.


"the path or URI"

Do we actually want those in the API? It's cute, but do plugin really care about that?

When you have a look at the plugins the patch affects, they do (maybe not all the g_file_test()s deal with possibly remote files but some definitely do).

But the question is good - we probably shouldn't make an utility function for every single IO function - instead there should be something like

utils_use_gio()

and plugins should use it as needed (we'll already need this for the saveaction plugin which needs to be updated to make a backup copy of a possibly remote file). This will lead to a minor code duplication in the plugins but I think from the API perspective this is the right way. What do you think?

The other question is whether to make such a function inside utils or somewhere else (prefs?) or whether to make it e.g. a variable in some config struct. Ideas?

elextr · 2016-03-19T22:49:23Z

Could you provide an example of such an URI pointing to some text file so I can try opening it in Geany?

No, I only speak ASCII remember :) You or @b4n would be more likely to know of a site with an accented character in the domain name.

b4n · 2016-03-19T22:50:43Z

src/utils.c

@@ -1788,6 +1788,9 @@ void utils_tidy_path(gchar *filename)
 	const gchar *needle;
 	gboolean preserve_double_backslash = FALSE;

+	if (utils_is_uri(filename))
+		return;


what about skipping the scheme instead? around the line of a sane version of filename = strstr(filename, "://") + 3.

Can do. But can relative paths be part of a valid URI?

As I found out elsewhere not all schemes need the // so maybe not such a good idea.

@b4n I kept it this way in the new patch - the current implementation of the function would have to be changed because there's e.g.

utils_string_replace_all(str, "/", G_DIR_SEPARATOR_S)

on Windows which we don't want. And since URIs cannot be relative, I think it's more or less OK the way it is?

@elextr :// is used on other places to detect URIs - is there a better way?

Omitting "//" for URI is rather crazy and I don't expect operating systems or applications will ever pass uris this way. GTK for instance always returns "file://" when opening files and asking for URI. IMO the "//"-less case can be safely ignored.

@techee did you notice the release date THIS MONTH, of course nothing omits it at the moment, its only just been allowed.

Though actually my exhaustive test with Chrome and Firefox shows that many ;) browsers are perfectly happy without the // already.

@techee did you notice the release date THIS MONTH

Sure, I'm aware of the release and the patches are definitely not meant for it. It's just that I had time now and the bigger pull requests are better to be merged early in the next release cycle to get better testing (of course if Colomban has time to review them).

Sure, I'm aware of the release and the patches are definitely not meant for it.

I didn't mean the release of Geany, I meant the release of RFC 8089 that allows for file: to not have the //es. As it was only released Feb 2017 nothing will take advantage of it yet, though as I noted both chrome and firefox accept file: URLs without the //.

b4n · 2016-03-19T23:00:30Z

src/project.c

@@ -1034,12 +1034,15 @@ static gboolean load_config(const gchar *filename)
 	GKeyFile *config;
 	GeanyProject *p;
 	GSList *node;
+	gchar *data;
+	gsize len;


needs freeing

b4n · 2016-03-19T23:03:29Z

locale_filename now can be an URI. Is it's encoding still good? Does all the code handle it being an URI rather than a path gracefully?

b4n · 2016-03-19T23:06:19Z

Looks mostly sensible. But all this GFile creation, and this making Geany use GIO more and more makes me wonder: don't we rather want to have a GFile member attached to a document in addition to the path, and have this NULL when not using GIO? That would re-use the same link all the way, and possibly might prevent some oddies when loading from an URI and writing to a path (when gvfs-fuse is available) -- I doubt it should be a problem, but still, could be suboptimal I guess.

b4n · 2016-03-19T23:19:12Z

@elextr

what does the file dialog show and what do we get for IRIs, a pretty UTF-8 version or the uglyfied punycode or percent encoded version?

That's most likely not up to us, and if it doesn't work now it'll probably get fixed in GIO at some point. And GEdit seems to display it just fine when I try to open http://bücher.ch/ (no, I don't have a better example than the WP one)

elextr · 2016-03-19T23:32:22Z

@b4n, agree its not up to us, I just wanted to know what the open dialog would show.

And what would show for the filename on the tab and in its tooltip? And in the documents sidebar? And in filebrowser plugin?

I will bet there will be confused users if some things show Unicoded names and some show punycode and percent escaped names :)

Note: both saveactions and filebrowser are core plugins and should be fixed (if they need to be) as part of this change.

techee · 2016-03-20T20:33:51Z

@elextr Works fine as far as I can tell (once it works at one place, it should work everywhere - the rest is just a matter of correct locale/utf8 handling we should do anyway):

techee · 2016-03-20T20:37:24Z

locale_filename now can be an URI. Is it's encoding still good? Does all the code handle it being an URI rather than a path gracefully?

Seems so for the core functionality - can't speak for all the plugins. The only exception at the moment is the tag manager which skips parsing because of the g_stat() I mentioned previously.

techee · 2016-03-20T20:48:50Z

Looks mostly sensible. But all this GFile creation, and this making Geany use GIO more and more makes me wonder: don't we rather want to have a GFile member attached to a document in addition to the path, and have this NULL when not using GIO?

Good idea. I'd just make one change - always create the GFile no matter whether GIO is enabled or not. The problem is GIO can be enabled/disabled in preferences at any time so we'd have to nullify/set the field based on the settings, plugins would have to always check it for NULL and it would introduce just complications. Better to have something like the utils_use_gio() and whoever wants to use the GFile should use the utils_use_gio() or know what he is doing.

That would re-use the same link all the way, and possibly might prevent some oddies when loading from an URI and writing to a path (when gvfs-fuse is available) -- I doubt it should be a problem, but still, could be suboptimal I guess.

I hope when using GIO consistently this shouldn't happen. Anyway, the problem with mtime we had was quite unique I believe and shouldn't happen when e.g. just testing file existence.

techee · 2016-03-20T20:55:24Z

Note: both saveactions and filebrowser are core plugins and should be fixed (if they need to be) as part of this change.

Agree. Filebrowser already works, saveactions need an update to be able to save backups of remote files.

techee · 2017-02-27T15:23:46Z

Looks mostly sensible. But all this GFile creation, and this making Geany use GIO more and more makes me wonder: don't we rather want to have a GFile member attached to a document in addition to the path, and have this NULL when not using GIO?

Good idea. I'd just make one change - always create the GFile no matter whether GIO is enabled or not. The problem is GIO can be enabled/disabled in preferences at any time so we'd have to nullify/set the field based on the settings, plugins would have to always check it for NULL and it would introduce just complications. Better to have something like the utils_use_gio() and whoever wants to use the GFile should use the utils_use_gio() or know what he is doing.

I was thinking about it more and it won't eliminate most of the GFile creation. Most of the cases when GFile is created isn't for the already opened document, but when opening a file and e.g. validating it exists. So I didn't make this change in #1414.

techee added 12 commits March 13, 2016 23:17

Add wrappers around g_file_test() and use them everywhere

4d2f204

Update utils_get_path_from_uri() to return URI when using GIO

f366d1d

Fix warning in utils_tidy_path()

b4cf423

Use g_file_new_for_uri() when needed

beb7aad

Preserve URIs in tm_get_real_path()

9c16401

Merge implementations of write_data_to_disk() and utils_write_file()

8bc3ae4

Use gtk_file_chooser_get_uris() in file opening/saving dialogs

2cb9467

Add GIO version of document_rename_file()

d212390

Add GIO implementation to utils_get_file_list_full()

926b6c5

Add file reading utils function

f2689a0

Load project config files using the new utility function

a781ffe

Allow opening projects using URI

2ff5a35

b4n reviewed Mar 19, 2016
View reviewed changes

b4n added the work in progress label Mar 19, 2016

b4n reviewed Mar 19, 2016
View reviewed changes

techee mentioned this pull request Jul 22, 2016

Allow for direct GVFS usage (without gvfs-fuse) #1145

Open

5 tasks

techee mentioned this pull request Oct 11, 2016

Add utils_get_real_path() and use it #1224

Closed

techee mentioned this pull request Feb 27, 2017

Support for remote files without gvfs-fuse or fuse #1414

Open

elextr mentioned this pull request Jul 23, 2018

Support for admin:// that replaces gksu in latest debian releases #1898

Open

elextr mentioned this pull request Mar 31, 2020

ssh milestone geany/geany-plugins#963

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Towards gvfs-fuse independence #963

Towards gvfs-fuse independence #963

techee commented Mar 13, 2016

elextr commented Mar 14, 2016

techee commented Mar 14, 2016

b4n Mar 19, 2016

b4n Mar 19, 2016

techee Mar 20, 2016

elextr commented Mar 19, 2016

b4n Mar 19, 2016

techee Mar 20, 2016

elextr Dec 1, 2016

techee Feb 27, 2017

techee Feb 27, 2017

techee Feb 28, 2017

elextr Feb 28, 2017

elextr Feb 28, 2017 •

edited

techee Mar 2, 2017

elextr Mar 2, 2017

b4n Mar 19, 2016

b4n commented Mar 19, 2016

b4n commented Mar 19, 2016

b4n commented Mar 19, 2016

elextr commented Mar 19, 2016

techee commented Mar 20, 2016

techee commented Mar 20, 2016

techee commented Mar 20, 2016

techee commented Mar 20, 2016

techee commented Feb 27, 2017

Towards gvfs-fuse independence #963

Are you sure you want to change the base?

Towards gvfs-fuse independence #963

Conversation

techee commented Mar 13, 2016

elextr commented Mar 14, 2016

techee commented Mar 14, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elextr commented Mar 19, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elextr Feb 28, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

b4n commented Mar 19, 2016

b4n commented Mar 19, 2016

b4n commented Mar 19, 2016

elextr commented Mar 19, 2016

techee commented Mar 20, 2016

techee commented Mar 20, 2016

techee commented Mar 20, 2016

techee commented Mar 20, 2016

techee commented Feb 27, 2017

elextr Feb 28, 2017 •

edited