I just made a test build of Geany Plugins 1.22 for Windows.
A little surprisingly for me, it all worked fine on the first attempt :).
I only had problems loading the Geany-Lua plugin with some strange error
message which I didn't investigate yet:
The error message occurs on plugin loading. I'm not sure whether it is
caused by my system or something else.
If anyone wants to test it, any feedback is appreciated.
... requires an existing Geany 1.22 installation.
Get my GPG key from http://www.uvena.de/pub.asc
I want to say, that it would be nice, if a DocumentMap/MiniMap would be added to Geany. Please add it to the Wishlist on your side.
Notepad++ have something called "Document Map":
Sublime Text have something called "MiniMap":
Since some time, Kate have a MiniMap, too:
All three have a line, where with very small fonts a bigger part of the document is shown and the current visible part of the Textarea have a colored background in the map.
But they differ in additional functionality of it.
Where Sublime Text only shows the MiniMap, Kate on the other side, can replace the scrollbar with it. And on Notepad++ it is a mix between the two. The scrollbar is still there, but you can click in parts of the Document Map, to jump to that position.
An additional point I want to mention, is a bug in your Webside-software.
As I wanted to add this wish to the wishlist, I clicked at the bottom of the page on "edit this page" of the line "(If you have another idea/wish which should be listed here, edit this page)".
Then it asks for a username and password. Because I don't have an account for it, and I find no place to register, I have somewhat input. After that it shows be an empty page and Geany.org was no longer available.
I thought, it would be an coincidental/hazard/fortuity/hap, that that happens.
But now there was again Geany.org reachable, then I tried it again. And again the Geany-side was after that down. :-(
So please update your Geany homepage software. Or it is really a very big coincidental/hazard/fortuity/hap, that in two times the Geany side goes in that time down, I tried to login there.
I'm still working on proxy plugins, sorts of. I thought it would be
useful to give you an update. I first taken my proxy-plugin approach to
the final stages, and then went onto researching what we can do with
libpeas and gobject based approaches. Please feel free to discuss things
and/or contribute to my efforts.
In my last post I've followed the approach of proxy plugins, aka pluxys.
This approach is based on geanypy and implements a plugin API for
plugins to act as proxy. I have mostly finished that (including an
trivial example pluxy), and ported geanypy to this framework. The result
is that with this approach I was successfully able to load python
plugins with the core, including access to the plugin API, to the extend
that geanypy allows plus keybindings via a new (experimental) API call.
I think this should cover almost everything you would want for python
Since with that work you can successfully load python plugins I consider
this approach workable. The code is on my github repo. The code is still
in a proof-of-concept state with rough edges but I invite you to try it
out. If you maintainers want to consider this for merging into geany
proper then let's get this done, I'm all for it.
Now that the pluxy approach is in the final stages I went onto toying
Libpeas provides a nice interface for loadable plugins, both from the
core's and plugin's point of view. For the core, plugins written in
different language can be loaded through a unified interface. And
plugins can implement multiple plugin entry points for different
functionalities. Everything is based on gobject interfaces.
There are three areas of problems with libpeas before we can adapt it,
two of which I could already solve in a fork.
1) backward-compat: Libpeas is fundamentally based on describing plugin
metadata with a separate .ini-style file ($plugin.plugin). It cannot
load plain .so files on its own.
-> I solved this by extending the libpeas parser such that it can
parse the plugin description of Geany plugins, and generate a
PeasPluginInfo from it. This way we can load existing plugins before
they transitioned to the .plugin file.
2) backward-compat again: libpeas' existing C parser cannot load the C
plugins because they do not implement a gobject interface.
-> For this I wrote a trivial custom loader which instantiates a
"PeasGeany" interface instance (it has the traditional init(),
configure(), help(), cleanup() methods) on behalf of the existing plugins.
with 1 and 2 i have successfully loaded existing plugins with libpeas.
3) access to Geany's plugin API for non-C plugins (aka bindings).
-> This problem also applies to the plugin-proxy approach, except that
for that it is mostly solved for python with geanypy. Anyway
gobject-introspection provides a nice path to autogenerate language
bindings. However, geany's API currently isn't introspectible.
3) is the problem I'm currently stuck at. I think Matthew already had an
idea how we could possibly make it introspectible with little effort,
with the help of vala. If anyone has other ideas or comments please
So, I do plan to make libpeas fully work as 3) would ultimately also
help with the pluxy approach so it's a good idea regardless. Then we can
have a look which of the approaches we want to merge for geany (if any (?)).
I want to let you knows know that glade upstream just merged my
backports for the "topological sorting algorithm" into glade-3-8 branch.
This means that we can now use upstream glade for our geany.glade as the
major outstanding deficiency is fixed: it now sorts the generated xml in
a predictable and stable manner, suitable for diff-review and probably
git merges too.
The backports should appear in 3.8.5 if you'd like to wait for a realease.
I would like to contribute to Geany by submitting additional license
headers and some more file templates like what would be found under
/usr/share/geany/templates. I have already made some license headers and
file templates. Would the Geany developers be interested in them? If so,
then where would be the best place to send them? Would the destination
like them as a zip, tarball, etc? Does this mailing list use bottom
posting or top posting?
Devyn Collier Johnson
I'm very wondered how does "smart indentation" feature work. If previous line
is empty, it removes indent assuming that single empty line is an empty indent.
Smart indentation for multiple lines is absolutely awful: it doesn't take into
account internal sub-indents and makes selection "flat".
Is anybody using this?
Under "smart" indentation people assume astyle, php-beautifier and so on:
Pavel Roschin aka RPG
Somehow we are in bad luck with hdd serving our environment. However:
One of the hard disks in the server where geany.org is hosted recently
showed up some errors and so we will change the disk against a new one
just to be prevent a complete failure in advance.
This maintenance is planned for upcoming Saturday, July 26 2014.
Therefore the server and its services will be down for a
short period of time.
The following services will be affected:
- all mailing lists
- websites *.geany.org (except plugins.geany.org)
- Updatechecker plugin
Saturday, July 26 2014
7:00 - 12:00 UTC
I'll report back here once all is done and up running again.
I have try to download Geany source code and I'm aware of geany glade
file which made up the UI. But, I can't load this file on the
__latest__ glade editor either with GTK+2 or GTK+3 glade. Is this
requare some specific setting? Or is the glade file edited by hand
manually (wonderful if so)?
based up on Matthew's fine GtkActions branch  I think we could
realistically rewrite keybindings.c use GtkAction/accelerators properly.
Currently it re-implements lots of gtk stuff, such as the actual looping
through the known keybindings for the callback when a keybinding
pressed. When this would be rewritten keybindings.c could probably be
half as large (in LOC terms).
The advantage of doing so would be that plugins could register
keybindings simply by providing a GtkAction instance (and optionally a
GtkMenuItem) instead of a plain callback. This would enable to handle
keybindings in a more natural (from a glib/gtk POV) form through
signals. This is especially interesting for non-C plugins because it
easier to support/implement a gobject-based API then a
function-pointer-based one. This is the major reason I'm interested in this.
I think it is possible to do this without breaking the API or at least
without actual damage because plugins don't use the fields of
GeanyKeyGroup and GeanyKeyBinding so we can change these structs.
Is such a rewrite desirable, and would it have a realistic chance of
getting merged? I'm asking because I don't want to spend time on this
and never get it merged. Otherwise I would volunteer to do this.