Hi there,
some time I asked about a common SVN repository for external plugins. There were no response so far, so i ask again in a new thread ;-).
We could add a separate path(outside of the Geany source directory) for external plugins in Geany's Subversion repository and give plugin authors access to it.
If anyone is interested in using it, just ask.
Regards, Enrico
Enrico Tröger wrote:
We could add a separate path(outside of the Geany source directory) for external plugins in Geany's Subversion repository and give plugin authors access to it.
You could also provide access to a part of the Geany source tree (like ext_plugins), to make the use of autotools more simple.
If anyone is interested in using it, just ask.
I think this could be nice, that way we could maintain one common structure for build and distribution.
My CMake plugin are showing progress, and it would be nice if it was easy for testers to just grab that and other plugins from one common repos.
/BL
On Wed, 02 Jan 2008 22:42:13 +0100, Bo Lorentsen bl@lue.dk wrote:
Enrico Tröger wrote:
We could add a separate path(outside of the Geany source directory) for external plugins in Geany's Subversion repository and give plugin authors access to it.
You could also provide access to a part of the Geany source tree (like ext_plugins), to make the use of autotools more simple.
Well, IIRC there is no qay at sourceforge to finetune access permissions of the SVN repo, everyone who has write access can write all files in the repo. But I think this isn't a problem as long as nobody commits any code in paths where he shouldn't. I'm not sure what you mean with ext_plugins.
What I meant in my first post was simply the ability to create a subdirectory for external plugins beside the Geany source tree. Nothing more.
Regards, Enrico
Enrico Tröger wrote:
We could add a separate path(outside of the Geany source directory) for external plugins in Geany's Subversion repository and give plugin authors access to it.
You could also provide access to a part of the Geany source tree (like ext_plugins), to make the use of autotools more simple.
Well, IIRC there is no qay at sourceforge to finetune access permissions of the SVN repo, everyone who has write access can write all files in the repo. But I think this isn't a problem as long as nobody commits any code in paths where he shouldn't.
Ok, that is very true ... I have never used SF but only trac/svn on my work, ans subversion has some real nice features in this regard.
I'm not sure what you mean with ext_plugins.
Just an eks on a subdirname, and I think we agree on this subject :-)
What I meant in my first post was simply the ability to create a subdirectory for external plugins beside the Geany source tree. Nothing more.
Ok sounds really nice ...
/BL
On Jan 2, 2008 2:47 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
We could add a separate path(outside of the Geany source directory) for external plugins in Geany's Subversion repository and give plugin authors access to it.
Right now the Lua plugin is mostly a one-man operation, so I don't see any big advantage to providing a collaborative environment for it.
But if enough people really want access to code changes on a day-to-day basis, or if some others want to join the project then yes, I would certainly consider moving it into SVN.
I have also considered registering it at luaforge[1], they offer web space, CVS account, forums, mailing lists, bug tracker, etc. for any projects that use Lua.
That might also provide some additional exposure for Geany, there seem to be a fair amount of Lua fans who use SciTE, so another editor that provides Lua scripting might be a big hit in that community.
Of course it is also possible to register the project at luaforge and still maintain the code somewhere else, if the people here would rather keep a central location for all Geany plugins.
One thing I would like to set up somewhere is a repository for contributed geanylua scripts, but that should probably be some sort of wiki or forum or something like that.
Not sure if that answers any questions, but I'm open to feedback...
- Jeff
FWIW, I just released a new version of the Lua plugin yesterday, and already it is broken against current Geany SVN.
So maybe SVN access for plugins might be a good idea...
- Jeff
On Wed, 2 Jan 2008 16:25:43 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
FWIW, I just released a new version of the Lua plugin yesterday, and already it is broken against current Geany SVN.
So maybe SVN access for plugins might be a good idea...
And probably broken again because of r2147. I'm sorry.
Regards, Enrico
On Wed, 2 Jan 2008 15:55:24 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Jan 2, 2008 2:47 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
We could add a separate path(outside of the Geany source directory) for external plugins in Geany's Subversion repository and give plugin authors access to it.
Right now the Lua plugin is mostly a one-man operation, so I don't see any big advantage to providing a collaborative environment for it.
But if enough people really want access to code changes on a day-to-day basis, or if some others want to join the project then yes, I would certainly consider moving it into SVN.
I have also considered registering it at luaforge[1], they offer web space, CVS account, forums, mailing lists, bug tracker, etc. for any projects that use Lua.
That might also provide some additional exposure for Geany, there seem to be a fair amount of Lua fans who use SciTE, so another editor that provides Lua scripting might be a big hit in that community.
Of course it is also possible to register the project at luaforge and still maintain the code somewhere else, if the people here would rather keep a central location for all Geany plugins.
No, at least not me. I only intented to offer the possiblity to use Geany's SVN not to force external plugin authors to do so. It's completely up to you whether and where you use a version control system or whatever you do with your code ;-).
Regards, Enrico
Hi
On Wed, Jan 02, 2008 at 09:47:56PM +0100, Enrico Tröger wrote:
some time I asked about a common SVN repository for external plugins. There were no response so far, so i ask again in a new thread ;-).
We could add a separate path(outside of the Geany source directory) for external plugins in Geany's Subversion repository and give plugin authors access to it.
If anyone is interested in using it, just ask.
I think it can be used as a way of distributing. What if we add such repo as external reference to geany main tree and compile external plugins if configure option is set?
So:
svn up ./configure --with-external-plugins make make install
will compile and install geany and all available plugins.
It will be much easier for users to find plugin he/she want.
Best regards, Yura Siamashka
On Jan 2, 2008 6:41 PM, Yura Siamashka yurand2@gmail.com wrote:
Hi
On Wed, Jan 02, 2008 at 09:47:56PM +0100, Enrico Tröger wrote:
We could add a separate path(outside of the Geany source directory) for external plugins in Geany's Subversion repository and give plugin authors access to it.
If anyone is interested in using it, just ask.
I think it can be used as a way of distributing. What if we add such repo as external reference to geany main tree and compile external plugins if configure option is set?
So: be very nice svn up ./configure --with-external-plugins make make install
will compile and install geany and all available plugins.
It will be much easier for users to find plugin he/she want.
Best regards, Yura Siamashka
From a user's perspective, having the high-level language plug-in "just work" is, IMO, most important.
A Lua user who wants to try out Geany and write some plug-in code will want to just grab the Geany code, "./configure; make; make install" and then have a local directory (like ./geany/plug-ins/lua or something) to drop their code into and have it be available when they restart Geany. It probably shouldn't be any more difficult than that, and there should be very little that could go wrong, IMO.
Down the road, if there are very many Geany plug-ins available, at that point it would probably be nice to have a plug-in manager capable of downloading and installing plug-ins from some central archive (I think jEdit has something like this). Maybe such a plug-in manager could install the Lua plug-in for you. But since there's no central archive of plug-ins yet, and no plug-in manager capable of grabbing plug-ins from elsewhere on the 'Net and installing them for you, it would seem to make the most sense to just include the Lua plug-in with Geany (if Jeff were amenable to that).
Just my 2 cents.
---John
On Jan 2, 2008 7:09 PM, John Gabriele jmg3000@gmail.com wrote:
On Jan 2, 2008 6:41 PM, Yura Siamashka yurand2@gmail.com wrote:
Hi
So: be very nice
^^^^^
svn up ./configure --with-external-plugins
Whoops. Not sure how I managed to jam that paste typo into Yura's quoted reply there. :)
---John
On Jan 2, 2008 6:09 PM, John Gabriele jmg3000@gmail.com wrote:
But since there's no central archive of plug-ins yet, and no plug-in manager capable of grabbing plug-ins from elsewhere on the 'Net and installing them for you, it would seem to make the most sense to just include the Lua plug-in with Geany (if Jeff were amenable to that).
I don't see any big problems with that, I would be happy to have the Lua plugin distributed with the current/stable/offical/release of Geany, but as far as trying to maintain the plugin from inside the Geany SVN tree, things could get a little more complicated - what happens when someone from the Geany team makes a change to the Geany code that breaks something in the plugin? That means either the Geany team takes responsibility for fixing the plugin, or else the SVN users end up with a checkout that won't compile.
Another small nit I have is with the "or any later version" clause in the Geany license - somehow the idea of agreeing to enter into a contract that hasn't been written yet doesn't seem to me like a very wise thing to do. What if GPL-v4 says: "the author agrees to pay all users of this software $1000 USD per bug report" , well, I don't think I want to give users the option of choosing THAT version :-)
- Jeff
Jeff Pohlmeyer wrote:
On Jan 2, 2008 6:09 PM, John Gabriele jmg3000@gmail.com wrote:
Another small nit I have is with the "or any later version" clause in the Geany license - somehow the idea of agreeing to enter into a contract that hasn't been written yet doesn't seem to me like a very wise thing to do. What if GPL-v4 says: "the author agrees to pay all users of this software $1000 USD per bug report" , well, I don't think I want to give users the option of choosing THAT version :-)
I would think that a plugin may well have a different license than geany, as it is not a derivative work of geany. How about starting an endless discussion about derivative works as the linux kernel modules discussion ;-) There, the last word from Linus seems to be: A module is _not_ a derivative work, so the author can choose the license freely.
But of course Enrico would be the one to ask, no me.
- Jeff
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 03 Jan 2008 17:42:59 +0100, Tim Tassonis timtas@cubic.ch wrote:
Jeff Pohlmeyer wrote:
On Jan 2, 2008 6:09 PM, John Gabriele jmg3000@gmail.com wrote:
Another small nit I have is with the "or any later version" clause
Me too. This came from a template I used when starting to write Geany using Anjuta. At this point, I didn't thought about publishing the code at all and so I didn't thought about the licence problem. OTOH, I recently read an article about the GPLv2 vs. GPLv3 problem and the author(a German lawyer) mentioned it isn't applicable in this case because an user can't agree to a licence or contract which isn't already known or even written. The easiest thing would be to remove this phrase but are we allowed to?
in the Geany license - somehow the idea of agreeing to enter into a contract that hasn't been written yet doesn't seem to me like a very wise thing to do. What if GPL-v4 says: "the author agrees to pay all users of this software $1000 USD per bug report" , well, I don't think I want to give users the option of choosing THAT version :-)
I would think that a plugin may well have a different license than geany, as it is not a derivative work of geany. How about starting an endless discussion about derivative works as the linux kernel modules discussion ;-) There, the last word from Linus seems to be: A module is _not_ a derivative work, so the author can choose the license freely.
But of course Enrico would be the one to ask, no me.
Or a lawyer who I'm not. Besides any lethal considerations which I don't know, in my opinion the choice of the licence of plugins is independent from Geany's licence as long as it is compatible with GPLv2. I.e. a plugin can't choose a closed-source licence because it uses code from Geany which is licenced under the GPLv2. In order to so Geany would have been licenced under the LGPL. I'm not completely sure about this but just publish your plugin sources and all should be fine ;-).
But I suggest any further discussion on this topic should be done in a new thread.
Regards, Enrico
On Fri, 4 Jan 2008 15:23:33 +0100, Enrico Tröger enrico.troeger@uvena.de wrote:
But of course Enrico would be the one to ask, no me.
Or a lawyer who I'm not. Besides any lethal considerations which I don't know, in my opinion
^^^^^^ This should have been "legal" not "lethal" ;-).
Regards, Enrico
On Jan 2, 2008 8:11 PM, Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
On Jan 2, 2008 6:09 PM, John Gabriele jmg3000@gmail.com wrote:
But since there's no central archive of plug-ins yet, and no plug-in manager capable of grabbing plug-ins from elsewhere on the 'Net and installing them for you, it would seem to make the most sense to just include the Lua plug-in with Geany (if Jeff were amenable to that).
I don't see any big problems with that, I would be happy to have the Lua plugin distributed with the current/stable/offical/release of Geany, but as far as trying to maintain the plugin from inside the Geany SVN tree, things could get a little more complicated - [snip]
Another small nit I have is with the "or any later version" clause in the Geany license - [snip]
Hm. To sidestep issues about licensing and also maintainability, *and* to keep the Geany core small, it would seem to me that Geany would benefit from having a plug-in manager that could download and install plug-ins.
---John
On Jan 3, 2008 2:28 PM, John Gabriele jmg3000@gmail.com wrote:
it would seem to me that Geany would benefit from having a plug-in manager that could download and install plug-ins.
That would be a great feature, but it could get really complicated. How would you handle the networking code?
It would be possible to write it from scratch, but it would be easier to rely on some some ready-made library, but that adds yet another dependency to Geany. I guess most Linux boxes will have libcurl, and possibly we could use wininet.dll on windows. I know Firefox uses SSL for downloading extensions, I don't guess we really need to go that far, but that would mean also depending on something like OpenSSL or GnuTLS.
Then there is also the question of what sort of repository to use, so that Geany knows where and how to look for the available plugins, and some means of checking compatibilty.
For starters, maybe if we just had a consistent package format for the plugins, and a plugin manager that could install/uninstall them from local hard drive, then maybe we could work out the networking stuff later.
- Jeff
On Jan 3, 2008 4:05 PM, Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
For starters, maybe if we just had a consistent package format for the plugins, and a plugin manager that could install/uninstall them from local hard drive, then maybe we could work out the networking stuff later.
Great idea, IMO.
On Thu, 3 Jan 2008 15:28:31 -0500 "John Gabriele" jmg3000@gmail.com wrote:
Hm. To sidestep issues about licensing and also maintainability, *and* to keep the Geany core small, it would seem to me that Geany would benefit from having a plug-in manager that could download and install plug-ins.
I don't think that fits in the core of Geany, and it would be a lot of work. One major show stopper would be that on Linux you can't just install a binary plugin (or at least not with a lot of expertise) that will work across different distributions, versions of glibc, etc.
Regards, Nick
On Fri, 4 Jan 2008 13:00:57 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 3 Jan 2008 15:28:31 -0500 "John Gabriele" jmg3000@gmail.com wrote:
Hm. To sidestep issues about licensing and also maintainability, *and* to keep the Geany core small, it would seem to me that Geany would benefit from having a plug-in manager that could download and install plug-ins.
I don't think that fits in the core of Geany, and it would be a lot of work. One major show stopper would be that on Linux you can't just install a binary plugin (or at least not with a lot of expertise) that will work across different distributions, versions of glibc, etc.
There is another problem(nowadays) with installing binaries from the net: security. On Debian, the package manager uses GPG signatures to verify you download only the official, unmodified binary packages to minimise any security risks. A security aware user shouldn't install or use any binaries which are downloaded from the net without proper verification. I'm going to do something similar with the Geany binaries for Windows in the future. They will probably signed with my certificate to ensure they weren't modified at any point.
And the alternative would be to compile plugins from source which raises a couple of new problems: * compile environment(compiler, linker, ...) * necessary libraries and their development files (GTK, GLib, any plugin specific requirements, ...) * make use of any package manager? Every distribution uses it's own with it's own package names * ...
To make a long story short, if anyone feels really bored, please go for it and write a plugin for a plugin manager of this kind. But something like this won't be in Geany's core. IMO, this is too complex, too error-prone. Of course, the advantage would be a nice user experience.
Regards, Enrico
I'm responding to several different messages at once here, hope you can follow it...
if the people here would rather keep a central location for all Geany plugins.
No, at least not me. I only intented to offer the possiblity to use Geany's SVN not to force external plugin authors to do so
Yes, I understand you weren't trying to force anything.
What I was trying to say is that I don't want to feel like the "odd man out" if everyone else wants to move their plugins into Geany's SVN.
Well, IIRC there is no way at sourceforge to finetune access permissions of the SVN repo, everyone who has write access can write all files in the repo. But I think this isn't a problem as long as nobody commits any code in paths where he shouldn't.
Hmmm.. I thought maybe you could to set up restrictions for various users and directories. Of course it's up to you, but it seems like it might turn into a real administrative nightmare, whether to allow John Doe write access to the entire repository for his new coffeemaker plugin, or risk hurting his feelings by rejecting it.
One major show stopper would be that on Linux you can't just install a binary plugin that will work across different distributions, versions of glibc, etc.
And things get even more complicated if the plugin requires additional third-party libraries or applications, like maybe libpython, etc...
And to add one more dependency, I imagine the plugin format would require some sort of archiving and compression library.
There is another problem with installing binaries from the net: security. A security aware user shouldn't install or use any binaries without proper verification.
Which I think also argues for keeping SVN commit access to a bare minimum.
To make a long story short, if anyone feels really bored, please go for it and write a plugin for a plugin manager of this kind.
I think I'll pass on that one :-)
- Jeff
On Fri, 4 Jan 2008 12:09:49 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
Well, IIRC there is no way at sourceforge to finetune access permissions of the SVN repo, everyone who has write access can write all files in the repo. But I think this isn't a problem as long as nobody commits any code in paths where he shouldn't.
Hmmm.. I thought maybe you could to set up restrictions for various users and directories. Of course it's up to you,
I just had a look at the admin area on SF and I can only give SVn write access to SF users but I can't say user John is allowed to write in directory geany_plugins and user Jane is allowed to write in directory geany. If one has write access, he has write access to the whole repository.
but it seems like it might turn into a real administrative nightmare, whether to allow John Doe write access to the entire repository for his new coffeemaker plugin, or risk hurting his feelings by rejecting it.
Hmm, I thought it might work by saying you can technically write to everything in the repository but you are only responsible for your plugin code and have to left all other things as they are. We are not talking about anonymous right access, only to user who are registered at SF and who I(or Nick) added to the Geany project as developers. But maybe there is another, better solution for all this. Maybe by creating an extra SF project explicitly for Geany plugins. Or we just forget all about this and every plugin author has to decide on its own whether and where he use a version control system. The idea behind this was only to offer the possibility to use our SVN repo in case the author want to use own and doesn't have the ability to use a version control system anywhere else. Just to mention it there is http://repo.or.cz/ where one can create a GIT repository for free.
There is another problem with installing binaries from the net: security. A security aware user shouldn't install or use any binaries without proper verification.
Which I think also argues for keeping SVN commit access to a bare minimum.
Well yes and no. Basically you are right but if anyone would commit any crap to geany itself without any confirmation we at least see what he has done in the commit messages. There is a commit mailing list (http://uvena.de/cgi-bin/mailman/listinfo/geany-commits) which is at least read by me and Nick and so we see that someone has committed something and in case it's really bad we can revert it and remove the write access of this user.
Regards, Enrico
On Jan 6, 2008 10:27 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
But maybe there is another, better solution for all this. Maybe by creating an extra SF project explicitly for Geany plugins.
Yes, I thought about that too - the Lazarus project has something similar: http://lazarus-ccr.sourceforge.net/
That would at least solve the problem of protecting the Geany code base, but it still isn't a 100% fix since it plugin authors would still have commit access to each other's code, and someone would still have the nasty job of deciding which projects have enough "merit" to be allowed into the repository.
Having a central hub for plugin development seems like a good idea, but considering how much vaporware and abandonware there is on sourceforge, I'm afraid this "geanyforge" idea might be more trouble than it's worth.
Having plugin projects scattered all over the net might actually have some advantages as well, someone who never heard of Geany might discover it while browsing the project list at repo.or.cz or luaforge.net or wherever.
So I would say for now the current setup of having the list of external plugin links on the Geany homepage is adequate, at least for me.
- Jeff
On Sun, 6 Jan 2008 22:32:55 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Jan 6, 2008 10:27 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
But maybe there is another, better solution for all this. Maybe by creating an extra SF project explicitly for Geany plugins.
Yes, I thought about that too - the Lazarus project has something similar: http://lazarus-ccr.sourceforge.net/
That would at least solve the problem of protecting the Geany code base, but it still isn't a 100% fix since it plugin authors would still have commit access to each other's code, and someone would still have the nasty job of deciding which projects have enough "merit" to be allowed into the repository.
Having a central hub for plugin development seems like a good idea, but considering how much vaporware and abandonware there is on sourceforge, I'm afraid this "geanyforge" idea might be more trouble than it's worth.
Just another idea(the last one ;-)): Maye we can use a tracker on Sourceforge to manage plugin related announces, bugs and so on. Similar to how pigdin it does: http://sourceforge.net/tracker/?group_id=235&atid=390395 Of course, only for those plugin authors who want to use it but it might help a bit at least.
Having plugin projects scattered all over the net might actually have some advantages as well, someone who never heard of Geany might discover it while browsing the project list at repo.or.cz or luaforge.net or wherever.
Maybe but I guess more users will search for a certain plugin for Geany. Both variants would be cool, we have a central place where plugin development *can* take place and many links and references to it widely spread in the net ;-). (don't take this too serious please)
So I would say for now the current setup of having the list of external plugin links on the Geany homepage is adequate, at least for me.
At least this doesn't effort any extra work ;-).
Regards, Enrico
On Sun, 6 Jan 2008 22:32:55 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Jan 6, 2008 10:27 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
But maybe there is another, better solution for all this. Maybe by creating an extra SF project explicitly for Geany plugins.
Yes, I thought about that too - the Lazarus project has something similar: http://lazarus-ccr.sourceforge.net/
That would at least solve the problem of protecting the Geany code base, but it still isn't a 100% fix since it plugin authors would still have commit access to each other's code, and someone would still have the nasty job of deciding which projects have enough "merit" to be allowed into the repository.
I finally remember where my optimism is based on that a common, separate repository for different plugin authors may work: the Xfce Goodies project. Anyone who want to write and publish a Goodie(Xfce speak for addon) can register an account and get (after human approval AFAIK) a subversion account to the Goodie repository where he or she can commit code. And it works, I read the goodie-commits mailing list and I have also access to this repository. At least in the past two years, I didn't noticed any misuse by anyone. In contrary, the common write access has also advantages(at least a few): I wrote a plugin for the Xfce panel, committed my code into the repository and some days later the first users contributed translations to the Xfce-i18n mailing list. The responsible translation supervisors committed the translations into my plugin's po directory without I had anything to do. And by commit mails and careful reading of svn log's an author can reproduce what have been done in the repository.
This is not meant to be the ultimate, last word. I just want to mention it may work and is not doomed by default ;-). But as long as nobody says something like "yes, I want to use it" there isn't much need to further talk about it. I don't care, it was just a try to help developers.
Regards, Enrico
On Sun, 6 Jan 2008 17:27:08 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
[...]
I just had a look at the admin area on SF and I can only give SVn write access to SF users but I can't say user John is allowed to write in directory geany_plugins and user Jane is allowed to write in directory geany. If one has write access, he has write access to the whole repository.
[...]
But maybe there is another, better solution for all this. Maybe by creating an extra SF project explicitly for Geany plugins. Or we just forget all about this and every plugin author has to decide on its own whether and where he use a version control system.
I think it would be better to have a geany-plugins type project than give some plugin authors write access to Geany. Just because it would be quite tempting to add something to the plugin API that a plugin needed, that wasn't the best function to be there (maybe it needs tidying up, less arguments or to be more flexible, or just not the best way of doing something).
It would still be up to plugin authors whether they use it or not, but the advantages would be that it might encourage people to use version control, and there would be the possibility of us core developers to fix compatibility issues.
Regards, Nick
Hi,
On Fri, 4 Jan 2008 13:00:57 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
I don't think that fits in the core of Geany, and it would be a lot of work. One major show stopper would be that on Linux you can't just install a binary plugin (or at least not with a lot of expertise) that will work across different distributions, versions of glibc, etc.
You have to think about, that there not only Linux-users outside, but also users of some strange operationg systems like Windows, AIX, Solaris, MacOS, OS/2, BeOS, Zeta, NetBSD, FeeBSD, OpenBSD .... We are not using JAVA, Mono or any other bytecode-interpreter language. So I'd suppose to distribute plugins in a suitable way, that users are able to use package managing system of their distribution like apt or yast.
But if there will be a big number of Lua plugins or maybe in future some written in Python I could imagine to have some kind of plugin manager allowing downloading of plugins from a central server. But not for plugins written in C.
Frank
Hi,
On Sat, 5 Jan 2008 15:10:04 +0100 Frank Lanitz linux@partysoke.de wrote:
On Fri, 4 Jan 2008 13:00:57 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
I don't think that fits in the core of Geany, and it would be a lot of work. One major show stopper would be that on Linux you can't just install a binary plugin (or at least not with a lot of expertise) that will work across different distributions, versions of glibc, etc.
You have to think about, that there not only Linux-users outside, but also users of some strange operationg systems like Windows, AIX, Solaris, MacOS, OS/2, BeOS, Zeta, NetBSD, FeeBSD, OpenBSD .... We are not using JAVA, Mono or any other bytecode-interpreter language. So I'd suppose to distribute plugins in a suitable way, that users are able to use package managing system of their distribution like apt or yast.
But if there will be a big number of Lua plugins or maybe in future some written in Python I could imagine to have some kind of plugin manager allowing downloading of plugins from a central server. But not for plugins written in C.
I have to revert myself a bit. I could imagine to build up something, that works like a frontend to wget, configure and make: Downloading a src-tarball from central server, extracting it and run the triple to install it. Well... to be honest: I'm not sure and should be better quiet ;D
Frank
On Jan 5, 2008 1:41 PM, Frank Lanitz linux@partysoke.de wrote:
On Sat, 5 Jan 2008 15:10:04 +0100 Frank Lanitz linux@partysoke.de also wrote:
But if there will be a big number of Lua plugins or maybe in future some written in Python I could imagine to have some kind of plugin manager allowing downloading of plugins from a central server. But not for plugins written in C.
I have to revert myself a bit. I could imagine to build up something, that works like a frontend to wget, configure and make: Downloading a src-tarball from central server, extracting it and run the triple to install it. Well... to be honest: I'm not sure and should be better quiet ;D
I think, Frank, that in your previous post you hit the nail on the head. Users, in general, will probably not want to write their Geany plug-ins in C. And plug-ins written in a HLL like Lua are easily distributed among different platforms.
So, if the Lua plug-in came standard with Geany, it would probably be good for Geany to provide some central archive of Lua plug-ins. But, at this point (without having the Lua plug-in in the core), if users are writing plug-ins in Lua, maybe they could let Jeff know -- and if the number of them hits some critical mass, Jeff might even start his own archive. ;)
---John
On Sat, 5 Jan 2008 15:14:07 -0500, "John Gabriele" jmg3000@gmail.com wrote:
On Jan 5, 2008 1:41 PM, Frank Lanitz linux@partysoke.de wrote:
On Sat, 5 Jan 2008 15:10:04 +0100 Frank Lanitz linux@partysoke.de also wrote:
But if there will be a big number of Lua plugins or maybe in future some written in Python I could imagine to have some kind of plugin manager allowing downloading of plugins from a central server. But not for plugins written in C.
I have to revert myself a bit. I could imagine to build up something, that works like a frontend to wget, configure and make: Downloading a src-tarball from central server, extracting it and run the triple to install it. Well... to be honest: I'm not sure and should be better quiet ;D
I think, Frank, that in your previous post you hit the nail on the head. Users, in general, will probably not want to write their Geany plug-ins in C. And plug-ins written in a HLL like Lua are easily
Lua is high-level programming level and C not? At least some years ago C was also a high-level programming language ;-). SCNR.
So, if the Lua plug-in came standard with Geany, it would probably be good for Geany to provide some central archive of Lua plug-ins. But, at this point (without having the Lua plug-in in the core), if users are writing plug-ins in Lua, maybe they could let Jeff know -- and if the number of them hits some critical mass, Jeff might even start his own archive. ;)
It would be cool to have something like the mentioned "plugin manager" which downloads, build(if necessary) and install various plugins by one click and without any further user interaction. I'm not against something like this. But I think this could (and should) be done itself as a plugin and I won't work on this.
Regards, Enrico
On Jan 6, 2008 11:07 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 5 Jan 2008 15:14:07 -0500, "John Gabriele" jmg3000@gmail.com wrote:
I think, Frank, that in your previous post you hit the nail on the head. Users, in general, will probably not want to write their Geany plug-ins in C. And plug-ins written in a HLL like Lua are easily
Lua is high-level programming level and C not? At least some years ago C was also a high-level programming language ;-). SCNR.
I see your point, Enrico, but my hunch is still that, if an average Geany user wants a plug-in that doesn't yet exist, they're most likely going to write it in a "high-level scripting language", or not write it at all. Of course, my crystal ball has been failing unit tests since I first plucked it from the land fill, so take that with a grain of salt. :)
---John
On Sun, 6 Jan 2008 15:58:05 -0500, "John Gabriele" jmg3000@gmail.com wrote:
On Jan 6, 2008 11:07 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 5 Jan 2008 15:14:07 -0500, "John Gabriele" jmg3000@gmail.com wrote:
I think, Frank, that in your previous post you hit the nail on the head. Users, in general, will probably not want to write their Geany plug-ins in C. And plug-ins written in a HLL like Lua are easily
Lua is high-level programming level and C not? At least some years ago C was also a high-level programming language ;-). SCNR.
I see your point, Enrico, but my hunch is still that, if an average Geany user wants a plug-in that doesn't yet exist, they're most likely going to write it in a "high-level scripting language", or not write it at all. Of course, my crystal ball has been failing unit tests since I first plucked it from the land fill, so take that with a grain of salt. :)
Sure ;-). I know what you mean, I just wanted to mention that IMO C is also a high-level programming language and yes, it's not a scripting language. And yes, I also agree that average users(dangerous to speak about "average" users in general ;-)) might rather be or get familar with some easy scripting languages than with a real programming language. Just a matter of taste and for plugins it might be indeed useful to use scripting languages if possible. Btw, I would like to work on the Python integration but still no idea how. If anyone has any experiences with that or know a good resource of documentation, feel free to post it(in a new thread please).
Regards, Enrico
On Jan 5, 2008 2:14 PM, John Gabriele jmg3000@gmail.com wrote:
if users are writing plug-ins in Lua, maybe they could let Jeff know -- and if the number of them hits some critical mass, Jeff might even start his own archive. ;)
Yes, I had hinted to something like that in one of my earlier posts. Another advantage is AFAIK scripts are not as encumbered by licensing issues as compiled plugins.
- Jeff
On Wed, 2 Jan 2008 19:11:57 -0600 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
Another small nit I have is with the "or any later version" clause in the Geany license - somehow the idea of agreeing to enter into a contract that hasn't been written yet doesn't seem to me like a very wise thing to do. What if GPL-v4 says: "the author agrees to pay all users of this software $1000 USD per bug report" , well, I don't think I want to give users the option of choosing THAT version :-)
Of course this would be up to Enrico, but if you wanted to distribute the Lua plugin code with Geany, it is possible to license it differently from Geany. This is already the case with the Scintilla library, which has it's own license (we added a note about this in the README and manual).
Regards, Nick