Hi All,
I have just returned from a no-computers except gmail at the local internet cafe family holiday.
Having had time to think (always dangerous) I consider that I have been implementing the build system modifications in the wrong way. Instead I am going to have a look at re-implementing it in a more open orthogonal manner and then incorporate current restrictions and behaviour from defaults or configuration files.
I believe that this will make the code smaller and simpler, eliminate some of the implementation imposed limitations of the current system and provide a base for easier addition of language specific functionality via plugins as requested by Frank.
The availability of sane defaults and configuration will also allow a simple configuration dialog to be used to change the most common things with one of those "Advanced..." buttons to unleash the full flexibility.
Cheers Lex
On Mon, 18 Jan 2010 09:52:49 +1100 Lex Trotman elextr@gmail.com wrote:
Having had time to think (always dangerous) I consider that I have been implementing the build system modifications in the wrong way. Instead I am going to have a look at re-implementing it in a more open orthogonal manner and then incorporate current restrictions and behaviour from defaults or configuration files.
I believe that this will make the code smaller and simpler, eliminate some of the implementation imposed limitations of the current system and provide a base for easier addition of language specific functionality via plugins as requested by Frank.
The availability of sane defaults and configuration will also allow a simple configuration dialog to be used to change the most common things with one of those "Advanced..." buttons to unleash the full flexibility.
Just wondering how much work this would be - would this be a full reworking?
If you do this, please commit to a branch regularly in small changes so we can follow your work ;-)
BTW I may have sounded too strict about the plugin API, this isn't something to worry about too much (we can break the ABI when we want).
IMO I'm quite happy with the new build system, we just need to iron out any issues users have with it.
Regards, Nick
2010/1/23 Nick Treleaven nick.treleaven@btinternet.com:
On Mon, 18 Jan 2010 09:52:49 +1100 Lex Trotman elextr@gmail.com wrote:
Having had time to think (always dangerous) I consider that I have been implementing the build system modifications in the wrong way. Instead I am going to have a look at re-implementing it in a more open orthogonal manner and then incorporate current restrictions and behaviour from defaults or configuration files.
I believe that this will make the code smaller and simpler, eliminate some of the implementation imposed limitations of the current system and provide a base for easier addition of language specific functionality via plugins as requested by Frank.
The availability of sane defaults and configuration will also allow a simple configuration dialog to be used to change the most common things with one of those "Advanced..." buttons to unleash the full flexibility.
Just wondering how much work this would be - would this be a full reworking?
In principle no, the general functionality will be the same, but in the details (the devil :) probably bits of everything in build.c are affected. I am also trying to reduce dependence from other parts of Geany once the interaction with the current implementation is removed.
If you do this, please commit to a branch regularly in small changes so we can follow your work ;-)
Will do.
Attached is a spec/design doc I'm using to remind me what is needed. The requirements section is ok, ATM the design section is just notes to self. It will expand. In the future it may be worthwhile putting this somewhere later maintainers can access it Where do you think, the doc directory?.
BTW I may have sounded too strict about the plugin API, this isn't something to worry about too much (we can break the ABI when we want).
Thats ok, but lets get it right and just do it once :-)
IMO I'm quite happy with the new build system, we just need to iron out any issues users have with it.
The reason I'm doing this is that there are a couple of issues that I have with it. I'm probably pushing it harder than most users but eventually others will run into the same issues.
1. GUI issues a. some things that matter (to me at least) are not GUI configurable b. the GUI split between project and build sections makes it hard to tell what is going on overall 2. internal functionality is poorly supported, shows up in a. difficulty accommodating plugin interface b. built in browser functionality has to be invoked by "magic" commands c. see 3.e. below 3. some functionality is dependent on where an item is in the menu a. custom target dialog is always item 3 section 2, even if I don't want it b. only execute commands are stopable c. parsing of command output for sections 1 & 2 always d. no ability to execute commands without a terminal or parse. e. fixed positions of next/prev error and dialog items
Gee that looks a long list now I've writen it down :-)
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 26 Jan 2010 17:00:48 +1100 Lex Trotman elextr@gmail.com wrote:
Just wondering how much work this would be - would this be a full reworking?
In principle no, the general functionality will be the same, but in the details (the devil :) probably bits of everything in build.c are affected. I am also trying to reduce dependence from other parts of Geany once the interaction with the current implementation is removed.
OK.
Attached is a spec/design doc I'm using to remind me what is needed. The requirements section is ok, ATM the design section is just notes to self. It will expand. In the future it may be worthwhile putting this somewhere later maintainers can access it Where do you think, the doc directory?.
Yes, IMO it would be OK in doc/.
BTW I may have sounded too strict about the plugin API, this isn't something to worry about too much (we can break the ABI when we want).
Thats ok, but lets get it right and just do it once :-)
IMO I'm quite happy with the new build system, we just need to iron out any issues users have with it.
The reason I'm doing this is that there are a couple of issues that I have with it. I'm probably pushing it harder than most users but eventually others will run into the same issues.
- GUI issues
a. some things that matter (to me at least) are not GUI configurable b. the GUI split between project and build sections makes it hard to tell what is going on overall 2. internal functionality is poorly supported, shows up in a. difficulty accommodating plugin interface b. built in browser functionality has to be invoked by "magic" commands c. see 3.e. below 3. some functionality is dependent on where an item is in the menu a. custom target dialog is always item 3 section 2, even if I don't want it b. only execute commands are stopable c. parsing of command output for sections 1 & 2 always d. no ability to execute commands without a terminal or parse. e. fixed positions of next/prev error and dialog items
Gee that looks a long list now I've writen it down :-)
Ok, good luck ;-)
Regards, Nick