Hi,
I just added a new signal for plugins: "populate-edit-menu".
The intended use is to modify or extend the editing menu (right-click
popup menu) before it is shown. The current word under the cursor, the
cursor position and a reference to the current document is passed to the
signal handler. So plugins have many information to perform some
actions. Usage example: I added this signal for the spellcheck plugin
where a "Spellcheck" menu item is added to the edit menu when the
cursor is above a misspelled word to provide a sub menu with
suggestions.
The more important thing is while adding the new code, I noticed the
function editor_find_current_word() wasn't Unicde-safe, this means when
the cursor is above a word containing Unicode characters (i.e. any
non-Ascii characters) the resulting string is wrong.
For Goto tag definition/declaration this isn't a big problem as these
are mainly plain Ascii. But it is also used e.g. for the Find dialogs
when the current word below the cursor is used as search word. This
badly fails with the old code.
So, I tried to fix it by explicitly allowing non-Ascii characters
which seems to work (SVN r2732).
I'm still not very happy with the current code. It allows also any
punctuation characters defined in Unicode. This is probably only a
small issue at least I don't think such are used widely.
A possible clean solution could be to read g_unichar's when searching
the word boundaries and check each g_unichar against the passed
wordchars and with e.g. g_unichar_isalnum().
But this still needs to be implemented. If anyone feels to do it,
patches are welcome :).
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi,
Since most of the Geany plugins were moved to the 'central' plugin
repository, I'd like to suggest to add the plugin name onto the commit
message in the first line. This would make it much easier for somebody
that is looking for a special commit than to have something like this:
r101: Compilation fixes
r102: Compilation fixes
r103: Compilation fixes
r104: Compilation fixes
With the prefix there would be something like that:
r101: Plugin A: Compilation fixes
r102: Plugin B: Compilation fixes
r103: Plugin C: Compilation fixes
r104: Plugin D: Compilation fixes
Opinions?
Cheers,
Frank
Hi,
We've just merged the document-pointer branch which removes all use of
document array indexes being passed to functions and signal callbacks.
Now a GeanyDocument* is used instead.
Normally you only need to check this against NULL, e.g. anytime you
check the result of a function call such as p_document->get_current().
If you're storing a document pointer over time and the user may have
closed that document, you can use the new DOC_VALID macro to check it's
still open. You shouldn't need this macro elsewhere - e.g. when
iterating over documents_array, just check documents[i]->is_valid to
see if it corresponds to an open document.
There is a new field GeanyDocument::index if you need to know where the
document is in the documents array, but this shouldn't really be needed.
DOC_IDX_VALID is now deprecated, as is a macro DOC_IDX which converts a
document pointer to an index in the documents array. It is better not
to use these and convert your code without them.
Some of the document functions have been renamed for clarity.
For details, check the updated API docs, and/or see:
http://geany.svn.sourceforge.net/geany/?rev=2705&view=rev
Regards,
Nick
Hi,
I've thought of some more plugin API changes to improve consistency
and/or organisation:
1. Make header names consistent - I've used ui_utils.h,
plugin-symbols.c - probably they should just be uiutils.h,
pluginsymbols.c.
2. Make editor functions take a GeanyEditor struct pointer. The editor
fields of GeanyDocument could be moved into a separate struct, as the
document struct is quite big, making it harder to locate fields. This
is also good for an object-based design.
3. The document functions could take/return a GeanyDocument pointer
instead of a document index, which would avoid the use of:
documents[idx]->
being repeated all over the code base when doc-> is much neater. We
would also need to update functions like msgwin_msg_add which take a
idx parameter (this seems to be the only one at first glance).
This could be quite a big change, so it could be brought in gradually
by having an additional p_documents field in GeanyFunctions, using a
documents_ prefix for the new functions instead of document_. Once the
changes are complete we could deprecate the old ones.
What do you think?
Regards,
Nick
Hi,
does anyone care about the Windows GTK 2.6 builds?
As you might know, the geany-$version_nogtk_setup.exe and
geany-$version_win32.zip files contain a geany.exe which is linked
against GTK 2.6 libs whereas geany-$version_setup.exe (full installer)
has a geany.exe which is linked against a recent GTK version which
runtime part is also included in the installer.
I was just testing something and accidentally screw up my gtk2.6 and
gtk2.12 folders (they got copied into each other, yay!). But it's a not
real problem at all.
But I'm anyway asking myself if it's necessary to provide all these
three files or if it weren't enough to provide only GTK 2.12 builds:
the full installer (everything included, ready to go) and the ZIP file
only including Geany itself for fast downloads.
Yes, this will stop Win9x support where GTK 2.12 doesn't run.
I'm just a little sick of compiling Geany on Windows every time two time
from scratch. This is necessary for the GTK major versions.
Only GTK 2.6 would mean no printing support on Windows and some minor
missing features. GTK 2.12 means no Windows 9x support.
Advantages:
- I will have more time to code instead of building Windows stuff
- less confusing download possibilities to Windows users
Disadvantages:
- we loose Windows 9x users (if there are any)
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hey,
some time ago, I played a little bit with autotools just to test about a
common build system for the plugins project.
First it was easier than I expected but it's still not working as I'd
wish.
Basically it's enough to create a simple configure.in and list the
plugins' makefiles in it. autogen.sh does the rest by walking any
subdirectories and init them if there is a configure.in is found.
Then the configure script is created in the top level directory and it
works fine, make will then build each plugin below.
So far it's pretty cool.
But once we want to include gettext support it's going to be tricky.
To get gettext support working, we need the GETTEXT_PACKAGE variable in
config.h, set by the configure script. And we need to create a
po/Makefile for each plugin. But both doesn't work with the top-level
configure script.
Each plugin uses the created config.h in the top-level directory
because in the plugin's directory there is none.
So GETTEXT_PACKAGE would be the same for all plugins.
We could simply skip all gettext support for the build system, then
most things are already done.
Or we use a global gettext infrastructure for all plugins and add
every source file to po/POTFILES.in. This would solve the problem and
had the advantage that translators need only one file to translate
containing the strings of all plugins.
The down side of this is that plugins loose their gettext support when
build alone or they have to manage a separate message catalog.
I also tried some experiements with some kind of a shared po directory
but all tries failed badly. Either I got build errors or endless loops
in make or even worse problems.
After all, I definetely won't work on a common build system based on
autotools. Maybe I just did something wrong, but it's to hard to find
out.
Two other suggestions:
a) use a simple Makefile in the top level directories which simply
iterates over plugins' directories and calls make && make install, if
necessary it calls configure before directly in the plugin's directory.
So, we would use the build system of each plugin and more or less just
iterate over available plugins.
This is easy to implement and should work. But you have to run
the configure script for each plugin at least everytime configure.in
has changed.
b) use another build system independent from plugins' build system. I'd
suggest Waf as I like it but maybe something else is better suited.
This could be realised quite clean and plugins doesn't need to be
changed but every none standard requirement of a single plugin (e.g.
library dependencies like aspell for the spellcheck plugin) has to be
maintained separately in this build system.
What do you think?
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
On Mon, 09 Jun 2008 10:43:49 -0700, eht16(a)users.sourceforge.net wrote:
> Modified: trunk/configure.in
> ===================================================================
> --- trunk/configure.in 2008-06-09 17:29:25 UTC (rev 2671)
> +++ trunk/configure.in 2008-06-09 17:43:48 UTC (rev 2672)
> @@ -230,6 +230,12 @@
> fi
> fi
>
> +# Set ${docdir} if it is empty
> +if test -z "${docdir}"; then
> + docdir='${datadir}/doc/${PACKAGE}'
> + AC_SUBST(docdir)
> +fi
> +
I've no idea why it can happen that $docdir isn't set but it actually
happened to an user on ASP 11.2 (should be based on Fedora).
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hey,
I was just thinking about to remove the configure checks for e.g.
strstr() or fgetpos() as these seem to be defined in the C89 standard
(according to their manpages on a Debian system).
I don't think we need to support any platforms which not even provide a
C89 compatible C library as probably Glib and GTK aren't available on
such platforms at all.
Furthermore, we already use strstr() in the Geany code without checks
and Scintilla uses strstr() also without checking.
And I'm not sure about the check for stdlib.h. Are there systems where
stdlib.h might not be available? At least is GLib and GTK available on
these systems?
According to
http://svn.gnome.org/viewvc/glib/trunk/configure.in?revision=6955&view=mark…,
GLib doesn't seem to check for strstr() and stdlib.h. So why should we?
What do you think?
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi,
in SVN r2646, I added support for an alternative build system to
configure and compile Geany's sources.
It's called Waf (http://code.google.com/p/waf/) and really nice ;-).
Short usage instructions:
Assuming a fresh SVN checkout:
1) ./waf configure
2) ./waf build
3) ./waf install
And you are done.
If you like fancy, coloured output and progress bars, replace step 2)
with:
./waf build -p
Waf requires Python 2.3, due to some extensions to the build script
(wscript) it actually needs Python 2.4 but I don't think this is a
problem.
Details:
This is not an attempt to remove or replace the autotools build system.
It is just an alternative. The autotools files keep being maintained in
future as well as Waf's wscript.
Why Waf?
It's great ;-). Some days ago, I read about Waf and had a looked at it.
Since this time, I fell in love with it and started to write the
wscript file for Geany.
Now let's get a little more technically :D.
Advantages:
- faster than autotools
- easier to use and understand
- no magic (!)
- more flexible
Disadvantages:
- equivalent of "make dist" is missing (it's actually there but is not
really unusable)
- maybe a little less portable
- need Python 2.4 (I guess almost every user on a mainstream Linux
distribution has it, so)
Waf's dist command is a little of the one of the autotools suite: it
includes everything in the source directory except some well known
files and a list of user-defined files. But this would make a lot of
work to create a list of all files to not include. Therefore, tarball
creation for releases should be done with the autotools suite, at least
for now.
At the moment, only the wscript (Python script with build instructions
for Geany) is included in EXTRA_DIST (used for release tarballs). If
you agree, I would like to add the waf script too. It increases the
tarball file size by about 80 KB.
There are still a few problems with the wscript, e.g. the dependency
handling of source files is not yet perfect but I'll work on this
within the next days. Anyway, it already works great in general, e.g.
building and installing the sources.
And it *should* also be possible to use both build systems side by side.
Every created or compiled file by Waf is stored in the a subdirectory
named "build". There are two exceptions: geany.desktop.in and
doc/Doxyfile. Everything else goes into build/default.
For those (like me) who are used to type configure && make && make
install, I wrote a little script wafinit.sh which creates a fake
configure script and a Makefile which actually only call the waf script
with the different actions.
configure.sh calls ./waf configure
make calls ./waf build
make install calls ./waf install
(some kind of wrapper just for convenience)
To use it, simply call once:
scripts/wafinit.sh
and the necessary configure and Makefile are created.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc