I try to code a small plugin that uses libxml2 to parse some data. I
searched a lot, but I don't understand how I can tell Geany that I want to
use that lib...
To compile my file, I use the following command lines :
gcc -o "output.o" -Wall -c -fpic "plugin.c" `pkg-config --cflags geany`
`pkg-config --cflags libxml-2.0`
for the shared library
gcc -shared -o "output.so" "output.o"
Thanks and best regards !
I started to write a plugin for auto-completion of haxe-code. The
Haxe compiler has a feature that it compiles up to a certain point
in a file and then spits out a list of possible classes and types
for the file at that point, see here:
There once was a plugin for using it called hxDev (latest version
But it doesn't compile with the newest plugin-API anymore. I couldn't
really figure out what to change and where to make it work, so I
tried to start from scratch. Thanks to your nice plugin-API and good
documentation of it I managed to get a running plugin in a couple of
days, although it's my very first attempt in GTK-programming.
Now I have a couple of questions:
- Would it make sense to add it to the geany-plugins repository
(because it's very language-specific)?
- I'm not sure what kind of build-system to use now. ATM I simply added
my plugin to wscript and use waf. Is waf deprecated now with the new
merged plugin-build-system? Is a makefile or a autogen.sh script
- The plugin depends on editor-notify of PluginCallback. Is it OK to
add that signal globally (will be called for all documents then,
right?) and then check for haxe-files or would it be better to add
that signal only when a haxe-file is active?
- I saw a property "type" in the GeanyProjects-struct that seems to
mean that projects can be extended by plugins. Is there some
documentation for this? It would be really nice to be able to add
some options for haxe-projects. I also read in a post here that there
is a build-system-upgrade in the making with lots of options that can
be set from projects. Maybe this would do already. Any plans when
this will be merged in the trunk?
Best regards and thanks for making this great editor.
I'm using the project feature of geany a lot and would like to suggest 2
1) After opening a project the file browser could jump to the base
directory of the project. I think the most people
use the file browser to select files *in* your project directory, so
it would be good to have that as a starting point..
2) A better support for alternative build systems was discussed here
sometimes... Is anyone working on this? What is the current status? When
working with projects, a global "make" command makes not really sense
anymore. I'm working with make , scons and waf projects, so it is very
hard to use a single "make" command for all of them.
Thanks for your work,
I have had a lot of problems with strange behavior for a couple of weeks. I
decided that the problems were related to the SVN merge of the build system
branch with trunk which seems not to have done what I had expected. Maybe
it was an update too far.
To "prove" this I checked out a truck (r3866) and copied some of my changes
into it. Success! No problems anywhere but in my code, but them I expect
I have continued with this basis and have continued to have success, so I
ask for someone with the permission to do, so please remove the current
build-system branch that appears to be massively broken and to make a new
one based on trunk r3866, that way I can just copy the changed files into a
checkout of the new branch and continue. Thanks in advance.
Currently I have both build dialog and project dialogs setting commands,
build menu created from them and am about to add save and restore in prefs
and projects, then will check it in as a prototype in the new branch. Oh
and most Latex special code gone, you won't recognise build.c.
On Sat, 20 Jun 2009 16:51:32 +0000
> Instantly reload (i.e. rebuild) the toolbar when ui_toolbar.xml is saved within Geany.
> Refactor some related code.
BTW, I know we're trying to save space, but should we show the Build
button by default? It's pretty useful, and it might confuse users to
only have the compile command visible (see the Valac sf.net bug
today I've got some news for i18n/l10n. After long discussion we finally
decided to create a big geany-plugins project for most common
plugins. For users, this step brings the advantage to have the main
plugins for Geany at one place and distributions can
provide one package including the most important plugins more easily.
For the translations process, we got the advantage to have a
centralised translation directory and global po files so each string
needs to be translated only once and will be available on each of the
plugins included into geany-plugins project.
During the creating of the new plugin structure we already merged all
existing translation into new created files so a start has been done.
Now it's our turn to improve and extend the translation so the first
release can be shipped with a good localisation as we do for Geany
itself. I'm aware that there needs some work to be done, but I'm 100%
sure its doable.
I've already updated the pot file as well as the po files of already
existing translation which you can find at
or by checking out from svn by
Some basic statistics can be found at http://i18n.geany.org/plugins/
As a deadline I'd like to include all new and updated translations
until Sundday night, June 28 so packaging can start early after.
Please don't hesitate to contact either me or the mailing list in case
of any questions regarding the translation.
Thanks and happy translating,
Hello Geany plugins developers,
Recently we've had some restructuring of the geany-plugins project,
whereby some plugins have been combined into a separate, geany-plugins
folder in the geany-plugins SVN. The plan is to release these plugins
together, synchronized somewhat with geany's release. As such, the first
version of the geany-plugins project will follow that of the current
version of Geany, i.e. 0.17. Currently, the plugins included in the
combined release are:
The autotools build system for these plugins which I've been working on
is more or less complete, save for perhaps some fine tuning of the
configure script to allow disabling individual plugins, and printing a
status report at the end of the configure script. If all goes well, we
should have a release pretty soon. I believe what's left is to have a
string freeze to allow translators to make sure the translations are in
Thanks everyone for helping to make this happen. =)
Chow Loong Jin