Re: [Geany-devel] Some sort of thoughts about geany-plugins-devel-git-repo
On 11/15/11 8:55 PM, Frank Lanitz wrote: Hi developers, It has been a while when I first announced a mail about my idea of process after transition of geany-plugins repository. As from my understand the only open point is to have clarified the svn-url-reference question its a good point to tell you what I'm thinking of. Currently we do have about 25 people which are allowed to commit to geany-plugins svn. Not all of them are active at the moment (and might won't get active again sometime in future), some of them are low in time or no responsive at the moment. On the other hand we do have about 30 plugins, which are mostly maintained. As you know from discussion about e.g. geanydbg/debugger and the project plugins, some of them are currently not maintained very actively and are getting obsolete. Given the changes for Python plugin support in pipeline of Geany I'm in a good mood that we will have a increasing number of contributors and plugins available for Geany. Some of the new plugins will be distributed via the geany-plugins-project for sure as well as contributors like to add maybe features, bugfixes etc. to existing code basis. Unfortunately in past we had not really some kind of a quality assurance on committing code beside authors and maybe devel users. We introduced the make check build target a couple of month ago which gave a more critical view onto code. Based on this a huge number of warnings, memory leaks and bugs has been able being removed. But still issues are left. As we will have some kind of a reset with movement to github, its a good point to rethink about the way, how patches are introduced to geany-plugins. So this is my idea how to do so: We will have one master branch where all changes intended for releasing are going in. Features and new plugins are going to be developed inside branches (more late onto this topic) and once they are in a suitable status, they are getting merged into master branch. Release are generated from master branch and are getting marked with a tag. If there is any need for some minor release as we had e.g. with 0.21.1 there will be a release branch that will include all patches going in. If they are also needed to get applied on master, we can cherry-pick them or find some other way of merging them back. We can divide contributors for plugins into 2 groups: 1: Contributors to existing plugins or general infrastructure as e.g waf/autotools 2: Contributors of new plugins Here we should set up 2 processes: Contributions of group 1 should clone the repository and sending a pull request or patch to maintainer of plugins. Once they did this, the maintainer is reviewing the changes and including them into his branch. Contributors of new plugins shall send a pull request of full diff to release team. And this is another point. I imagine to have a release team which is taking care of overall quality of geany-plugins. This is including following: If a plugin maintainer is finishing a change or a review he is sending a merge request to the release team. After they did a review based on criteria given e.g. inside HACKING they are merging it into master branch. If the patch is not hitting a minimum on quality its getting refused. Thins to be done in front if you like this change: - Defining release team - Reviewing HACKING and defining basic quality criteria - Pushing all to github ;) What do you think? Feedback is highly welcome ;) Cheers, Frnak ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel Hi there, I also vote for increasing plugins quality, but as for me Franks ideas about different branches seem a bit overcomplicated. Maybe we can use git pre-commit hook to prevent commits that breaks some quality criteria? http://book.git-scm.com/5_git_hooks.html To be honest I didn't get much into details but it seemed to me that it can handle quality check tasks. So my suggestion is still to use a single common repo for all plugins and use commit hooks to prevent unqualified code. This requires that at some point all plugins in this repo pass this quality check, and here is what I suggest - move plugins from svn one by one, checking code for quality. For those that didn't pass we can create a distinct repo under geany organization. Once a maintainer or a volunteer refine a code to fit the requirements it can be moved to a main repo. Until then it can be still available but won't be included in g-p release (maybe we can create distinct release geany-plugins-unsupported, as IIUC I already suggested once). To easily move plugins between probably it's a good idea to use submodules, IIUC this is svn externals analogue. To make every plugin compile and build independently I vote for eliminating common po catalog, that I also suggested recently, this will also help to avoid translations intersection between different plugins. Renaming
Re: [Geany-devel] Some sort of thoughts about geany-plugins-devel-git-repo
Am 15.11.2011 17:55, schrieb Frank Lanitz: We will have one master branch where all changes intended for releasing are going in. Features and new plugins are going to be developed inside branches (more late onto this topic) and once they are in a suitable status, they are getting merged into master branch. Release are generated from master branch and are getting marked with a tag. If there is any need for some minor release as we had e.g. with 0.21.1 there will be a release branch that will include all patches going in. If they are also needed to get applied on master, we can cherry-pick them or find some other way of merging them back. I like this proposal. Requiring pull requests will also formally mean get your plugin in shape before release. I'd like to extend this to the point that if a plugin is not ready (due to bad code, inactive maintainer, or otherwise) the snapshot from the previous release will be taken as to not lose functionality (this is in most cases automatic, since the merge didn't happen). I strongly advice against delaying releases for individual plugins. However, there's one problem that isn't addressed, and I'm not sure it can be technically since it's more a cultural problem: There's IMO too little collaboration on plugins. It's kind of each plugin to its maintainer, with little to no collaborative effort to form the best and greatest plugins. It feels like the source is available but not really open. OTOH perhaps my perception is just wrong, and this cannot be fixed by technical measures anyway. Regarding the ideas with separate repos/submodules: This basically breaks what the initial idea of geany-plugins was. To share infrastructure, build system and translations. The combined release idea came actually some time after that. If the repos are separate and only merged for release, then they can just as well be separate entirely. So I disagree with that.They should be one repo, since they share a common code base via the translation and infrastructure. Am 16.11.2011 07:12, schrieb Lex Trotman: Although I am not a plugin developer I have a couple of suggestions based on the following needs: 1. Individual plugin maintainers shouldn't care about all the other plugins in the combined release Not caring about other plugins is ok, but that doesn't mean his clone/checkout must not have other plugins. 2. Users getting the combined release to build should get everything in one command This is status quo, and should be kept, yes. 3. The combined release maintainers still need to be able to make changes to each plugin in case of urgent bugfix and temporarily or permanently missing individual plugin maintainer. I agree. 4. Not all plugins are in the combined release, due to quality, timing, or maintainer availability issues. But users rely on plugins so it is bad to remove their availability. Covered by my suggestion to simply re-use the previous release. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Some sort of thoughts about geany-plugins-devel-git-repo
Am 16.11.2011 02:18, schrieb Matthew Brush: With some changes to the build system(s) it should be possible to make each plugin buildable on its own or as part of the geany-plugins project, as opposed to now, where it's difficult (impossible?) to have your plugin build independently of the geany-plugins project and still use Autotools (or Waf). This wasn't the goal. The goal was to have one, single plugin release. Singe build wasn't goal and I'd like to don't some thinking about at this point. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] question, webhelper plugin on windows xp
Le 23/10/2011 23:21, Ross McKay a écrit : Jérôme Andanson wrote: Another question will be is it possible to have two times the plugin,like two tab ? (two can be2 but 2 is good) [...] I know my request is a little bit strange. the case is developing a website with a manager part and a public part. for switch from the first to the second, two view will be more pratical. the first 'bad' thing come in my head was just compile the plugin with a different name so i can have twice. I think you would find it best to work in either Firefox with the Firebug[1] and Web Developer[2] extensions, or Google Chrome with its developer tools. There you could easily have two tabs open and viewing what actually goes to the browser, with good developer inspection tools. If you have two screens, all the better because you can have the whole page in view on one screen whilst inspecting elements, CSS and scripts on the other screen. Opera has reasonable developer tools too, called Dragonfly[3], but I've always found it a little clunky compared to Firebug... but it does let you remote-debug Opera Mobile [1] https://addons.mozilla.org/en-US/firefox/addon/firebug/ [2] https://addons.mozilla.org/en-US/firefox/addon/web-developer/ [3] http://www.opera.com/dragonfly/ thanks Ross Late response due of a bad thunderclap who broke some materials I know this kind of use (browser with extension), just note webhelper plugins include The webkit web inspector who is almost similar as chrome's version. I use a big screen (27) and i can see sidebar with webhelper browser + inspector and the editor at once, pretty awesome. I really think my request was irrelevant for the use of two tabs, just centralize action for windows port. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Some sort of thoughts about geany-plugins-devel-git-repo
[...] I like this proposal. Requiring pull requests will also formally mean get your plugin in shape before release. I'd like to extend this to the point that if a plugin is not ready (due to bad code, inactive maintainer, or otherwise) the snapshot from the previous release will be taken as to not lose functionality (this is in most cases automatic, since the merge didn't happen). I strongly advice against delaying releases for individual plugins. Yes, using an older version is a good idea if it still builds ok. If it doesn't (eg devhelp plugin on some systems because only gtk3 version is available) then the decision needs to be made at the time to accept the upgrade or remove the plugin and what to do with it. However, there's one problem that isn't addressed, and I'm not sure it can be technically since it's more a cultural problem: There's IMO too little collaboration on plugins. It's kind of each plugin to its maintainer, with little to no collaborative effort to form the best and greatest plugins. It feels like the source is available but not really open. OTOH perhaps my perception is just wrong, and this cannot be fixed by technical measures anyway. I don't think your perception is wrong, but I think that keeping plugins reasonably separate is also a good idea. As a user I can choose the parts I want without the parts I don't need. So only really tiny things should be combined like addons. In other cases, like project management, there is sufficient variation in use-cases that there may be more than one plugin, like how the current project plugins address two slightly differernt uses. Or in some cases there is a natural progression from an old plugin to a new (and hopefully better) one, eg debugger plugins What it needs is a technical solution to allow plugins to build on other plugins. That way the original functionality doesn't need to be re-built, but it introduces dependencies between plugins. Regarding the ideas with separate repos/submodules: This basically breaks what the initial idea of geany-plugins was. To share infrastructure, build system and translations. The combined release idea came actually some time after that. I'm not sure that it prevents any of this, but as I now understand it, GP plugins can't be built separately so, yes, it makes less sense to have separate repos. If the repos are separate and only merged for release, then they can just as well be separate entirely. So I disagree with that.They should be one repo, since they share a common code base via the translation and infrastructure. As you say above, they actually share bugger all :) [...] Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Preventing cd to clutter VTE shell history
Hi, An user on IRC asked whether there was a way to prevent the cd commands that Geany launches on the VTE when follow_path is enabled to clutter his shell history. I first though no, but actually Bash don't put in the history commands prefixed with a space [1]; and ZSH has an option [2] to follow this behavior (while doing nothing special without the option). The reason of this mail is to ask you if you think that prefixing the cd command with a space should be made a pref or not. Pros: * 1-char change (only adds a space) * No extra hidden pref no body cares about * Probably no need to be configurable * Probably won't do anything wrong with other shells (CSH, whatever) * ... Cons: * Not configurable * Maybe some shell would interpret this another way? * ... So... do you think it should be configurable or do I simply put a leading space and be done with it? Cheers, Colomban [1] though I didn't found the feature in bash's manual, with a fast and inaccurate grep. [2] HIST_IGNORE_SPACE ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Preventing cd to clutter VTE shell history
[...] So... do you think it should be configurable or do I simply put a leading space and be done with it? Make it a various pref since its configurabel in bash [3] Cheers Lex Cheers, Colomban [1] though I didn't found the feature in bash's manual, with a fast and inaccurate grep. [3] See HISTCONTROL and HISTIGNORE variables in http://www.gnu.org/s/bash/manual/bash.html#Bash-Variables [2] HIST_IGNORE_SPACE ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Writing a plugin, not sure what to do with it
Hi, Thanks very much for the input! I've pasted an updated version here [1] which should implement your suggestions (assuming I understand them correctly). Cheers Alex [1] http://pastebin.com/WJXYQm1N On Tue, Nov 15, 2011 at 6:45 PM, Lex Trotman ele...@gmail.com wrote: On Wed, Nov 16, 2011 at 8:29 AM, Meyer 3m.me...@gmail.com wrote: Hi all, I was looking for some programming to do recently and found this feature request: https://sourceforge.net/tracker/?func=detailaid=3383201group_id=153444atid=787794 . I tried writing a plugin which implements the feature, and it seems to work, but now I'm not sure what to do with it now. I've pasted the code here: http://pastebin.com/549Dazj0. My main concerns are that it seems very hack-ish, and seems too simple to be a full plugin. Any advice regarding the code, what to do with it, etc. would be much appreciated. Hi, Nice simple plugin, but very fixed in operation, I have a couple of suggestions. 1. Use keybindings rather than the editor notify. This lets you catch the key before it is inserted in Scintilla and allows the user to set the trigger keycode (for me the actual characters would not be appropriate, but ctrlshiftchar would be, but different users would have different use-cases). See for eg addons plugin for how to use keybindings. 2. Group the changes you make into one undo group, see the scintilla docs. 3. Add a preferences dialog to allow the opening and the respective closing character(s) to be set for each trigger keycode. It would of course default to your current pairs but would allow updating for other languages and multi character sequences. See again for eg addons. 4. Have 1 and 3 allow up to say eight codes/pairs to be defined. The plugins infrastructure is about to get moved to Github and some new processes are being defined, see http://news.gmane.org/find-root.php?message_id=%3c4EC29977.1030802%40frank.uvena.de%3e so keep an eye on that thread and you can be the first new plugin using the new process :) Cheers Lex Thanks, Alex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Preventing cd to clutter VTE shell history
Le 17/11/2011 02:30, Lex Trotman a écrit : [...] So... do you think it should be configurable or do I simply put a leading space and be done with it? Make it a various pref since its configurabel in bash [3] Ah thanks, makes sense :) Committed as 59eb055. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
