Hey Nick, Matthew, Lex, Frank, Enrico, whoever cares,
https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64
I wrote this patch that adds automatic mounting of volumes needed to open a GIO URI, so one don't have to first mount the corresponding volume in Nautilus/whatever. This make opening arbitrary URIs from the CLI easier, though it's probably not needed when using a file manager (who would've already mounted the volume to browse it).
I'm quite confident mounting the volume is a good idea in theory, but there is a small thing making it a bit tricky: GIO doesn't seem to provide a synchronous API to do that.
So, it either requires the calling code to be asynchronous (which we don't have yet and that don't fit well with current code), or to hack around to make the asynchronous code look synchronous.
I did the latter, and that's basically the reason why I post this mail: do you think it's too ugly, too useless, too something?
Basically, points I see in a pros/cons:
+ allows to open URIs on unmounted volumes; + as a cause, makes Geany handle URIs more naturally; + mount is tried only as a last resort, so doesn't impact already working situations;
- code is a bit hackish (the loop thing), though it works fine [1]; - may be slow if mounting the volume is slow (since it is synchronous); - may not be really useful in practice (since people probably open URI through the file manager, who will mount the volume).
So... thoughts?
Cheers, Colomban
[1] only problem might be that idle/timeout callbacks (e.g. main loop sources) can still run during the mount -- though, I don't see why it'd be an actual problem for us
On Tue, Jan 31, 2012 at 11:30 AM, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hey Nick, Matthew, Lex, Frank, Enrico, whoever cares,
https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64
I wrote this patch that adds automatic mounting of volumes needed to open a GIO URI, so one don't have to first mount the corresponding volume in Nautilus/whatever. This make opening arbitrary URIs from the CLI easier, though it's probably not needed when using a file manager (who would've already mounted the volume to browse it).
I'm quite confident mounting the volume is a good idea in theory, but there is a small thing making it a bit tricky: GIO doesn't seem to provide a synchronous API to do that.
My only problem with making uri operations easier is that the incidence of remote data loss or performance complaints will increase.
So, it either requires the calling code to be asynchronous (which we don't have yet and that don't fit well with current code), or to hack around to make the asynchronous code look synchronous.
I did the latter, and that's basically the reason why I post this mail: do you think it's too ugly, too useless, too something?
Well, shrug, what else can you do?
But if the mainloop is still running while waiting, does that mean the UI is still available and the user can trigger another open? Will that work since AFAIK none of Geany is intended to be re-entrant.
Its a pity our old friend g_replace_contents doesn't work safely, otherwise we could g_file_new_from_uri, g_file_read to read it and g_file_replace_contents to write it, and let GIO do what it is meant to, sigh.
Basically, points I see in a pros/cons:
- allows to open URIs on unmounted volumes;
- as a cause, makes Geany handle URIs more naturally;
- mount is tried only as a last resort, so doesn't impact already
working situations;
- code is a bit hackish (the loop thing), though it works fine [1];
- may be slow if mounting the volume is slow (since it is synchronous);
- may not be really useful in practice (since people probably open URI
through the file manager, who will mount the volume).
Well I can't comment on its utility since I never edit anything remotely anyway. (but I guess that was a comment anyway).
Cheers Lex
So... thoughts?
Cheers, Colomban
[1] only problem might be that idle/timeout callbacks (e.g. main loop sources) can still run during the mount -- though, I don't see why it'd be an actual problem for us
See question above
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 31/01/2012 02:04, Lex Trotman a écrit :
On Tue, Jan 31, 2012 at 11:30 AM, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hey Nick, Matthew, Lex, Frank, Enrico, whoever cares,
https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64
I wrote this patch that adds automatic mounting of volumes needed to open a GIO URI, so one don't have to first mount the corresponding volume in Nautilus/whatever. This make opening arbitrary URIs from the CLI easier, though it's probably not needed when using a file manager (who would've already mounted the volume to browse it).
I'm quite confident mounting the volume is a good idea in theory, but there is a small thing making it a bit tricky: GIO doesn't seem to provide a synchronous API to do that.
My only problem with making uri operations easier is that the incidence of remote data loss or performance complaints will increase.
Hum, while I don't like the reason why it is a good point (remote support not being perfect), it still IS a good point. Though, I don't think that we shouldn't mount the volume to make things harder, if we really want to stop getting boring reports of users messing with their data remotely, we should probably simply drop the remote support and let the user do the mounts AND opens manually. But do we want that?
So, it either requires the calling code to be asynchronous (which we don't have yet and that don't fit well with current code), or to hack around to make the asynchronous code look synchronous.
I did the latter, and that's basically the reason why I post this mail: do you think it's too ugly, too useless, too something?
Well, shrug, what else can you do?
But if the mainloop is still running while waiting, does that mean the UI is still available and the user can trigger another open? Will that work since AFAIK none of Geany is intended to be re-entrant.
Good point. Just two things to note:
1) It's not actually any worst than gtk_dialog_run() which does the same, now I added a modal progress dialog [1]. We use gtk_dialog_run() in many places and don't worry much, so maybe it's enough.
2) The only (easy) way to trigger the volume mounting code is currently to open an URI pointing to an unmounted volume from the CLI. All other ways of of opening remote files (File->Open, URI list DnD, ..) almost surely needs the volume to be already mounted. OK, this only makes a buggy behavior less likely, it doesn't prevent it completely.
The sad story is that GLib/GIO actually HAS the API needed to make this work completely fine (g_main_context_push/pop_thread_default(), g_file_supports_thread_contexts()), but GVfsDaemon doesn't support it. BTW, GVfsDaemon seems to lack plenty of things, see the other mail...
Its a pity our old friend g_replace_contents doesn't work safely, otherwise we could g_file_new_from_uri, g_file_read to read it and g_file_replace_contents to write it, and let GIO do what it is meant to, sigh.
I think you're a bit too optimistic/naive. AFAIK, GIO won't ever mount you a volume implicitly just because you want to read from it. Actually it's unlikely it can, because it might require user interaction, like asking an username or a password. And GEdit itself does call g_file_mount_enclosing_volume().
Basically, points I see in a pros/cons:
- allows to open URIs on unmounted volumes;
- as a cause, makes Geany handle URIs more naturally;
- mount is tried only as a last resort, so doesn't impact already
working situations;
- code is a bit hackish (the loop thing), though it works fine [1];
- may be slow if mounting the volume is slow (since it is synchronous);
- may not be really useful in practice (since people probably open URI
through the file manager, who will mount the volume).
Well I can't comment on its utility since I never edit anything remotely anyway. (but I guess that was a comment anyway).
I don't edit much remote files myself and prefer either local edit + upload or simply Git :) -- but yes, was a useful comment, thanks :)
Cheers, Colomban
[1] https://github.com/b4n/geany/commit/540e6b28d8ce461b44f6fd4dce32c38167bca99b
Cheers Lex
So... thoughts?
Cheers, Colomban
[1] only problem might be that idle/timeout callbacks (e.g. main loop sources) can still run during the mount -- though, I don't see why it'd be an actual problem for us
See question above
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
On Tue, 31 Jan 2012 01:30:58 +0100, Colomban wrote:
Ho Colomban and the rest,
https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64
I wrote this patch that adds automatic mounting of volumes needed to open a GIO URI, so one don't have to first mount the corresponding volume in Nautilus/whatever. This make opening arbitrary URIs from the
whatever = Gigolo!
:)
I'm quite confident mounting the volume is a good idea in theory, but there is a small thing making it a bit tricky: GIO doesn't seem to provide a synchronous API to do that.
So, it either requires the calling code to be asynchronous (which we don't have yet and that don't fit well with current code), or to hack around to make the asynchronous code look synchronous.
I did the latter, and that's basically the reason why I post this mail: do you think it's too ugly, too useless, too something?
I basically like the idea. If I remember correctly, the relevant code is also called when starting Geany and the main GUI isn't yet shown. If so, I see one big problem: if the mount won't finish in a short time, the user doesn't know what's happening and probably only notices that Geany doesn't start because no GUI is shown. So, I think at the very least we would need some sort of timeout, a short timeout, to cancel the mount operation if it takes too long. Not sure what exactly is 'too long', maybe a few seconds. Or even better (and more complex) we would show the user a dialog with a pulsing progressbar or so stating that a mount operation is in progress. A cancel button would be a big bonus but probabaly not necessarily needed.
Regards, Enrico
Le 31/01/2012 20:14, Enrico Tröger a écrit :
On Tue, 31 Jan 2012 01:30:58 +0100, Colomban wrote:
Ho Colomban and the rest,
https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64
I wrote this patch that adds automatic mounting of volumes needed to open a GIO URI, so one don't have to first mount the corresponding volume in Nautilus/whatever. This make opening arbitrary URIs from the
whatever = Gigolo!
:)
I'm quite confident mounting the volume is a good idea in theory, but there is a small thing making it a bit tricky: GIO doesn't seem to provide a synchronous API to do that.
So, it either requires the calling code to be asynchronous (which we don't have yet and that don't fit well with current code), or to hack around to make the asynchronous code look synchronous.
I did the latter, and that's basically the reason why I post this mail: do you think it's too ugly, too useless, too something?
I basically like the idea. If I remember correctly, the relevant code is also called when starting Geany and the main GUI isn't yet shown. If so, I see one big problem:
Actually opening from CLI is ~ the only way to trigger the code since most other would need the volume to be already mounted. So startup and remote control.
if the mount won't finish in a short time, the user doesn't know what's happening and probably only notices that Geany doesn't start because no GUI is shown. So, I think at the very least we would need some sort of timeout, a short timeout, to cancel the mount operation if it takes too long. Not sure what exactly is 'too long', maybe a few seconds. Or even better (and more complex) we would show the user a dialog with a pulsing progressbar or so stating that a mount operation is in progress. A cancel button would be a big bonus but probabaly not necessarily needed.
Good point, here you go with a dialog, pulse & cancel: https://github.com/b4n/geany/commit/540e6b28d8ce461b44f6fd4dce32c38167bca99b
Having a modal dialog also has the advantage of blocking user interaction on the main window, addressing a part of Lex's worries.
Just as a funny note, implementing all this required some more hackery because GVfsDaemon (bridge of all remote FS) doesn't actually honor cancellation even though the API is supposed to provide it.
So, here it is with a progress dialog & cancellation support. I tested it a bit, particularly the opening a second URI from the CLI while waiting to mount a first one, and it looked like it worked fine: mounted the stuff and/or asked for details, each after the other, no weird concurrency. Though, if anyone wants to test it a bit more, it can't be wrong.
Comments still welcome of course :)
Cheers, Colomban
Regards, Enrico
On Thu, 02 Feb 2012 14:46:03 +0100, Colomban wrote:
if the mount won't finish in a short time, the user doesn't know what's happening and probably only notices that Geany doesn't start because no GUI is shown. So, I think at the very least we would need some sort of timeout, a short timeout, to cancel the mount operation if it takes too long. Not sure what exactly is 'too long', maybe a few seconds. Or even better (and more complex) we would show the user a dialog with a pulsing progressbar or so stating that a mount operation is in progress. A cancel button would be a big bonus but probabaly not necessarily needed.
Good point, here you go with a dialog, pulse & cancel: https://github.com/b4n/geany/commit/540e6b28d8ce461b44f6fd4dce32c38167bca99b
Cool!
Having a modal dialog also has the advantage of blocking user interaction on the main window, addressing a part of Lex's worries.
Just as a funny note, implementing all this required some more hackery because GVfsDaemon (bridge of all remote FS) doesn't actually honor cancellation even though the API is supposed to provide it.
Not so cool.
So, here it is with a progress dialog & cancellation support. I tested it a bit, particularly the opening a second URI from the CLI while waiting to mount a first one, and it looked like it worked fine: mounted the stuff and/or asked for details, each after the other, no weird concurrency. Though, if anyone wants to test it a bit more, it can't be wrong.
Nice. I'll test it tomorrow maybe if I find time.
One more thought, though this is less important and can be done later as well: we could move the GIO code into a separate file to have it separated from the rest. But as said, this is not that important and can be done later. Just an idea.
Regards, Enrico
Am 31.01.2012 01:30, schrieb Colomban Wendling:
Hey Nick, Matthew, Lex, Frank, Enrico, whoever cares,
https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64
FWIW, I find it a strange feature for an IDE. While it provides conviniences, I'm not sure it should be "core functionality". Perhaps a plugin would be a better fit?
Best regards.