Hey,
yesterday, I talked to Chow Loong Jin on IRC about the whole recent plugins release issues and we came across an interesting question about restructuring the whole way how we organise our external plugins currently.
We once said, plugins should be and keep independent so they can installed on their own and without the need to install all other plugins. Therefore, currently each plugin (those in the geany-plugins project) have an own build system, based on autotools. Additionally we have a common build system, based on waf, which one can use to build all plugins at once from SVN.
While discussing how a possible geany-plugins release could be done and what's necessary, we came across the idea of changing the above idea: give up the independence of each plugin and instead create one big project consisting of the various plugins but with only one build system. Following you'll find a list of pros and cons which instantly came to my mind as some kind of rationale.
Pros: - easier developing for plugin authors, no need to fiddle with the own build system, no stress about creating releases, you can just concentrate on coding - one central po/ directory with translations of all plugins which makes it much easier for translators so we hopefully get more translations for the plugins - just one global build system, easier for developers, release manager and users - with Chow Loong Jin we get a release manager who takes care of creating releases and their coordination
Cons: - we loose the independence of plugins, i.e. plugins can't be released on their own anymore or at least it gets harder to do so - we will end up with one big geany-plugins release which probably contains more plugins than users generally want/need (however the build system should allow users to exclude certain plugins from being built and automatically exclude those which can't be built due to missing dependencies) - plugins (rather plugin releases) get dependent of other plugins and their authors and after all, dependent of the release manager
One more note about translations: Yesterday, Frank mentioned he succeeded in writing a script to manage a global gettext system for plugins by copying and merging the individual message catalogues. However, this is of course just some kind of hack and far away from a clean solution. So, this is both, an argument for and against the above idea. It could be a workaround if we keep the current way of managing plugins, OTOH it shows the advantages of changing the handling.
So, you'll see this is some kind of basic question about the future of our plugins organisation. And because this affects all further actions, I'd like to hear your feedback first before continuing the other recent thread. Thanks.
I ask especially all current plugin authors for their opinion since this affects you directly. We don't want to decide anything without and force you to anything you don't want.
Raise your voice. Thanks.
I personally am not yet completely done with my decision as I still think separated, independent plugins is a good idea. But on the other hand, the advantages like the better translation coordination and the loss of responsibility of creating releases tempts me to change my mind (I don't like creating releases :D).
Regards, Enrico
P.S.: sorry for the mass of text, I tried to keep it short but obviously failed :(.
I'm no plugin creator (yet), and as such probably can't provide any valuable insights here, but nevertheless, here goes...
Maybe, the plugin creators themselves could decide if they wanted to be added to this central plugin scheme. And if a plugin creator doesn't want that, he can just as well keep his own build system and make releases on his own, so the users of his plugin can install at their leisure. The downsides of this will be known, as the end-user will most certainly have a more difficult time getting the plugin and keeping it up to date (hail packages!).
So the way I see it, it's not an either-or situation, just a logical or situation (note that I didn't say xor ;) ).
Kind regards, Nicolas
2009/6/3 Enrico Tröger enrico.troeger@uvena.de
Hey,
yesterday, I talked to Chow Loong Jin on IRC about the whole recent plugins release issues and we came across an interesting question about restructuring the whole way how we organise our external plugins currently.
We once said, plugins should be and keep independent so they can installed on their own and without the need to install all other plugins. Therefore, currently each plugin (those in the geany-plugins project) have an own build system, based on autotools. Additionally we have a common build system, based on waf, which one can use to build all plugins at once from SVN.
While discussing how a possible geany-plugins release could be done and what's necessary, we came across the idea of changing the above idea: give up the independence of each plugin and instead create one big project consisting of the various plugins but with only one build system. Following you'll find a list of pros and cons which instantly came to my mind as some kind of rationale.
Pros:
- easier developing for plugin authors, no need to fiddle with the own
build system, no stress about creating releases, you can just concentrate on coding
- one central po/ directory with translations of all plugins which
makes it much easier for translators so we hopefully get more translations for the plugins
- just one global build system, easier for developers, release manager
and users
- with Chow Loong Jin we get a release manager who takes care of
creating releases and their coordination
Cons:
- we loose the independence of plugins, i.e. plugins can't be released
on their own anymore or at least it gets harder to do so
- we will end up with one big geany-plugins release which probably
contains more plugins than users generally want/need (however the build system should allow users to exclude certain plugins from being built and automatically exclude those which can't be built due to missing dependencies)
- plugins (rather plugin releases) get dependent of other plugins and
their authors and after all, dependent of the release manager
One more note about translations: Yesterday, Frank mentioned he succeeded in writing a script to manage a global gettext system for plugins by copying and merging the individual message catalogues. However, this is of course just some kind of hack and far away from a clean solution. So, this is both, an argument for and against the above idea. It could be a workaround if we keep the current way of managing plugins, OTOH it shows the advantages of changing the handling.
So, you'll see this is some kind of basic question about the future of our plugins organisation. And because this affects all further actions, I'd like to hear your feedback first before continuing the other recent thread. Thanks.
I ask especially all current plugin authors for their opinion since this affects you directly. We don't want to decide anything without and force you to anything you don't want.
Raise your voice. Thanks.
I personally am not yet completely done with my decision as I still think separated, independent plugins is a good idea. But on the other hand, the advantages like the better translation coordination and the loss of responsibility of creating releases tempts me to change my mind (I don't like creating releases :D).
Regards, Enrico
P.S.: sorry for the mass of text, I tried to keep it short but obviously failed :(.
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 2009-06-03 at 20:02 +0200, Enrico Tröger wrote:
We once said, plugins should be and keep independent so they can installed on their own and without the need to install all other plugins. Therefore, currently each plugin (those in the geany-plugins project) have an own build system, based on autotools. Additionally we have a common build system, based on waf, which one can use to build all plugins at once from SVN.
While discussing how a possible geany-plugins release could be done and what's necessary, we came across the idea of changing the above idea: give up the independence of each plugin and instead create one big project consisting of the various plugins but with only one build system. Following you'll find a list of pros and cons which instantly came to my mind as some kind of rationale.
[...]
So, you'll see this is some kind of basic question about the future of our plugins organisation. And because this affects all further actions, I'd like to hear your feedback first before continuing the other recent thread. Thanks.
I ask especially all current plugin authors for their opinion since this affects you directly. We don't want to decide anything without and force you to anything you don't want.
Raise your voice. Thanks.
I am most definitely in favor of joining plugins together into one build system and released package. Having a separate build system always seemed unnecessary to me, and as Nicolas said, plugin authors that want to keep their software separate are certainly free to do so.
The most preferrable situation IMHO is that a user installing geany for the first time has all the plugins available -- even enabled -- the moment he starts up the editor. You can make a good argument that putting plugins and geany together is a (distribution) package maintainer's job, but certainly having a geany-plugins release together with geany releases will help a great deal with this.
Hi,
On Wed, 3 Jun 2009 20:02:07 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
We once said, plugins should be and keep independent so they can installed on their own and without the need to install all other plugins. Therefore, currently each plugin (those in the geany-plugins project) have an own build system, based on autotools. Additionally we have a common build system, based on waf, which one can use to build all plugins at once from SVN.
I'd like to keep this way. Reasons for: A plugin like geanyLaTeX is only needed by a very low number of people (unfortunately) around on the one hand, on the other hand its using some memory and needs to be distributed with other maybe needed plugins. A plugin like geanyLua is depending on Lua, which is quiet popular but not as popular as everybody got Lua installed or is using it at all. These are only two plugins which might cause trouble since availability would be left to the plugin management (how every this will be organised in future) and package maintainer in case of all plguins were joined since they are the persons which are deciding which items will make there way into the big package and which compiling options are used and of course which dependencies will the package have. So either some plugins are not distributed even they are in the project might causing bug reports etc by unsatisfied users or the package will gets too big. Just to show what I mean: I've got all plugins installed from geany main distribution as well as from the geany-plugins project - 18 if wc is counting correct - which takes about 2MB only for the *.so files on my AMD64 Debian/Linux system. The translation files for German language takes about 40KB at the moment. I know its all not this much on modern systems, but when I have a look onto the plugin wish list I'm getting a feeling this values will increase by factor 10 soon.
Please don't take me wrong. I like the current way to build all plugins together and like to see this improved by e.g. the already mentioned merging features for translation but I'd like to keep the decision up to the user. Also I don't care much whether autotools or waf or cmake or smake or whatever is used for (even though waf is most sympatic to me at the moment) as long as it just works. Also I agree that this can be used by distributions as e.g. done with the pidgin plugins or other *-plugins packages - but this is up to the packagers and should be discussed on Debian-/Ubuntu-/openSUSE-/Fedora-/Gentoo-/*BSD-/-project.
As a conclusion I pretty much vote for: - leaving plugins independent - Improving the build system of plugins (maybe providing some good template - feature request for geanyprj?;) ) - Improving the build system for a geany-plugins release to support a regular snapshot release as well as supporting the merging of po files.
Cheers, Frank
On Wed, 3 Jun 2009 23:24:28 +0200, Frank wrote:
Hey,
On Wed, 3 Jun 2009 20:02:07 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
We once said, plugins should be and keep independent so they can installed on their own and without the need to install all other plugins. Therefore, currently each plugin (those in the geany-plugins project) have an own build system, based on autotools. Additionally we have a common build system, based on waf, which one can use to build all plugins at once from SVN.
I'd like to keep this way. Reasons for: A plugin like geanyLaTeX is only needed by a very low number of people (unfortunately) around on the one hand, on the other hand its using some memory and needs to be distributed with other maybe needed
Only if users activate the plugin, I think the disk space it needs when only being installed can be ignored.
plugins. A plugin like geanyLua is depending on Lua, which is quiet popular but not as popular as everybody got Lua installed or is using it at all. These are only two plugins which might cause trouble since
Same as above. If users don't have installed Lua, the Lua plugin can't be loaded at all, so there is no problem.
Just to show what I mean: I've got all plugins installed from geany main distribution as well as from the geany-plugins project - 18 if wc is counting correct - which takes about 2MB only for the *.so files on
Well, if you strip your binaries, you will notice it only takes about 600K. So again, this isn't really a matter.
As a conclusion I pretty much vote for: [...]
- Improving the build system for a geany-plugins release to support a
regular snapshot release as well as supporting the merging of po files.
IMO regular snapshot releases are independent of the build system as such, it's more a matter of the timing and from where to take the code for a release (trunk, branches, tags, whatever).
As the others said, in theory we could do both: a common infrastructure of plugins whose authors wish it (that is, *one* build system, *one* translation system) and keep the other plugins separated. So, for now this would result in a common plugin package including spellcheck, addons (mine), shiftcolumn (Andrew) and geanydoc, externdbg (Yura). Then geanylatex, geanylipsum, geanysendmail (Frank) would keep separated and so won't benefit from the changes at all.
(not sure about the other plugins)
Thinking about this makes me even more puzzled as this would make things even more complicated for packagers and especially for users. Then they can install some plugins bundled together (spellcheck, addons, shiftcolumn, ...) and they must install others explicitly (geanylatex, geanysendmail, geanylipsum). Not to mention the hazzle for package maintainers.
So, I think if ever we need to find a solution for all or at least most plugins not only for some. And since Frank won't agree on the proposal of a common plugin project, I guess we will keep the current way with all its limitations as already pointed out and need to find workarounds or whatever for the translation issues and stuff.
Regards, Enrico
On Fri, 5 Jun 2009 17:03:00 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
(not sure about the other plugins)
I can look after the geanylua plugin, I think that should be part of the common release.
...
So, I think if ever we need to find a solution for all or at least most plugins not only for some. And since Frank won't agree on the proposal of a common plugin project, I guess we will keep the current way with all its limitations as already pointed out and need to find workarounds or whatever for the translation issues and stuff.
Well, I think there will perhaps be people that only want SVN access, not anything else. So I propose we use trunk, tags, branches for common geany-plugins code, and make another path for devs that only want SVN access, and move those folders there.
e.g. trunk/ configure.ac geanylua/ etc tags/ geany-plugins-0.17 branches/ geany-plugins-0.17 other/ someproject/
Then the dev could also create their own tags etc. subdirectories, it would be up to them.
Regards, Nick
On Fri, 5 Jun 2009 16:35:17 +0100, Nick wrote:
On Fri, 5 Jun 2009 17:03:00 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
(not sure about the other plugins)
I can look after the geanylua plugin, I think that should be part of the common release.
...
So, I think if ever we need to find a solution for all or at least most plugins not only for some. And since Frank won't agree on the proposal of a common plugin project, I guess we will keep the current way with all its limitations as already pointed out and need to find workarounds or whatever for the translation issues and stuff.
Well, I think there will perhaps be people that only want SVN access, not anything else. So I propose we use trunk, tags, branches for common geany-plugins code, and make another path for devs that only want SVN access, and move those folders there.
e.g. trunk/ configure.ac geanylua/ etc tags/ geany-plugins-0.17 branches/ geany-plugins-0.17 other/ someproject/
Then the dev could also create their own tags etc. subdirectories, it would be up to them.
Sounds quite good so far and wouldn't require much more than a 'svn mkdir other' :).
But still the problem what I'm afraid of is that we end up in a mix of various plugins, plugin releases and users might get confused where which plugin is how developed and by whom. OTOH while thinking about, this is already partly the case as it will be always with independent plugins especially when a plugin author doesn't use the geany-plugins Sourceforge project and instead use some other place for hosting. So, my worries about that are maybe exaggerated. Perhaps it's enough when we try to keep update to date with the index page at http://plugins.geany.org and http://www.geany.org/Support/Plugins as a some kind of reference list of known plugins.
Regards, Enrico
On Sun, 2009-06-07 at 19:07 +0200, Enrico Tröger wrote:
Sounds quite good so far and wouldn't require much more than a 'svn mkdir other' :).
But still the problem what I'm afraid of is that we end up in a mix of various plugins, plugin releases and users might get confused where which plugin is how developed and by whom. OTOH while thinking about, this is already partly the case as it will be always with independent plugins especially when a plugin author doesn't use the geany-plugins Sourceforge project and instead use some other place for hosting. So, my worries about that are maybe exaggerated. Perhaps it's enough when we try to keep update to date with the index page at http://plugins.geany.org and http://www.geany.org/Support/Plugins as a some kind of reference list of known plugins.
I'm all for this. So, which plugin developers (and the plugins they develop) are in favour of this move exactly? Perhaps we could have some sort of page on the website documenting this?
On Wed, 2009-06-10 at 04:34 +0800, Chow Loong Jin wrote:
On Sun, 2009-06-07 at 19:07 +0200, Enrico Tröger wrote:
Sounds quite good so far and wouldn't require much more than a 'svn mkdir other' :).
But still the problem what I'm afraid of is that we end up in a mix of various plugins, plugin releases and users might get confused where which plugin is how developed and by whom. OTOH while thinking about, this is already partly the case as it will be always with independent plugins especially when a plugin author doesn't use the geany-plugins Sourceforge project and instead use some other place for hosting. So, my worries about that are maybe exaggerated. Perhaps it's enough when we try to keep update to date with the index page at http://plugins.geany.org and http://www.geany.org/Support/Plugins as a some kind of reference list of known plugins.
I'm all for this. So, which plugin developers (and the plugins they develop) are in favour of this move exactly? Perhaps we could have some sort of page on the website documenting this?
That's just how it is now, and I don't think the status quo is nearly good enough. I've explained my point of view earlier in this thread.
I am the author of the Tasks plugin, part of the "addons" set of small plugins.
On Wed, 10 Jun 2009 04:34:08 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sun, 2009-06-07 at 19:07 +0200, Enrico Tröger wrote:
Sounds quite good so far and wouldn't require much more than a 'svn mkdir other' :).
But still the problem what I'm afraid of is that we end up in a mix of various plugins, plugin releases and users might get confused where which plugin is how developed and by whom. OTOH while thinking about, this is already partly the case as it will be always with independent plugins especially when a plugin author doesn't use the geany-plugins Sourceforge project and instead use some other place for hosting. So, my worries about that are maybe exaggerated. Perhaps it's enough when we try to keep update to date with the index page at http://plugins.geany.org and http://www.geany.org/Support/Plugins as a some kind of reference list of known plugins.
I'm all for this. So, which plugin developers (and the plugins they develop) are in favour of this move exactly? Perhaps we could have some sort of page on the website documenting this?
I'm afraid I'm not 100% sure which point you are referring here to? Having a including-all-plugins-list-on-homepage or the general refactoring of svn and geany-pugins release?
Cheers, Frank
On Wed, 10 Jun 2009 11:56:42 +0200, Frank wrote:
On Wed, 10 Jun 2009 04:34:08 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sun, 2009-06-07 at 19:07 +0200, Enrico Tröger wrote:
Sounds quite good so far and wouldn't require much more than a 'svn mkdir other' :).
But still the problem what I'm afraid of is that we end up in a mix of various plugins, plugin releases and users might get confused where which plugin is how developed and by whom. OTOH while thinking about, this is already partly the case as it will be always with independent plugins especially when a plugin author doesn't use the geany-plugins Sourceforge project and instead use some other place for hosting. So, my worries about that are maybe exaggerated. Perhaps it's enough when we try to keep update to date with the index page at http://plugins.geany.org and http://www.geany.org/Support/Plugins as a some kind of reference list of known plugins.
I'm all for this. So, which plugin developers (and the plugins they develop) are in favour of this move exactly? Perhaps we could have some sort of page on the website documenting this?
I'm afraid I'm not 100% sure which point you are referring here to? Having a including-all-plugins-list-on-homepage or the general refactoring of svn and geany-pugins release?
Assuming we are talking about the homepage: I'd say we either create an overview page for the common plugins, similar to what is now at http://plugins.geany.org/ but instead of linking to each plugin's own webpage, provide one page with sections for each included plugin and some common notes about installation, downloads and such.
Alternatively, we could redirect http://plugins.geany.org to http://www.geany.org/Support/Plugins and update it accordingly.
I don't mind much how we go in that matter but I'd like to delay this a bit until the technical (SVN layout changes, proper build system and code changes) are done or at least basically done.
Regards, Enrico
On Wed, 10 Jun 2009 16:32:02 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Assuming we are talking about the homepage: I'd say we either create an overview page for the common plugins, similar to what is now at http://plugins.geany.org/ but instead of linking to each plugin's own webpage, provide one page with sections for each included plugin and some common notes about installation, downloads and such.
Alternatively, we could redirect http://plugins.geany.org to http://www.geany.org/Support/Plugins and update it accordingly.
I prefer the redirect for the start. Midterm/longterm we could build up some particular pages but not needed at the moment IMHO.
I don't mind much how we go in that matter but I'd like to delay this a bit until the technical (SVN layout changes, proper build system and code changes) are done or at least basically done.
ACK.
Cheers, Frank
Hi,
I just want to bring up this topic on the plate: Homepage for geany-plugins project:
Enrico succeeded
On Wed, 10 Jun 2009 16:32:02 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
I'd say we either create an overview page for the common plugins, similar to what is now at http://plugins.geany.org/ but instead of linking to each plugin's own webpage, provide one page with sections for each included plugin and some common notes about installation, downloads and such.
Alternatively, we could redirect http://plugins.geany.org to http://www.geany.org/Support/Plugins and update it accordingly.
I don't mind much how we go in that matter but I'd like to delay this a bit until the technical (SVN layout changes, proper build system and code changes) are done or at least basically done.
As I mentioned for the start (? until we have ore content) we can use either the already existing page a bit updated or put the content into geany.org's. As ylong as the use can find a link for download and how to install and some more information I'm fine with.
Now its your turn! What do you thin about?
Cheers, Frank
On Wed, 17 Jun 2009 21:15:13 +0200, Frank wrote:
I'd say we either create an overview page for the common plugins, similar to what is now at http://plugins.geany.org/ but instead of linking to each plugin's own webpage, provide one page with sections for each included plugin and some common notes about installation, downloads and such.
Alternatively, we could redirect http://plugins.geany.org to http://www.geany.org/Support/Plugins and update it accordingly.
I don't mind much how we go in that matter but I'd like to delay this a bit until the technical (SVN layout changes, proper build system and code changes) are done or at least basically done.
As I mentioned for the start (? until we have ore content) we can use either the already existing page a bit updated or put the content into geany.org's. As ylong as the use can find a link for download and how to install and some more information I'm fine with.
My suggestion:
we update the content at http://plugins.geany.org [1] to properly reflect the recent changes, i.e. list and describe all plugins which are part of the geany-plugins enclosure and list all other "outside" plugins and link to their website.
On http://www.geany.org/Support/Plugins we do something similar to what we have currently: - list the geany-plugins enclosure as one plugin of the others and mention the containing plugins and link it to http://plugins.geany.org
Just my 2cents.
[1] http://plugins.geany.org is actually the same as http://geany-plugins.sourceforge.net and hosted at sourceforge.net. So, every plugin author with SVN write access can also access and modify this site.
Regards, Enrico
On Wed, 2009-06-10 at 11:56 +0200, Frank Lanitz wrote:
I'm afraid I'm not 100% sure which point you are referring here to? Having a including-all-plugins-list-on-homepage or the general refactoring of svn and geany-pugins release?
More like a page documenting which plugins well be merged, and which will not be, so that we can handle refactoring.
Hi guys,
I finally did a decision at least for my plugins ;)
On Sun, 7 Jun 2009 19:07:31 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 5 Jun 2009 16:35:17 +0100, Nick wrote:
On Fri, 5 Jun 2009 17:03:00 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
(not sure about the other plugins)
I can look after the geanylua plugin, I think that should be part of the common release.
...
So, I think if ever we need to find a solution for all or at least most plugins not only for some. And since Frank won't agree on the proposal of a common plugin project, I guess we will keep the current way with all its limitations as already pointed out and need to find workarounds or whatever for the translation issues and stuff.
Well, I think there will perhaps be people that only want SVN access, not anything else. So I propose we use trunk, tags, branches for common geany-plugins code, and make another path for devs that only want SVN access, and move those folders there.
e.g. trunk/ configure.ac geanylua/ etc tags/ geany-plugins-0.17 branches/ geany-plugins-0.17 other/ someproject/
Then the dev could also create their own tags etc. subdirectories, it would be up to them.
Sounds quite good so far and wouldn't require much more than a 'svn mkdir other' :).
I agree.
And now my final point ;) I'm ok with including my plugins to the big release but will keep on doing separate releases at least for GeanyLaTeX from time to time where I will point out the fact, it’s an addition release to the plugins one, so users have a bit more flexibility while there are getting not to much confused – a bit like it’s done with TeXlive and packages included there. I will do all needed merging stuff here including the po files etc. I pretty much hope there will be no negative impact on general geany-plugins release and workload of release managing team. ;)
But still the problem what I'm afraid of is that we end up in a mix of various plugins, plugin releases and users might get confused where which plugin is how developed and by whom.
OTOH while thinking about, this is already partly the case as it will be always with independent plugins especially when a plugin author doesn't use the geany-plugins Sourceforge project and instead use some other place for hosting. So, my worries about that are maybe exaggerated. Perhaps it's enough when we try to keep update to date with the index page at http://plugins.geany.org and http://www.geany.org/Support/Plugins as a some kind of reference list of known plugins.
Yes. We should go one with progress we already started here. It’s from my point of view a good thing for every user.
Cheers, Frank
On Wed, 10 Jun 2009 11:08:31 +0200, Frank wrote:
Hi guys,
I finally did a decision at least for my plugins ;)
Yay! I know this probably wasn't the most beloved decision you took but since you maintain most of the current plugins, this is a great step from my POV :). really appreciated.
trunk/ configure.ac geanylua/ etc tags/ geany-plugins-0.17 branches/ geany-plugins-0.17 other/ someproject/
Then the dev could also create their own tags etc. subdirectories, it would be up to them.
Sounds quite good so far and wouldn't require much more than a 'svn mkdir other' :).
I agree.
After thinking about it a bit more, I propose the following changes and further steps to get this done:
Instead of moving any plugins into a 'other' directory from trunk, I think it's the easiest way to create a new directory in trunk called 'geany-plugins' which will contain all plugins whose authors joined the common release concept and of course the build system. I.e. we will create the 'geany-plugins' directory and then the plugin authors will move their own plugins into this directory to get it part of the common release. This way we won't break existing plugins whose authors don't want to move on or currently can't do it (lack of time, whatever).
In short this means, all further actions on the common plugins will happen in trunk/geany-plugins/.
If you agree so far, I will start with the conversion and create that directory, move the spellcheck and addons into it, create the initial po/ directory for the translations and adjust the Waf build system to work properly. Once this is done, the other plugins authors can move their stuff too and Chow can start working on the autotools based build system.
Yo?
And now my final point ;) I'm ok with including my plugins to the big release but will keep on doing separate releases at least for GeanyLaTeX from time to time where
That's absolutely fine.
Regards, Enrico
On Wed, 10 Jun 2009 16:41:19 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
After thinking about it a bit more, I propose the following changes and further steps to get this done:
Instead of moving any plugins into a 'other' directory from trunk, I think it's the easiest way to create a new directory in trunk called 'geany-plugins' which will contain all plugins whose authors joined the common release concept and of course the build system. I.e. we will create the 'geany-plugins' directory and then the plugin authors will move their own plugins into this directory to get it part of the common release. This way we won't break existing plugins whose authors don't want to move on or currently can't do it (lack of time, whatever).
OK, good idea. Saves a lot of delays and emails ;-)
In short this means, all further actions on the common plugins will happen in trunk/geany-plugins/.
If you agree so far, I will start with the conversion and create that directory, move the spellcheck and addons into it, create the initial po/ directory for the translations and adjust the Waf build system to work properly. Once this is done, the other plugins authors can move their stuff too and Chow can start working on the autotools based build system.
Yo?
Fine with me, looking forward to it :)
Regards, Nick
On Wed, 10 Jun 2009 16:41:19 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
After thinking about it a bit more, I propose the following changes and further steps to get this done:
Instead of moving any plugins into a 'other' directory from trunk, I think it's the easiest way to create a new directory in trunk called 'geany-plugins' which will contain all plugins whose authors joined the common release concept and of course the build system. I.e. we will create the 'geany-plugins' directory and then the plugin authors will move their own plugins into this directory to get it part of the common release. This way we won't break existing plugins whose authors don't want to move on or currently can't do it (lack of time, whatever).
In short this means, all further actions on the common plugins will happen in trunk/geany-plugins/.
If you agree so far, I will start with the conversion and create that directory, move the spellcheck and addons into it, create the initial po/ directory for the translations and adjust the Waf build system to work properly. Once this is done, the other plugins authors can move their stuff too and Chow can start working on the autotools based build system.
Yo?
Tak jo. ;)
Cheers, Frank
On Wed, 10 Jun 2009 17:47:52 +0200 Frank Lanitz frank@frank.uvena.de wrote:
On Wed, 10 Jun 2009 16:41:19 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
After thinking about it a bit more, I propose the following changes and further steps to get this done:
Instead of moving any plugins into a 'other' directory from trunk, I think it's the easiest way to create a new directory in trunk called 'geany-plugins' which will contain all plugins whose authors joined the common release concept and of course the build system. I.e. we will create the 'geany-plugins' directory and then the plugin authors will move their own plugins into this directory to get it part of the common release. This way we won't break existing plugins whose authors don't want to move on or currently can't do it (lack of time, whatever).
In short this means, all further actions on the common plugins will happen in trunk/geany-plugins/.
If you agree so far, I will start with the conversion and create that directory, move the spellcheck and addons into it, create the initial po/ directory for the translations and adjust the Waf build system to work properly. Once this is done, the other plugins authors can move their stuff too and Chow can start working on the autotools based build system.
Yo?
Tak jo. ;)
I just wanted to say: I'm fine with this. ;)
Cheers, Frank
On Wed, 10 Jun 2009 16:41:19 +0200, Enrico wrote:
Yo,
If you agree so far, I will start with the conversion and create that directory, move the spellcheck and addons into it, create the initial po/ directory for the translations and adjust the Waf build system to
Done. I also moved the shiftcolumn into the geany-plugins directory, hope Andrew is fine with that :). I did this mainly because it had the most translations and moving it was the easiest way for me, yes I'm lazy.
work properly. Once this is done, the other plugins authors can move their stuff too and Chow can start working on the autotools based build system.
Here we go.
What's to happen next?
- remaining plugins need to be moved into the geany-plugins directory, this should be done by the corresponding plugin authors, moving also means deleting previously used autotools configuration files, don't forget to edit geany-plugins/wscript: - there is a big commented list of plugins at the beginning of the file, find your plugin and move it into the 'plugins' list - edit geany-plugins/po/POTFILES.in and add your source files which contain translatable strings
- Chow can start working on an autotools based build system if he likes to
- the translation system in po/ is ready and works, ./waf --update-po does correctly update the message catalogues. However some needs to review the headers of the message catalogues (*.po) as they vary heavily and some are missing stuff, e.g. plural definitions
Have fun.
Regards, Enrico
On Thu, 11 Jun 2009 01:04:05 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
- the translation system in po/ is ready and works, ./waf --update-po
does correctly update the message catalogues. However some needs to review the headers of the message catalogues (*.po) as they vary heavily and some are missing stuff, e.g. plural definitions
Please merge also current translations for already merged plugins into po file. This should be able to be done by just c&p the current ones with only some minor problems. I've already done this with GeanySendMail translation files during my last commit but I'm not sure whether I messed something up here.
Cheers, Frank
On Thu, 11 Jun 2009 01:25:23 +0200, Frank wrote:
On Thu, 11 Jun 2009 01:04:05 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
- the translation system in po/ is ready and works, ./waf --update-po
does correctly update the message catalogues. However some needs to review the headers of the message catalogues (*.po) as they vary heavily and some are missing stuff, e.g. plural definitions
Please merge also current translations for already merged plugins into po file. This should be able to be done by just c&p the current ones
Done in SVN r700. I merged the translations of all existing plugins and fixed the headers.
As a bonus, now we have: http://i18n.geany.org/plugins/
Regards, Enrico
I also moved the shiftcolumn into the geany-plugins directory, hope Andrew is fine with that :). I did this mainly because it had the most translations and moving it was the easiest way for me, yes I'm lazy.
Certainly works for me. :)
-- Andrew Janke (a.janke@gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883
Hi,
On Wed, 10 Jun 2009 16:41:19 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
And now my final point ;) I'm ok with including my plugins to the big release but will keep on doing separate releases at least for GeanyLaTeX from time to time where
That's absolutely fine.
I've merged all of my plugins into common geany-plugins project. There is only documentation of GeanyLaTeX missing were I’d like to provide also the PDF as well as the HTML version inside tarball but due the size this depends on your decision how we go on here.
By now I did not remove stand alone folders with build system since I did not do a final decision by now how I will go on with independent releases. For geanylipsum and geanysendmail it’s pretty much likely that I will do remove them next time as well as I will keep it for geanyLaTeX. However, for you to know is that I finished merging beside the documentation point I’ve already mentioned.
Cheers, Frank
Attached is a patch which makes some changes to each plugin's autogen.sh script (copies out the autofoo parts into a separate "bootstrap" script, whereby autogen.sh includes the bootstrap script, and calls configure), as well as includes a toplevel configure.in and Makefile.am to hook up all the plugins. The reasoning for this is that the toplevel autogen.sh only wants to call the bootstrapping part, but not configure of each plugin, or it'll increase the autogen.sh time substantially.
I've excluded some plugins because they either have no autogen.sh script, and/or don't have a working build system yet. But once it's all done, you can just update the list of working plugins in the toplevel autogen.sh, configure.in, and Makefile.am.
Pros: * No need to merge the po/ directory * Plugins can be distributed and built independently or together.
Cons: * No way to disable plugins yet, though that can be added using AC_ARG_WITH, AC_ARG_ENABLE, or something. * Long configure time, due to repeated checks from calling each plugin's configure script.
On Wed, 3 Jun 2009 20:02:07 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
While discussing how a possible geany-plugins release could be done and what's necessary, we came across the idea of changing the above idea: give up the independence of each plugin and instead create one big project consisting of the various plugins but with only one build system. Following you'll find a list of pros and cons which instantly came to my mind as some kind of rationale.
I am perfectly fine with current state of things but I don't mind one big project idea too. So generally I don't care and will be fine with any decision made by people with strong opinion.
Hey,
forwarded message of Andrew Janke :).
Begin forwarded message:
Date: Fri, 5 Jun 2009 23:15:04 +1000 From: Andrew Janke a.janke@gmail.com To: Enrico Tröger enrico.troeger@uvena.de Subject: Re: Fw: [Geany-devel] Restructuring the Geany-plugins project?
I am 100% for one big "approved" plugin package/repository/build thing.
More Pros:
* Lowers the bar for people (like me) to write a new one. I effectively wrote shift-column by reading the other plugins and duplicating the entire build structure. In my case I am very familiar with automake perhaps harder for others who aren't. If all I had to do was to add one line to Makefile.am and then make a new subdir, things would have been a lot easier and I would have benefited from others input on the build stuff.
* A lot of plugin authors (like myself) are generally just scratching their own personal itches. Meaning once it works, the interest in fixing bugs and updating the build system wanes. If they are part of a big package this is ameliorated somewhat.
* All good plugins will eventually make it to Debian/Ubuntu/etc via the help of others (package manager), this is a good thing!