Hi folks,
Unfortunately I didn't heard back of developer of
geany-mini-script-plugin so today I like to ask you whether somebody
likes to take over maintenance for geany-mini-script plugin inside
geany-plugins-svn. It's untouched since maybe 2009 and to be honest I
have no idea, what's the current status. Also I'm not 100% whether its
still a useful plugin or maybe some other plugin is taking over the
task in a better way. Personally I remember it as a possible useful
plugin but don't have the resources to look after and used it >>1 year
for the last time.
If nobody is feeling responsible I suggest, similar to previous plugins,
we remove it from official repository.
Cheers,
Frank
--
http://frank.uvena.de/en/
Hi Colomban,
RE your discussion on IRC about $subject
To save you searching, some info about g_spawn not working (right) on
windows, and that it won't be fixed:
http://article.gmane.org/gmane.editors.geany.devel/583
and it appears that it was always recognised that splitting on space
wasn't an elegant way of generating argv for windows, and the problems
that causes for filenames containing spaces, but nobody has been
concerned enough to fix it :) see:
http://lists.uvena.de/geany/2007-November/002082.html
There is no discussion on why windows commands were used in the first
place, but given the first reference above I guess it might still not
be possible to avoid it.
Cheers
Lex
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
Hi,
The subject pretty much explains it.
I have a couple theories why there's so many duplicates:
- SourceForge.net is kind of hard to use, especially searching
- No login required makes it "too easy" for people to quickly post
bug reports without thinking too much as soon as they experience a bug
Anyway, I just wanted to see if anybody had any ideas for how we could
minimize duplicate bug reports since it's a quite a pain to keep up with
the all the report as it is, especially with things like GTK+ bugs where
a distro upgrades their GTK+ and we get a pile of duplicate bugs about
the same non-Geany bugs.
Two recent examples come to mind:
- GTK+ file chooser dialog bug causes Geany to crash
- DBus menu bug causes console spam and non-functioning menus
Both of these had more than 3 or 4 duplicate bugs reported already, even
when some of the other duplicate reports were already on the first
screen you see before you post a bug. Both have been fixed in Git, but
bug reporters won't know this unless they first check for duplicates and
see that we've fixed it.
Ideas would be appreciated.
Cheers,
Matthew Brush