Hi,
Is there anyone who feels like creating and(or) maintaining Linux distro packages for Geany-Themes[1]?
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Cheers, Matthew Brush
Matthew,
I'll try doing this for my current distribution - Frugalware Linux. Great idea!
On 11 December 2011 12:59, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
Is there anyone who feels like creating and(or) maintaining Linux distro packages for Geany-Themes[1]?
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Cheers, Matthew Brush
[1] https://github.com/codebrainz/geany-themes _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
Best regards.
To be honest it's up to the distribution how Geany and extras are packaged. Some might include Geany's core, all plugins and themes in one package. Others prefer to create separate packages etc.
I think the main point here is to make them available to people so that they can enjoy Geany in all its various colour schemes. :)
On 12 December 2011 01:46, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
Best regards.
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Sun, 11 Dec 2011 16:46:23 +0100 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
I disagree, even they are cool. We should keep in mind to do not bloat Geany core with extra stuff. I guess we did a good step with moving a lot of tag files out (btw here a package would also be cool) and don't want to go step back
Cheers, Frank
On 12/17/2011 08:32 AM, Frank Lanitz wrote:
On Sun, 11 Dec 2011 16:46:23 +0100 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
I disagree, even they are cool. We should keep in mind to do not bloat Geany core with extra stuff. I guess we did a good step with moving a lot of tag files out (btw here a package would also be cool) and don't want to go step back
Bloat, hehehe. It's ~36kb for all 17 themes combined :)
I personally don't care if they're part of Geany core, but there *definitively* needs to be packages available if not in core.
Cheers, Matthew Brush
Make 'em core!!! :-)
ちモれ匕 下尺◯爪 爪ㄚ 匚モㄥㄥㄗ卄◯れモ, モ卄... On Dec 17, 2011 5:11 PM, "Matthew Brush" mbrush@codebrainz.ca wrote:
On 12/17/2011 08:32 AM, Frank Lanitz wrote:
On Sun, 11 Dec 2011 16:46:23 +0100 Thomas Martitz<thomas.martitz@**student.htw-berlin.dethomas.martitz@student.htw-berlin.de> wrote:
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/**colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
I disagree, even they are cool. We should keep in mind to do not bloat Geany core with extra stuff. I guess we did a good step with moving a lot of tag files out (btw here a package would also be cool) and don't want to go step back
Bloat, hehehe. It's ~36kb for all 17 themes combined :)
I personally don't care if they're part of Geany core, but there *definitively* needs to be packages available if not in core.
Cheers, Matthew Brush ______________________________**_________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-**bin/mailman/listinfo/geanyhttps://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Le 17/12/2011 23:13, Matthew Brush a écrit :
On 12/17/2011 08:32 AM, Frank Lanitz wrote:
On Sun, 11 Dec 2011 16:46:23 +0100 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
I disagree, even they are cool. We should keep in mind to do not bloat Geany core with extra stuff. I guess we did a good step with moving a lot of tag files out (btw here a package would also be cool) and don't want to go step back
Bloat, hehehe. It's ~36kb for all 17 themes combined :)
I'm with Frank here, it's not a sizing question. Themes are good, but there is not point in providing 65536 themes, and if we provide all the geany-themes ones, why not all the user's created ones? We already provides 2 themes, and we (should) link somewhere users can find some others on the website, but we shouldn't distribute all of them.
No, I definitely think these should go in some "extra" package or something, why not with some tags files or other selected extras.
Cheers, Colomban
I personally don't care if they're part of Geany core, but there *definitively* needs to be packages available if not in core.
Cheers, Matthew Brush _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
I think it would be prudent to further Darko's geany theme so that it would work with current geany . This would keep geany core size small and allow users to theme geany to their hearts desire.
Sent from my iPhone
On 18/12/2011, at 10:25 AM, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 17/12/2011 23:13, Matthew Brush a écrit :
On 12/17/2011 08:32 AM, Frank Lanitz wrote:
On Sun, 11 Dec 2011 16:46:23 +0100 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
I disagree, even they are cool. We should keep in mind to do not bloat Geany core with extra stuff. I guess we did a good step with moving a lot of tag files out (btw here a package would also be cool) and don't want to go step back
Bloat, hehehe. It's ~36kb for all 17 themes combined :)
I'm with Frank here, it's not a sizing question. Themes are good, but there is not point in providing 65536 themes, and if we provide all the geany-themes ones, why not all the user's created ones? We already provides 2 themes, and we (should) link somewhere users can find some others on the website, but we shouldn't distribute all of them.
No, I definitely think these should go in some "extra" package or something, why not with some tags files or other selected extras.
Cheers, Colomban
I personally don't care if they're part of Geany core, but there *definitively* needs to be packages available if not in core.
Cheers, Matthew Brush _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Le 18/12/2011 01:35, Sayth a écrit :
I think it would be prudent to further Darko's geany theme so that it would work with current geany . This would keep geany core size small and allow users to theme geany to their hearts desire.
Sorry? I know I'm no native English speaker but I'm quite confident the first sentence isn't English either... Could you please rephrase?
Regards, Colomban
On Sun, Dec 18, 2011 at 11:43 AM, Colomban Wendling < lists.ban@herbesfolles.org> wrote:
Le 18/12/2011 01:35, Sayth a écrit :
I think it would be prudent to further Darko's geany theme so that it would work with current geany . This would keep geany core size small and allow users to theme geany to their hearts desire.
Sorry? I know I'm no native English speaker but I'm quite confident the first sentence isn't English either... Could you please rephrase?
Regards, Colomban _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
The first sentence definitely makes sense in English, but I can see how it could be difficult to understand. Darko(person's name) created an online geany theme's editor the link of which can be found at the geany extra's [age http://www.geany.org/Download/Extras and his online editor here http://geanycolourscheme.xtreemhost.com/ . It's a great little theme editor but since geany 0.18 the themes can't be saved and loaded into geany anymore.
Not many editor's or ide's have such a great little facility. if this worked with geany current it would resolve the themes issue and the amount of themes that could be created would be only limited to the users wishes.
Sayth
On 12/18/2011 01:41 AM, Sayth Renshaw wrote:
On Sun, Dec 18, 2011 at 11:43 AM, Colomban Wendling <lists.ban@herbesfolles.org mailto:lists.ban@herbesfolles.org> wrote:
Le 18/12/2011 01:35, Sayth a écrit : > I think it would be prudent to further Darko's geany theme so that it > would work with current geany . > This would keep geany core size small and allow users to theme geany > to their hearts desire. Sorry? I know I'm no native English speaker but I'm quite confident the first sentence isn't English either... Could you please rephrase? Regards, Colomban _______________________________________________ Geany mailing list Geany@uvena.de <mailto:Geany@uvena.de> https://lists.uvena.de/cgi-bin/mailman/listinfo/geanyThe first sentence definitely makes sense in English, but I can see how it could be difficult to understand. Darko(person's name) created an online geany theme's editor the link of which can be found at the geany extra's [age http://www.geany.org/Download/Extras and his online editor here http://geanycolourscheme.xtreemhost.com/ . It's a great little theme editor but since geany 0.18 the themes can't be saved and loaded into geany anymore.
Not many editor's or ide's have such a great little facility. if this worked with geany current it would resolve the themes issue and the amount of themes that could be created would be only limited to the users wishes.
Heh, I must admit I also had no idea what you were talking about :)
FWIW, with the new fildefs and using color schemes similar to geany-themes ones, it's now trivial to edit themes by hand. It would still be cool to have a GUI editor, but at least it's far less insane now without one.
Cheers, Matthew Brush
On 12/17/2011 03:25 PM, Colomban Wendling wrote:
Le 17/12/2011 23:13, Matthew Brush a écrit :
On 12/17/2011 08:32 AM, Frank Lanitz wrote:
On Sun, 11 Dec 2011 16:46:23 +0100 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
I disagree, even they are cool. We should keep in mind to do not bloat Geany core with extra stuff. I guess we did a good step with moving a lot of tag files out (btw here a package would also be cool) and don't want to go step back
Bloat, hehehe. It's ~36kb for all 17 themes combined :)
I'm with Frank here, it's not a sizing question. Themes are good, but there is not point in providing 65536 themes, and if we provide all the geany-themes ones, why not all the user's created ones? We already provides 2 themes, and we (should) link somewhere users can find some others on the website, but we shouldn't distribute all of them.
No, I definitely think these should go in some "extra" package or something, why not with some tags files or other selected extras.
Agreed, I think there should be a package called "geany-themes" available in the various repos along side of "geany" and "geany-plugins" or whatever. This is why I started the thread asking for help :)
With such packages and fixing up the Extras page, I think this is enough to make it less crazy to figure out how to install the color schemes.
If no one can help me, I might be able to make an "unofficial" .deb and .rpm packages if I can figure it out, but it won't be in any repos.
Cheers, Matthew Brush
On 12/17/2011 03:25 PM, Colomban Wendling wrote:
Le 17/12/2011 23:13, Matthew Brush a écrit :
On 12/17/2011 08:32 AM, Frank Lanitz wrote:
On Sun, 11 Dec 2011 16:46:23 +0100 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
Am 11.12.2011 03:59, schrieb Matthew Brush:
I don't think it would be too hard, basically just copy some `.conf` files to `${prefix}/share/geany/colorschemes/`. I guess it should also depend on the Geany package.
It would be probably be best if coordinated with (or done directly by) existing Geany distro package maintainers.
Bah, I still think it should be part of Geany, not a separate package.
I disagree, even they are cool. We should keep in mind to do not bloat Geany core with extra stuff. I guess we did a good step with moving a lot of tag files out (btw here a package would also be cool) and don't want to go step back
Bloat, hehehe. It's ~36kb for all 17 themes combined :)
I'm with Frank here, it's not a sizing question. Themes are good, but there is not point in providing 65536 themes, and if we provide all the geany-themes ones, why not all the user's created ones? We already provides 2 themes, and we (should) link somewhere users can find some others on the website, but we shouldn't distribute all of them.
No, I definitely think these should go in some "extra" package or something, why not with some tags files or other selected extras.
Here's a reasonable list of packages that could exist:
geany <- core application geany-common <- ? geany-dev <- geany.pc and header files geany-extras <- geany themes, bindings, tags geany-vala <- vala binding geany-python <- python binding geany-themes <- all theme files from geany-themes geany-tags <- all geany tags (slooooooow!) geany-tags-c <- C tags only geany-tags-python <- Python tags only, and so on... ...other tags geany-plugins <- all plugins combined geany-plugins-common <- ? geany-plugin-addons <- Addon plugin only, and so on... ...other plugins
Of course we need to get the distro package maintainers on side with this :)
Cheers, Matthew Brush
Am Samstag, den 17.12.2011, 21:27 -0800 schrieb Matthew Brush:
Here's a reasonable list of packages that could exist:
geany <- core application geany-common <- ? geany-dev <- geany.pc and header files geany-extras <- geany themes, bindings, tags geany-vala <- vala binding geany-python <- python binding geany-themes <- all theme files from geany-themes geany-tags <- all geany tags (slooooooow!) geany-tags-c <- C tags only geany-tags-python <- Python tags only, and so on... ...other tags geany-plugins <- all plugins combined geany-plugins-common <- ? geany-plugin-addons <- Addon plugin only, and so on... ...other plugins
I'd basically say we shouldn't even care about the packages of specific GNU/Linux distributions upstream and leave the packaging up to the particular package maintainer. They have to find the right way for their users to provide as much flexibility as possible for the user when installing stuff and keeping package maintenance efforts feasible for them.
While we're at it and I'm maintaining some stuff on Fedora I can tell you my personal opinion: I'd put everything I find as a separate repository upstream [1] in a separate package. In case some packages are too big or it would make sense, I'd maybe split a package into sub-packages.
Note the technical difference between separate packages and sub-packages as it is the case for example for the geany-plugins-* stuff in Fedora: geany-plugins is another package than geany, but geany-plugins-$foo is a sub-package of geany-plugins. There is no installable so-called meta-package called "geany-plugins" which would install every plugin, users would just type `yum install geany-plugins-*` to install everything.
The situation for Tag files taken from [2] is a bit special, because they currently are just additional sources for the Geany package in Fedora and thus installed when you do a `yum install geany`. Users did not claim yet about a bloated package, they rather provided feedback that they found this a cool feature. I don't see a reason (yet) why I should put every tag file in a separate sub-package. I can imagine a separate package for geany-tags, though. This however will be not easy to change, since removing the tags files from the Geany package (they were there since Geany is in Fedora) would significantly change the behavior of Geany in Fedora and thus maybe only can be done between different Fedora releases.
To get back to the topic: A geany-themes package would be easily possible, not sure yet about the way to package - separate package or sub-package of geany, but this mainly is a question of package maintenance in Fedora and the difference will not be even obvious for the user. I tend to put it in a newly created separate package since the themes are (or will/would be) provided in a separate repository upstream and extending the Geany package itself in that amount would need a re-review for the Geany package in Fedora.
Did I miss something for the Python and Vala stuff (are they there yet?) or was this just example names? :)
Regards, Dominic
[1] https://github.com/geany [2] http://download.geany.org/contrib/tags/
Le 18/12/2011 14:26, Dominic Hopf a écrit :
Am Samstag, den 17.12.2011, 21:27 -0800 schrieb Matthew Brush:
Here's a reasonable list of packages that could exist:
geany <- core application geany-common <- ? geany-dev <- geany.pc and header files geany-extras <- geany themes, bindings, tags geany-vala <- vala binding geany-python <- python binding geany-themes <- all theme files from geany-themes geany-tags <- all geany tags (slooooooow!) geany-tags-c <- C tags only geany-tags-python <- Python tags only, and so on... ...other tags geany-plugins <- all plugins combined geany-plugins-common <- ? geany-plugin-addons <- Addon plugin only, and so on... ...other plugins
I'd basically say we shouldn't even care about the packages of specific GNU/Linux distributions upstream and leave the packaging up to the particular package maintainer. They have to find the right way for their users to provide as much flexibility as possible for the user when installing stuff and keeping package maintenance efforts feasible for them.
While we're at it and I'm maintaining some stuff on Fedora I can tell you my personal opinion: I'd put everything I find as a separate repository upstream [1] in a separate package. In case some packages are too big or it would make sense, I'd maybe split a package into sub-packages.
Note the technical difference between separate packages and sub-packages as it is the case for example for the geany-plugins-* stuff in Fedora: geany-plugins is another package than geany, but geany-plugins-$foo is a sub-package of geany-plugins. There is no installable so-called meta-package called "geany-plugins" which would install every plugin, users would just type `yum install geany-plugins-*` to install everything.
The situation for Tag files taken from [2] is a bit special, because they currently are just additional sources for the Geany package in Fedora and thus installed when you do a `yum install geany`. Users did not claim yet about a bloated package, they rather provided feedback that they found this a cool feature. I don't see a reason (yet) why I should put every tag file in a separate sub-package. I can imagine a separate package for geany-tags, though. This however will be not easy to change, since removing the tags files from the Geany package (they were there since Geany is in Fedora) would significantly change the behavior of Geany in Fedora and thus maybe only can be done between different Fedora releases.
To get back to the topic: A geany-themes package would be easily possible, not sure yet about the way to package - separate package or sub-package of geany, but this mainly is a question of package maintenance in Fedora and the difference will not be even obvious for the user. I tend to put it in a newly created separate package since the themes are (or will/would be) provided in a separate repository upstream and extending the Geany package itself in that amount would need a re-review for the Geany package in Fedora.
+1, just provide a geany-theme tarball release and leave the packaging choice to the packagers, we don't have to care.
Did I miss something for the Python and Vala stuff (are they there yet?) or was this just example names? :)
There is an experimental Vala biding [1] and I guess geany-python referred to Matthew's python plugin [2].
Regards, Colomban
[1] https://gitorious.org/geany-vala-binding [2] https://github.com/codebrainz/geanypy
Regards, Dominic
[1] https://github.com/geany [2] http://download.geany.org/contrib/tags/
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 12/18/2011 06:46 AM, Colomban Wendling wrote:
[...]
+1, just provide a geany-theme tarball release and leave the packaging choice to the packagers, we don't have to care.
This is what I tried to ask about! Currently geany-themes isn't packaged, it needs to be, and I was asking if anyone would mind packaging it. No packagers responded until I made a list of packages I thought might be a good idea, so I guess my "plan" worked, to get responses from packagers :)
Now I just need to say something to piss off the Debian, Ubuntu and Arch packagers to get them reading this thread and responding to whether or not they mind packaging geany-themes and I'll be all set :)
Cheers, Matthew Brush
Am Sonntag, den 18.12.2011, 11:45 -0800 schrieb Matthew Brush:
This is what I tried to ask about! Currently geany-themes isn't packaged, it needs to be, and I was asking if anyone would mind packaging it. No packagers responded until I made a list of packages I thought might be a good idea, so I guess my "plan" worked, to get responses from packagers :)
I noticed your highlight on IRC about this thread. ;P
On 12/18/2011 05:26 AM, Dominic Hopf wrote:
Am Samstag, den 17.12.2011, 21:27 -0800 schrieb Matthew Brush:
Here's a reasonable list of packages that could exist:
geany<- core application geany-common<- ? geany-dev<- geany.pc and header files geany-extras<- geany themes, bindings, tags geany-vala<- vala binding geany-python<- python binding geany-themes<- all theme files from geany-themes geany-tags<- all geany tags (slooooooow!) geany-tags-c<- C tags only geany-tags-python<- Python tags only, and so on... ...other tags geany-plugins<- all plugins combined geany-plugins-common<- ? geany-plugin-addons<- Addon plugin only, and so on... ...other plugins
I'd basically say we shouldn't even care about the packages of specific GNU/Linux distributions upstream and leave the packaging up to the particular package maintainer. They have to find the right way for their users to provide as much flexibility as possible for the user when installing stuff and keeping package maintenance efforts feasible for them.
Yeah, I just meant it to provide some ideas because there's some new stuff that isn't currently packaged.
While we're at it and I'm maintaining some stuff on Fedora I can tell you my personal opinion: I'd put everything I find as a separate repository upstream [1] in a separate package. In case some packages are too big or it would make sense, I'd maybe split a package into sub-packages.
Note the technical difference between separate packages and sub-packages as it is the case for example for the geany-plugins-* stuff in Fedora: geany-plugins is another package than geany, but geany-plugins-$foo is a sub-package of geany-plugins. There is no installable so-called meta-package called "geany-plugins" which would install every plugin, users would just type `yum install geany-plugins-*` to install everything.
I didn't know about this, I've only ever made Debian packages, and even that was just for my own use :)
The situation for Tag files taken from [2] is a bit special, because they currently are just additional sources for the Geany package in Fedora and thus installed when you do a `yum install geany`. Users did not claim yet about a bloated package, they rather provided feedback that they found this a cool feature. I don't see a reason (yet) why I should put every tag file in a separate sub-package. I can imagine a separate package for geany-tags, though. This however will be not easy to change, since removing the tags files from the Geany package (they were there since Geany is in Fedora) would significantly change the behavior of Geany in Fedora and thus maybe only can be done between different Fedora releases.
The problem is that your source [2] isn't where the tags are anymore, they're all moved to the Wiki and there's lots of new ones as well. The reason you might want separately packages for different tag file languages is that Geany becomes terribly slow as you add more tags for a given language. If you have too many tag files, when you a load a file that uses the language of those tags, Geany freezes for a noticeable amount of time while it parses the tag files.
To get back to the topic: A geany-themes package would be easily possible, not sure yet about the way to package - separate package or sub-package of geany, but this mainly is a question of package maintenance in Fedora and the difference will not be even obvious for the user. I tend to put it in a newly created separate package since the themes are (or will/would be) provided in a separate repository upstream and extending the Geany package itself in that amount would need a re-review for the Geany package in Fedora.
I don't know about this, but finally we're getting to my original question, "can someone make packages for geany-themes" :) So is this something you wouldn't mind doing for Fedora?
Did I miss something for the Python and Vala stuff (are they there yet?) or was this just example names? :)
The Vala binding is two files (geany.vapi and geany.deps) which need to go into the system's VAPI dir (it's /usr/share/vala-VERSION/vapi here). This allows to write plugins in Vala, and at present the one plugin (which I just added) that uses the binding embeds these files in the source, but as soon as one more Vala plugin comes along, it will be weird having the Vala binding embedded twice in two different places, which is why I suggested a package for it. IIUC, the Vala files would typically be installed with the -dev package (on Debian), along with the pkg-config file and headers.
I'm not too sure about how GeanyPy should be packaged. It provides two things; a Python binding and a Geany-Plugin. Typically in Debian, the binding would be a package called `python-geany` but since the actual Geany-Plugin for GeanyPy can't work without the Python binding and the Python binding can't work without GeanyPy, it might not make much sense to split it up. Probably best here is just to have it be a regular plugin with both parts in it.
Cheers, Matthew Brush
Regards, Dominic
[1] https://github.com/geany [2] http://download.geany.org/contrib/tags/
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Am Sonntag, den 18.12.2011, 11:41 -0800 schrieb Matthew Brush:
The situation for Tag files taken from [2] is a bit special, because they currently are just additional sources for the Geany package in Fedora and thus installed when you do a `yum install geany`. Users did not claim yet about a bloated package, they rather provided feedback that they found this a cool feature. I don't see a reason (yet) why I should put every tag file in a separate sub-package. I can imagine a separate package for geany-tags, though. This however will be not easy to change, since removing the tags files from the Geany package (they were there since Geany is in Fedora) would significantly change the behavior of Geany in Fedora and thus maybe only can be done between different Fedora releases.
The problem is that your source [2] isn't where the tags are anymore, they're all moved to the Wiki and there's lots of new ones as well. The reason you might want separately packages for different tag file languages is that Geany becomes terribly slow as you add more tags for a given language. If you have too many tag files, when you a load a file that uses the language of those tags, Geany freezes for a noticeable amount of time while it parses the tag files.
Good point, I'll rethink how the packaging in Fedora can be improved and will update references to the wiki.
I don't know about this, but finally we're getting to my original question, "can someone make packages for geany-themes" :) So is this something you wouldn't mind doing for Fedora?
Yep, definitely. I'll do so as soon as I get a round to it and no other Fedora package beats me doing it. :)
Anyway, the repository is yours [1], right? I suggest making this repo "official" and move it to the Geany organisation. :)
Did I miss something for the Python and Vala stuff (are they there yet?) or was this just example names? :)
The Vala binding is two files (geany.vapi and geany.deps) which need to go into the system's VAPI dir (it's /usr/share/vala-VERSION/vapi here).
Are they delivered with the Geany tarball or should they be obtained via [2]? In latter case I'd also suggest to make it "official". :)
This allows to write plugins in Vala, and at present the one plugin (which I just added) that uses the binding embeds these files in the source, but as soon as one more Vala plugin comes along, it will be weird having the Vala binding embedded twice in two different places, which is why I suggested a package for it. IIUC, the Vala files would typically be installed with the -dev package (on Debian), along with the pkg-config file and headers.
Well, if I provide the Vala bindings in the geany-devel package in Fedora, and add a Vala plugin as a new geany-plugins sub-package which requires geany-devel, wouldn't that do the job? - You'd just need to use the Vala stuff from /usr/share/vala-VERSION/vapi in your plugin then.
I'm not too sure about how GeanyPy should be packaged. It provides two things; a Python binding and a Geany-Plugin. Typically in Debian, the binding would be a package called `python-geany` but since the actual Geany-Plugin for GeanyPy can't work without the Python binding and the Python binding can't work without GeanyPy, it might not make much sense to split it up. Probably best here is just to have it be a regular plugin with both parts in it.
I think so too. :)
Regards, Dominic
[1] https://github.com/codebrainz/geany-themes [2] https://github.com/codebrainz/geany-vala-binding
On Mon, Dec 19, 2011 at 8:08 AM, Dominic Hopf dmaphy@googlemail.com wrote:
Am Sonntag, den 18.12.2011, 11:41 -0800 schrieb Matthew Brush:
The situation for Tag files taken from [2] is a bit special, because they currently are just additional sources for the Geany package in Fedora and thus installed when you do a `yum install geany`. Users did not claim yet about a bloated package, they rather provided feedback that they found this a cool feature. I don't see a reason (yet) why I should put every tag file in a separate sub-package. I can imagine a separate package for geany-tags, though. This however will be not easy to change, since removing the tags files from the Geany package (they were there since Geany is in Fedora) would significantly change the behavior of Geany in Fedora and thus maybe only can be done between different Fedora releases.
The problem is that your source [2] isn't where the tags are anymore, they're all moved to the Wiki and there's lots of new ones as well. The reason you might want separately packages for different tag file languages is that Geany becomes terribly slow as you add more tags for a given language. If you have too many tag files, when you a load a file that uses the language of those tags, Geany freezes for a noticeable amount of time while it parses the tag files.
Good point, I'll rethink how the packaging in Fedora can be improved and will update references to the wiki.
I don't know about this, but finally we're getting to my original question, "can someone make packages for geany-themes" :) So is this something you wouldn't mind doing for Fedora?
Yep, definitely. I'll do so as soon as I get a round to it and no other Fedora package beats me doing it. :)
Anyway, the repository is yours [1], right? I suggest making this repo "official" and move it to the Geany organisation. :)
Did I miss something for the Python and Vala stuff (are they there
yet?)
or was this just example names? :)
The Vala binding is two files (geany.vapi and geany.deps) which need to go into the system's VAPI dir (it's /usr/share/vala-VERSION/vapi here).
Are they delivered with the Geany tarball or should they be obtained via [2]? In latter case I'd also suggest to make it "official". :)
This allows to write plugins in Vala, and at present the one plugin (which I just added) that uses the binding embeds these files in the source, but as soon as one more Vala plugin comes along, it will be weird having the Vala binding embedded twice in two different places, which is why I suggested a package for it. IIUC, the Vala files would typically be installed with the -dev package (on Debian), along with the pkg-config file and headers.
Well, if I provide the Vala bindings in the geany-devel package in Fedora, and add a Vala plugin as a new geany-plugins sub-package which requires geany-devel, wouldn't that do the job? - You'd just need to use the Vala stuff from /usr/share/vala-VERSION/vapi in your plugin then.
I'm not too sure about how GeanyPy should be packaged. It provides two things; a Python binding and a Geany-Plugin. Typically in Debian, the binding would be a package called `python-geany` but since the actual Geany-Plugin for GeanyPy can't work without the Python binding and the Python binding can't work without GeanyPy, it might not make much sense to split it up. Probably best here is just to have it be a regular plugin with both parts in it.
I think so too. :)
Regards, Dominic
[1] https://github.com/codebrainz/geany-themes [2] https://github.com/codebrainz/geany-vala-binding
-- Dominic Hopf http://dominichopf.de/
Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Instead of getting a maintainer for Fedora, a maintainer for Debian etc we could utilise the Suse OBS which creates packages for many distro's in one build service http://en.opensuse.org/Portal:Build_Service
Sayth
On 12/18/2011 01:08 PM, Dominic Hopf wrote:
Am Sonntag, den 18.12.2011, 11:41 -0800 schrieb Matthew Brush:
I don't know about this, but finally we're getting to my original question, "can someone make packages for geany-themes" :) So is this something you wouldn't mind doing for Fedora?
Yep, definitely. I'll do so as soon as I get a round to it and no other Fedora package beats me doing it. :)
Anyway, the repository is yours [1], right? I suggest making this repo "official" and move it to the Geany organisation. :)
Yes, it's mine. I was thinking about moving it to the Geany org but for a few things: there's lots of people watching my repo on github, so I didn't want to make people thinking it had dissappeared, and the other is that I didn't want to increase the amount of bugs reported on Geany's SF.net trackers when I can easily manage them on the Github issues tracker separately without causing noise on SF.net.
Still, I think it would be a good idea to move it, if nobody else objects.
Did I miss something for the Python and Vala stuff (are they there yet?) or was this just example names? :)
The Vala binding is two files (geany.vapi and geany.deps) which need to go into the system's VAPI dir (it's /usr/share/vala-VERSION/vapi here).
Are they delivered with the Geany tarball or should they be obtained via [2]? In latter case I'd also suggest to make it "official". :)
It makes sense to me to distribute the Vala binding with Geany, but of course this up to Colomban as both the maintainer of Geany and the author/maintainer of the binding. I think his main concern is that binding doesn't have much testing so is too "experimental" to be included, but IMO it's the best way to get more testing and bug fixes done on it.
This allows to write plugins in Vala, and at present the one plugin (which I just added) that uses the binding embeds these files in the source, but as soon as one more Vala plugin comes along, it will be weird having the Vala binding embedded twice in two different places, which is why I suggested a package for it. IIUC, the Vala files would typically be installed with the -dev package (on Debian), along with the pkg-config file and headers.
Well, if I provide the Vala bindings in the geany-devel package in Fedora, and add a Vala plugin as a new geany-plugins sub-package which requires geany-devel, wouldn't that do the job? - You'd just need to use the Vala stuff from /usr/share/vala-VERSION/vapi in your plugin then.
That would be perfect, but still it only covers Fedora, so I'd need to include the binding in the source if it wasn't included with Geany and installed in the other distro's packages.
Cheers, Matthew Brush
Am 18.12.2011 22:49, schrieb Matthew Brush:
On 12/18/2011 01:08 PM, Dominic Hopf wrote:
Am Sonntag, den 18.12.2011, 11:41 -0800 schrieb Matthew Brush:
I don't know about this, but finally we're getting to my original question, "can someone make packages for geany-themes" :) So is this something you wouldn't mind doing for Fedora?
Yep, definitely. I'll do so as soon as I get a round to it and no other Fedora package beats me doing it. :)
Anyway, the repository is yours [1], right? I suggest making this repo "official" and move it to the Geany organisation. :)
Yes, it's mine. I was thinking about moving it to the Geany org but for a few things: there's lots of people watching my repo on github, so I didn't want to make people thinking it had dissappeared, and the other is that I didn't want to increase the amount of bugs reported on Geany's SF.net trackers when I can easily manage them on the Github issues tracker separately without causing noise on SF.net.
Still, I think it would be a good idea to move it, if nobody else objects.
Moving the repo to Geany wouldn't make your repo disappear. It would be turned into a clone of Geany's repo, or simply the way around (you can easily make the Geany-repo be cloned initially from your repo even if main development then happens in the Geany-repo). That way the followers of your repo are still notified.
Best regards.
On 12/19/2011 12:33 AM, Thomas Martitz wrote:
Am 18.12.2011 22:49, schrieb Matthew Brush:
On 12/18/2011 01:08 PM, Dominic Hopf wrote:
Am Sonntag, den 18.12.2011, 11:41 -0800 schrieb Matthew Brush:
I don't know about this, but finally we're getting to my original question, "can someone make packages for geany-themes" :) So is this something you wouldn't mind doing for Fedora?
Yep, definitely. I'll do so as soon as I get a round to it and no other Fedora package beats me doing it. :)
Anyway, the repository is yours [1], right? I suggest making this repo "official" and move it to the Geany organisation. :)
Yes, it's mine. I was thinking about moving it to the Geany org but for a few things: there's lots of people watching my repo on github, so I didn't want to make people thinking it had dissappeared, and the other is that I didn't want to increase the amount of bugs reported on Geany's SF.net trackers when I can easily manage them on the Github issues tracker separately without causing noise on SF.net.
Still, I think it would be a good idea to move it, if nobody else objects.
Moving the repo to Geany wouldn't make your repo disappear. It would be turned into a clone of Geany's repo, or simply the way around (you can easily make the Geany-repo be cloned initially from your repo even if main development then happens in the Geany-repo). That way the followers of your repo are still notified.
Is there an automatic way to keep them in sync, or would I have to push to each one for each commit? Not that that's a big deal, just curious.
Cheers, Matthew Brush
Hi together,
as a result of this discussion, here we go:
http://dmaphy.fedorapeople.org/geany-tags/
I did not request an official review for the package, though. Since it there are some issues I'd like to clarify in advance:
* I have to set a License: tag for the package, it is not mentioned under which license the "tags project" is distributed
* the source tarball is pulled from here at present:
http://wiki.geany.org/get_tags
That page is sending the correct file name via HTTP headers, a users browser suggests to save the downloaded file as geany-tags.tar.bz2 then. A command line tool like wget or Fedoras spectool don't.
* There doesn't seem to be any release concept yet for the tags, thus a version is completely missing at present. It's a lot of effort for a package maintainer to track changes and keep his package up-to-date with latest tags files.
My suggestion: Create a new Git repository under the hood of Geany at GitHub, add or update new tags files as pull requests, tag releases (e.g. 0.21 and when additional tags files come through, increase to 0.21.1 and so on) and have branches for different Geany versions.
Objections on this?
Regards, Dominic
On 12/24/2011 12:19 PM, Dominic Hopf wrote:
Hi together,
as a result of this discussion, here we go:
http://dmaphy.fedorapeople.org/geany-tags/I did not request an official review for the package, though. Since it there are some issues I'd like to clarify in advance:
I have to set a License: tag for the package, it is not mentioned under which license the "tags project" is distributed
the source tarball is pulled from here at present:
That page is sending the correct file name via HTTP headers, a users browser suggests to save the downloaded file as geany-tags.tar.bz2 then. A command line tool like wget or Fedoras spectool don't.
It's running a little CGI Python script I made that creates the tarball on-the-fly. It uses the following header:
Content-Type: application/octect-stream Content-Disposition: attachment; filename=geany<-language>-tags.<ext> Content-Length: <size of tarball>
You can see more looking at the script on the server and it also has a help output: http://wiki.geany.org/get_tags?help=true
- There doesn't seem to be any release concept yet for the tags, thus a version is completely missing at present. It's a lot of effort for a package maintainer to track changes and keep his package up-to-date with latest tags files.
My suggestion: Create a new Git repository under the hood of Geany at GitHub, add or update new tags files as pull requests, tag releases (e.g. 0.21 and when additional tags files come through, increase to 0.21.1 and so on) and have branches for different Geany versions.
Objections on this?
No objections here. All it would take is to re-link the stuff on the wiki page to download from the github address using a little script/sed. Not sure if the above Python tarball script would be useful still, but that's ok.
Cheers, Matthew Brush
has anyone had much experience using JavaScript and jslint with geany? I was looking at the scintilla release notes and couldn't find much mention of JavaScript except for the may 27 release bug fix of JavaScript with nested php, and a note in the December 9 release that coffeescript support was added.
I can probably add jslint to the build commands.
Sent from iPhone
Please do! Im using vim with jslint, and if geany could work in a simular manner than that would be great.
Eddy On Dec 25, 2011 6:35 AM, "Sayth" flebber.crue@gmail.com wrote:
has anyone had much experience using JavaScript and jslint with geany? I was looking at the scintilla release notes and couldn't find much mention of JavaScript except for the may 27 release bug fix of JavaScript with nested php, and a note in the December 9 release that coffeescript support was added.
I can probably add jslint to the build commands.
Sent from iPhone _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Jslint is a lint program similar to the original c lint program. It checks for syntax errors in JavaScript that can be very hard to spot otherwise.
There is also a new community originated checker jshint.
Sayth
Sent from my iPhone
On 25/12/2011, at 7:07 PM, Frank Lanitz frank@frank.uvena.de wrote:
Am 25.12.2011 06:34, schrieb Sayth:
has anyone had much experience using JavaScript and jslint with geany?
What is jslint?
Cheers, Frank
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
G'day Sayth,
I use JavaScript Lint on Fedora Linux with Geany, it integrates just fine. I'll email details tomorrow when I don't have a glass in my hand :)
merry whats'its, Ross
Sayth wrote:
has anyone had much experience using JavaScript and jslint with geany? I was looking at the scintilla release notes and couldn't find much mention of JavaScript except for the may 27 release bug fix of JavaScript with nested php, and a note in the December 9 release that coffeescript support was added.
I can probably add jslint to the build commands.
SWMBO has gone off somewhere and my glass is sadly empty, so:
Yes, you can add it to the build commands. Here's what I did, but note that I'm using JavaScript Lint (jsl)[1] not jslint[2] so you'll need to adjust as necessary.
Just open Geany, and make sure that you have no project open. This will ensure that your build commands are common to the filetype, not specific to whatever project you are running.
Then set your build commands, per the manual[3], taking note of the possible substitutions. For jsl, I set the first command label as Lint and the command string as:
jsl -conf ~/jsl.conf -process %f
where ~/jsl.conf has my JavaScript Lint configuration (where I turn off the nagging I really don't need!)
While you're at it, you might as well add your favourite minifier, e.g. YUICompressor[4] or whatever.
What I end up with is the following lines in my ~/.config/geany/filedefs/filetypes.javascript file:
[build-menu] FT_00_LB=Lint FT_00_CM=jsl -conf ~/jsl.conf -process %f FT_00_WD=%d FT_01_LB=Minify FT_01_CM=yuimin %f -o %e.min.js FT_01_WD=%d
(yuimin is a simple bash wrapper around YUICompressor)
This means I can bang away at some JS, hit F8 to get a serious lint nagging, and F9 to minify to the_file_name.min.js
cheers and bleary xmas, Ross
PS: i checked out jsl and jslint, and for some reason jslint pissed me off so I settled on jsl instead (probably because I could tell it what not to nag me about); just my AUD0.02 for what little that's worth.
[1] http://www.javascriptlint.com/ [2] http://www.jslint.com/ [3] http://www.geany.org/manual/current/index.html#build-menu [4] http://developer.yahoo.com/yui/compressor/
Hi Ross
Thanks for the reply. Have been caught up with Xmas festivities myself.
I need to sort out installing jsl on Ubuntu first and then will let you know how I get on with setting up geany.
Sent from my iPhone
On 25/12/2011, at 11:05 PM, Ross McKay rosko@zeta.org.au wrote:
Sayth wrote:
has anyone had much experience using JavaScript and jslint with geany? I was looking at the scintilla release notes and couldn't find much mention of JavaScript except for the may 27 release bug fix of JavaScript with nested php, and a note in the December 9 release that coffeescript support was added.
I can probably add jslint to the build commands.
SWMBO has gone off somewhere and my glass is sadly empty, so:
Yes, you can add it to the build commands. Here's what I did, but note that I'm using JavaScript Lint (jsl)[1] not jslint[2] so you'll need to adjust as necessary.
Just open Geany, and make sure that you have no project open. This will ensure that your build commands are common to the filetype, not specific to whatever project you are running.
Then set your build commands, per the manual[3], taking note of the possible substitutions. For jsl, I set the first command label as Lint and the command string as:
jsl -conf ~/jsl.conf -process %f
where ~/jsl.conf has my JavaScript Lint configuration (where I turn off the nagging I really don't need!)
While you're at it, you might as well add your favourite minifier, e.g. YUICompressor[4] or whatever.
What I end up with is the following lines in my ~/.config/geany/filedefs/filetypes.javascript file:
[build-menu] FT_00_LB=Lint FT_00_CM=jsl -conf ~/jsl.conf -process %f FT_00_WD=%d FT_01_LB=Minify FT_01_CM=yuimin %f -o %e.min.js FT_01_WD=%d
(yuimin is a simple bash wrapper around YUICompressor)
This means I can bang away at some JS, hit F8 to get a serious lint nagging, and F9 to minify to the_file_name.min.js
cheers and bleary xmas, Ross
PS: i checked out jsl and jslint, and for some reason jslint pissed me off so I settled on jsl instead (probably because I could tell it what not to nag me about); just my AUD0.02 for what little that's worth.
[1] http://www.javascriptlint.com/ [2] http://www.jslint.com/ [3] http://www.geany.org/manual/current/index.html#build-menu [4] http://developer.yahoo.com/yui/compressor/ -- Ross McKay, Toronto, NSW Australia "It's not the right time to be sober, Now that the idiots have taken over" - NOFX _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
G'day Sayth,
Thanks for the reply. Have been caught up with Xmas festivities myself.
cheers :)
I need to sort out installing jsl on Ubuntu first and then will let you know how I get on with setting up geany.
It should be in your package manager (it was on Fedora anyway).
I just noticed that I left out a step:
[...]
Just open Geany, and make sure that you have no project open. This will ensure that your build commands are common to the filetype, not specific to whatever project you are running.
Set document filetype to JavaScript (so that the build settings go into that filetype's config!) e.g. save empty document as /tmp/junk.js
Then set your build commands, per the manual[3], taking note of the possible substitutions. For jsl, I set the first command label as Lint and the command string as:
jsl -conf ~/jsl.conf -process %f
where ~/jsl.conf has my JavaScript Lint configuration (where I turn off the nagging I really don't need!) [...]