Re: [Geany-devel] [geany/geany] 7cc443: Don't append file truncation warning if file doesn't exist - incorrect for remote files
On 27/01/2012 21:36, Lex Trotman wrote: Anyway, I don't know how to improve the situation. My commit is necessary to avoid confusing users about truncation on a local file that doesn't even No, neither do I, but we do get complaints about truncated files on network shares/gvfs every so often, thats why we added the message. IIRC I added the message because of unexpected truncation of files on any FS that has run out of space. So this change actually prevents the message in its main use-case, where harm may have been done, in favour of a use-case where no harm has been done, and that is bad. Confusing the user is also harm. A (paranoid) user may worry some other file got truncated. When writing to a networked file I would expect users to take more notice of error messages, i.e. they should expect a save error might cause truncation. Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Opening unmounted GIO URIs
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 -- Get my GPG key from http://www.uvena.de/pub.asc pgp4jXh9lQVA4.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] [geany/geany] 7cc443: Don't append file truncation warning if file doesn't exist - incorrect for remote files
On Wed, Feb 1, 2012 at 4:14 AM, Nick Treleaven nick.trelea...@btinternet.com wrote: On 27/01/2012 21:36, Lex Trotman wrote: Anyway, I don't know how to improve the situation. My commit is necessary to avoid confusing users about truncation on a local file that doesn't even No, neither do I, but we do get complaints about truncated files on network shares/gvfs every so often, thats why we added the message. IIRC I added the message because of unexpected truncation of files on any FS that has run out of space. It doesn't actually matter what the initial trigger for adding it was, it also indicates harm in the remote case, and one of the (war and peace sized) ML threads was triggered by complaint about truncation of remote files IIRC. So this change actually prevents the message in its main use-case, where harm may have been done, in favour of a use-case where no harm has been done, and that is bad. Confusing the user is also harm. A (paranoid) user may worry some other file got truncated. Ok, better put the filename in the message then, but preventing the message in the case where it is probable that actual harm has been done is really bad. Cheers Lex When writing to a networked file I would expect users to take more notice of error messages, i.e. they should expect a save error might cause truncation. Nick ___ 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
Re: [Geany-devel] get build command from a plugin
On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Tue, 31 Jan 2012 15:39:52 +1100 Lex Trotman ele...@gmail.com wrote: Dimitar, Matthew, See git://github.com/elextr/geany.git, the more testing the better :) I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings: Well, it should be normal practice, thats what HACKING says, I just forgot to set it with a new clean clone, oops. Actually you should add -O2 because a couple of the warnings need the dataflow computation that the optimisation does. build.c: In function 'build_get_current_menu_item': build.c:576:2: warning: enumeration value 'GEANY_BC_CMDENTRIES_COUNT' not handled in switch [-Wswitch] build.c: In function 'build_set_menu_item': build.c:620:2: warning: enumeration value 'GEANY_BC_CMDENTRIES_COUNT' not handled in switch [-Wswitch] build.c:607:9: warning: unused variable 'str' [-Wunused-variable] These are probably harmless. Yes, stupid compiler can't see that there is a g_return_if_fail just before that limits fld to the range in the switch, fixed now anyway. build_get_current_menu_item() works, and returns the non-expanded values (%e, %f) as I expected. About returning NULL instead of for the empty fields, I'm not very sure. How do we separate a completely empty command with a valid cmd, such as the 3rd default C command, and an out-of-range cmd? The semantics of a command (well actually the label) that is vs NULL is important, a label hides commands from a lower priority source without showing itself in the menu, a NULL does not. So a for example a project that isn't using make could override the first make command with whatever it is using and hide the other two unused default make commands by setting the labels to . Unfortunately there isn't anthing else besides NULL that is sensible to return to indicate out of range. So I've exposed build_get_group_count() as well so you can get the count and then its your fault if you pass an out of range index :). Cheers Lex -- E-gards: Jimmy ___ 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
