Devel June 2009

devel@lists.geany.org

17 participants
19 discussions

Restructuring the Geany-plugins project?
by Enrico Tröger 19 Jun '09

19 Jun '09

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

8 27

Nightly build failed: Gigolo build
by nightly.geany.org 17 Jun '09

17 Jun '09

Gigolo build failed at: waf configure See http://nightly.geany.org/misc/build_gigolo_stderr.log for details. Last error message: ERROR:root: error: No module named gnu_dirs http://nightly.geany.org/

2 1

Python plugin API
by Jonas Haag 15 Jun '09

15 Jun '09

Hi there, I'm now hacking python for about two to three years and I'm willing to wrap that plugin api to python. Browsing the geany site I noticed that you want such an api as well, so my question is: Are there any special plans for that interface? Or shall I just take the C api and wrap it? Cheers, Jonas

4 17

Nightly build failed: Plugins Windows build
by nightly.geany.org 15 Jun '09

15 Jun '09

Plugins Windows build failed at: waf configure plugins See http://nightly.geany.org/win32/build_win32_plugins_stderr.log for details. Last error message: File "/home/enrico/geany/plugins_svn/.waf-1.5.7-8edda22ed216daab7aed3d430dc291cf/wafadmin/Scripting.py", line 168, in configure conf.sub_config(['']) File "/home/enrico/geany/plugins_svn/.waf-1.5.7-8edda22ed216daab7aed3d430dc291cf/wafadmin/Configure.py", line 100, in sub_config self.recurse(k,name='configure') File "/home/enrico/geany/plugins_svn/.waf-1.5.7-8edda22ed216daab7aed3d430dc291cf/wafadmin/Utils.py", line 391, in recurse f(self) File "<string>", line 284, in configure TypeError: not enough arguments for format string http://nightly.geany.org/

2 1

nightly.geany.org improvements
by Enrico Tröger 14 Jun '09

14 Jun '09

Hey all, I improved the nightly builds a bit and added a fancy overview page at http://nightly.geany.org/ to show what has been built and what's the status of each build. Additionally, now we build Geany and the geany-plugins against GTK 2.8 just to test the compatibility and to early get notified when we (most probably I) broke it :). And finally, once any of the builds fail for whatever reason, the script sends a mail to the geany-devel list to inform us developers. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc

2 1

Nightly build failed: Geany GTK 2.8 build test
by nightly.geany.org 14 Jun '09

14 Jun '09

Geany GTK 2.8 build test failed at: waf build See http://nightly.geany.org/build_gtk28_stderr.log for details. Last error message: [191/192] cxx_link: _build_/default/src/about_3.o _build_/default/src/build_3.o _build_/default/src/callbacks_3.o _build_/default/src/dialogs_3.o _build_/default/src/document_3.o _build_/default/src/editor_3.o _build_/default/src/encodings_3.o _build_/default/src/filetypes_3.o _build_/default/src/geanyentryaction_3.o _build_/default/src/geanymenubuttonaction_3.o _build_/default/src/geanyobject_3.o _build_/default/src/geanywraplabel_3.o _build_/default/src/highlighting_3.o _build_/default/src/interface_3.o _build_/default/src/keybindings_3.o _build_/default/src/keyfile_3.o _build_/default/src/log_3.o _build_/default/src/main_3.o _build_/default/src/msgwindow_3.o _build_/default/src/navqueue_3.o _build_/default/src/notebook_3.o _build_/default/src/plugins_3.o _build_/default/src/prefix_3.o _build_/default/src/prefs_3.o _build_/default/src/printing_3.o _build_/default/src/project_3.o _build_/default/src/queue_3.o _build_/default/src/sciwrappers_3.o _build_/default/src/search_3.o _build_/default/src/socket_3.o _build_/default/src/stash_3.o _build_/default/src/symbols_3.o _build_/default/src/templates_3.o _build_/default/src/toolbar_3.o _build_/default/src/tools_3.o _build_/default/src/treeviews_3.o _build_/default/src/ui_utils_3.o _build_/default/src/utils_3.o _build_/default/src/vte_3.o -> _build_/default/geany default/src/about_3.o: In function `create_dialog': about.c:(.text+0x17d6): undefined reference to `g_intern_string' collect2: ld returned 1 exit status Waf: Leaving directory `/home/enrico/geany/gtk28_test/_build_' Build failed -> task failed (err #1): {task: cxx_link about_3.o,build_3.o,callbacks_3.o,dialogs_3.o,document_3.o,editor_3.o,encodings_3.o,filetypes_3.o,geanyentryaction_3.o,geanymenubuttonaction_3.o,geanyobject_3.o,geanywraplabel_3.o,highlighting_3.o,interface_3.o,keybindings_3.o,keyfile_3.o,log_3.o,main_3.o,msgwindow_3.o,navqueue_3.o,notebook_3.o,plugins_3.o,prefix_3.o,prefs_3.o,printing_3.o,project_3.o,queue_3.o,sciwrappers_3.o,search_3.o,socket_3.o,stash_3.o,symbols_3.o,templates_3.o,toolbar_3.o,tools_3.o,treeviews_3.o,ui_utils_3.o,utils_3.o,vte_3.o -> geany} http://nightly.geany.org/

2 1

Patches for Code Page 932
by Ryūsei Yamaguchi 14 Jun '09

14 Jun '09

Hi Geany Developers, Please use the files attached this mail. Them are patches for Code Page 932(Windows-31J). Regards, Ryusei

2 1

executing .m files with octave by default
by Amr Hassan 05 Jun '09

05 Jun '09

Hey guys, Great work on Geany. It's by far my most favorite text editor. A few minutes ago with the help of dmaphy on IRC, I was able to make it a bit more awesome for me by having it execute .m files on octave the way it does with python. All I had to do was add: [build_settings] # %f will be replaced by the complete filename # %e will be replaced by the filename without extension # (use only one of it at one time) compiler= run_cmd=octave -q "%f" to the end of the file ~/.config/geany/filedefs/filetypes.matlab, that would execute the script on octave if it's installed. I was wondering if this could be added by default. Octave is a pretty decent matlab-compatible free tool ( http://en.wikipedia.org/wiki/GNU_Octave). So, what do you guys think? -- Amr

3 4

Merging of Geany Plugins
by Chow Loong Jin 04 Jun '09

04 Jun '09

Hi Geany Developers, I've recently begun packaging the whole set of Geany plugins for Ubuntu (and will be working on it for Debian soon), and Enrico Tröger has mentioned before that he'd like to see the whole set of plugins packaged as one instead of separately, as it is currently. I, too, think it's a good idea to do something like that. However, for that to be done, I'll need the whole geany-plugins tarball released together at once. This has several implications: * Synchronizing the plugins' releases. * There must be a build system capable of building the plugins together as well as separately. The first, I'll have to leave to the plugin developers to discuss among themselves. For the second issue, I've noticed that there has been discussion about this before. In that thread, there were two main issues: * large and hard to maintain configure.in file * po/ is required to be in the top level directory by intltool. For the first issue, I have a solution. Autotools allows you to pass -I<include directory> to aclocal. This can be seen in Banshee[1]'s autogen.sh. This allows you to factor out all the plugin-specific checks into plugin/build/m4/<stuff>.m4 as individual m4 macros, and have one macro per plugin that calls all the plugin-specific checks. This can then be called in the top-level configure.in, as well as each plugin's configure.in. For the second issue, I think maintaining the plugins' independence is possible if the translations from all plugins are merged into the top-level po/ directory by autogen.sh. This would mean that if the plugins' are built together, GETTEXT_PACKAGE="geany-plugins", whereas if they are built separately, GETTEXT_PACKAGE="$pluginname". Whether or not they are built together would be left up to the user. That said, I hope to hear positive responses about this matter. =) Thank you for your time. [1] http://git.gnome.org/cgit/banshee/tree/autogen.sh -- Regards, Chow Loong Jin

6 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel June 2009