Hi,
There are a couple of things I'm wondering about changing for the API:
1. Should we use underscores for struct names? E.g. _GeanyProject. I
know GTK uses this, but I've read in C programming books that tag names
with a leading underscore should not be used as the compiler uses them.
Also it looks a bit ugly. But I don't know if there is a portability
reason why GTK uses it.
2. Maybe we could add a 'geany' macro to pluginmacros.h that expands to
(*geany_data) - this could be used instead of adding macros for app,
prefs, etc. E.g. geany.app->configdir.
Regards,
Nick
Hi,
To fix the ABI problem described in my previous post, I've now replaced
doc_array with a GPtrArray. Whilst doing that I decided to rename it
documents_array, and the doc_list macro documents (for consistency
with filetypes_array). It wasn't possible to deprecate the doc_list
macro. The deprecated function macro documents is now removed
completely.
To fix outside plugins, I suggest doing the following:
1. Word-replace any use of the deprecated function macro documents with
p_document.
2. Do a regex replace for:
\<doc_list\[(\w+)\]\.
with:
documents[\1]->
3. Word-replace doc_array with documents_array.
I hope that the remaining API changes won't affect plugins so much.
For commit details, see:
http://geany.svn.sourceforge.net/geany/?rev=2624&view=rev
As usual, any comments, ideas, problems, etc, just let us know.
Regards,
Nick
Hi,
I've just discovered a problem - if we add any fields to GeanyDocument,
we have to break the ABI. This is because I used a GArray data
structure, and the doc_list macro indexes this based on the size of
GeanyDocument.
This is clearly a big problem, and the only solution seems to be to
use a GPtrArray instead. This will involve rewriting of every use of
the doc_list macro in all code :-/
Regards,
Nick
Hi,
The configure() symbol has been removed, replaced with plugin_configure
(), but *this works differently* from the old symbol. Examples of using
it are in the Demo, Autosave and File Browser plugins. For details, see:
http://geany.svn.sourceforge.net/geany/?rev=2621&view=rev
Regards,
Nick
Hi all,
I've now split up the GeanyApp struct with the new GeanyMainWidgets
struct (and renamed or moved a few fields), to allow us to
keep the plugin ABI stable without making the code difficult to
read/maintain.
For details, see:
http://geany.svn.sourceforge.net/geany/?rev=2609&view=rev
I'm hoping we can make all the major API changes (ones that affect
most plugins) before the 0.15 release. There are a few more I think are
worth doing:
1. Add a plugin_ prefix for plugin symbols like init(), cleanup(), etc.
2. Change the info() plugin function to allow for more PluginInfo
fields being added in future.
3. Change the configure() plugin function so that multiple/all plugins
can be configured at once from a common dialog.
4. Fix any obvious inconsistencies such as naming - this one is a bit
vague ;-)
If anyone has any comments/ideas about how to improve the API (without
too much porting needed), let us know.
Regards,
Nick
Hi all,
The function fields of the main API data struct GeanyData have now been
split into GeanyFunctions, so we can append new data fields without
breaking the ABI.
For plugins using pluginmacros.h, it should be quite simple to support
this change, probably just adding:
GeanyFunctions *geany_functions;
Also the p_encoding macro was renamed to p_encodings (but there's a
deprecated alias macro for this).
For details, see:
http://geany.svn.sourceforge.net/geany/?rev=2599&view=rev
Regards,
Nick
On Wed, 14 May 2008 08:46:49 -0700
eht16(a)users.sourceforge.net wrote:
> Revision: 2581
> http://geany.svn.sourceforge.net/geany/?rev=2581&view=rev
> Author: eht16
> Date: 2008-05-14 08:46:48 -0700 (Wed, 14 May 2008)
>
> Log Message:
> -----------
> Add new function document_set_indicator_on_line() for future use.
> Add some functions to the plugin API for the upcoming spell check
> plugin.
Hmm, maybe those indicator functions should be moved to editor.c - it
seems to me that the current API document functions are strongly
document related, like opening files or setting encoding of files.
Indicators might fit better as editor functionality. What do you
think?
Regards,
Nick
Hi
What do you think about 2 "Execute" commands instead of current 1:
1) execute cmd on file as if no project exists
2) execute cmd from "run_cmd" project field
I can write patch for it.
If you don't think this is great idea can I ask you to add "execute" command to plugin interface so I will be able implement such separation in geanyprj.
--
Yura Siamashka <yurand2(a)gmail.com>
Hi,
I've just merged some changes that should help to implement custom
filetype support (but this is still quite a long way off yet):
http://geany.svn.sourceforge.net/viewvc/geany?view=rev&revision=2559
The main things for plugin authors are:
Use filetypes_array->len instead of GEANY_MAX_FILE_TYPES.
GEANY_FILETYPES_ALL has been renamed GEANY_FILETYPES_NONE.
There's also a new function p_filetypes->lookup_by_name() which
replaces the old unique ID code.
I'm hoping this won't affect most plugins too much, as there are still
some deprecated macros for the first two changes mentioned above.
Any problems/ideas, just let us know ;-)
Regards,
Nick
Hi
While writting previous mail I start thinking about the following idea:
Provide all functions from "Keyboard shortcuts" to plugin interface using something like:
<function ptr> keybinding_get_function(const char section, const char name);
What do you think?
--
Yura Siamashka <yurand2(a)gmail.com>