Devel June 2008

devel@lists.geany.org

5 participants
9 discussions

New "populate-edit-menu" plugin signal
by Enrico Tröger 01 Jul '08

01 Jul '08

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

2 2

Geany-plugin-svn: Prefix with plugin name
by Frank Lanitz 23 Jun '08

23 Jun '08

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

5 12

ANN: document-pointer changes merged
by Nick Treleaven 18 Jun '08

18 Jun '08

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

1 0

API: headers / GeanyEditor / gint idx
by Nick Treleaven 13 Jun '08

13 Jun '08

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

2 7

Windows GTK 2.6 builds
by Enrico Tröger 10 Jun '08

10 Jun '08

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

2 3

Plugins build system
by Enrico Tröger 10 Jun '08

10 Jun '08

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

3 10

Re: [Geany-devel] SF.net SVN: geany: [2672] trunk
by Enrico Tröger 09 Jun '08

09 Jun '08

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

1 0

Configure checks for strstr and others
by Enrico Tröger 09 Jun '08

09 Jun '08

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

2 2

Alternative build system: Waf.
by Enrico Tröger 05 Jun '08

05 Jun '08

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

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel June 2008