On Thu, 12 Mar 2009 13:55:47 +1100, Lex wrote:

Hi guys,

I tried to update my working copy of the build-system branch with the latest changes in trunk so I had a reasonably up to date basis for further work.

Used: svn merge https://geany.svn.sourceforge.net/svnroot/geany/trunk

it noted conflicts in build.c/h and project.c as expected but it also deleted files like autogen.sh and Makefile.am as well as directories tagmanager and data among others.

Full command output attached(extracted from my xterm to file with self explanatory name aaa ;-).

Obviously it won't build and is generally !@#$%^&*(ed.

I'm no svn guru, any suggestions for fixes or a better way of doing it?

No idea, sorry. I just tried it and get even more weird problems :(.

Regards, Enrico

Hi,

As you will have seen from the commit I got it to work. Can now get on with it.

Warning, merge seems to only work on a newly checked out working copy of the branch, any changes seem to cause chaos. Make changes after merge before the commit back to the branch. Have raised question with SVN.

Compiles, runs but is not extensively tested (Geany needs a regression suite, and if you find a usable GUI tester let me know I am looking for one ;-)

Regards Lex

2009/3/17 Nick Treleaven nick.treleaven@btinternet.com

On Thu, 12 Mar 2009 13:55:47 +1100 Lex Trotman elextr@gmail.com wrote:

...

I tried to update my working copy of the build-system branch with the

latest

...

changes in trunk so I had a reasonably up to date basis for further work.

Used: svn merge https://geany.svn.sourceforge.net/svnroot/geany/trunk

I think you have to say what range of revisions you want to merge, e.g. -r branched:HEAD

Seems to help, not what the SVN book says, but who ever heard of documentation being up to date :-}

where branched is the revision no. your branch was copied from.

Only recent versions of svn have branch tracking, and I haven't tried it.

Also, it's a good idea to backup any local changes before a merge. svn should handle them, but if the command is wrong horrible things can happen :-/

It appears that you have to not make any!!!!

Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On Mon, 23 Mar 2009 13:35:19 +1100 Lex Trotman elextr@gmail.com wrote:

Compiles, runs but is not extensively tested (Geany needs a regression suite, and if you find a usable GUI tester let me know I am looking for one ;-)

Feel free to build one ;) In fact we already thought about it, but it's still in a very early stage.

Cheers, Frank

On Mon, 23 Mar 2009 09:45:40 +0100 Frank Lanitz frank@frank.uvena.de wrote:

...

Compiles, runs but is not extensively tested (Geany needs a regression suite, and if you find a usable GUI tester let me know I am looking for one ;-)

Feel free to build one ;) In fact we already thought about it, but it's still in a very early stage.

Did we? Personally I don't know anything about GUI regression testing. Or does it just mean unit tests? Anyway not sure how they'd work...

Regards, Nick

On Tue, 24 Mar 2009 13:17:14 +0000, Nick wrote:

On Mon, 23 Mar 2009 09:45:40 +0100 Frank Lanitz frank@frank.uvena.de wrote:

...

...

Compiles, runs but is not extensively tested (Geany needs a regression suite, and if you find a usable GUI tester let me know I am looking for one ;-)

Feel free to build one ;) In fact we already thought about it, but it's still in a very early stage.

Did we? Personally I don't know anything about GUI regression testing. Or does it just mean unit tests? Anyway not sure how they'd work...

No, we did not. Frank thought about it (just unit tests AFAIK), told me it would be cool to have, I agreed but nothing more.

So, what Frank wanted to say should have been: yes, a good idea. :)

That being said, having unit tests definitely would be cool but in any way, it needs someone to write the tests and the framework around.

Regarding automated GUI tests, there are frameworks around to make this possible/easier. One of those is http://ldtp.freedesktop.org/wiki/ and there is at least one other one which name I forgot :). But this probably requires even more work than 'just' unit tests.

Regards, Enrico

Hi Enrico,

I don't think we had a conclusively brilliant suggestion for what to call the dialog so I was just using"set build commands" in the interim, after all its easy to change any time up to string freeze. I am not sure that "Set Build Options" directly implies to me that is where you set the commands, although I would probably end up trying it and find the commands. So maybe "Set Build Commands/Options" if it will fit.

Warning: GUI discussion below!!!!

There is no reason not to add other things in the dialog but:

In general I personally am not sure which I prefer, 1. applications with a single big multi-page settings dialog where at least you know its in there somewhere, or 2. applications which spread settings throughout the application in an attempt to put them near to the menus they apply to, which is sensible so long as users think like the developer ;-)

Geany has generally been leaning towards the former with some notable exceptions (build and projects for example).

Let me make a couple of notes on the current build-system GUI extensions (at the risk of opening up too much discussion ;-):

1. They are based on minimal changes from the current design but that has some negatives as follows

2. The "set build commands" dialog is partly modal, that is, parts of it depend on if a project is open or not. Yes the dialog title changes and some internal labels change to reflect the state but it is not GUI best practice. You have to notice to know where your changes are being saved.

3. This modality can be removed if project based build commands/options are added to the project properties dialog instead, atfer all the run command is there.

4. The non-modal build commands/options should remain as a build menu dialog since in a way they are still partly modal on the language of the current document, ie if a C file is current then the C commands can be edited, if a python file ... So I don't think that fits well into the main preferences which are fully general.

So possibly the better solution would be to put a tab in project properties to set build commands/options for the project which, if set override the general settings in the build menu set build commands/options. The project value could be displayed there but greyed out and uneditable. This means that the commands that are going to be used are visible in the one place which is connected with the build menu, but editing is separate to make it clearer where the commands/options are stored.

Now for the error_regex, is it a base option or one that is project overridable (after all if you change the commands you may change the error messages by using a different compiler). And how does it relate to filetypes commands, the messages from different compilers could change per language? Or is all this too hard and it is only a personal preference?

Obviously the answers above suggest the best place to put it. I can easy handle project overrides personal preferences, thats how all the commands work, but by language may be a bit of a streach for now.

Sorry for the really long answer to a simple question, with lots more questions added, unfortunately the question triggered me to think about the GUI some more.

Let me know what you think.

Cheers Lex

2009/3/26 Enrico Tröger enrico.troeger@uvena.de

On Thu, 12 Mar 2009 13:55:47 +1100, Lex wrote:

Hey Lex,

assuming you are having something like a TODO list for your branch, I got an idea inspired by an user on IRC:

I remember we talked about the "Set Includes and Arguments" dialog in the past and how to rename it. Though I don't remember whether and how we decided :).

So, here is a suggestion: "Set Build Options".

This is a bit more general and allows us to add a field for the "error_regex" setting so users can on the fly change this setting without editing config files.

Just an idea.

Regards, Enrico

-- Get my GPG key from http://www.uvena.de/pub.asc

---

Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On Fri, 27 Mar 2009 17:04:20 +1100, Lex wrote:

Warning: GUI discussion below!!!!

Ahh, time to run away...

:)

There is no reason not to add other things in the dialog but:

In general I personally am not sure which I prefer,

1. applications with a single big multi-page settings dialog where at

least you know its in there somewhere, or 2. applications which spread settings throughout the application in an attempt to put them near to the menus they apply to, which is sensible so long as users think like the developer ;-)

Geany has generally been leaning towards the former with some notable exceptions (build and projects for example).

I personally prefer 1), i.e. a single preferences dialog where all global settings can be found. As you pointed out, the build menu dialog is an exception and you also correctly pointed out the rationale in point 4, below.

Let me make a couple of notes on the current build-system GUI extensions (at the risk of opening up too much discussion ;-):

1. They are based on minimal changes from the current design but that

has some negatives as follows

2. The "set build commands" dialog is partly modal, that is, parts of

it depend on if a project is open or not. Yes the dialog title changes and some internal labels change to reflect the state but it is not GUI best practice. You have to notice to know where your changes are being saved.

3. This modality can be removed if project based build

commands/options are added to the project properties dialog instead, atfer all the run command is there.

I don't mind much about it. On the one hand, all build/run commands belong to build settings, on the other hand project-related build/run commands belong to the project. It's more or less even :). But you said above 'you have to know where your changes are being saved', this is a good point and IMO argues for having project-related commands in the project properties dialog.

But I'd leave this decision up to you and/or Nick.

4. The non-modal build commands/options should remain as a build menu

dialog since in a way they are still partly modal on the language of the current document, ie if a C file is current then the C commands can be edited, if a python file ... So I don't think that fits well into the main preferences which are fully general.

Full ACK, nothing to add.

Now for the error_regex, is it a base option or one that is project overridable (after all if you change the commands you may change the error messages by using a different compiler). And how does it relate

For now, it is a per filetype setting, stored together with the build/run commands. But of course, when build commands get also project-related, error_regex maybe need also to be project-related though it would complicate things a bit. And then, probably most users don't need to use the error_regex setting at all because the builtin defaults may suffice. So, maybe it's not worth it at all and just don't add any GUI for it.

Sorry for the really long answer to a simple question, with lots more questions added, unfortunately the question triggered me to think

Haha, I was afraid that happens :).

Regards, Enrico