Devel September 2011

devel@lists.geany.org

18 participants
38 discussions

Various pref changes not ignored on dialog cancel
by Nick Treleaven 21 Sep '11

21 Sep '11

Hi, I've found a bug when changing a various pref setting in the prefs dialog, then cancelling the dialog without applying the changes. Next time the dialog is shown the edited values are still present. Could cause the user to then apply the unwanted changes without realizing, so it's quite a nasty bug. Nick

4 9

geany-commits reply subject line
by Nick Treleaven 21 Sep '11

21 Sep '11

Hi all, When replying to geany-commits mails, please edit the subject to include something descriptive, not just the revison number. That would really help pick out any important needles in the haystack of emails ;-) Thanks, Nick

1 0

Re: [Geany-devel] SF.net SVN: geany:[5937] trunk
by Lex Trotman 21 Sep '11

21 Sep '11

On 21 September 2011 00:29, <ntrel(a)users.sourceforge.net> wrote: > Revision: 5937 > http://geany.svn.sourceforge.net/geany/?rev=5937&view=rev > Author: ntrel > Date: 2011-09-20 14:29:46 +0000 (Tue, 20 Sep 2011) > Log Message: > ----------- > Rename use_safe_file_saving various pref to use_atomic_file_saving > as it's not 'safe'. Use old pref if new one is missing for > compatibility with Geany <= 0.20. > Hi Nick, I like atomic, large mushroom cloud when you use this setting :) Don't forget to update the manual Cheers Lex

2 1

ChangeLog for Geany: is that useful, for who and how? (was Re: Geany-Plugins: Please check for ChangeLog-entries on commit)
by Colomban Wendling 21 Sep '11

21 Sep '11

Le 19/09/2011 08:15, Frank Lanitz a écrit : > Hi folks, > > Another episode from topic improving plugins by Frank ;) > > In last time I saw a lot of changes going in into plugins without > having a ChageLog entry set. > > Its not always useful in every case but its a nice thing for users of > trunk and also stable releases to have a middle view between NEWS-file > which is in most cases only a very short compilation of changes and > the very, very verbose svn/git log view. So I'm bagging you to have > in mind updating your ChangeLog and when every updating po-files or > something else inside geany-plugins/trunk/geany-plugins/po I make it > mandatory ;) Oh no, I planned to start (again [1]) a discussion about *removing* ChangeLog committing :D (OK, I though about Geany itself, not GP) I'll start it right now then, if you don't mind. Introduction ------------ My POV on ChangeLogs is that they are from the old days, the time nobody used VCS, so it was a VCS log. Nowadays with VCS, I think a ChangeLog only causes useless efforts -- especially if combined with a DVCS, with which you got the full history locally [2]. So, I think we should get rid of a versioned ChangeLog. What's the ChangeLog's problems? -------------------------------- Here are a few points (not really sorted) I see against versioned ChangeLogs, why I don't really like them: 1) They causes VCS conflicts. When doing a perfectly linear development, it's not a so big deal -- only two concurrent commits could require somebody to fix a conflict --, but when merging branches it is far less straightforward. 2) They needs to be maintained, as Frank just said. I feel this as a useless additional effort since we have the VCS commit, moreover since both will look quite the same in practice. 3) Some people argue that ChangeLogs don't hold all the information a VCS log would hold, and are less clobbered with uninteresting changes. While I might agree that a plain VCS log might contain more entries than a ChangeLog for the same tree, I also think that the ChangeLog is *far* less useable that the VCS log. Why? Because using the VCS, one can filter by directories, files, commits, branches, etc., many things that are very hard, if not impossible, to do with a ChangeLog. So I thing that even if the VCS log might contain a few uninteresting entries for some ChangeLog readers, it is so easier to filter the ones to show I don't think it is a real concern. 4) Who actually reads ChangeLog that couldn't do the same with VCS log? OK, SVN is a pain to use when it comes to play with the history because it's laggy, but imagine you were using a DVCS like, say, Git, where navigating the history is instantaneous. I mean, who is interested by ChangeLog's content actually? 4.1) Developers? I think they better use VCS log, it's more complete and as I already said, I think it's more flexible (VCS have log, blame, bisect, show, diff, etc.). 4.2) Users? I think either NEWS is complete enough, or ChangeLog is clobbered with useless information (like date, authors, modified files, etc.). 5) It's a versioned file that records changes... sounds weird, doesn't it? What format a ChangeLog should actually have, if any? ----------------------------------------------------- If it is meant for power users for whom the NEWS is not complete enough (4.2), I think that we should then just make it a more complete version of NEWS, e.g. a list of changes but without dates, authors and files (maybe that's Release Notes?). It would then either be built like NEWS, e.g. manually soon before release, or somewhat automated (see below). However, if we just want ChangeLog to be the VCS history for the non-VCS situations like tarballs, I think that generating it from VCS log is good enough. Could ChangeLog be auto-generated? ---------------------------------- I think the answer is "yes". If ChangeLog is a VCS log for tarballs, it's very easy to generate it, many scripts already exists for various VCS (e.g. I know GLib does it, for a concrete example). If ChangeLog is a filtered version of the VCS' log (with either format we want), we could imagine we annotate commits so that we could automatically filter them for inclusion in the generated ChangeLog. E.g. in a git-style pseudo-header [3], something like: changelog-entry: [true|false] or something. If we choose something like this, we probably could even setup commit hooks to check that the header is present to make sure we don't forget it by accident. Such generated ChangeLog might even only contain the commit summary (e.g. the first line in a good Git-style commit) if we think the whole message might not be useful. Conclusion ---------- I know I already started a thread on a very close topic about a year ago [1], but I think it might be interesting to ask again since we're supposed to change a little the Geany's commit workflow with a VCS change, so it's the right time I guess. And maybe some people have changed their mind? :D Honestly the part that really frightens me is the conflicts if we adopt a merge-based (or any non-linear) workflow. So, this is it. I'm waiting for any POVs, remarks, flamewars, insults, etc. you find appropriate :) Regards, Colomban [1] http://lists.uvena.de/pipermail/geany-devel/2010-November/003401.html [2] and we're supposed to witch to Git after the release, and it's a DVCS :) [3] which, like most pseudo-headers like signed-of-by, acked-by, etc are actually commit's footers...

5 7

saving plugin settings in a project file
by Alexander Petukhov 20 Sep '11

20 Sep '11

I would like to store debugger settings such as watches, breaks, target etc in a project file. These are not the settings that apply to a plugin in a whole but look like being related to files user is working with, i.e. a project. After looking at project signals I was 100% sure that they are intended to give a plugin a place to store its settings that apply to a project. Yesterday on IRC we talked about it and Matthew said that it's better to have a distinct file. As for me, I'd better keep all session related settings in one file, i.e. in a project and would like to ask you here what do you think about? One more question is about project signals, looks like to save settings in a project a plugin is encouraged to add a notebook tab in "project_dialog_create" signal handler and to save setting when this dialog is closed when processing a "project_save" signal. The GKeyFile that is passed in "project_open" signal is closed right after sending a signal, so plugins can't use it for saving data. What if I want to write settings not using project settings dialog that looks unsuitable for a debugger, is it correct to initialize and the save a new GKeyFile to geany_data->app->project->file_name? Regards, Alexander

3 2

Geany-Plugins: Please check for ChangeLog-entries on commit
by Frank Lanitz 19 Sep '11

19 Sep '11

Hi folks, Another episode from topic improving plugins by Frank ;) In last time I saw a lot of changes going in into plugins without having a ChageLog entry set. Its not always useful in every case but its a nice thing for users of trunk and also stable releases to have a middle view between NEWS-file which is in most cases only a very short compilation of changes and the very, very verbose svn/git log view. So I'm bagging you to have in mind updating your ChangeLog and when every updating po-files or something else inside geany-plugins/trunk/geany-plugins/po I make it mandatory ;) Cheers, Frank

2 1

A few JavaScript tag parser fixes from exuberant ctags?
by Colomban Wendling 18 Sep '11

18 Sep '11

Hi, I've merged exuberant ctags changes on the javascript parser [1] (in the hope it fixed [2], without success [3]), and it contains a few fixes (4 actually). Attached is a the patch I made, but I'm wondering whether I should commit it now, or wait until the release. It's supposed only to contain fixes -- and looks like it does, from reading upstream log and the resulting patch -- but I don't know JavaScript enough to actually do any checks [4]. Any thoughts? Cheers, Colomban [1] http://ctags.svn.sf.net/viewvc/ctags/trunk/jscript.c?view=markup [2] https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3398636&group_… [3] although I found what's the problem (the regex aren't parsed, so "//" inside one is considered as a comment start, etc.) I can't find a correct way to fix it :/ [4] but upstream has a testsuite

2 1

various prefs warning
by Nick Treleaven 18 Sep '11

18 Sep '11

Hi, I think there should be a clear warning about changing the new various prefs - e.g. a user might enable use_safe_file_saving and then run into problems. I'll try to add a warning label and perhaps put the treeview in an expander, collapsed by default. We want to make it obvious that changing those settings should only be done if you know what you're doing. I think this change should go through before the string freeze. Nick

5 22

String freeze for Geany 0.21
by Frank Lanitz 17 Sep '11

17 Sep '11

Hi translators and friends of Geany, Time is passing by and it's time for doing a new release of Geany! To manage all translation coming in in time we are having a string freeze for upcoming Geany 0.21, which will be release around October, 1st. The list of changes done for this release is long, but number of new and changed strings isn't that huge. How I like to ask all translators to check the translations so we really could put in updated translations files into the new release and make to the best release we ever had. I'd be very happy if you could send a patch or complete file with translation to either the geany-i18n mailing list or direct to me within the next two weeks so we can include it to the next release. Deadline will be 2011-09-29. To make it more easy for you I've already uploaded updated versions of the po files to svn with r5929. You can access them as always at http://geany.svn.sourceforge.net/viewvc/geany/trunk/po/ or by checking out the svn tree of Geany by using e.g. svn co https://geany.svn.sourceforge.net/svnroot/geany/trunk geany Fans of git can also use the interface provided by http://git.geany.org by using git clone http://git.geany.org/git/geany Also at http://i18n.geany.org/ are statistics and daily updated files available. As mentioned before, we are trying to have all translations complete by 2011-09-29. If your language was translated by two or more in past, please double check directly with them or by pinging me, so we don't need to translate same things two or three times. Also please feel to ping me for every question or if you like to start a new translation for an unsupported language. Thanks and happy translating ;) Frank P.S. As we are used to on previous releases also the combined geany-plugins project will have a new stable release. Its currently scheduled two weeks after Geany 0.21 with a string freeze around October, 1st. If you like to provide also some translation for, it would be much appreciated. ;) -- http://frank.uvena.de/en/

1 0

Re: [Geany-devel] build commands - Re: SF.net SVN: geany:[5915] trunk/TODO
by Nick Treleaven 17 Sep '11

17 Sep '11

--- On Thu, 15/9/11, Lex Trotman <elextr(a)gmail.com> wrote: > So it was late at night and I never actually said what I > meant, can't > you read my mind? I realized later you might want the TODO changed, see below. > >> > + o (filetype-independent run > command & > >> keybinding) > >> > >> This only needs a GUI, you can already put > filetype > > The point that I meant to make was that the to do is > misleading and > should be re-worded to be a GUI change, IAW the conclusion > we came to > in the conversation you cite below. Now done. Does the non-GUI option override the filetype run command? I mentioned keybinding in the item because it's more flexible as a different command. Even with the overriding, a GUI option would still be nice. I'm now preferring a Build/Run notebook tab split rather than filetype/independent. That way we can avoid a subnotebook for the project dialog. > >> Keybindings need to be for all extra commands, > filetype and > >> filetype > >> independent ones, not just the exe one. Probably > the > >> whole build > >> keybinding group needs to be made dynamically like > plugin > >> groups are > >> so the size can be determined at runtime? > > This is a question about possible implementation that might > be simpler > than previously thought, IIUC plugin keybindings groups get > their > keybindings saved and restored for them, although they are > dynamically > added entries. If nothing is saved then they can be > set to a default > value. The build keybinding group can be re-sized > based on the config > entries at startup, which seems to me to be very similar to > plugins. It might not require many changes to allow this, not sure. I don't think the TODO requires dynamic keybindings though. > As a general question that I have never thought about > before, how is > the to-do list (which is in the VCS and the distribution so > it must be > official right?) maintained and community agreement reached > on what is > in it and the priorities? It is sometimes out of date or missing things. I use it as a reminder and to let others know about important things. I think we should avoid putting everything in it, it would require too much maintenance. I'm in favour of a Wiki version also, so long as it stays focused (not a wishlist) and based on concensus. Regards, Nick

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel September 2011