Hi guys,
During the last weeks a huge number mails at this list was stating to make usage of GObject on building up a new plugin interface. It has been talked about libpeas and adding support for Vala, Python etc. Before we do discuss any further I'd like to point to an email Enrico sent earlier this year onto this list:
http://lists.uvena.de/geany-devel/2011-February/003905.html
Originally Geany wasn't designed/coded to work with GObject. Moving to an plugin interface using this would most likely cause rewriting of a lot of code. However, if really somebody of you like to go this further I suggest to start a new branch where all changes can be tracked in. But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task?
Cheers, Frank
On 03/12/11 10:11, Frank Lanitz wrote:
But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task?
I would like to work on this, but I'm not sure I would define myself as a lead engineer or project manager. I have some pretty good ideas about how the interface should look, having hacked with Colomban on the Vala bindings and seeing the "problems"/limitations with the current interface. I've also done a fair bit of thinking on this while working on GeanyPy.
If there was someone with lots of GObject experience that would be willing to review my code on a regular basis, I'm willing to volunteer my time and do most of the coding (or at least my share, depending who else is interested in working on this).
Cheers, Matthew Brush (codebrainz)
On 13 March 2011 05:39, Matthew Brush matthewbrush@gmail.com wrote:
On 03/12/11 10:11, Frank Lanitz wrote:
But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task?
I would like to work on this, but I'm not sure I would define myself as a lead engineer or project manager. I have some pretty good ideas about how the interface should look, having hacked with Colomban on the Vala bindings and seeing the "problems"/limitations with the current interface. I've also done a fair bit of thinking on this while working on GeanyPy.
If there was someone with lots of GObject experience that would be willing to review my code on a regular basis, I'm willing to volunteer my time and do most of the coding (or at least my share, depending who else is interested in working on this).
Hi Matthew,
I currently have a looong commute where I can't actually code or compile or test things (my tablet is just not suited), but I can review and discuss things by the magic of wifi.
I'm not specifically a GObject specialist but have a lot of general OO design and development experience so hopefully I could be helpful.
I would suggest that the GObject interface needs to be designed to work right for the plugin developer languages and then mapped over the current internal implementation. I'm not totally convinced that the current implementation is the best way to present things to plugins, although after some discussion it may be the best way to go. This might not be very efficient initially but it allows testing of the interface without disrupting core too much. Then over time other changes could be made.
This will also help to allay some of Franks fear of the size of the change.
I would suggest that the interface needs to support one static compiled language, Vala? and one interpreted dynamic language Python?
Cheers Lex
Cheers, Matthew Brush (codebrainz)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 13/03/2011 03:01, Lex Trotman a écrit :
On 13 March 2011 05:39, Matthew Brush matthewbrush@gmail.com wrote:
[...]
If there was someone with lots of GObject experience that would be willing to review my code on a regular basis, I'm willing to volunteer my time and do most of the coding (or at least my share, depending who else is interested in working on this).
[...]
I would suggest that the GObject interface needs to be designed to work right for the plugin developer languages and then mapped over the current internal implementation. I'm not totally convinced that the current implementation is the best way to present things to plugins, although after some discussion it may be the best way to go. This might not be very efficient initially but it allows testing of the interface without disrupting core too much. Then over time other changes could be made.
Agreed. Maybe the easiest way to go would be to write this wrapper library in Vala, at least as a start point: 1) it's an OO language, and would save a significant part of the work needed to write GObject code; 2) there is a raw wrapper I wrote, with good patches from Matthew [1][2] 3) the amount of work to translate the interface to plain GObject code would be "relatively" small if needed (though Vala should be OK: it outputs C code)
This will also help to allay some of Franks fear of the size of the change.
I would suggest that the interface needs to support one static compiled language, Vala? and one interpreted dynamic language Python?
They are good targets IMO, but I also think it would be good to support more languages if possible. GObject-Introspection, if done right, can provide good-quality binding for a plenty of languages almost for free (C++, Python, JavaScript and many more). Normally the GI bindings for the target language takes care of translating between conventions -- for example, a Python programer would like to use obj.foo_bar() and a JavaScript one better obj.fooBar().
However, even though I like the idea of creating this new plugin API supporting other languages, I will not tell I'll help a lot because I'm really not sure of the amount of time I could spend on it. However, I'd be happy to help from time to time, when I can :)
Just my 2¢, Colomban
[1] http://gitorious.org/geany-vala-binding/ [2] though we started to try to make it a more Vala-style API, I doubt we could succeed without a wrapper library. Maybe the work Matthew did on GeanyDBus might be a start
On 13 March 2011 13:36, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 13/03/2011 03:01, Lex Trotman a écrit :
On 13 March 2011 05:39, Matthew Brush matthewbrush@gmail.com wrote:
[...]
If there was someone with lots of GObject experience that would be willing to review my code on a regular basis, I'm willing to volunteer my time and do most of the coding (or at least my share, depending who else is interested in working on this).
[...]
I would suggest that the GObject interface needs to be designed to work right for the plugin developer languages and then mapped over the current internal implementation. I'm not totally convinced that the current implementation is the best way to present things to plugins, although after some discussion it may be the best way to go. This might not be very efficient initially but it allows testing of the interface without disrupting core too much. Then over time other changes could be made.
Agreed. Maybe the easiest way to go would be to write this wrapper library in Vala, at least as a start point:
- it's an OO language, and would save a significant part of the work
needed to write GObject code; 2) there is a raw wrapper I wrote, with good patches from Matthew [1][2] 3) the amount of work to translate the interface to plain GObject code would be "relatively" small if needed (though Vala should be OK: it outputs C code)
I don't mind what language is used initially to implement, but I think in the long term it needs to go back to C so as to not increase Geany's dependencies.
Reusing some initial work is great, but I would caution that we should think about how the interface should look first.
This will also help to allay some of Franks fear of the size of the change.
I would suggest that the interface needs to support one static compiled language, Vala? and one interpreted dynamic language Python?
I should have said I suggest using one static and one dynamic one during development, I wasn't intending to suggest they be the only ones in the long term. But my experience is that it is important to try both because it is easy to tailor the way the interface works to one paradigm only and make the other harder to implement or spectacularly less efficient.
They are good targets IMO, but I also think it would be good to support more languages if possible. GObject-Introspection, if done right, can provide good-quality binding for a plenty of languages almost for free (C++, Python, JavaScript and many more). Normally the GI bindings for the target language takes care of translating between conventions -- for example, a Python programer would like to use obj.foo_bar() and a JavaScript one better obj.fooBar().
Yes, but only if good *language specific* API documentation is generated. It really p@!#$ me off with some (unnamed) C++ wrappers that require you to guess how the underlying C maps to C++ because of lousy (lazy?) documentation.
Cheers Lex
However, even though I like the idea of creating this new plugin API supporting other languages, I will not tell I'll help a lot because I'm really not sure of the amount of time I could spend on it. However, I'd be happy to help from time to time, when I can :)
Just my 2¢, Colomban
[1] http://gitorious.org/geany-vala-binding/ [2] though we started to try to make it a more Vala-style API, I doubt we could succeed without a wrapper library. Maybe the work Matthew did on GeanyDBus might be a start _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 03/12/11 19:46, Lex Trotman wrote:
On 13 March 2011 13:36, Colomban Wendlinglists.ban@herbesfolles.org wrote:
Agreed. Maybe the easiest way to go would be to write this wrapper library in Vala, at least as a start point:
- it's an OO language, and would save a significant part of the work
needed to write GObject code; 2) there is a raw wrapper I wrote, with good patches from Matthew [1][2] 3) the amount of work to translate the interface to plain GObject code would be "relatively" small if needed (though Vala should be OK: it outputs C code)
I don't mind what language is used initially to implement, but I think in the long term it needs to go back to C so as to not increase Geany's dependencies.
Vala generates a robust C/GObject API from the Vala code, the only dependency is for developers who want to recompile the C code from the Vala code. I'm not saying it should be done in Vala over C (I'm thinking it) but it's important to note that Vala compiles to pure C/GObject. In any case, we could mix C and Vala quite easily, using both at the same time, or one or the other for specific things, or starting in Vala then changing to C in the end, without changing the GObject C API.
Reusing some initial work is great, but I would caution that we should think about how the interface should look first.
I agree, but just to be clear, that's what's been goin on with Geany-DBus[1]/Geany-Vala-Binding (picturing how the interface *should* look). That's not say we don't need to think about it A LOT more, but at least we have some ideas started with those projects.
Yes, but only if good *language specific* API documentation is generated. It really p@!#$ me off with some (unnamed) C++ wrappers that require you to guess how the underlying C maps to C++ because of lousy (lazy?) documentation.
If I'm not mistaken, with GObject-introspection, the GTK-DOC gets wrapped up in the target bindings, so at a bare minimum, there would be docs for things like methods, properties, signals, etc. Of course I'm just assuming the GTK-DOC gets put into the target bindings, I've never actually tried to do it, and as always, the C API needs good docs :)
[1] https://github.com/codebrainz/geany-dbus
Cheers, Matthew Brush (codebrainz)
On 13 March 2011 17:10, Matthew Brush matthewbrush@gmail.com wrote:
On 03/12/11 19:46, Lex Trotman wrote:
On 13 March 2011 13:36, Colomban Wendlinglists.ban@herbesfolles.org wrote:
Agreed. Maybe the easiest way to go would be to write this wrapper library in Vala, at least as a start point:
- it's an OO language, and would save a significant part of the work
needed to write GObject code; 2) there is a raw wrapper I wrote, with good patches from Matthew [1][2] 3) the amount of work to translate the interface to plain GObject code would be "relatively" small if needed (though Vala should be OK: it outputs C code)
I don't mind what language is used initially to implement, but I think in the long term it needs to go back to C so as to not increase Geany's dependencies.
Vala generates a robust C/GObject API from the Vala code, the only dependency is for developers who want to recompile the C code from the Vala code. I'm not saying it should be done in Vala over C (I'm thinking it) but it's important to note that Vala compiles to pure C/GObject. In any case, we could mix C and Vala quite easily, using both at the same time, or one or the other for specific things, or starting in Vala then changing to C in the end, without changing the GObject C API.
I think that Vala can be used so long as it generates C code that can be included in SVN so that someone who just wants to compile the latest doesn't need to have Vala available. Similar idea to putting the geany.html in SVN, even though its a generated file, so you only need the docutils if you want to change the documentation. You only need Vala if you are going to change the interface.
Reusing some initial work is great, but I would caution that we should think about how the interface should look first.
I agree, but just to be clear, that's what's been goin on with Geany-DBus[1]/Geany-Vala-Binding (picturing how the interface *should* look). That's not say we don't need to think about it A LOT more, but at least we have some ideas started with those projects.
Ok, I'll have a look and ask dumb questions.
Yes, but only if good *language specific* API documentation is generated. It really p@!#$ me off with some (unnamed) C++ wrappers that require you to guess how the underlying C maps to C++ because of lousy (lazy?) documentation.
If I'm not mistaken, with GObject-introspection, the GTK-DOC gets wrapped up in the target bindings, so at a bare minimum, there would be docs for things like methods, properties, signals, etc. Of course I'm just assuming the GTK-DOC gets put into the target bindings, I've never actually tried to do it, and as always, the C API needs good docs :)
My question is does it get adapted to the specific target, if the Python interface is erm Pythonic, the documentation shouldn't be Cic, if you see what I mean.
Cheers Lex
[1] https://github.com/codebrainz/geany-dbus
Cheers, Matthew Brush (codebrainz) _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi,
Am 12.03.2011 19:11, schrieb Frank Lanitz:
During the last weeks a huge number mails at this list was stating to make usage of GObject on building up a new plugin interface. It has been talked about libpeas and adding support for Vala, Python etc. Before we do discuss any further I'd like to point to an email Enrico sent earlier this year onto this list:
http://lists.uvena.de/geany-devel/2011-February/003905.html
Originally Geany wasn't designed/coded to work with GObject. Moving to an plugin interface using this would most likely cause rewriting of a lot of code. However, if really somebody of you like to go this further I suggest to start a new branch where all changes can be tracked in. But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task?
What's the outcome here? I saw a lot of technical discussion followed up by my original posting but nobody took over the rule to bring all the idea into synch. Not sure whether I might did miss something.
Cheers, Frank
On 04/28/11 00:01, Frank Lanitz wrote:
Hi,
Am 12.03.2011 19:11, schrieb Frank Lanitz:
During the last weeks a huge number mails at this list was stating to make usage of GObject on building up a new plugin interface. It has been talked about libpeas and adding support for Vala, Python etc. Before we do discuss any further I'd like to point to an email Enrico sent earlier this year onto this list:
http://lists.uvena.de/geany-devel/2011-February/003905.html
Originally Geany wasn't designed/coded to work with GObject. Moving to an plugin interface using this would most likely cause rewriting of a lot of code. However, if really somebody of you like to go this further I suggest to start a new branch where all changes can be tracked in. But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task?
What's the outcome here? I saw a lot of technical discussion followed up by my original posting but nobody took over the rule to bring all the idea into synch. Not sure whether I might did miss something.
I had offered to work on this, but I wanted to make sure someone would be willing to review/commit all the changes, the responses were:
From Lex: "I currently have a looong commute where I can't actually code or compile or test things (my tablet is just not suited), but I can review and discuss things by the magic of wifi."
From Colomban: "However, even though I like the idea of creating this new plugin API supporting other languages, I will not tell I'll help a lot because I'm really not sure of the amount of time I could spend on it. However, I'd be happy to help from time to time, when I can :)"
In another thread from you: "And as I mentioned according to plugin interface discussion, I like to have it this way for enabling GObject fun: I want to have someone with experince managing this kind of stuff."
Nothing from Enrico, Nick or other core developers with commit access. So I pretty much decided I would be wasting my time on this if the code won't get committed and the core developers aren't even very much interested in this.
Cheers, Matthew Brush
Am 28.04.2011 09:32, schrieb Matthew Brush:
On 04/28/11 00:01, Frank Lanitz wrote:
Hi,
Am 12.03.2011 19:11, schrieb Frank Lanitz:
During the last weeks a huge number mails at this list was stating to make usage of GObject on building up a new plugin interface. It has been talked about libpeas and adding support for Vala, Python etc. Before we do discuss any further I'd like to point to an email Enrico sent earlier this year onto this list:
http://lists.uvena.de/geany-devel/2011-February/003905.html
Originally Geany wasn't designed/coded to work with GObject. Moving to an plugin interface using this would most likely cause rewriting of a lot of code. However, if really somebody of you like to go this further I suggest to start a new branch where all changes can be tracked in. But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task?
What's the outcome here? I saw a lot of technical discussion followed up by my original posting but nobody took over the rule to bring all the idea into synch. Not sure whether I might did miss something.
I had offered to work on this, but I wanted to make sure someone would be willing to review/commit all the changes, the responses were:
From Lex: "I currently have a looong commute where I can't actually code or compile or test things (my tablet is just not suited), but I can review and discuss things by the magic of wifi."
From Colomban: "However, even though I like the idea of creating this new plugin API supporting other languages, I will not tell I'll help a lot because I'm really not sure of the amount of time I could spend on it. However, I'd be happy to help from time to time, when I can :)"
In another thread from you: "And as I mentioned according to plugin interface discussion, I like to have it this way for enabling GObject fun: I want to have someone with experince managing this kind of stuff."
Nothing from Enrico, Nick or other core developers with commit access. So I pretty much decided I would be wasting my time on this if the code won't get committed and the core developers aren't even very much interested in this.
I think we had an agreement that we can develop it inside a new branch (where of course you can commit) and once its stable its getting merged into trunk.
If everybody is fine with it I'd suggest to give Matthew commit rights for new branch to build up the GObject plugin interface as some kind of project leader.
Cheers, Frank
Am 28.04.2011 14:54, schrieb Frank Lanitz:
I think we had an agreement that we can develop it inside a new branch (where of course you can commit) and once its stable its getting merged into trunk.
If everybody is fine with it I'd suggest to give Matthew commit rights for new branch to build up the GObject plugin interface as some kind of project leader.
That doesn't make a lot of sense.
It doesn't enhance the chance to get reviewed and merged into trunk. If neither happens it ends up like the sm-branch. And on the other hand working with branches is far better with Git, especially if you like using Git better (which is I suspect true for Matthew).
So it can just as well, or better, be developed outside on e.g. Github, but Matthew's points still remain.
Best regards.
On Thu, 28 Apr 2011 09:01:08 +0200 Frank Lanitz frank@frank.uvena.de wrote:
During the last weeks a huge number mails at this list was stating to make usage of GObject on building up a new plugin interface. It has been talked about libpeas and adding support for Vala, Python etc. Before we
BTW Colomban started work on Vala bindings without changing the plugin API: http://gitorious.org/geany-vala-binding
I think this is great. It might be doable to maintain this with Geany's API when ready. This would be a big leap forward for plugin writers, and little/no impact on the existing API.
do discuss any further I'd like to point to an email Enrico sent earlier this year onto this list:
http://lists.uvena.de/geany-devel/2011-February/003905.html
Originally Geany wasn't designed/coded to work with GObject. Moving to an plugin interface using this would most likely cause rewriting of a lot of code. However, if really somebody of you like to go this further I suggest to start a new branch where all changes can be tracked in. But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task?
What's the outcome here? I saw a lot of technical discussion followed up by my original posting but nobody took over the rule to bring all the idea into synch. Not sure whether I might did miss something.
Just to add my point of view:
1. I think this would be very disruptive to both Geany's core and existing plugins. I also really don't like GObject code in C.
2. Would it actually work? Geany is not a shared library, so this might cause problems for dynamic language bindings. Until this and perhaps other issues are dealt with, we should not start on using GObject IMO. (To prove dynamic bindings would be possible, a minimal binding for the current API could be made).
Regards, Nick
Am 29.04.2011 19:12, schrieb Nick Treleaven:
I think this is great. It might be doable to maintain this with Geany's API when ready. This would be a big leap forward for plugin writers, and little/no impact on the existing API.
Will Geany's API ever be ready? I doubt so, especially at this development rate. But this vala bindings are great for sure.
do discuss any further I'd like to point to an email Enrico sent earlier this year onto this list:
http://lists.uvena.de/geany-devel/2011-February/003905.html
Originally Geany wasn't designed/coded to work with GObject. Moving to an plugin interface using this would most likely cause rewriting of a lot of code. However, if really somebody of you like to go this further I suggest to start a new branch where all changes can be tracked in. But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task?
What's the outcome here? I saw a lot of technical discussion followed up by my original posting but nobody took over the rule to bring all the idea into synch. Not sure whether I might did miss something.
Just to add my point of view:
- I think this would be very disruptive to both Geany's core and
existing plugins. I also really don't like GObject code in C.
Wasn't the idea to implement the GObject interface one by one, maintaining the current one in the meantime (and a bit after)? You can also always do compatibility magic with cpp or some sort. I don't see it disruptive for plugin writers.
- Would it actually work? Geany is not a shared library, so this
might cause problems for dynamic language bindings. Until this and perhaps other issues are dealt with, we should not start on using GObject IMO. (To prove dynamic bindings would be possible, a minimal binding for the current API could be made).
It works for all other the programs (e.g. gedit) too, doesn't it?
I don't hope you just killed all hope with your mail, we basically already agreed this would be a nice thing to have, no?
Best regards.
On Fri, 29 Apr 2011 19:19:00 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 29.04.2011 19:12, schrieb Nick Treleaven:
I think this is great. It might be doable to maintain this with Geany's API when ready. This would be a big leap forward for plugin writers, and little/no impact on the existing API.
Will Geany's API ever be ready? I doubt so, especially at this development rate.
I was talking about the Vala API being ready. Maybe it is already.
Just to add my point of view:
- I think this would be very disruptive to both Geany's core and
existing plugins. I also really don't like GObject code in C.
Wasn't the idea to implement the GObject interface one by one, maintaining the current one in the meantime (and a bit after)? You can also always do compatibility magic with cpp or some sort. I don't see it disruptive for plugin writers.
- Would it actually work? Geany is not a shared library, so this
might cause problems for dynamic language bindings. Until this and perhaps other issues are dealt with, we should not start on using GObject IMO. (To prove dynamic bindings would be possible, a minimal binding for the current API could be made).
It works for all other the programs (e.g. gedit) too, doesn't it?
I don't hope you just killed all hope with your mail, we basically already agreed this would be a nice thing to have, no?
I was just adding my thoughts. At the time I was too busy to read the list so didn't contribute. Obviously I'm not going to override everyone else, and there may be solutions to the issues I see.
Regards, Nick
On 04/29/11 10:12, Nick Treleaven wrote:
On Thu, 28 Apr 2011 09:01:08 +0200 Frank Lanitzfrank@frank.uvena.de wrote:
During the last weeks a huge number mails at this list was stating to make usage of GObject on building up a new plugin interface. It has been talked about libpeas and adding support for Vala, Python etc. Before we
BTW Colomban started work on Vala bindings without changing the plugin API: http://gitorious.org/geany-vala-binding
This has been discussed quite a bit in the thread: http://permalink.gmane.org/gmane.editors.geany.devel/4138
I think this is great. It might be doable to maintain this with Geany's API when ready. This would be a big leap forward for plugin writers, and little/no impact on the existing API.
I've written/started a few plugins with it so far, for example geany-multiterm, geany-dbus previously mentioned in the thread, and a few others, and it's quite nice, although not very "Vala-like" since it directly wraps the existing non-(G)Object API.
What's the outcome here? I saw a lot of technical discussion followed up by my original posting but nobody took over the rule to bring all the idea into synch. Not sure whether I might did miss something.
Just to add my point of view:
- I think this would be very disruptive to both Geany's core and
existing plugins. I also really don't like GObject code in C.
*VERY* disruptive as noted in the thread, if the core code was modified directly. Regarding preference for GObject, my only thought is that the plugin API should consider the user of the API rather than the developer writing the API, unlike in the rest of the core code where it doesn't matter to the user and more to the developers. In geany-plugins there is already at least a few plugins which are using GObject C code despite the current API and IIUC, there would basically be only 1 "mandatory" GObject class to use a GObject API, the rest of the code could be written however.
- Would it actually work? Geany is not a shared library, so this
might cause problems for dynamic language bindings. Until this and perhaps other issues are dealt with, we should not start on using GObject IMO. (To prove dynamic bindings would be possible, a minimal binding for the current API could be made).
The idea previously discussed, IIRC, is to make a separate shared library and also a separate plugin loader, being loaded (for the time being) as a proper/regular Geany plugin, to minimize the impact to the core code. I'm pretty sure it would work, but with the current setup it's just too much trouble (see GeanyPy).
Cheers, Matthew Brush
On Sat, 30 Apr 2011 00:24:10 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 04/29/11 10:12, Nick Treleaven wrote:
On Thu, 28 Apr 2011 09:01:08 +0200 Frank Lanitzfrank@frank.uvena.de wrote:
During the last weeks a huge number mails at this list was stating to make usage of GObject on building up a new plugin interface. It has been talked about libpeas and adding support for Vala, Python etc. Before we
BTW Colomban started work on Vala bindings without changing the plugin API: http://gitorious.org/geany-vala-binding
This has been discussed quite a bit in the thread: http://permalink.gmane.org/gmane.editors.geany.devel/4138
Thanks for the link.
Just to add my point of view:
- I think this would be very disruptive to both Geany's core and
existing plugins. I also really don't like GObject code in C.
So the GObject code could be written in Vala, solving that issue.
*VERY* disruptive as noted in the thread, if the core code was modified directly. Regarding preference for GObject, my only thought is that the plugin API should consider the user of the API rather than the developer writing the API, unlike in the rest of the core code where it doesn't matter to the user and more to the developers. In geany-plugins there is already at least a few plugins which are using GObject C code despite the current API and IIUC, there would basically be only 1 "mandatory" GObject class to use a GObject API, the rest of the code could be written however.
It just seems like a lot of work. Vala is quite high level, I have to wonder whether all the disruption is worth it.
- Would it actually work? Geany is not a shared library, so this
might cause problems for dynamic language bindings. Until this and perhaps other issues are dealt with, we should not start on using GObject IMO. (To prove dynamic bindings would be possible, a minimal binding for the current API could be made).
The idea previously discussed, IIRC, is to make a separate shared library and also a separate plugin loader, being loaded (for the time being) as a proper/regular Geany plugin, to minimize the impact to the core code. I'm pretty sure it would work, but with the current setup it's just too much trouble (see GeanyPy).
Ok. Thanks for explaining. Both current setup and the new approach would need plugins to be able to contain multiple other plugins, in order to support a dynamic language.
Regards, Nick
It just seems like a lot of work. Vala is quite high level, I have to wonder whether all the disruption is worth it.
Hi Nick, I have suggested that the new plugin API be GObjects which are just thin shells referring everything to the existing Geany structures like GeanyDocument. The GObject methods just called one or more Geany functions that work on the existing structures. The only disruption I can see in core would be that it would need to emit the signals on these objects.
Even if there is one GObject per Geany structure (well the ones needed by plugins anyway) this would somewhat insulate the plugin interface from changes in the Geany structures since the GObject methods can be pointed at different places in the core without affecting the plugin API.
Since there is this insulation I tried to start the discussion whether the best set of GObjects was to have one per Geany structure or a different set of GObjects that used more than one Geany structure, making the GObjects a little more complicated but their use by plugins easier. But the discussion didn't seem to go anywhere.
But when I queried how these GObjects could be written in Vala no one knew since its documentation is a bit lacking (as in missing entirely) when it comes to interfacing to C.
Cheers Lex
On Sat, 30 Apr 2011 22:46:32 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Nick, I have suggested that the new plugin API be GObjects which are just thin shells referring everything to the existing Geany structures like GeanyDocument. The GObject methods just called one or more Geany functions that work on the existing structures. The only disruption I can see in core would be that it would need to emit the signals on these objects.
Even if there is one GObject per Geany structure (well the ones needed by plugins anyway) this would somewhat insulate the plugin interface from changes in the Geany structures since the GObject methods can be pointed at different places in the core without affecting the plugin API.
Since there is this insulation I tried to start the discussion whether the best set of GObjects was to have one per Geany structure or a different set of GObjects that used more than one Geany structure, making the GObjects a little more complicated but their use by plugins easier. But the discussion didn't seem to go anywhere.
But when I queried how these GObjects could be written in Vala no one knew since its documentation is a bit lacking (as in missing entirely) when it comes to interfacing to C.
Thanks for explaining. I still feel against the idea, but I won't try to veto it.
Regards, Nick
On 04/30/11 08:14, Nick Treleaven wrote:
Thanks for explaining. I still feel against the idea, but I won't try to veto it.
I think this is pretty much where we left off the previous discussion on GObject plugin API. Basically, the core developers are either against the idea or don't have time to accept/review/commit work on this, which means an "unspoken veto" of sorts. I'm not saying there's anything wrong with this per se, you guys guide/control the project's development, so it's really your choice.
Cheers, Matthew Brush
On 04/30/11 05:46, Lex Trotman wrote:
But when I queried how these GObjects could be written in Vala no one knew since its documentation is a bit lacking (as in missing entirely) when it comes to interfacing to C.
That's not true, the Vala bindings for Geany provide the "thin" mapping to the Geany structures to classes, and the Geany-DBus shows a way to make them real GObjects.
The documentation, while not perfect, is here: http://live.gnome.org/Vala/Manual/Attributes
Cheers, Matthew Brush
On 1 May 2011 09:19, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/30/11 05:46, Lex Trotman wrote:
But when I queried how these GObjects could be written in Vala no one knew since its documentation is a bit lacking (as in missing entirely) when it comes to interfacing to C.
That's not true, the Vala bindings for Geany provide the "thin" mapping to the Geany structures to classes, and the Geany-DBus shows a way to make them real GObjects.
The documentation, while not perfect, is here: http://live.gnome.org/Vala/Manual/Attributes
That was the bit I couldn't find when I last looked, and someone else agreed so thanks for pointing to it.
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 04/30/11 17:30, Lex Trotman wrote:
On 1 May 2011 09:19, Matthew Brushmbrush@codebrainz.ca wrote:
The documentation, while not perfect, is here: http://live.gnome.org/Vala/Manual/Attributes
That was the bit I couldn't find when I last looked, and someone else agreed so thanks for pointing to it.
It honestly isn't easy to find at all, I can't find a single place on live.gnome.org or elsewhere where it's linked. I had to google quite a few things to get back to it.
There's a similar piece of documentation that is linked from the main site: http://live.gnome.org/Vala/Manual/GIDL%20metadata%20format
Cheers, Matthew Brush
On 1 May 2011 10:37, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/30/11 17:30, Lex Trotman wrote:
On 1 May 2011 09:19, Matthew Brushmbrush@codebrainz.ca wrote:
The documentation, while not perfect, is here: http://live.gnome.org/Vala/Manual/Attributes
That was the bit I couldn't find when I last looked, and someone else agreed so thanks for pointing to it.
It honestly isn't easy to find at all, I can't find a single place on live.gnome.org or elsewhere where it's linked. I had to google quite a few things to get back to it.
There's a similar piece of documentation that is linked from the main site: http://live.gnome.org/Vala/Manual/GIDL%20metadata%20format
I didn't associate that with the values of cdata, but I'm *not* a Vala programmer. Now you have pointed out the other documentation it looks similar.
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel