Hi All,
I have created a branch for further development of the build system called bs2.
I have added the current state of the design spec to the doc directory and a temporary Python prototype implementation of the configure dialog in scripts (since I know how much you all hate reading GUI descriptions). It is intended to delete this before merge but it will be useful to get ideas on making it usable, for example which fields should be visible normally and which only in advanced mode.
@Nick as the padding guru you might have some suggestions, in my opinion applying padding to rows containing buttons or combo boxes makes a disproportionate increase in size, so for now I've taken it off, see what you think.
Running the script (python build_dialog_prototype.py) produces a window with two buttons, one produces the dialog as it will be when no project is open and one as it will be when a project is open. Clearly the dialog has no code or data behind it, but the "advanced" and "show all" buttons work. Apply, cancel and ok all close the dialog.
Please be warned, if you havn't read the spec (which is the only documentation until the manual is updated) that this looks complex when you first see it in advanced mode. But the dialog does no more than bring together settings that already exist in various hidden places in Geany.
Cheers Lex
Am Samstag, den 06.02.2010, 21:21 +1100 schrieb Lex Trotman:
Hi All,
I have created a branch for further development of the build system called bs2.
I have added the current state of the design spec to the doc directory and a temporary Python prototype implementation of the configure dialog in scripts (since I know how much you all hate reading GUI descriptions). It is intended to delete this before merge but it will be useful to get ideas on making it usable, for example which fields should be visible normally and which only in advanced mode.
@Nick as the padding guru you might have some suggestions, in my opinion applying padding to rows containing buttons or combo boxes makes a disproportionate increase in size, so for now I've taken it off, see what you think.
Running the script (python build_dialog_prototype.py) produces a window with two buttons, one produces the dialog as it will be when no project is open and one as it will be when a project is open. Clearly the dialog has no code or data behind it, but the "advanced" and "show all" buttons work. Apply, cancel and ok all close the dialog.
Please be warned, if you havn't read the spec (which is the only documentation until the manual is updated) that this looks complex when you first see it in advanced mode. But the dialog does no more than bring together settings that already exist in various hidden places in Geany.
Cheers Lex
Wouldn't it have had to be easier to design that with glade instead of writing python scripts? - Or alternative, a pen and paper? ;)
When seeing this from a user point of view there is very much information to enter. A bit "overload" on the screen - in special the advanced mode. Yes, you warned me. ;)
As you said, this is a prototype which maybe needs more work. - Also from the user point of view and in GUI design. Just a suggestion: You could work with the GUI element from GTK which allows to extend the dialog via clicking on the arrow (as in the Find or Replace dialog in Geany) :)
Regards, Dominic
On Sat, 06 Feb 2010 13:47:33 +0100, Dominic wrote:
Am Samstag, den 06.02.2010, 21:21 +1100 schrieb Lex Trotman:
Hi All,
I have created a branch for further development of the build system called bs2.
I have added the current state of the design spec to the doc directory and a temporary Python prototype implementation of the configure dialog in scripts (since I know how much you all hate reading GUI descriptions). It is intended to delete this before merge but it will be useful to get ideas on making it usable, for example which fields should be visible normally and which only in advanced mode.
@Nick as the padding guru you might have some suggestions, in my opinion applying padding to rows containing buttons or combo boxes makes a disproportionate increase in size, so for now I've taken it off, see what you think.
Running the script (python build_dialog_prototype.py) produces a window with two buttons, one produces the dialog as it will be when no project is open and one as it will be when a project is open. Clearly the dialog has no code or data behind it, but the "advanced" and "show all" buttons work. Apply, cancel and ok all close the dialog.
Please be warned, if you havn't read the spec (which is the only documentation until the manual is updated) that this looks complex when you first see it in advanced mode. But the dialog does no more than bring together settings that already exist in various hidden places in Geany.
Cheers Lex
Wouldn't it have had to be easier to design that with glade instead of writing python scripts? - Or alternative, a pen and paper? ;)
When seeing this from a user point of view there is very much information to enter. A bit "overload" on the screen - in special the advanced mode. Yes, you warned me. ;)
IMO way too much information. I already said that about the current build settings in the SVN version and this one is even worse, IMHO. Yes, for users who want the ultimate control of every single build option that could be useful but, as also said multiple times before, the idea of Geany's build system was to be easy to use and to just get the job done. From my experience, this was much appreciated by users (getting lots of mail stating this). Well, this feature we will loose with the current rework in the SVN version and with the mockup in the new branch, it won't get better, IMHO.
Sorry when this sounds a bit hard and I do understand your motivation to make it all more flexible. But it's maybe just not want some/most/all users want.
Please be warned, if you havn't read the spec (which is the only documentation until the manual is updated) that this looks complex when you first see it in advanced mode. But the dialog does no more than bring together settings that already exist in various hidden places in Geany.
I skimmed over the docs but it didn't make it better. The dialog is still heavily crowded and quite complex.
As you said, this is a prototype which maybe needs more work. - Also from the user point of view and in GUI design. Just a suggestion: You could work with the GUI element from GTK which allows to extend the dialog via clicking on the arrow (as in the Find or Replace dialog in
Just for the record, iIt's called GtkExpander.
Regards, Enrico
Hi Enrico,
IMO way too much information.
Then I guess Geany does too much :-) because other than working directory the build-system adds no extra functionality. As you say below its all about configuration.
At the moment a lot of the configuration invisibly set by where in the menu an item appears, both limiting and confusing. Maybe I'm slow, but all the time I have been working on the build system I didn't really realise this point, and that its the cause of many code complications and the configuration problems I had..
If it took that long for me to realise that this hidden, hard coded paradigm exists I am sure that it is going to be a problem for others as well so I want to remove it.
I already said that about the current build settings in the SVN version and this one is even worse, IMHO. Yes, for users who want the ultimate control of every single build option that could be useful but, as also said multiple times before, the idea of Geany's build system was to be easy to use and to just get the job done. From my experience, this was much appreciated by users (getting lots of mail stating this). Well, this feature we will loose with the current rework in the SVN version and with the mockup in the new branch, it won't get better, IMHO.
I understand your point, thats why I made a prototype thats easy to fiddle with so that we can try things out. The intention is to make it better.
I fundamentally disagree with the notion that functionality should not be available to the user if its in the software, but i agree that simple things should, no MUST be simple.
The approach is to allow progressive expansion of detail as users get more confident and need more complex control. Clearly the rate of expansion is a bit too fast in the current version :-). But I thought I would start with the simplest expansion paradigm and we can go from there.
As an alternative to expansion we could have sub-dialogs for detail. Personally I like spreadsheets where I can see it all spread of in front of me but I understand the apparent complexity problem.
Sorry when this sounds a bit hard and I do understand your motivation to make it all more flexible. But it's maybe just not want some/most/all users want.
Please be warned, if you havn't read the spec (which is the only documentation until the manual is updated) that this looks complex when you first see it in advanced mode. But the dialog does no more than bring together settings that already exist in various hidden places in Geany.
I skimmed over the docs but it didn't make it better. The dialog is still heavily crowded and quite complex.
What about when its not in advanced mode and no project, There is a picture of the menu to select which menu item settings you want to adjust, and for each item only 3 entries (for label, command and working directory) for each of the filetype and the user prefs.
With a project open you have the two extra sets of 3 to save in the project.
As you said, this is a prototype which maybe needs more work. - Also from the user point of view and in GUI design. Just a suggestion: You could work with the GUI element from GTK which allows to extend the dialog via clicking on the arrow (as in the Find or Replace dialog in
Just for the record, iIt's called GtkExpander.
I'll see if that can be used to allow more progressive expansion an operation at a time. Other suggestions welcome.
Cheers Lex
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
Hi All,
Committed to bs2 branch is a version of the prototype which uses sub-dialogs for changing details.
It took me so long to figure out how to have non-modal children of a modal dialog, I.ve learned new GTK :-)
Due to the above the sub-dialog isn't very pretty, but I'm sure you all can see past that to consider if the paradigm works better.
Cheers Lex
On Sat, 6 Feb 2010 16:40:57 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
IMO way too much information. I already said that about the current build settings in the SVN version and this one is even worse, IMHO. Yes, for users who want the ultimate control of every single build option that could be useful but, as also said multiple times before, the idea of Geany's build system was to be easy to use and to just get the job done. From my experience, this was much appreciated by users (getting lots of mail stating this). Well, this feature we will loose with the current rework in the SVN version and with the mockup in the new branch, it won't get better, IMHO.
Sorry when this sounds a bit hard and I do understand your motivation to make it all more flexible. But it's maybe just not want some/most/all users want.
I agree, I don't like this design, sorry Lex ;-)
I think making all functionality available is overkill. We've got to come up with a design that makes sense for each set of commands.
For example, you can only have one build command stopable, unless you make new build tabs in the message window. I think this is too complex.
Any increase in functionality needs to have a rationale. Do we need each command to be handled individually, or should sets of commands have the same behaviour? I prefer the latter.
Regards, Nick
On 11 February 2010 00:01, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 6 Feb 2010 16:40:57 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
IMO way too much information. I already said that about the current build settings in the SVN version and this one is even worse, IMHO. Yes, for users who want the ultimate control of every single build option that could be useful but, as also said multiple times before, the idea of Geany's build system was to be easy to use and to just get the job done. From my experience, this was much appreciated by users (getting lots of mail stating this). Well, this feature we will loose with the current rework in the SVN version and with the mockup in the new branch, it won't get better, IMHO.
Sorry when this sounds a bit hard and I do understand your motivation to make it all more flexible. But it's maybe just not want some/most/all users want.
I agree, I don't like this design, sorry Lex ;-)
Hey, thats what I made a python prototype for, so no sorry needed.
I think making all functionality available is overkill. We've got to come up with a design that makes sense for each set of commands.
Yes, but hard coding such restrictions increases the complications of the code (those special cases) and then forces users who need something else to change code not just configure. Including having to change existing special cases (or to ask you to change it). There should be much less work to create and maintain a good general solution.
For example, you can only have one build command stopable, unless you make new build tabs in the message window. I think this is too complex.
Agree that there should be only one output to the message window, and I have already written that in the spec. (I like the tabbed idea, maybe Geany version 3.0 :-) But the dialog wouldn't show that, its a function of the menu operation. When a parsed command is run, all the other parsed menu items become insensitive.
For stopability, (if thats a word) the decision which command is stopable has to be made at the time a menu item is selected, the one thats selected becomes stopable, the other parsed menu items become insensitive.
But there are some build commands that should NOT be stopable, ever, because of the risk of corruption ( see past discussions with Thomas and Enrico), so stopability needs to be able to be turned off for them, and since in general we don't know what commands are running, it has to be off by default.
Any increase in functionality needs to have a rationale. Do we need each command to be handled individually, or should sets of commands have the same behaviour? I prefer the latter.
Yes thats a reasonable way to do it, but what are the groups and what are their characteristics. I couldn't come up with a sensible set of fixed groupings that don't unreasonably limit the behaviour.
The current SVN version basically works like that and I can't twist it to support the build commands that I want to use, let alone what other people may need. For example Frank & Thomas both have asked for executes without terminal or parsing. The current SVN can't support that without one more setting being added and then the next variant has to be added etc. and soon it gets to where I am at now.
So I gave up and made everything settable :-) no special cases or inconsistent operation :-) but as you and Enrico say, making the configuration GUI approachable is a problem :-(
It would be possible to have a separate dialog to define new groups and their characteristics so all that needs to be set in the main configuration dialog is the group name from a combo box.
The advanced dialog would only have 6 characteristics to set, or actually only 4 when you consider some are just an enable for the following value.
Default groups and their characteristics:
- Internal - internal and which internal item - Parsed - parsed, not stopable, regex - Execute - to terminal, stopable, stop label "Stop" - Execute no terminal - no terminal, stopable, stop label "Stop"
Lets see what that can do for us.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
I'm still thinking that - if Geany wants to call itself an IDE - we should allow the maximum of build configurations because there is about an infinite amount of that out there. I can agree with grouping it, but *limiting* it intentionally for no obvious reasons (the advanced parts can be hidden until "advanced settings" is checked") defeats the goal of being an IDE.
Before the v1 build system was committed into trunk, I didn't even dare to call it an IDE, because build settings belong to it. This, and an integrated debugger, is what an IDE seperates from a simple text editor (hence my remark in the very first sentence).
The current dialog is a bit bloated indeed. I could imagine to solve it by hiding advanced settings (like the working directory), by providing an assitant which leads through the configuration or by a multi-tabbed interfaced to group similar build-system settings.
I must admit that I worked a bit with visual studio in the meantime. I'm not saying this bloody bloat thing (it's really huge, but it runs fast and has a lot of features[I probably used only 2% of it]) is the way to go, but (as I mentioned) its integrated debugger and build settings is what I expect from an IDE.
The "integrated debugger" is a plugin. Fine. But the limited build settings it had before committing the branch basically made it a text editor, not an IDE. I now more or less depend on the new capabilities of the build settings, so if you remove features I'm going to be dependant on the bloody terminal (VTE) feature again which simply sucks for just building a project.
Best regards.
On Thu, 11 Feb 2010 05:53:59 +0100 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
But the limited build settings it had before committing the branch basically made it a text editor, not an IDE. I now more or less depend on the new capabilities of the build settings, so if you remove features I'm going to be dependant on the bloody terminal (VTE) feature again which simply sucks for just building a project.
I don't think anyone mentioned removing features from trunk ;-) We're discussing Lex's new prototype.
Regards, Nick
On Thu, 11 Feb 2010 05:53:59 +0100, Thomas wrote:
OT:
I'm still thinking that - if Geany wants to call itself an IDE - we
I think we all agree Geany isn't a real IDE and I think that's fine. Geany might be just an advanced text editor or whatever. And then, these are just terms, what counts are the features, speed and usability. Then, I don't mind whether one might call it IDE, text editor or just 'crap' :).
Regards, Enrico
On Thu, 11 Feb 2010 09:04:07 +1100 Lex Trotman elextr@gmail.com wrote:
On 11 February 2010 00:01, Nick Treleaven nick.treleaven@btinternet.com wrote:
I think making all functionality available is overkill. We've got to come up with a design that makes sense for each set of commands.
Yes, but hard coding such restrictions increases the complications of the code (those special cases) and then forces users who need something else to change code not just configure. Including having to change existing special cases (or to ask you to change it). There should be much less work to create and maintain a good general solution.
The goal is to provide understandable options, not to simplify implementation. I doubt that the implementation is/will be too complex though.
The problem with mass configurability is that it can still harm the casual user when they accidentally change something then have to go and study the manual.
I'm actually arguing for limiting complexity, options should be specific (see below).
For example, you can only have one build command stopable, unless you make new build tabs in the message window. I think this is too complex.
Agree that there should be only one output to the message window, and I have already written that in the spec. (I like the tabbed idea, maybe Geany version 3.0 :-) But the dialog wouldn't show that, its a function of the menu operation. When a parsed command is run, all the other parsed menu items become insensitive.
For stopability, (if thats a word) the decision which command is stopable has to be made at the time a menu item is selected, the one thats selected becomes stopable, the other parsed menu items become insensitive.
But there are some build commands that should NOT be stopable, ever, because of the risk of corruption ( see past discussions with Thomas and Enrico), so stopability needs to be able to be turned off for them, and since in general we don't know what commands are running, it has to be off by default.
I think the 'make everything as configurable as possible' idea is one that leads to very complex dialogs, and also IMO is against the design of Geany. There may be other ways.
We could solve the stop issue by having 2 stop commands, one for any build command and one for the execute command (as current).
Each stop command would prompt 'Killing the process may be unsafe. Are you sure?'.
Any increase in functionality needs to have a rationale. Do we need each command to be handled individually, or should sets of commands have the same behaviour? I prefer the latter.
Yes thats a reasonable way to do it, but what are the groups and what are their characteristics. I couldn't come up with a sensible set of fixed groupings that don't unreasonably limit the behaviour.
The current SVN version basically works like that and I can't twist it to support the build commands that I want to use, let alone what other people may need. For example Frank & Thomas both have asked for executes without terminal or parsing. The current SVN can't support that without one more setting being added and then the next variant has to be added etc. and soon it gets to where I am at now.
Maybe add an execute option for this, I don't think any build commands should need this.
I think it's good to keep build and execute commands separate. They are intended for different things.
So I gave up and made everything settable :-) no special cases or inconsistent operation :-) but as you and Enrico say, making the configuration GUI approachable is a problem :-(
It would be possible to have a separate dialog to define new groups and their characteristics so all that needs to be set in the main configuration dialog is the group name from a combo box.
The advanced dialog would only have 6 characteristics to set, or actually only 4 when you consider some are just an enable for the following value.
Default groups and their characteristics:
- Internal - internal and which internal item
- Parsed - parsed, not stopable, regex
- Execute - to terminal, stopable, stop label "Stop"
- Execute no terminal - no terminal, stopable, stop label "Stop"
Lets see what that can do for us.
This isn't what I meant, though I wasn't clear. I think we should have simple filetype build commands, 'make' commands, execute command(s), and then [a bit] more configurable options for project commands.
This is perhaps a bit vague but I'm trying to say the extra configurability should be linked to what it's needed for, not an option for every single command.
Regards, Nick
On 12 February 2010 05:32, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 11 Feb 2010 09:04:07 +1100 Lex Trotman elextr@gmail.com wrote:
On 11 February 2010 00:01, Nick Treleaven nick.treleaven@btinternet.com
wrote:
I think making all functionality available is overkill. We've got to come up with a design that makes sense for each set of commands.
Yes, but hard coding such restrictions increases the complications of the code (those special cases) and then forces users who need something else to change code not just configure. Including having to change existing special cases (or to ask you to change it). There should be much less work to create and maintain a good general solution.
The goal is to provide understandable options, not to simplify implementation. I doubt that the implementation is/will be too complex though.
The problem with mass configurability is that it can still harm the casual user when they accidentally change something then have to go and study the manual.
I'm actually arguing for limiting complexity, options should be specific (see below).
What I'm arguing is that it isn't possible to sensibly decide what limitations to apply without sounding like a dictator, "do it my way or not at all". Let me try to ask some leading questions referring to various restrictions in the current system.
Why do all non-filetype dependent commands have to have their output parsed? and so block all other commands? So now I can't use a pair of tools together. What about tools that display output in a GUI, eg viewers, I have to close them and lose the output to be able to run another command.
Same argument for filetype dependent commands of course, but compounded by having different tools for different languages, but still if one is running no others can. Even if their is no parsed output to be confused.
Since any command can be run by the build menu, it can be a long-running command, so why not allow a competent user to decide that it is safe to stop it if its going wrong?
For example, you can only have one build command stopable, unless you make new build tabs in the message window. I think this is too complex.
Agree that there should be only one output to the message window, and I have already written that in the spec. (I like the tabbed idea, maybe Geany version 3.0 :-) But the dialog wouldn't show that, its a function of the menu operation. When a parsed command is run, all the other parsed menu items become insensitive.
For stopability, (if thats a word) the decision which command is stopable has to be made at the time a menu item is selected, the one thats selected becomes stopable, the other parsed menu items become insensitive.
But there are some build commands that should NOT be stopable, ever, because of the risk of corruption ( see past discussions with Thomas and Enrico), so stopability needs to be able to be turned off for them, and since in general we don't know what commands are running, it has to be off by default.
I think the 'make everything as configurable as possible' idea is one that leads to very complex dialogs, and also IMO is against the design of Geany. There may be other ways.
Well, I think that making everything configurable stops you having to wire logic in the code making it simpler.
We could solve the stop issue by having 2 stop commands, one for any build command and one for the execute command (as current).
Another band-aid (R J&J :-) solution adding more special cases.
Each stop command would prompt 'Killing the process may be unsafe. Are you sure?'.
Thats a good idea, but better to configure it off so only a user that at least understands the question will enable it, rather than asking a question of a user who has no idea of the answer.
Any increase in functionality needs to have a rationale. Do we need each command to be handled individually, or should sets of commands have the same behaviour? I prefer the latter.
Yes thats a reasonable way to do it, but what are the groups and what are their characteristics. I couldn't come up with a sensible set of fixed groupings that don't unreasonably limit the behaviour.
The current SVN version basically works like that and I can't twist it to support the build commands that I want to use, let alone what other people may need. For example Frank & Thomas both have asked for executes without terminal or parsing. The current SVN can't support that without one more setting being added and then the next variant has to be added etc. and soon it gets to where I am at now.
Maybe add an execute option for this, I don't think any build commands should need this.
Why not? See comments above, you are still thinking in terms of a "make" type builder whereas it could be anything. Since the "make" commands can be programmed from a project file it makes perfect sense that it may be a web CMS or anything else associated with the project.
I think it's good to keep build and execute commands separate. They are intended for different things.
They are only different in the C/C++ workflow, in interpreted languages build=execute, in web languages view=execute, if either can execute any command how can you separate them?
So I gave up and made everything settable :-) no special cases or inconsistent operation :-) but as you and Enrico say, making the configuration GUI approachable is a problem :-(
It would be possible to have a separate dialog to define new groups and their characteristics so all that needs to be set in the main configuration dialog is the group name from a combo box.
The advanced dialog would only have 6 characteristics to set, or actually only 4 when you consider some are just an enable for the following value.
Default groups and their characteristics:
- Internal - internal and which internal item
- Parsed - parsed, not stopable, regex
- Execute - to terminal, stopable, stop label "Stop"
- Execute no terminal - no terminal, stopable, stop label "Stop"
Lets see what that can do for us.
This isn't what I meant, though I wasn't clear. I think we should have simple filetype build commands, 'make' commands, execute command(s), and then [a bit] more configurable options for project commands.
As I said above, this is one particular workflow, no problem if the default configuration follows that, but I don't see its good to LIMIT it to that.
Cheers Lex
This is perhaps a bit vague but I'm trying to say the extra configurability should be linked to what it's needed for, not an option for every single command.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 12 Feb 2010 22:59:59 +1100 Lex Trotman elextr@gmail.com wrote:
What I'm arguing is that it isn't possible to sensibly decide what limitations to apply without sounding like a dictator, "do it my way or not at all". Let me try to ask some leading questions referring to various restrictions in the current system.
Why do all non-filetype dependent commands have to have their output parsed? and so block all other commands? So now I can't use a pair of tools
together. What about tools that display output in a GUI, eg viewers, I have to close them and lose the output to be able to run another command.
Same argument for filetype dependent commands of course, but compounded by having different tools for different languages, but still if one is running no others can. Even if their is no parsed output to be confused.
Since any command can be run by the build menu, it can be a long-running command, so why not allow a competent user to decide that it is safe to stop it if its going wrong?
IMO the solution to all of this is to use Execute commands, not build commands. Build commands are things that you want geany to monitor during a build.
I think the 'make everything as configurable as possible' idea is one that leads to very complex dialogs, and also IMO is against the design of Geany. There may be other ways.
Well, I think that making everything configurable stops you having to wire logic in the code making it simpler.
We could solve the stop issue by having 2 stop commands, one for any build command and one for the execute command (as current).
Another band-aid (R J&J :-) solution adding more special cases.
No, you're saying add a setting for every possible command, I'm saying, just add a dialog. You're suggesting more work ;-)
Each stop command would prompt 'Killing the process may be unsafe. Are you sure?'.
Thats a good idea, but better to configure it off so only a user that at least understands the question will enable it, rather than asking a question of a user who has no idea of the answer.
If the user doesn't understand it, they shouldn't be killing things ;-)
But my point was really that having lots of settings for each command is one approach to doing this, one I (and I think Enrico) don't like. There are other ways to add configurability/flexibility which can be simpler to understand.
Any increase in functionality needs to have a rationale. Do we need each command to be handled individually, or should sets of commands have the same behaviour? I prefer the latter.
...
The current SVN version basically works like that and I can't twist it to support the build commands that I want to use, let alone what other people may need. For example Frank & Thomas both have asked for executes without terminal or parsing. The current SVN can't support that without one more setting being added and then the next variant has to be added etc. and soon it gets to where I am at now.
Maybe add an execute option for this, I don't think any build commands should need this.
Why not? See comments above, you are still thinking in terms of a "make" type builder whereas it could be anything. Since the "make" commands can be programmed from a project file it makes perfect sense that it may be a web CMS or anything else associated with the project.
I think it's good to keep build and execute commands separate. They are intended for different things.
They are only different in the C/C++ workflow, in interpreted languages build=execute, in web languages view=execute, if either can execute any command how can you separate them?
If you don't want parsing, use execute commands. This can make understanding the build system easier for the user.
This isn't what I meant, though I wasn't clear. I think we should have simple filetype build commands, 'make' commands, execute command(s), and then [a bit] more configurable options for project commands.
As I said above, this is one particular workflow, no problem if the default configuration follows that, but I don't see its good to LIMIT it to that.
I might have forgotten to say: I don't think we should deny users any features, just that the more advanced things can be done in a way that doesn't complicate everything else.
Regards, Nick
On Mon, 15 Feb 2010 13:02:05 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Since any command can be run by the build menu, it can be a long-running command, so why not allow a competent user to decide that it is safe to stop it if its going wrong?
Sorry, my comment about execute commands was not in reply to the above, only about commands that you don't want to be parsed in the Compiler tab.
For the stop issue, I don't think a dialog is that bad. How often do you need to stop things? You could still have a pref, on by default, for whether to ask/warn the user first or not.
I would prefer for each new 'feature' like stopability or concurrent commands or whatever to be discussed separately, otherwise it's difficult to find the best solution. You're saying look at all these things people might want from the build system, hence a big and complicated configuration dialog is necessary. I'd prefer to look at it from where we are, what is needed incrementally.
Regards, Nick
On 16 February 2010 03:09, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Mon, 15 Feb 2010 13:02:05 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Since any command can be run by the build menu, it can be a
long-running
command, so why not allow a competent user to decide that it is safe to
stop
it if its going wrong?
Sorry, my comment about execute commands was not in reply to the above, only about commands that you don't want to be parsed in the Compiler tab.
Understand.
For the stop issue, I don't think a dialog is that bad. How often do you need to stop things?
Usually not for weeks then several times in a row ;-)
You could still have a pref, on by default, for whether to ask/warn the user first or not.
What ANOTHER setting? :-D HeHe, sorry I couldn't resist....
I would prefer for each new 'feature' like stopability or concurrent commands or whatever to be discussed separately, otherwise it's difficult to find the best solution. You're saying look at all these things people might want from the build system, hence a big and complicated configuration dialog is necessary. I'd prefer to look at it from where we are, what is needed incrementally.
I don't really agree, I'm aware that the dialog is a problem, I may not have been clear but I'm talking only about the internal implementation here.
All of the functionality I am proposing exists in the SVN version, sensitivity of parsed commands, stopability (without dialog) etc, but which menu items each piece of functionality applies to is hard coded. I am a lazy programmer, I want to have only one type of menu item and let configuration control its functionality. That is simpler than having the same functionality controlled by lots of hard coded nested ifs as it is in the SVN version.
Then, as I said in reply to Enrico, the configuration and the default configure dialog can hide as much or as little of the functionality as you want. That will take some talking about... ;-)
And the complex full configuration dialog could be a plugin.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 6 February 2010 23:47, Dominic Hopf dmaphy@googlemail.com wrote:
Am Samstag, den 06.02.2010, 21:21 +1100 schrieb Lex Trotman:
Hi All,
I have created a branch for further development of the build system called bs2.
I have added the current state of the design spec to the doc directory and a temporary Python prototype implementation of the configure dialog in scripts (since I know how much you all hate reading GUI descriptions). It is intended to delete this before merge but it will be useful to get ideas on making it usable, for example which fields should be visible normally and which only in advanced mode.
@Nick as the padding guru you might have some suggestions, in my opinion applying padding to rows containing buttons or combo boxes makes a disproportionate increase in size, so for now I've taken it off, see what you think.
Running the script (python build_dialog_prototype.py) produces a window with two buttons, one produces the dialog as it will be when no project is open and one as it will be when a project is open. Clearly the dialog has no code or data behind it, but the "advanced" and "show all" buttons work. Apply, cancel and ok all close the dialog.
Please be warned, if you havn't read the spec (which is the only documentation until the manual is updated) that this looks complex when you first see it in advanced mode. But the dialog does no more than bring together settings that already exist in various hidden places in Geany.
Cheers Lex
Wouldn't it have had to be easier to design that with glade instead of writing python scripts? - Or alternative, a pen and paper? ;)
Pen & paper is hard to share via e-mail :) & I have problems with Glade. The good thing about the Python approach is that I can just translate the GTK calls into C when it is ok.
When seeing this from a user point of view there is very much information to enter. A bit "overload" on the screen - in special the advanced mode. Yes, you warned me. ;)
As you said, this is a prototype which maybe needs more work. - Also from the user point of view and in GUI design. Just a suggestion: You could work with the GUI element from GTK which allows to extend the dialog via clicking on the arrow (as in the Find or Replace dialog in Geany) :)
Thats a good suggestion, it would reduce the "hit you in the face" factor as only one part needs unrolling at a time, I'll try it.
Regards, Dominic
-- Dominic Hopf dmaphy@googlemail.com
Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 6 Feb 2010 21:21:03 +1100, Lex wrote:
Heya guys,
since we have quite different ideas of the future of the whole build systems features and in particular about its configuration using GUI dialogs, I got a weird idea:
Why not moving the build system code into a plugin?
This isn't completely new, I think to remember we discussed this before Lex' first rewrite of the build system and decided to not do this to keep it in the core and so always available.
Though having the build system as a plugin has some advantages, IMO.
First, Lex could realise it as he wants, as complex and flexible as necessary giving users all the powers they want to and don't limit them with any hardcoded defaults (I completely understand this wish).
And alternatively, we could implement a very basic, limited and easy to use(KISS) build system alternatively, similar to the old one(as in 0.18 and before) alternatively to the advanced one.
Then users can choose which build system plugin they want to use and so have even more flexibility.
This would probably make things a bit harder and would require some additions to the plugin API, especially to get project support properly involved but I think it might be worth in the long term.
Any ideas?
Regards, Enrico
Am Samstag, den 13.02.2010, 16:58 +0100 schrieb Enrico Tröger:
On Sat, 6 Feb 2010 21:21:03 +1100, Lex wrote:
Heya guys,
since we have quite different ideas of the future of the whole build systems features and in particular about its configuration using GUI dialogs, I got a weird idea:
Why not moving the build system code into a plugin?
This isn't completely new, I think to remember we discussed this before Lex' first rewrite of the build system and decided to not do this to keep it in the core and so always available.
Though having the build system as a plugin has some advantages, IMO.
First, Lex could realise it as he wants, as complex and flexible as necessary giving users all the powers they want to and don't limit them with any hardcoded defaults (I completely understand this wish).
And alternatively, we could implement a very basic, limited and easy to use(KISS) build system alternatively, similar to the old one(as in 0.18 and before) alternatively to the advanced one.
Then users can choose which build system plugin they want to use and so have even more flexibility.
This would probably make things a bit harder and would require some additions to the plugin API, especially to get project support properly involved but I think it might be worth in the long term.
Basic functionality for building, compiling and running programs (yes, as in 0.18 and before) should definitely keep included in Geanys core. Functionality which extends (or even might replaces) this - as Lex's effort does - could be implemented as a plugin, yes.
I personally prefer any KISS solution over a solution which just provides (maybe too much) features. The hit-you-in-the-face-factor, you know? ;)
From the user point of view the dialog for setting includes and arguments in current SVN trunk is okay so far concerning the hyitf-factor. It maybe could be optimized in other apsects, in special I am missing tooltips which explain the fields as in any other place in Geany. The usage of the GtkExpander in the right place could even reduce the hyitf-factor a bit. ;)
Regards, Dominic
Hi,
On Sat, 13 Feb 2010 16:58:34 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 6 Feb 2010 21:21:03 +1100, Lex wrote:
since we have quite different ideas of the future of the whole build systems features and in particular about its configuration using GUI dialogs, I got a weird idea:
Why not moving the build system code into a plugin?
I think we should just move some parts of it. But more below.
This isn't completely new, I think to remember we discussed this before Lex' first rewrite of the build system and decided to not do this to keep it in the core and so always available.
Though having the build system as a plugin has some advantages, IMO.
First, Lex could realise it as he wants, as complex and flexible as necessary giving users all the powers they want to and don't limit them with any hardcoded defaults (I completely understand this wish).
And alternatively, we could implement a very basic, limited and easy to use(KISS) build system alternatively, similar to the old one(as in 0.18 and before) alternatively to the advanced one.
Then users can choose which build system plugin they want to use and so have even more flexibility.
I think a good way could be to have the current status (or maybe the version from 0.18) build in, but make plugin API be able to replace/extend it with an additional plugin specified by the user. I disagree to have two plugins as the confusion for the user will be much bigger. I understand plugins always as optional additions and a build system is an elementary part of an IDE.
This would probably make things a bit harder and would require some additions to the plugin API, especially to get project support properly involved but I think it might be worth in the long term.
I agree. This is nothing we can do within an evening-coding-session But as a midterm it would make sense. When keeping a usable default inside core and put some additions to a plugin. Well, yepp. Would like that thing.
Cheers, Frank
Hi Enrico,
2010/2/14 Enrico Tröger enrico.troeger@uvena.de
On Sat, 6 Feb 2010 21:21:03 +1100, Lex wrote:
Heya guys,
since we have quite different ideas of the future of the whole build systems features and in particular about its configuration using GUI dialogs, I got a weird idea:
Why not moving the build system code into a plugin?
This isn't completely new, I think to remember we discussed this before Lex' first rewrite of the build system and decided to not do this to keep it in the core and so always available.
As I said I don't care, so long as it can do what is needed.
Though having the build system as a plugin has some advantages, IMO.
First, Lex could realise it as he wants, as complex and flexible as necessary giving users all the powers they want to and don't limit them with any hardcoded defaults (I completely understand this wish).
Yes, provided that the plugin has sufficient control over the core to do what it wants, see 4.
And alternatively, we could implement a very basic, limited and easy to use(KISS) build system alternatively, similar to the old one(as in 0.18 and before) alternatively to the advanced one.
Unless the basic plugin installs and loads fully automatically it might be a problem for new/beginner users. However its implemented it must be automatically available as soon as Geany is installed.
Then users can choose which build system plugin they want to use and so have even more flexibility.
This would probably make things a bit harder and would require some additions to the plugin API, especially to get project support properly involved but I think it might be worth in the long term.
I have had a think about it and I'd say it will be a lot of additions to the plugin API. Not that thats necessarily bad, just effort someone has to do... in addition to the implementation of the build system capabilities in the plugin.
Any ideas?
As I see it there area couple of ways of implementing your suggestion:
1. a basic build system in the core and the advanced one in the plugin, or 2. the two plugins approach
1. has the advantage that the basic system is always available even if Geany is started without plugins, but then the build-in system needs to be able to be completely disabled when the plugin takes over 2. makes the takeover problem simpler,
But both require that everything that the build system needs to do is available through the plugin API, and thats likely to be a big API, much of which no one else will want to use. This includes interface to the preferences and filetype files for saving and restoring settings.
Now as I understand it, what we are trying to achieve is:
1. By default Geany provides a set of capabilities roughly equivalent to 0.18 2. By default Geany provides an easy configuration capability that hides complex capability 3. An alternative that allows "configure everything" control
Now it seems to me that it doesn't matter how complex the internal operation of the build system is, so long as a default user sees functionality as at 1. and 2. does not expose that complexity.
So I propose that a build-system with full capability but only a simple configuration dialog be in core, and the full configure dialog be in a plugin.
This makes the plugin interface much narrower, mostly the capability to set the configuration. That interface would be the interface to the "operation" object I defined in the design spec (I'll get you to read it yet ;-)
Also there is no "changeover" of control, just which dialog is opened when the "Set Build Configuration" menu item is selected.
And the same interface still allows Frank to hook into the process to control building dependent on file contents irrespective of which configure dialog is being used..
Any thoughts?
Cheers Lex
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 Sun, 14 Feb 2010 12:52:42 +1100, Lex wrote:
Hi,
sorry (again) for the late response...real life sucks.
As I see it there area couple of ways of implementing your suggestion:
- a basic build system in the core and the advanced one in the
plugin, or 2. the two plugins approach
- has the advantage that the basic system is always available even if
Geany is started without plugins, but then the build-in system needs to be able to be completely disabled when the plugin takes over 2. makes the takeover problem simpler,
But both require that everything that the build system needs to do is available through the plugin API, and thats likely to be a big API, much of which no one else will want to use. This includes interface to the preferences and filetype files for saving and restoring settings.
Now as I understand it, what we are trying to achieve is:
- By default Geany provides a set of capabilities roughly equivalent
to 0.18 2. By default Geany provides an easy configuration capability that hides complex capability 3. An alternative that allows "configure everything" control
Now it seems to me that it doesn't matter how complex the internal operation of the build system is, so long as a default user sees functionality as at
- and 2. does not expose that complexity.
So I propose that a build-system with full capability but only a simple configuration dialog be in core, and the full configure dialog be in a plugin.
This makes the plugin interface much narrower, mostly the capability to set the configuration. That interface would be the interface to the "operation" object I defined in the design spec (I'll get you to read it yet ;-)
In the meantime, I realised my idea wasn't the best I ever had...:) But I do like your proposal to have it all in the core except the "heavy" configuration dialog which could be in a plugin.
As long as it works in the end, I'm all for it.
Just go to get it, I don't want to hinder new stuff any longer.
Regards, Enrico
2010/2/22 Enrico Tröger enrico.troeger@uvena.de
On Sun, 14 Feb 2010 12:52:42 +1100, Lex wrote:
Hi,
sorry (again) for the late response...real life sucks.
<snip>
Just go to get it, I don't want to hinder new stuff any longer.
Don't worry, I've currently been sidetracked by writing a Python based flashcard memory trainer for my 87 year old Dad to replace the overly simplistic one he found on the internet.
Real life can be strange :-)
I'll get back in a few days (that is of course a software schedule estimate :-)
Cheers Lex
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 Sun, 21 Feb 2010 15:03:01 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
As I see it there area couple of ways of implementing your suggestion:
- a basic build system in the core and the advanced one in the
plugin, or 2. the two plugins approach
- has the advantage that the basic system is always available even if
Geany is started without plugins, but then the build-in system needs to be able to be completely disabled when the plugin takes over 2. makes the takeover problem simpler,
But both require that everything that the build system needs to do is available through the plugin API, and thats likely to be a big API, much of which no one else will want to use. This includes interface to the preferences and filetype files for saving and restoring settings.
Now as I understand it, what we are trying to achieve is:
- By default Geany provides a set of capabilities roughly equivalent
to 0.18 2. By default Geany provides an easy configuration capability that hides complex capability 3. An alternative that allows "configure everything" control
Now it seems to me that it doesn't matter how complex the internal operation of the build system is, so long as a default user sees functionality as at
- and 2. does not expose that complexity.
So I propose that a build-system with full capability but only a simple configuration dialog be in core, and the full configure dialog be in a plugin.
This makes the plugin interface much narrower, mostly the capability to set the configuration. That interface would be the interface to the "operation" object I defined in the design spec (I'll get you to read it yet ;-)
In the meantime, I realised my idea wasn't the best I ever had...:) But I do like your proposal to have it all in the core except the "heavy" configuration dialog which could be in a plugin.
As long as it works in the end, I'm all for it.
Just go to get it, I don't want to hinder new stuff any longer.
Personally I'm not sure that tying the two implementations together is a good idea. I haven't really studied Lex's build.c implementation but I don't want to have to expose all of it to the plugin API. This will straightjacket any changes we want to make on the core build system.
One option would be for a plugin to completely replace the build system by hiding the build menu and overriding the build keybindings.
Regards, Nick
On 25 February 2010 00:17, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Sun, 21 Feb 2010 15:03:01 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
As I see it there area couple of ways of implementing your suggestion:
- a basic build system in the core and the advanced one in the
plugin, or 2. the two plugins approach
- has the advantage that the basic system is always available even if
Geany is started without plugins, but then the build-in system needs to be able to be completely disabled when the plugin takes over 2. makes the takeover problem simpler,
But both require that everything that the build system needs to do is available through the plugin API, and thats likely to be a big API, much of which no one else will want to use. This includes interface to the preferences and filetype files for saving and restoring settings.
Now as I understand it, what we are trying to achieve is:
- By default Geany provides a set of capabilities roughly equivalent
to 0.18 2. By default Geany provides an easy configuration capability that hides complex capability 3. An alternative that allows "configure everything" control
Now it seems to me that it doesn't matter how complex the internal operation of the build system is, so long as a default user sees functionality as at
- and 2. does not expose that complexity.
So I propose that a build-system with full capability but only a simple configuration dialog be in core, and the full configure dialog be in a plugin.
This makes the plugin interface much narrower, mostly the capability to set the configuration. That interface would be the interface to the "operation" object I defined in the design spec (I'll get you to read it yet ;-)
In the meantime, I realised my idea wasn't the best I ever had...:) But I do like your proposal to have it all in the core except the "heavy" configuration dialog which could be in a plugin.
As long as it works in the end, I'm all for it.
Just go to get it, I don't want to hinder new stuff any longer.
Personally I'm not sure that tying the two implementations together is a good idea. I haven't really studied Lex's build.c implementation but I don't want to have to expose all of it to the plugin API. This will straightjacket any changes we want to make on the core build system.
Totally agree, thats why I am proposing to change it so that only the configuration interface be exposed (see attached proposed interface).
This interface is narrow, typesafe, and expandable but exposes little of the internal workings because the BuildOperation type is opaque. It is also ABI safe if extra fields and functions are added and still ABI safe if enums are extended and API safe if no functions/enums are removed.
This API also makes it possible for other plugins to manipulate settings such as Franks proposed plugin that sets build commands based on contents of latex files.
One option would be for a plugin to completely replace the build system by hiding the build menu and overriding the build keybindings.
This would make loading/storing settings messy, the filetypes, project and preferences load/store interface needs to be available to the plugin. And what happens if the plugin isn't loaded when the filetypes etc are loaded? When the plugin is loaded how does it get to re-load these settings? Or does the plugin have to have another set of settings files mirroring the filetype projects and preferences files? And structures mirroring the GeanyFiletype, GeanyProject etc structures or do those structures have fields for a plugin that may not be loaded?
Makes the plugin much bigger and also requires more of the build functionality to be exposed unless everything is re-implemented in the plugin in which case maintenance is a nightmare to keep them in line. For example the build_command, build_run _cmd, build_replace_placeholder functions.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 25 Feb 2010 09:43:33 +1100 Lex Trotman elextr@gmail.com wrote:
On 25 February 2010 00:17, Nick Treleaven nick.treleaven@btinternet.comwrote:
Personally I'm not sure that tying the two implementations together is a good idea. I haven't really studied Lex's build.c implementation but I don't want to have to expose all of it to the plugin API. This will straightjacket any changes we want to make on the core build system.
Totally agree, thats why I am proposing to change it so that only the configuration interface be exposed (see attached proposed interface).
This interface is narrow, typesafe, and expandable but exposes little of the internal workings because the BuildOperation type is opaque. It is also ABI safe if extra fields and functions are added and still ABI safe if enums are extended and API safe if no functions/enums are removed.
Yes, but exposing an interface puts controls on what our build code must do. It's hard to define interfaces well with foresight. It adds a significant maintenance burden.
Anyway, if you and Enrico want to do this I suppose it's OK, but obviously if we need to change the core we will try to maintain the API but we may need to break it from time to time.
This API also makes it possible for other plugins to manipulate settings such as Franks proposed plugin that sets build commands based on contents of latex files.
OK.
One option would be for a plugin to completely replace the build system by hiding the build menu and overriding the build keybindings.
This would make loading/storing settings messy, the filetypes, project and preferences load/store interface needs to be available to the plugin. And what happens if the plugin isn't loaded when the filetypes etc are loaded? When the plugin is loaded how does it get to re-load these settings? Or does the plugin have to have another set of settings files mirroring the filetype projects and preferences files? And structures mirroring the GeanyFiletype, GeanyProject etc structures or do those structures have fields for a plugin that may not be loaded?
As independent as possible, so all settings in a separate config file. Remember you want settings that we don't need for the core.
Makes the plugin much bigger and also requires more of the build
Makes the core smaller ;-)
functionality to be exposed unless everything is re-implemented in the plugin in which case maintenance is a nightmare to keep them in line. For example the build_command, build_run _cmd, build_replace_placeholder functions.
Why keep them in line?
Anyway you might be right that it's less work for you if we share the build.c functionality. I'm not really convinced that it's necessary to have 'delta' level control on each command - I think it would be best to improve the core to allow advanced users to do anything they want but in a structured way that doesn't confuse basic users.
But don't let me stop you, just wanted to air my thoughts ;-)
Regards, Nick
On Fri, 26 Feb 2010 17:54:31 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Makes the plugin much bigger and also requires more of the build
Makes the core smaller ;-)
Probably not by much though.
functionality to be exposed unless everything is re-implemented in the plugin in which case maintenance is a nightmare to keep them in line. For example the build_command, build_run _cmd, build_replace_placeholder functions.
Why keep them in line?
Anyway you might be right that it's less work for you if we share the build.c functionality. I'm not really convinced that it's necessary to have 'delta' level control on each command - I think it would be best to improve the core to allow advanced users to do anything they want but in a structured way that doesn't confuse basic users.
But don't let me stop you, just wanted to air my thoughts ;-)
Having thought more and feeling a bit less defensive, I think for the core Execute command(s) a checkbox for whether to run without xterm/VTE per command for GUI programs is good.
So at least the core might be able to benefit from your changes.
I might have been a bit pessimistic, probably having a competing build interface will encourage development of both, which would be good for users.
Regards, Nick
On 2 March 2010 00:37, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 26 Feb 2010 17:54:31 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Makes the plugin much bigger and also requires more of the build
Makes the core smaller ;-)
Probably not by much though.
The build.c in SVN is 500 lines longer than build.c in 0.18.1, which is not bad given the increase in functionality (see below for an indication of some of the things missing)
A rough check says the extra lines are mostly in the dialog, load/save and some of the logic sections. I'd hope that much of that will be clawed back when the complex dialog goes to a plugin and the logic is simplified.
functionality to be exposed unless everything is re-implemented in the plugin in which case maintenance is a nightmare to keep them in line.
For
example the build_command, build_run _cmd, build_replace_placeholder functions.
Why keep them in line?
Anyway you might be right that it's less work for you if we share the build.c functionality. I'm not really convinced that it's necessary to have 'delta' level control on each command - I think it would be best to improve the core to allow advanced users to do anything they want but in a structured way that doesn't confuse basic users.
But don't let me stop you, just wanted to air my thoughts ;-)
Having thought more and feeling a bit less defensive,
Don't worry I understand you are just defending the Geany key feature, ie "fast lightweight"
I think for the core Execute command(s) a checkbox for whether to run without xterm/VTE per command for GUI programs is good.
This gives me an opening to start discussion on what functionality should be exposed by the core configuration dialog, thanks Nick. ;-)
I actually went back to 0.18.1 and looked at what is available there, and I think that the following need to be added, but I'm open to suggestions:
1. edit each of the "make" commands individually (0.18.1 has single setting shared by all three) 2. edit project build settings (don't exist in 0.18.1) for "make" commands only, not filetype 3. edit working directory for each command (doesn't exist in 0.18.1) 4. if above, remove "make in base path" since its no longer needed 5. for execute commands only, the option to run without terminal, checkbox (new) 6. single shared parsing regex per filetype (hidden setting, not in GUI in 0.18.1, this is used for make commands as well based on current document) It might be less confusing to have another regex for the make commands as well?
Things to not make available (to avoid "dialog shock"):
1. edit menu item label 2. which commands are parsed and which are not 3. which commands are stopable and which are not 4. extra commands in sections (propose simple dialog allows editing 2 fieltype,3 make,2 execute) 5. change internal command locations (next/prev error, show dialog) 6. project filetype commands (just so the dialog is smaller) 7. parsing regex per command, source or global 8. viewing settings from non-editable sources ie default, system filetypes, plugins/internal
When I get time I'll see what this make the core configuration look like.
These (and the settings from the core dialog) would all be configurable from the plugin dialog.
What does everyone think?
So at least the core might be able to benefit from your changes.
:-)
I might have been a bit pessimistic, probably having a competing build interface will encourage development of both, which would be good for users.
Yes, but it will take a great deal of firm control to prevent more and more functionality from the plugin configuration dialog from migrating into the core dialog :-D
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 2 Mar 2010 10:21:27 +1100 Lex Trotman elextr@gmail.com wrote:
On Fri, 26 Feb 2010 17:54:31 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Makes the plugin much bigger and also requires more of the build
Makes the core smaller ;-)
Probably not by much though.
The build.c in SVN is 500 lines longer than build.c in 0.18.1, which is not bad given the increase in functionality (see below for an indication of some of the things missing)
I was just backtracking on my comment about core size, not complaining ;-)
A rough check says the extra lines are mostly in the dialog, load/save and some of the logic sections. I'd hope that much of that will be clawed back when the complex dialog goes to a plugin and the logic is simplified.
I'm not worried about size really, just concerned about simplifying things. But it could be good.
...
I think for the core Execute command(s) a checkbox for whether to run without xterm/VTE per command for GUI programs is good.
This gives me an opening to start discussion on what functionality should be exposed by the core configuration dialog, thanks Nick. ;-)
I actually went back to 0.18.1 and looked at what is available there, and I think that the following need to be added, but I'm open to suggestions:
Hmm, this seems quite complicated. You know we accept current trunk as good, no need to rethink everything.
- edit each of the "make" commands individually (0.18.1 has single setting
shared by all three) 2. edit project build settings (don't exist in 0.18.1) for "make" commands only, not filetype 3. edit working directory for each command (doesn't exist in 0.18.1) 4. if above, remove "make in base path" since its no longer needed 5. for execute commands only, the option to run without terminal, checkbox (new) 6. single shared parsing regex per filetype (hidden setting, not in GUI in 0.18.1, this is used for make commands as well based on current document) It might be less confusing to have another regex for the make commands as well?
Things to not make available (to avoid "dialog shock"):
- edit menu item label
- which commands are parsed and which are not
- which commands are stopable and which are not
- extra commands in sections (propose simple dialog allows editing 2
fieltype,3 make,2 execute) 5. change internal command locations (next/prev error, show dialog) 6. project filetype commands (just so the dialog is smaller) 7. parsing regex per command, source or global 8. viewing settings from non-editable sources ie default, system filetypes, plugins/internal
Sorry, I've been thinking about the build system enough already lately :-p I can't really take all this in (but I'm a bit stressed for reasons outside of Geany for the next few months).
Maybe it's better to start a new thread to discuss these things.
I might have been a bit pessimistic, probably having a competing build interface will encourage development of both, which would be good for users.
Yes, but it will take a great deal of firm control to prevent more and more functionality from the plugin configuration dialog from migrating into the core dialog :-D
Haha ;-)
Regards, Nick