Frank and others,
Is there something that describes how to go about adding a plugin to geany-plugins? That describes the build system requirements for non-autotools experts etc.
I couldn't find anything.
Cheers Lex
I also am curious, as I'd like to add my plugins, but so far they have their own make files. I was told to get on IRC and talk it out, but I haven't gotten to it yet, so a tutorial may be a more convenient option :-)
________________________________ From: Lex Trotman elextr@gmail.com To: Geany development list devel@lists.geany.org Sent: Friday, June 7, 2013 11:51 PM Subject: [Geany-Devel] Adding a plugin
Frank and others,
Is there something that describes how to go about adding a plugin to geany-plugins? That describes the build system requirements for non-autotools experts etc.
I couldn't find anything.
Cheers Lex _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Fri, 7 Jun 2013 23:03:24 -0700 (PDT) Steven Blatnick steve8track@yahoo.com wrote:
I also am curious, as I'd like to add my plugins, but so far they have their own make files. I was told to get on IRC and talk it out, but I haven't gotten to it yet, so a tutorial may be a more convenient option :-)
Please check HACKING from G-P-source-tree or e.g. at https://github.com/geany/geany-plugins/blob/master/HACKING
Cheers, Frank
On 13-06-07 10:51 PM, Lex Trotman wrote:
Frank and others,
Is there something that describes how to go about adding a plugin to geany-plugins? That describes the build system requirements for non-autotools experts etc.
I couldn't find anything.
The HACKING file has some good project information:
https://github.com/geany/geany-plugins/blob/master/HACKING
A must-read:
http://www.geany.org/manual/reference/howto.html
A must-use:
http://www.geany.org/manual/reference/
And then a good place to plop more know-how:
http://wiki.geany.org/plugins/development
And then of course there's the build system wizards who frequent the #geany IRC channel and this mailing list.
Cheers, Matthew Brush
On 8 June 2013 16:25, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-06-07 10:51 PM, Lex Trotman wrote:
Frank and others,
Is there something that describes how to go about adding a plugin to geany-plugins? That describes the build system requirements for non-autotools experts etc.
I couldn't find anything.
The HACKING file has some good project information:
https://github.com/geany/**geany-plugins/blob/master/**HACKINGhttps://github.com/geany/geany-plugins/blob/master/HACKING
"for non autotools experts" I said, that includes not knowing how to program in m4 :-)
Unless you are telling me just cut and paste of the code fragments in hacking is all thats needed?
Cheers Lex
On Sat, Jun 08, 2013 at 05:59:51PM +1000, Lex Trotman wrote:
[...] "for non autotools experts" I said, that includes not knowing how to program in m4 :-)
Unless you are telling me just cut and paste of the code fragments in hacking is all thats needed?
Actually cutting and pasting the code fragments in HACKING should be enough for most cases. There are also plenty of examples (other plugins) to look at if anything extra needs to be done.
On 06/08/2013 02:31 AM, Chow Loong Jin wrote:
On Sat, Jun 08, 2013 at 05:59:51PM +1000, Lex Trotman wrote:
[...] "for non autotools experts" I said, that includes not knowing how to program in m4 :-)
Unless you are telling me just cut and paste of the code fragments in hacking is all thats needed?
Actually cutting and pasting the code fragments in HACKING should be enough for most cases. There are also plenty of examples (other plugins) to look at if anything extra needs to be done.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
The example below is what I came up with after a few minutes checking out your documentation.
It didn't take me long to create this basic plugin. However, I reserve the right to bitch about the level of documentation for the data types GeanyPlugin, GeanyData and GeanyFunctions, although GeanyFunctions seems really transparent, just exposing Geany functions (maybe thats how its file name was decided).
As a nit, I don't understand why the plugin_init function is passed the GeanyData parameter. Seems superfluous to me. Note that I ignore it in the example, and in all plugins I've written to date. Is it not the same as the global *geany_data? If not, then I'd say that needs documentation.
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
---------------- main.cpp ----------------------------- /* * http://www.geany.org/manual/reference/ * http://www.geany.org/manual/reference/howto.html * http://www.geany.org/manual/reference/guidelines.html */
#include <geanyplugin.h>
GeanyPlugin *geany_plugin; GeanyData *geany_data; GeanyFunctions *geany_functions;
PLUGIN_VERSION_CHECK(211)
PLUGIN_SET_INFO("Hello World", "Just another tool to say hello world", "1.0", "Joe Doe joe.doe@example.org");
extern "C" void plugin_init(GeanyData *) { }
extern "C" void plugin_cleanup(void) { }
------------ makefile -----------------------------
debug/helloworld.so: debug/main.o @echo Creating library @gcc -o debug/helloworld.so -shared `pkg-config --libs geany` debug/main.o
debug/main.o: ../src/main.cpp @echo debug/main.o @g++ -o debug/main.o -c ../src/main.cpp -I../src -std=gnu++0x -fPIC `pkg-config --cflags geany` -g -ggdb -ggdb3 -ansi -W -Wall -Wundef -O2 -MT debug/main.o -MF debug/main.o.d -MMD -include debug/main.o.d
On Sat, 08 Jun 2013 02:54:38 -0700 Roger Booth rbooth@kabooth.com wrote:
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
A lot of functions have a note at Geany's API documentation, since which version of Geany they are avaialble. E.g. Since: 0.16 at utils_str_casecmp(). At http://wiki.geany.org/plugins/development/api-versions you can find also the connection between API and ABI as well as the corresponding Geany version.
Cheers, Frank
On 06/08/2013 03:02 AM, Frank Lanitz wrote:
On Sat, 08 Jun 2013 02:54:38 -0700 Roger Booth rbooth@kabooth.com wrote:
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
A lot of functions have a note at Geany's API documentation, since which version of Geany they are avaialble. E.g. Since: 0.16 at utils_str_casecmp(). At http://wiki.geany.org/plugins/development/api-versions you can find also the connection between API and ABI as well as the corresponding Geany version.
Cheers, Frank
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
I guess what I was asking for was a note in the docs that talk about writing plugins, and especially in the docs about PLUGIN_VERSION_CHECK() that points to where the programmer can read up on the connection between api and abi. Or at least how the programmer can find out the number.
Its great that you tell me here, and I know that somewhere in my mail history I have the info as well, but wouldn't it be better to put the info at the location where it helps the the programmer that is about to add a PLUGIN_VERSION_CHECK() to a plugin? That was an issue for me, and adding the references to the location where I was looking would have helped me.
But beyond that, let me understand. What I do when writing a plugin is I keep track of the least value of x.yy in "Since: x.yy" for every function I use from the Geany API. Then I look at the URL you listed to find x.yy and cross reference it to an abi number. And that abi number is the number I plug in to the PLUGIN_VERSION_CHECK() macro. Is that how this works? If that is so, again, maybe it would be nice to document the manual procedure programmers should follow.
Your initial post in this thread asked
Is there something that describes how to go about adding a plugin to geany-plugins?
It sounded to me like you wanted to know about issues folks had writing plugins. Well, I'm listing issues I have had writing Geany plugins.
On 8 June 2013 20:31, Roger Booth rbooth@kabooth.com wrote:
On 06/08/2013 03:02 AM, Frank Lanitz wrote:
On Sat, 08 Jun 2013 02:54:38 -0700 Roger Booth rbooth@kabooth.com rbooth@kabooth.com wrote:
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
A lot of functions have a note at Geany's API documentation, since which version of Geany they are avaialble. E.g. Since: 0.16 at utils_str_casecmp(). At http://wiki.geany.org/plugins/development/api-versions you can find also the connection between API and ABI as well as the corresponding Geany version.
Cheers, Frank
Devel mailing listDevel@lists.geany.orghttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
I guess what I was asking for was a note in the docs that talk about writing plugins, and especially in the docs about PLUGIN_VERSION_CHECK() that points to where the programmer can read up on the connection between api and abi. Or at least how the programmer can find out the number.
Its great that you tell me here, and I know that somewhere in my mail history I have the info as well, but wouldn't it be better to put the info at the location where it helps the the programmer that is about to add a PLUGIN_VERSION_CHECK() to a plugin? That was an issue for me, and adding the references to the location where I was looking would have helped me.
But beyond that, let me understand. What I do when writing a plugin is I keep track of the least value of x.yy in "Since: x.yy" for every function I use from the Geany API. Then I look at the URL you listed to find x.yy and cross reference it to an abi number. And that abi number is the number I plug in to the PLUGIN_VERSION_CHECK() macro. Is that how this works? If that is so, again, maybe it would be nice to document the manual procedure programmers should follow.
It might be just a typo on your part, but it is the biggest A*P*I number you get from the table that you plug into the version check. You don't do anything with the ABI number, its automatic.
Or to be more realistic, plug in the API number of the geany you are developing your plugin against. If you are using a function that is too new for the Geany you are using you will get a compilation error. So simply use the oldest version of Geany you want the plugin to work for and sit back and let the compiler take the strain :)
If you develop with a new version of Geany, then only when you are *sure* your plugin is finished should you consider looking for the oldest version of API that will work, therefore defining the oldest version of Geany that will work. But due to the unfortunate changes of ABI that have happened every few versions, people will have to compile your plugin themselves to use older Geany versions, so your audience is narrowed significantly (those who use an older Geany but are willing to compile plugins). It is not possible to use a precompiled plugin with a version of Geany that has a different ABI, even if the API is ok.
Your initial post in this thread asked
Is there something that describes how to go about adding a plugin togeany-plugins?
It sounded to me like you wanted to know about issues folks had writing plugins. Well, I'm listing issues I have had writing Geany plugins.
Actually I wanted to know how to add them to the g-p build system, rather than just plugins in general, since I havn't done anything g-p before :)
Since various people claim its just copying the examples in the docs I'll see tomorrow :)
But thanks for the feedback that it isn't clear how best to use the API/ABI versions, thats the sort of info the experts need if they are to be able to improve the docs.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 06/08/2013 04:13 AM, Lex Trotman wrote:
On 8 June 2013 20:31, Roger Booth <rbooth@kabooth.com mailto:rbooth@kabooth.com> wrote:
On 06/08/2013 03:02 AM, Frank Lanitz wrote:On Sat, 08 Jun 2013 02:54:38 -0700 Roger Booth<rbooth@kabooth.com> <mailto:rbooth@kabooth.com> wrote:One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)A lot of functions have a note at Geany's API documentation, since which version of Geany they are avaialble. E.g. Since: 0.16 at utils_str_casecmp(). Athttp://wiki.geany.org/plugins/development/api-versions you can find also the connection between API and ABI as well as the corresponding Geany version. Cheers, Frank _______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/develI guess what I was asking for was a note in the docs that talk about writing plugins, and especially in the docs about PLUGIN_VERSION_CHECK() that points to where the programmer can read up on the connection between api and abi. Or at least how the programmer can find out the number. Its great that you tell me here, and I know that somewhere in my mail history I have the info as well, but wouldn't it be better to put the info at the location where it helps the the programmer that is about to add a PLUGIN_VERSION_CHECK() to a plugin? That was an issue for me, and adding the references to the location where I was looking would have helped me. But beyond that, let me understand. What I do when writing a plugin is I keep track of the least value of x.yy in "Since: x.yy" for every function I use from the Geany API. Then I look at the URL you listed to find x.yy and cross reference it to an abi number. And that abi number is the number I plug in to the PLUGIN_VERSION_CHECK() macro. Is that how this works? If that is so, again, maybe it would be nice to document the manual procedure programmers should follow.It might be just a typo on your part, but it is the biggest A*P*I number you get from the table that you plug into the version check. You don't do anything with the ABI number, its automatic.
Or to be more realistic, plug in the API number of the geany you are developing your plugin against. If you are using a function that is too new for the Geany you are using you will get a compilation error. So simply use the oldest version of Geany you want the plugin to work for and sit back and let the compiler take the strain :)
If you develop with a new version of Geany, then only when you are *sure* your plugin is finished should you consider looking for the oldest version of API that will work, therefore defining the oldest version of Geany that will work. But due to the unfortunate changes of ABI that have happened every few versions, people will have to compile your plugin themselves to use older Geany versions, so your audience is narrowed significantly (those who use an older Geany but are willing to compile plugins). It is not possible to use a precompiled plugin with a version of Geany that has a different ABI, even if the API is ok.
Your initial post in this thread asked Is there something that describes how to go about adding a plugin to geany-plugins? It sounded to me like you wanted to know about issues folks had writing plugins. Well, I'm listing issues I have had writing Geany plugins.Actually I wanted to know how to add them to the g-p build system, rather than just plugins in general, since I havn't done anything g-p before :)
Since various people claim its just copying the examples in the docs I'll see tomorrow :)
But thanks for the feedback that it isn't clear how best to use the API/ABI versions, thats the sort of info the experts need if they are to be able to improve the docs.
Cheers Lex
_______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
From the Geany plugin website at http://www.geany.org/manual/reference/plugindata_8h.html#a68c850fc7108c65909...
==================================================== #define PLUGIN_VERSION_CHECK ( api_required )
*Value:*
gintplugin_version_check http://www.geany.org/manual/reference/pluginsymbols_8c.html#a02238186945c26ea04e20410daf5b209(gint abi_ver) \ { \ if (abi_ver !=GEANY_ABI_VERSION http://www.geany.org/manual/reference/plugindata_8h.html#a81ace29a6d7fb7cce2b59100fe3f6d71) \ return -1; \ return (api_required); \ }
Defines a function to check the plugin is safe to load.
This performs runtime checks that try to ensure:
* Geany ABI data types are compatible with this plugin. * Geany sources provide the required API for this plugin.
*Parameters:*
/api_required/ The minimum API number your plugin requires. Look at the source for the value of |GEANY_API_VERSION| to use if you want your plugin to require the current Geany version on your machine. You should update this value when using any new API features.
====================================================== The above documentation is crap.
First, note that the macro definition describes the parameter as abi_ver. So, according to the documentation, where does the sole parameter - abi_ver - come from?
So we can skip the test if(abi_ver blah blah) unless somebody can answer the above question.
So that leads to the last line of code that generates stuff: return api_required;
I eliminated superfluous parens.
As documented, this macro returns what it is passed.
And you wonder why I'm confused?
BTW, this one is
*Since:* 0.19
[...]
From the Geany plugin website at
http://www.geany.org/manual/reference/plugindata_8h.html#a68c850fc7108c65909...
==================================================== #define PLUGIN_VERSION_CHECK ( api_required ) *Value:*
gint plugin_version_check http://www.geany.org/manual/reference/pluginsymbols_8c.html#a02238186945c26ea04e20410daf5b209(gint abi_ver) \ { \ if (abi_ver != GEANY_ABI_VERSION http://www.geany.org/manual/reference/plugindata_8h.html#a81ace29a6d7fb7cce2b59100fe3f6d71) \ return -1; \ return (api_required); \ }
Defines a function to check the plugin is safe to load.
This performs runtime checks that try to ensure:
- Geany ABI data types are compatible with this plugin.
- Geany sources provide the required API for this plugin. *Parameters:*
*api_required* The minimum API number your plugin requires. Look atthe source for the value of GEANY_API_VERSION to use if you want your plugin to require the current Geany version on your machine. You should update this value when using any new API features.
====================================================== The above documentation is crap.
Which isn't a very helpful comment.
First, note that the macro definition describes the parameter as abi_ver. So, according to the documentation, where does the sole parameter - abi_ver
- come from?
The macro is defining a function, so the parameter comes from the caller of that function, ie Geany, so you don't need to know about it. So it isn't described.
So we can skip the test if(abi_ver blah blah) unless somebody can answer the above question.
The macro will generate the test, which *IS* required to prevent plugins with the wrong ABI being used. A plugin which uses the wrong ABI may cause crashes, so if its wrong it will return -1 and Geany will not run that plugin. This is all transparent to you, the plugin writer, just provide api_required to the macro.
So that leads to the last line of code that generates stuff: return api_required;
I eliminated superfluous parens.
As documented, this macro returns what it is passed.
Only *IF* the abi matches.
And you wonder why I'm confused?
BTW, this one is *Since:* 0.19
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 06/09/2013 03:42 AM, Lex Trotman wrote:
[...]
From the Geany plugin website at http://www.geany.org/manual/reference/plugindata_8h.html#a68c850fc7108c65909f4340da8c16df9 ==================================================== #define PLUGIN_VERSION_CHECK ( api_required ) *Value:* gintplugin_version_check <http://www.geany.org/manual/reference/pluginsymbols_8c.html#a02238186945c26ea04e20410daf5b209>(gint abi_ver) \ { \ if (abi_ver !=GEANY_ABI_VERSION <http://www.geany.org/manual/reference/plugindata_8h.html#a81ace29a6d7fb7cce2b59100fe3f6d71>) \ return -1; \ return (api_required); \ } Defines a function to check the plugin is safe to load. This performs runtime checks that try to ensure: * Geany ABI data types are compatible with this plugin. * Geany sources provide the required API for this plugin. *Parameters:* /api_required/ The minimum API number your plugin requires. Look at the source for the value of |GEANY_API_VERSION| to use if you want your plugin to require the current Geany version on your machine. You should update this value when using any new API features. ====================================================== The above documentation is crap.Which isn't a very helpful comment.
First, note that the macro definition describes the parameter as abi_ver. So, according to the documentation, where does the sole parameter - abi_ver - come from?The macro is defining a function, so the parameter comes from the caller of that function, ie Geany, so you don't need to know about it. So it isn't described.
So we can skip the test if(abi_ver blah blah) unless somebody can answer the above question.The macro will generate the test, which *IS* required to prevent plugins with the wrong ABI being used. A plugin which uses the wrong ABI may cause crashes, so if its wrong it will return -1 and Geany will not run that plugin. This is all transparent to you, the plugin writer, just provide api_required to the macro.
So that leads to the last line of code that generates stuff: return api_required; I eliminated superfluous parens. As documented, this macro returns what it is passed.Only *IF* the abi matches.
And you wonder why I'm confused? BTW, this one is *Since:* 0.19 _______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
I described exactly what the reader of your documentation would glean from reading said documentation. Who cares what is the implementation behind the documentation? Oh, I forget. You do. But me? I want to know how to use it.
I assume you are surprised by this. How dare the user of our docs not study to great lengths the implementations of the shit we (and others that have come before us) have produced. Nobody should have the effrontery to attempt to interface our code without spending a sufficient amount of time appreciating the edifice we have erected.
Sorry, I forgot to genuflect.
On Sun, 09 Jun 2013 03:54:05 -0700 Roger Booth rbooth@kabooth.com wrote:
I assume you are surprised by this. How dare the user of our docs not study to great lengths the implementations of the shit we (and others that have come before us) have produced. Nobody should have the effrontery to attempt to interface our code without spending a sufficient amount of time appreciating the edifice we have erected.
Please don't be a party-puper. Geany is FLOSS and everybody is welcome to improve ... also the documentation. You recognized that the documentation might not be clear in all cases. .. yepp. That's true. But it's hard to find such things for somebody who knows the code from deep inside the heard that Geany-Version -> API-Version -> ABI-Version. so no need to document it for them. Please take a look at github and improve the parts of documentation. Complaining on the mailing list that the whole documentation suckz just is making people spending a lot of spare time sad and sending them into aggro-mode.
Would be really happy to see a patch improving that aspect from documentation as well as the Plugin-HowTo.
cheers, Frank
On 06/09/2013 04:48 AM, Frank Lanitz wrote:
On Sun, 09 Jun 2013 03:54:05 -0700 Roger Booth rbooth@kabooth.com wrote:
I assume you are surprised by this. How dare the user of our docs not study to great lengths the implementations of the shit we (and others that have come before us) have produced. Nobody should have the effrontery to attempt to interface our code without spending a sufficient amount of time appreciating the edifice we have erected.
Please don't be a party-puper. Geany is FLOSS and everybody is welcome to improve ... also the documentation. You recognized that the documentation might not be clear in all cases. .. yepp. That's true. But it's hard to find such things for somebody who knows the code from deep inside the heard that Geany-Version -> API-Version -> ABI-Version. so no need to document it for them. Please take a look at github and improve the parts of documentation. Complaining on the mailing list that the whole documentation suckz just is making people spending a lot of spare time sad and sending them into aggro-mode.
Would be really happy to see a patch improving that aspect from documentation as well as the Plugin-HowTo.
cheers, Frank
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
I have submitted patches before and I will be happy to provide patches for this. Thank you for asking. Guess that was what I was asking for.
On 06/09/2013 04:48 AM, Frank Lanitz wrote:
On Sun, 09 Jun 2013 03:54:05 -0700 Roger Booth rbooth@kabooth.com wrote:
I assume you are surprised by this. How dare the user of our docs not study to great lengths the implementations of the shit we (and others that have come before us) have produced. Nobody should have the effrontery to attempt to interface our code without spending a sufficient amount of time appreciating the edifice we have erected.
Please don't be a party-puper. Geany is FLOSS and everybody is welcome to improve ... also the documentation. You recognized that the documentation might not be clear in all cases. .. yepp. That's true. But it's hard to find such things for somebody who knows the code from deep inside the heard that Geany-Version -> API-Version -> ABI-Version. so no need to document it for them. Please take a look at github and improve the parts of documentation. Complaining on the mailing list that the whole documentation suckz just is making people spending a lot of spare time sad and sending them into aggro-mode.
Would be really happy to see a patch improving that aspect from documentation as well as the Plugin-HowTo.
cheers, Frank
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
But if I'm going to *improve* the docs, I *still* have an outstanding (in a manner of speaking) question:
Why does the function plugin_init() accept the one parameter GeanyData*?
The reason that is a question is that the three global variables
GeanyPlugin *geany_plugin; GeanyData *geany_data; GeanyFunctions *geany_functions;
are available to a plugin and you will notice that one of those global variables is geany_data which is suspiciously similar to the parameter to plugin_init().
So either there is no reason to pass the parameter to plugin_init() or there is a good reason to pass the parameter to plugin_init().
Either way, I'd like to know. Maybe others would to.
A previous reply from Matthew Brush made me think that I need to really spell out what I mean here. Say I have the following
GeanyData *geany_data; extern "C" void plugin_init(GeanyData *bob) { if(*geany_data == *bob) { exit(1); } else { exit(2); } }
What I'm trying to ask by this example, and remember, I'm a moron, is
'is geany_data the same as bob?'
Please don't get all wishy-washy on me here. geany_data and bob are both pointers. My question is
Do bob and geany_data point to the same location in memory.
Now you could all say "geez, moron, just do a comparison". I know how to do that. But that would only say that this version is blah. What I want to know is about API guarantees. I want to be able to document the plugin_init() function and say
geany_data == bob
or not.
P.S.
Complaining on the mailing list that the whole documentation suckz
Um, I was commenting on one macro for the plugin API. Actually, I think in general the docs are superb. I want to improve the areas where I see they can be improved, and I volunteer to do so and have already done so. What pissed me off was my impression that yall thought this particular area of the docs was just peachy and I was just blowing smoke.
[...]
But if I'm going to *improve* the docs, I *still* have an outstanding (in a manner of speaking) question:
Why does the function plugin_init() accept the one parameter GeanyData*?
The reason that is a question is that the three global variables
GeanyPlugin *geany_plugin; GeanyData *geany_data; GeanyFunctions *geany_functions;
are available to a plugin and you will notice that one of those global variables is geany_data which is suspiciously similar to the parameter to plugin_init().
Yes it is the same.
So either there is no reason to pass the parameter to plugin_init() or there is a good reason to pass the parameter to plugin_init().
Since it is generally acknowledged that globals are bad, possibly someone started the process of removing the globals by switching to passing as parameters, but did not get time to finish the process or ran into other problems, but there is no indication I can find of why its that way.
[...]
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 06/09/2013 07:18 AM, Lex Trotman wrote:
[...]
But if I'm going to *improve* the docs, I *still* have an outstanding (in a manner of speaking) question:
Why does the function plugin_init() accept the one parameter GeanyData*? The reason that is a question is that the three global variables GeanyPlugin *geany_plugin; GeanyData *geany_data; GeanyFunctions *geany_functions; are available to a plugin and you will notice that one of those global variables is geany_data which is suspiciously similar to the parameter to plugin_init().Yes it is the same.
So either there is no reason to pass the parameter to plugin_init() or there is a good reason to pass the parameter to plugin_init().Since it is generally acknowledged that globals are bad, possibly someone started the process of removing the globals by switching to passing as parameters, but did not get time to finish the process or ran into other problems, but there is no indication I can find of why its that way.
[...]Cheers Lex
_______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
So when I document plugin_init(), you are OK with me saying that the developer can use the global variable geany_data interchangeably with the parameter to plugin_init(), and this behavior will not change until -- gee, is this when the ABI changes?
On 10 June 2013 00:43, Roger Booth rbooth@kabooth.com wrote:
On 06/09/2013 07:18 AM, Lex Trotman wrote:
[...]
But if I'm going to *improve* the docs, I *still* have an outstanding (in a manner of speaking) question:
Why does the function plugin_init() accept the one parameter GeanyData*?
The reason that is a question is that the three global variables
GeanyPlugin *geany_plugin; GeanyData *geany_data; GeanyFunctions *geany_functions;
are available to a plugin and you will notice that one of those global variables is geany_data which is suspiciously similar to the parameter to plugin_init().
Yes it is the same.
So either there is no reason to pass the parameter to plugin_init() or there is a good reason to pass the parameter to plugin_init().
Since it is generally acknowledged that globals are bad, possibly someone started the process of removing the globals by switching to passing as parameters, but did not get time to finish the process or ran into other problems, but there is no indication I can find of why its that way.
[...]
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing listDevel@lists.geany.orghttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
So when I document plugin_init(), you are OK with me saying that the developer can use the global variable geany_data interchangeably with the parameter to plugin_init(), and this behavior will not change until -- gee, is this when the ABI changes?
Yes that would be an ABI change, and an API change.
I am not aware of anyone proposing to change this at the moment, so you should be ok.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 06/09/2013 07:59 AM, Lex Trotman wrote:
On 10 June 2013 00:43, Roger Booth <rbooth@kabooth.com mailto:rbooth@kabooth.com> wrote:
On 06/09/2013 07:18 AM, Lex Trotman wrote:[...] But if I'm going to *improve* the docs, I *still* have an outstanding (in a manner of speaking) question: Why does the function plugin_init() accept the one parameter GeanyData*? The reason that is a question is that the three global variables GeanyPlugin *geany_plugin; GeanyData *geany_data; GeanyFunctions *geany_functions; are available to a plugin and you will notice that one of those global variables is geany_data which is suspiciously similar to the parameter to plugin_init(). Yes it is the same. So either there is no reason to pass the parameter to plugin_init() or there is a good reason to pass the parameter to plugin_init(). Since it is generally acknowledged that globals are bad, possibly someone started the process of removing the globals by switching to passing as parameters, but did not get time to finish the process or ran into other problems, but there is no indication I can find of why its that way. [...] Cheers Lex _______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/develSo when I document plugin_init(), you are OK with me saying that the developer can use the global variable geany_data interchangeably with the parameter to plugin_init(), and this behavior will not change until -- gee, is this when the ABI changes?Yes that would be an ABI change, and an API change.
I am not aware of anyone proposing to change this at the moment, so you should be ok.
Cheers Lex
_______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
I thought you wanted me to propose enhancements to the documentation of the plugin API. If that is what we are talking about, then we are not talking about whether I am OK or not. What we are discussing is the defined API.
What I am asking is...
Is it a defined fact that the global variable geany_data and the parameter to the plugin_init() function can be used interchangeably?
Do the Geany developers swear on a stack of paper that this will not change until it does, and when it does, the docs will be changed to reflect that change and plugins will be given time (versions) to change behavior accordingly?
Is this the official position of the Geany developers?
Otherwise, what good is anything said here?
On 06/09/2013 04:48 AM, Frank Lanitz wrote:
On Sun, 09 Jun 2013 03:54:05 -0700 Roger Booth rbooth@kabooth.com wrote:
I assume you are surprised by this. How dare the user of our docs not study to great lengths the implementations of the shit we (and others that have come before us) have produced. Nobody should have the effrontery to attempt to interface our code without spending a sufficient amount of time appreciating the edifice we have erected.
Please don't be a party-puper. Geany is FLOSS and everybody is welcome to improve ... also the documentation. You recognized that the documentation might not be clear in all cases. .. yepp. That's true. But it's hard to find such things for somebody who knows the code from deep inside the heard that Geany-Version -> API-Version -> ABI-Version. so no need to document it for them. Please take a look at github and improve the parts of documentation. Complaining on the mailing list that the whole documentation suckz just is making people spending a lot of spare time sad and sending them into aggro-mode.
Would be really happy to see a patch improving that aspect from documentation as well as the Plugin-HowTo.
cheers, Frank
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Me? party-puper? Not! :-)
Geany is a great editor - the best I've found since I switched to Linux. The documentation is best of class. But I saw there were a few places where fixes could be suggested. Because it is FLOSS I did feel that I should contribute and I did. I have submitted documentation patches for the editor documentation. If my patches are accepted, there will be no more "to to"s and no more "Furter"s (at least the instances I caught).
But my last submission of patches left me a bit confused.
I know *git* is a version control thingie. So be it. I don't do version control. So my preferred submission method is via patch file. So I submitted patches. And got zero feedback.
What should I expect?
If I do this, if I submit patches to, in my opinion, write the best damn doc about versions ever written, who reads and edits my tome (not that it would ever need editing:). I edited the text file documenting the main Geany editor and submitted the patch file and I haven't heard boo about it since. Maybe I screwed it up. OK, tell my what I did wrong and I'll do it over and fix it. Maybe you / they don't like the edits I made. OK, lets talk. Why don't they like the edits? etc.
Its frustrating to submit changes that just seem to get filed in the garbage.
On 13-06-08 02:54 AM, Roger Booth wrote:
[...]
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
As mentioned in other replies, there's the wiki page that maps API, ABI and other versions into a simple table.
IMO, plugin authors shouldn't have to bother with ABI numbers at all and API numbers should be transparent. If I want to write a plugin, I would like to have some boilerplate like:
#include <geanyplugins.h>
GEANY_PLUGIN_REGISTER(1, 24, 0, /* min supported geany version */ "Hello World", "0.01", "Another hello world", "You you@yourdomain.org");
void plugin_load(GeanyPlugin *plugin) { g_print("Loading plugin '%s'...\n", geany_plugin_get_name(plugin)); }
void plugin_unload(GeanyPlugin *plugin) { g_print("Unloading plugin '%s'...\n", geany_plugin_get_name(plugin)); }
Cheers, Matthew Brush
On 06/09/2013 01:46 AM, Matthew Brush wrote:
On 13-06-08 02:54 AM, Roger Booth wrote:
[...]
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
As mentioned in other replies, there's the wiki page that maps API, ABI and other versions into a simple table.
IMO, plugin authors shouldn't have to bother with ABI numbers at all and API numbers should be transparent. If I want to write a plugin, I would like to have some boilerplate like:
#include <geanyplugins.h> GEANY_PLUGIN_REGISTER(1, 24, 0, /* min supported geany version */ "Hello World", "0.01", "Another hello world", "You <you@yourdomain.org>"); void plugin_load(GeanyPlugin *plugin) { g_print("Loading plugin '%s'...\n", geany_plugin_get_name(plugin)); } void plugin_unload(GeanyPlugin *plugin) { g_print("Unloading plugin '%s'...\n", geany_plugin_get_name(plugin)); }Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Thank you for this example. One question I have after looking at this (and I mentioned this in my original post) is whether there is any reason to grab the param that is passed to plugin_load. Does it not point to the same as the global variable?
But back to the version number. I don't think I'm getting through to any of you. You know where the answer is, and now I know where the numbers are (I won't commit to knowing the answer yet). But that's not my point.
The web is a cool thing. Y'all'r reading a page and you have a question. One click and you have the answer.
Its that one click I'm asking for. Put that one click where the question is, so folks can read what the answer is.
On Sun, 09 Jun 2013 01:46:09 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 13-06-08 02:54 AM, Roger Booth wrote:
[...]
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
As mentioned in other replies, there's the wiki page that maps API, ABI and other versions into a simple table.
IMO, plugin authors shouldn't have to bother with ABI numbers at all and API numbers should be transparent. If I want to write a plugin, I would like to have some boilerplate like:
#include <geanyplugins.h> GEANY_PLUGIN_REGISTER(1, 24, 0, /* min supported geany version */ "Hello World", "0.01", "Another hello world", "You <you@yourdomain.org>"); void plugin_load(GeanyPlugin *plugin) { g_print("Loading plugin '%s'...\n", geany_plugin_get_name(plugin)); } void plugin_unload(GeanyPlugin *plugin) { g_print("Unloading plugin '%s'...\n", geany_plugin_get_name(plugin)); }
Well... Not sure whether it's really better than the current approach but patches are welcome ;)
Cheers, Frank
On 13-06-09 03:07 AM, Frank Lanitz wrote:
On Sun, 09 Jun 2013 01:46:09 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 13-06-08 02:54 AM, Roger Booth wrote:
[...]
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
As mentioned in other replies, there's the wiki page that maps API, ABI and other versions into a simple table.
IMO, plugin authors shouldn't have to bother with ABI numbers at all and API numbers should be transparent. If I want to write a plugin, I would like to have some boilerplate like:
#include <geanyplugins.h> GEANY_PLUGIN_REGISTER(1, 24, 0, /* min supported geany version */ "Hello World", "0.01", "Another hello world", "You <you@yourdomain.org>"); void plugin_load(GeanyPlugin *plugin) { g_print("Loading plugin '%s'...\n", geany_plugin_get_name(plugin)); } void plugin_unload(GeanyPlugin *plugin) { g_print("Unloading plugin '%s'...\n", geany_plugin_get_name(plugin)); }Well... Not sure whether it's really better than the current approach but patches are welcome ;)
Compared to current approach:
#include <geanyplugin.h>
GeanyFunctions *geany_functions; // WTF is this? GeanyPlugin *geany_plugin; // Why is this global? GeanyData *geany_data; // WTF?
GEANY_VERSION_CHECK(211 /* WTF!? What is this!? */) /* semi-colon? */
GEANY_SET_INFO("Hello World", _("0.01"), /* What stuff to translate? */ "Another hello world", "You you@yourdomain.org");
void plugin_init(GeanyData *data /* WTF!? isn't this the global GeanyData? */ { /* If you use any custom GObjects, you must register them and then you must call the Geany version of the make_resident() function from GModule. */ }
void plugin_cleanup(void /* WTF!? Why not GeanyData or GeanyPlugin? */) { /* free nasty globals here */ }
Cheers, Matthew Brush
On 06/09/2013 03:19 AM, Matthew Brush wrote:
On 13-06-09 03:07 AM, Frank Lanitz wrote:
On Sun, 09 Jun 2013 01:46:09 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 13-06-08 02:54 AM, Roger Booth wrote:
[...]
One thing I could ask for is a reference in the docs to where I can find the correspondence between api and abi. Maybe thats the wrong question, but anyway, how do i know which abi version I need? This is in regards to PLUGIN_VERSION_CHECK(xxx)
As mentioned in other replies, there's the wiki page that maps API, ABI and other versions into a simple table.
IMO, plugin authors shouldn't have to bother with ABI numbers at all and API numbers should be transparent. If I want to write a plugin, I would like to have some boilerplate like:
#include <geanyplugins.h> GEANY_PLUGIN_REGISTER(1, 24, 0, /* min supported geany version */ "Hello World", "0.01", "Another hello world", "You <you@yourdomain.org>"); void plugin_load(GeanyPlugin *plugin) { g_print("Loading plugin '%s'...\n", geany_plugin_get_name(plugin)); } void plugin_unload(GeanyPlugin *plugin) { g_print("Unloading plugin '%s'...\n", geany_plugin_get_name(plugin)); }Well... Not sure whether it's really better than the current approach but patches are welcome ;)
Compared to current approach:
#include <geanyplugin.h> GeanyFunctions *geany_functions; // WTF is this? GeanyPlugin *geany_plugin; // Why is this global? GeanyData *geany_data; // WTF? GEANY_VERSION_CHECK(211 /* WTF!? What is this!? */) /* semi-colon? */ GEANY_SET_INFO("Hello World", _("0.01"), /* What stuff to translate? */ "Another hello world", "You <you@yourdomain.org>"); void plugin_init(GeanyData *data /* WTF!? isn't this the globalGeanyData? */ { /* If you use any custom GObjects, you must register them and then you must call the Geany version of the make_resident() function from GModule. */ }
void plugin_cleanup(void /* WTF!? Why not GeanyData orGeanyPlugin? */) { /* free nasty globals here */ }
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Sorry, but I didn't understand exactly what you were attempting to demonstrate in your example. Please take pity on an admitted moron here and expand a bit on what is going on in the example.
Main questions: where does the magic number 211 come from? GEANY_VERSION_CHECK(211...) Lex says we're supposed to use API numbers, like 0.19. Please, as a demo, convert that to an int. When I try, I get zero. But, like I said, I'm a moron. in plugin_init you have this WTF comment, but do not answer the question. Is the param the same as the global? Param == global: true or false? in plugin_cleanup yes, I clean my dishes. As long as I can find the sink.
[...]
Sorry, but I didn't understand exactly what you were attempting to demonstrate in your example. Please take pity on an admitted moron here and expand a bit on what is going on in the example.
Main questions: where does the magic number 211 come from? GEANY_VERSION_CHECK(211...) Lex says we're supposed to use API numbers, like 0.19. Please, as a demo, convert that to an int. When I try, I get zero. But, like I said, I'm a moron.
Ahhh, theres the confusion, API numbers are not version numbers, version numbers can be all over the place, 1.23, 1.23.1 etc. API numbers are nice numbers that simply increase whenever something is chnaged in the API, currently the numbers are in the 2xx region, or for the experimental GTK3 version of Geany 3xx.
The current git geany has an API of 216, the API versions for releases are given in the table inthe wiki.
Cheers Lex
On 06/09/2013 03:47 AM, Lex Trotman wrote:
[...]
Sorry, but I didn't understand exactly what you were attempting to demonstrate in your example. Please take pity on an admitted moron here and expand a bit on what is going on in the example. Main questions: where does the magic number 211 come from? GEANY_VERSION_CHECK(211...) Lex says we're supposed to use API numbers, like 0.19. Please, as a demo, convert that to an int. When I try, I get zero. But, like I said, I'm a moron.Ahhh, theres the confusion, API numbers are not version numbers, version numbers can be all over the place, 1.23, 1.23.1 etc. API numbers are nice numbers that simply increase whenever something is chnaged in the API, currently the numbers are in the 2xx region, or for the experimental GTK3 version of Geany 3xx.
The current git geany has an API of 216, the API versions for releases are given in the table inthe wiki.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
OK, so to recap, we have
version numbers, which are documented on the web site API number, which I don't know how to determine ABI number, which I don't need to worry about
Is that about it?
Bottom line:
I use a function from Geany. How do I know what number to plug in to GEANY_VERSION_CHECK()?
On 06/09/2013 03:47 AM, Lex Trotman wrote:
[...]
Sorry, but I didn't understand exactly what you were attempting to demonstrate in your example. Please take pity on an admitted moron here and expand a bit on what is going on in the example. Main questions: where does the magic number 211 come from? GEANY_VERSION_CHECK(211...) Lex says we're supposed to use API numbers, like 0.19. Please, as a demo, convert that to an int. When I try, I get zero. But, like I said, I'm a moron.Ahhh, theres the confusion, API numbers are not version numbers, version numbers can be all over the place, 1.23, 1.23.1 etc. API numbers are nice numbers that simply increase whenever something is chnaged in the API, currently the numbers are in the 2xx region, or for the experimental GTK3 version of Geany 3xx.
The current git geany has an API of 216, the API versions for releases are given in the table inthe wiki.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Do you mean
http://wiki.geany.org/plugins/development/api-versions?s%5B%5D=api
Well, if so, it would have helped this moron to expand just a bit *in the docs* on the differences between version and api and to include a link *in the docs* to the above wiki, once the poor sods know what they are looking at.
But like I say, I'm just a moron.
Do you mean
http://wiki.geany.org/plugins/development/api-versionshttp://wiki.geany.org/plugins/development/api-versions?s
Yes.
Well, if so, it would have helped this moron to expand just a bit *in the docs* on the differences between version and api and to include a link *in the docs* to the above wiki, once the poor sods know what they are looking at.
But like I say, I'm just a moron.
More probably just differing programming background.
I'm sure the guy who wrote it did his best, but when you understand something it is hard to always anticipate what others with different programming backgrounds will not understand. So please propose patches to improve those areas which from your background are lacking. Geany is a volunteer software development and will only improve if people of all experience levels and programming backgrounds contribute.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 06/09/2013 03:47 AM, Lex Trotman wrote:
[...]
Sorry, but I didn't understand exactly what you were attempting to demonstrate in your example. Please take pity on an admitted moron here and expand a bit on what is going on in the example. Main questions: where does the magic number 211 come from? GEANY_VERSION_CHECK(211...) Lex says we're supposed to use API numbers, like 0.19. Please, as a demo, convert that to an int. When I try, I get zero. But, like I said, I'm a moron.Ahhh, theres the confusion, API numbers are not version numbers, version numbers can be all over the place, 1.23, 1.23.1 etc. API numbers are nice numbers that simply increase whenever something is chnaged in the API, currently the numbers are in the 2xx region, or for the experimental GTK3 version of Geany 3xx.
The current git geany has an API of 216, the API versions for releases are given in the table inthe wiki.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Look, bottom line
Like I said, I'm a moron, but ...
I wanted to write plugins in C++.
I know C++.
I've written and tested (successfully) "Hello World" as a Geany plugin
When I looked at the documentation on your web site, I had two questions:
Why does plugin_init accept a pointer to GeanyData when the example shows that a pointer to GeanyData is available as global data? When I use a random Geany function which is made available for the use of a plugin, under what version restriction does that place my plugin?
As a casual user of the plugin API, I don't want to ask for special treatment. Problem is, the documentation for the API is, in some places, crap. Specifically, documenting the macro GEANY_VERSION_CHECK(). Now Lex has already given excuses. "Gee, its an implementation detail" or some such. Look it up in this thread if you are interested. But I don't give a shit. Me, I want to know when I look at the docs what the damn thing will do. Not whether it calls three levels of subroutines, one on fortran, another in asm. I want to know *what goes in* gives *what comes out*. I'll let Lex sweat the internals.
For me, the docs for GEANY_VERSION_CHECK() flunk that test.
This whole thread has been about how the poor moron (me) developer can know how to plug a number into the GEANY_VERSION_CHECK() macro. So show where in the plugin docs where that is described.
On Sat, 8 Jun 2013 17:31:57 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sat, Jun 08, 2013 at 05:59:51PM +1000, Lex Trotman wrote:
[...] "for non autotools experts" I said, that includes not knowing how to program in m4 :-)
Unless you are telling me just cut and paste of the code fragments in hacking is all thats needed?
Actually cutting and pasting the code fragments in HACKING should be enough for most cases. There are also plenty of examples (other plugins) to look at if anything extra needs to be done.
At least that was the goal of putting them there ;)
Cheers, Frank
On Sat, Jun 08, 2013 at 11:58:16AM +0200, Frank Lanitz wrote:
On Sat, 8 Jun 2013 17:31:57 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sat, Jun 08, 2013 at 05:59:51PM +1000, Lex Trotman wrote:
[...] "for non autotools experts" I said, that includes not knowing how to program in m4 :-)
Unless you are telling me just cut and paste of the code fragments in hacking is all thats needed?
Actually cutting and pasting the code fragments in HACKING should be enough for most cases. There are also plenty of examples (other plugins) to look at if anything extra needs to be done.
At least that was the goal of putting them there ;)
Yeah, I just had a look through it, and it looks quite good actually. Great work! :)
On 13-06-08 12:59 AM, Lex Trotman wrote:
On 8 June 2013 16:25, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-06-07 10:51 PM, Lex Trotman wrote:
Frank and others,
Is there something that describes how to go about adding a plugin to geany-plugins? That describes the build system requirements for non-autotools experts etc.
I couldn't find anything.
The HACKING file has some good project information:
https://github.com/geany/**geany-plugins/blob/master/**HACKINGhttps://github.com/geany/geany-plugins/blob/master/HACKING
"for non autotools experts" I said, that includes not knowing how to program in m4 :-)
Yeah I had originally typed a little rant about it in my last email that I removed to avoid being negative/complainy, but I believe it went something like this:
To add an already written plugin to Geany-Plugins you have to learn (at least a little of):
- m4 and gp-specific set of m4 functions
- bash/shell
- gnu make
- autoconf
- automake
- python
- waf
- mingw/win32-isms
IMO, that's a pretty hefty list of tangential tech.
Cheers, Matthew Brush
On Sun, Jun 09, 2013 at 01:59:57AM -0700, Matthew Brush wrote:
[...]
Yeah I had originally typed a little rant about it in my last email that I removed to avoid being negative/complainy, but I believe it went something like this:
To add an already written plugin to Geany-Plugins you have to learn (at least a little of):
- m4 and gp-specific set of m4 functions
- bash/shell
- gnu make
- autoconf
- automake
- python
- waf
- mingw/win32-isms
IMO, that's a pretty hefty list of tangential tech.
Or you could just copy-paste everything without understanding anything, and poke someone on IRC to help you out for anything extra.
Is waf still around, or were we phasing that out? I kind of remember some talk about removing it sometime back.
On Sun, 9 Jun 2013 17:53:21 +0800 Chow Loong Jin hyperair@gmail.com wrote:
Is waf still around, or were we phasing that out? I kind of remember some talk about removing it sometime back.
It's still around and not removed due to some real alternative is missing.
Cheers, Frank
On Sun, Jun 09, 2013 at 11:59:20AM +0200, Frank Lanitz wrote:
On Sun, 9 Jun 2013 17:53:21 +0800 Chow Loong Jin hyperair@gmail.com wrote:
Is waf still around, or were we phasing that out? I kind of remember some talk about removing it sometime back.
It's still around and not removed due to some real alternative is missing.
What real alternative?
On Sun, 9 Jun 2013 18:12:49 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sun, Jun 09, 2013 at 11:59:20AM +0200, Frank Lanitz wrote:
On Sun, 9 Jun 2013 17:53:21 +0800 Chow Loong Jin hyperair@gmail.com wrote:
Is waf still around, or were we phasing that out? I kind of remember some talk about removing it sometime back.
It's still around and not removed due to some real alternative is missing.
What real alternative?
The build for Windows is currently done with waf IIRC.
Cheers, Frank
On 06/09/13 13:41, Frank Lanitz wrote:
On Sun, 9 Jun 2013 18:12:49 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sun, Jun 09, 2013 at 11:59:20AM +0200, Frank Lanitz wrote:
On Sun, 9 Jun 2013 17:53:21 +0800 Chow Loong Jin hyperair@gmail.com wrote:
Is waf still around, or were we phasing that out? I kind of remember some talk about removing it sometime back.
It's still around and not removed due to some real alternative is missing.
What real alternative?
The build for Windows is currently done with waf IIRC.
True. And as long as nobody else take care about this and/or provide a convenient way to make the builds, I'd like to stick with Waf, even if it is only for Windows.
Working with autotools on Windows is just even more pain than on Linux.
Regards, Enrico
On 9 June 2013 19:53, Chow Loong Jin hyperair@gmail.com wrote:
On Sun, Jun 09, 2013 at 01:59:57AM -0700, Matthew Brush wrote:
[...]
Yeah I had originally typed a little rant about it in my last email that I removed to avoid being negative/complainy, but I believe it went something like this:
To add an already written plugin to Geany-Plugins you have to learn
(at least a little of):
- m4 and gp-specific set of m4 functions
- bash/shell
- gnu make
- autoconf
- automake
- python
- waf
- mingw/win32-isms
IMO, that's a pretty hefty list of tangential tech.
Or you could just copy-paste everything without understanding anything, and poke someone on IRC to help you out for anything extra.
Heh, thats my intended approach, possibly tomorrow, see ya on IRC ;)
Cheers Lex
BTW just to pre-warn you I am attempting to get geanypy into g-p, so it might be more complex than first thought, or due to the work already done on it, maybe easier, who knows.
Is waf still around, or were we phasing that out? I kind of remember some talk about removing it sometime back.
-- Kind regards, Loong Jin
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Sat, 8 Jun 2013 15:51:46 +1000 Lex Trotman elextr@gmail.com wrote:
Is there something that describes how to go about adding a plugin to geany-plugins? That describes the build system requirements for non-autotools experts etc.
I couldn't find anything.
At least inside HACKING of g-p there should be some notes for the build system.
Cheers, Frank
After many problems with my email address, I hope I can send messages (not HTML) :-)
Maybe attach the Geany Vala Toys[1] ? Especially the plugin GVT Project.
Currently it works only GTK+ 2.
[1] https://github.com/gandalfn/geany-vala-toys
Regards, Yosef Or Boczko
On Sat, Jun 8, 2013 at 8:51 AM, Lex Trotman elextr@gmail.com wrote:
Frank and others,
Is there something that describes how to go about adding a plugin to geany-plugins? That describes the build system requirements for non-autotools experts etc.
I couldn't find anything.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel