Hey,
I noticed a few more smaller and bigger problems with the new Build system:
See attached image build_dialog_py_initial.png: this is the initial build settings dialog for an opened Python file. So far it looks fine except the "null" values for two Make commands.
Then I changed the Python Compile and Run commands to use python2.5 instead of just python. Worked fine.
But then, I opened the Build settings dialog for a XML file and for some reason, it shows me the Python Run command as Run command for the XML file. And it does this probably for each other filetype as well, tested also with Shellscript and I got again the Python Run command. This completely contradicts the original idea of the build system: being easy to use to compile&run single files. Not sure whether this is a bug or actually intended behaviour of your code, but it is not what Geany should do and it is not what Geany did before! Run commands were and should be filetype-dependent except you have opened a project and the project has a Run command defined.
Furthermore, the Compile button is disabled in the toolbar. But this seems to be a separate issue :).
The reported issues happened with latest Geany from SVN, a clean config (geany -c /tmp/test) and without a project being opened.
Regards, Enrico
2009/10/11 Enrico Tröger enrico.troeger@uvena.de:
Hey,
I noticed a few more smaller and bigger problems with the new Build system:
See attached image build_dialog_py_initial.png: this is the initial build settings dialog for an opened Python file. So far it looks fine except the "null" values for two Make commands.
Then I changed the Python Compile and Run commands to use python2.5 instead of just python. Worked fine.
But then, I opened the Build settings dialog for a XML file and for some reason, it shows me the Python Run command as Run command for the XML file. And it does this probably for each other filetype as well, tested also with Shellscript and I got again the Python Run command. This completely contradicts the original idea of the build system: being easy to use to compile&run single files. Not sure whether this is a bug or actually intended behaviour of your code, but it is not what Geany should do and it is not what Geany did before! Run commands were and should be filetype-dependent except you have opened a project and the project has a Run command defined.
Sounds pretty much like a bug, it is intended to work as you describe. Can't look at it until Tuesday.
Cheers Lex
Furthermore, the Compile button is disabled in the toolbar. But this seems to be a separate issue :).
The reported issues happened with latest Geany from SVN, a clean config (geany -c /tmp/test) and without a project being opened.
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 Enrico,
I had a chance to have a quick look at these. Results so far below.
2009/10/11 Enrico Tröger enrico.troeger@uvena.de:
Hey,
I noticed a few more smaller and bigger problems with the new Build system:
See attached image build_dialog_py_initial.png: this is the initial build settings dialog for an opened Python file. So far it looks fine except the "null" values for two Make commands.
Hmmmm, the nulls only appear if geany is run with an empty config, ie geany -v -c empty_config_dir something I never tested.
Ok, found and fixed in my local copy plus a potential if unlikely similar problem for compile and build if a filetype configuration file is missing. Commit as soon as I test better ;-)
Then I changed the Python Compile and Run commands to use python2.5 instead of just python. Worked fine.
But then, I opened the Build settings dialog for a XML file and for some reason, it shows me the Python Run command as Run command for the XML file. And it does this probably for each other filetype as well, tested also with Shellscript and I got again the Python Run command. This completely contradicts the original idea of the build system: being easy to use to compile&run single files. Not sure whether this is a bug or actually intended behaviour of your code, but it is not what Geany should do and it is not what Geany did before! Run commands were and should be filetype-dependent except you have opened a project and the project has a Run command defined.
In the new build system there are more execute commands than in the old system:
1. from system filetypes files 2. from user preferences filetypes files 3. from user preference 4. from project filetypes in the project file 5. from project preference
The cause of the issue you've identified is because modified execute commands are treated as a user preference rather than as a filetype. Its actually documented in the manual this way (see the table in 'build menu configuration') and it notes that you can't set the filetype dependent execute commands using the dialog.
Because the dialog doesn't have any way of selecting if the user is changing the preference/project setting or the filetype dependent setting a decision one way or the other had to be made. I don't remember why this particular decision was made, but I see two "solutions":
1. Since projects are most likely to have an execute command independent of the filetype and non-projects are more likely to be dependent on filetype we could have the execute commands set in the 'build commands' dialog set the filetype preferences execute not the preferences execute, but the execute commands in the project 'build commands' dialog set the project execute not the project filetypes execute, but this is potentially confusing (I'm confused just writing it)
2. Or I can try to get Enrico to agree to adding one itty bitty teeny weeny little checkbox to the build commands dialog to make the selection, I'll put it on the same line as the execute commands header and it won't make the dialog any bigger I *promise*. :-) It will default to acting as above, still confusing but it defaults to the most likely scenario and at least it will be visible.
Personally I like 2 since it gets rid of the problem of a bit of functionality that exists but can't be configured from the dialog.
Let me know what you think.
Furthermore, the Compile button is disabled in the toolbar. But this seems to be a separate issue :).
AFAICT build.c doesn't know about the compile toolbar menu button, or the execute menu button for that matter, it only knows about the build toolbar menu button and the compile, build and execute actions, so I don't know what is setting the sensitivity of the compile and execute menu buttons.
The reported issues happened with latest Geany from SVN, a clean config (geany -c /tmp/test) and without a project being opened.
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
2009/10/12 Lex Trotman elextr@gmail.com:
Hi Enrico,
I had a chance to have a quick look at these. Results so far below.
2009/10/11 Enrico Tröger enrico.troeger@uvena.de:
Hey,
I noticed a few more smaller and bigger problems with the new Build system:
See attached image build_dialog_py_initial.png: this is the initial build settings dialog for an opened Python file. So far it looks fine except the "null" values for two Make commands.
Hmmmm, the nulls only appear if geany is run with an empty config, ie geany -v -c empty_config_dir something I never tested.
Ok, found and fixed in my local copy plus a potential if unlikely similar problem for compile and build if a filetype configuration file is missing. Commit as soon as I test better ;-)
This part fixed in SVN, ironically the problem would have shown up earlier if we had taken Franks advice to delete the old [build-settings] from filetype latex, oh well.
Cheers Lex
On Mon, 12 Oct 2009 16:49:43 +1100, Lex wrote:
Hey,
In the new build system there are more execute commands than in the old system:
- from system filetypes files
- from user preferences filetypes files
- from user preference
- from project filetypes in the project file
- from project preference
The cause of the issue you've identified is because modified execute commands are treated as a user preference rather than as a filetype. Its actually documented in the manual this way (see the table in 'build menu configuration') and it notes that you can't set the filetype dependent execute commands using the dialog.
Because the dialog doesn't have any way of selecting if the user is changing the preference/project setting or the filetype dependent setting a decision one way or the other had to be made. I don't remember why this particular decision was made, but I see two "solutions":
- Since projects are most likely to have an execute command
independent of the filetype and non-projects are more likely to be dependent on filetype we could have the execute commands set in the 'build commands' dialog set the filetype preferences execute not the preferences execute, but the execute commands in the project 'build commands' dialog set the project execute not the project filetypes execute, but this is potentially confusing (I'm confused just writing it)
- Or I can try to get Enrico to agree to adding one itty bitty teeny
weeny little checkbox to the build commands dialog to make the selection, I'll put it on the same line as the execute commands header and it won't make the dialog any bigger I *promise*. :-) It will
Putting things very close together won't help making better UIs...it's not about size, it's about complexity.
Let me know what you think.
No idea, really. I somewhat prefer 1) as it is closer to the previous, original behaviour which I believed we wanted to keep. Maybe I missed the decision against it in one of the thousands mails about the build system stuff. If so, my bad.
Though I remember saying myself a couple of times I wanted to have it as compatible as possible and to not change the default behaviour when not absolutely necessary.
Why the hell does one need so many different types of Run commands you listed above? I loved the old behaviour so much where I just opened a file and could execute it, without configuring anything and without thinking about which of the thousands things it could do now...
(Sorry for sounding a bit harsh, probably I should have done deeper testing before the merge but well, it doesn't make things better. We, at least I thought so, tried to keep things small and stupid...maybe we left this way without noticing.)
Furthermore, the Compile button is disabled in the toolbar. But this seems to be a separate issue :).
AFAICT build.c doesn't know about the compile toolbar menu button, or the execute menu button for that matter, it only knows about the build toolbar menu button and the compile, build and execute actions, so I don't know what is setting the sensitivity of the compile and execute menu buttons.
The action is the toolbar button, at least it is the parent instance which creates the actual button widget for the toolbar. So, setting the sensitivity of the action, implicitly changes the sensitivity of the toolbar button widget. And the action's sensitivity is changed at the end of build_menu_update(). And at some point, this worked.
Regards, Enrico
Hi Enrico,
2009/10/13 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 12 Oct 2009 16:49:43 +1100, Lex wrote:
Hey,
In the new build system there are more execute commands than in the old system:
- from system filetypes files
- from user preferences filetypes files
- from user preference
- from project filetypes in the project file
- from project preference
The cause of the issue you've identified is because modified execute commands are treated as a user preference rather than as a filetype. Its actually documented in the manual this way (see the table in 'build menu configuration') and it notes that you can't set the filetype dependent execute commands using the dialog.
Because the dialog doesn't have any way of selecting if the user is changing the preference/project setting or the filetype dependent setting a decision one way or the other had to be made. I don't remember why this particular decision was made, but I see two "solutions":
- Since projects are most likely to have an execute command
independent of the filetype and non-projects are more likely to be dependent on filetype we could have the execute commands set in the 'build commands' dialog set the filetype preferences execute not the preferences execute, but the execute commands in the project 'build commands' dialog set the project execute not the project filetypes execute, but this is potentially confusing (I'm confused just writing it)
- Or I can try to get Enrico to agree to adding one itty bitty teeny
weeny little checkbox to the build commands dialog to make the selection, I'll put it on the same line as the execute commands header and it won't make the dialog any bigger I *promise*. :-) It will
Putting things very close together won't help making better UIs...it's not about size, it's about complexity.
I guess I'm not the best to judge since I designed it and understand the underlying ideas, but to me just having lots of repeated rows of the same thing isn't complex, it just shows that there are several things to be configured.
Your point about crowding the dialog is true, I was thinking about making the title of the execute section say some thing like:
Execute commands [checkbox] for filetype xxx,
where the filetype xxx could grey out if the box was unchecked and so the commands would be stored in the geany.conf which is filetype independent (see further explanation below)
Or maybe its better for the whole section title to be a combo box choosing between "Execute commands for all filetypes" or "Execute commands for this filetype only". I think thats clearer and it will translate better.
Let me know what you think.
No idea, really. I somewhat prefer 1) as it is closer to the previous, original behaviour which I believed we wanted to keep. Maybe I missed the decision against it in one of the thousands mails about the build system stuff. If so, my bad.
Though I remember saying myself a couple of times I wanted to have it as compatible as possible and to not change the default behaviour when not absolutely necessary.
Much of the "thousands of mails" was me trying to understand the existing behaviour, you designed it and so it was obvious to you, but although I sort of knew what it did, all the implications were not obvious. And clearly I still missed some :-)
Why the hell does one need so many different types of Run commands you
Please note this is me trying to explain clearly, because to me its not complicated, but clearly that hasn't been communicated properly. It is often hard to describe flexibility without it sounding complicated or so obvious its insulting to explain it.
- from system filetypes files
Thats the standard behaviour
- from user preferences filetypes files
Thats so a user can edit the behaviour without changing system files or impacting other users.
- from user preference (geany.conf)
As soon as there is more than one file in the program, the run command is usually no longer dependent on the file, you usually want to run the main program. You don't want to have to always switch back to the "main" file before selecting run, so the command needs to be able to be set somewhere that is file independent
- from project filetypes in the project file
Same argument as for user filetypes, but only set for the project
- from project preference
Same argument as for user preference, but only set for the project
From here on numbers refer to items in the list above
The old system already had 1,2 and 5. The lack of 3 I found really annoying because I constantly forgot to change back to the main file. And an example of a good use of 4 is to set the project and only the project to run using python3 whilst everything else is still python2.5.
None of these seem unnecessary to me.
listed above? I loved the old behaviour so much where I just opened a file and could execute it, without configuring anything and without thinking about which of the thousands things it could do now...
(Sorry for sounding a bit harsh, probably I should have done deeper testing before the merge but well, it doesn't make things better. We, at least I thought so, tried to keep things small and stupid...maybe we left this way without noticing.)
Well it *should* still "just work" by default, the only problem you've got is that the configure dialog edits 3 not 2 and the more we talk about it the more obvious it is that there is a need to choose which one to edit rather than having it fixed (whichever way we fix it it will always be wrong for someone).
The combobox I described above would choose to edit 2 or 3 in the build menu "set build commands" dialog and 4 or 5 in the project dialog "build" tab.
Furthermore, the Compile button is disabled in the toolbar. But this seems to be a separate issue :).
AFAICT build.c doesn't know about the compile toolbar menu button, or the execute menu button for that matter, it only knows about the build toolbar menu button and the compile, build and execute actions, so I don't know what is setting the sensitivity of the compile and execute menu buttons.
The action is the toolbar button, at least it is the parent instance which creates the actual button widget for the toolbar. So, setting the sensitivity of the action, implicitly changes the sensitivity of the toolbar button widget. And the action's sensitivity is changed at the end of build_menu_update(). And at some point, this worked.
I didn't realise that the gtkaction controlled the widget, I've read the documentation and learned more GTK :-)
The problem is that can_compile and can_build have been combined into one, so for python it is wrong because it has a compile but no build. I had tried to copy the logic from the old build_menu_update and can_compile and can_build *seemed* to be the same tests so I used the same value.
Clearly they should be different. Fixed in SVN.
BTW should the set sensitive for widgets.compile_action, build_action and run_action be protected from NULL or do the actions always exist?
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
Sorry that I just ditch in, I just want to point something out from a user pov.
Lex Trotman schrieb:
- from user preference (geany.conf)
As soon as there is more than one file in the program, the run command is usually no longer dependent on the file, you usually want to run the main program. You don't want to have to always switch back to the "main" file before selecting run, so the command needs to be able to be set somewhere that is file independent
I disagree with that. That's what a project/session is for. If there's no project open, it should be document-sensitive/filetype-sensitive (unfortunately that's not entirely the same).
To me, there's no such thing as a "main file" if I have various random files open. I use project if I'm to lazy for switching files and the run command is the same.
For me a project is a collection of related files. I don't have a bunch of open files open and want the same run command for all if I do not have a project open.
Well it *should* still "just work" by default, the only problem you've got is that the configure dialog edits 3 not 2 and the more we talk about it the more obvious it is that there is a need to choose which one to edit rather than having it fixed (whichever way we fix it it will always be wrong for someone).
The combobox I described above would choose to edit 2 or 3 in the build menu "set build commands" dialog and 4 or 5 in the project dialog "build" tab.
I don't see a need for a checkbox here. a) use global run command per project, or b) filetype specific commands.
I agree with Enrico here. I stumbled on this quite a bit times already. Something just overrode my html run command (i.e. open in in a browser). I needed to change it back for no apparent reason (I had no project open).
Best regards.
2009/10/14 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Sorry that I just ditch in, I just want to point something out from a user pov.
Don't worry, everyone has the right to express their opinion.
Lex Trotman schrieb:
- from user preference (geany.conf)
As soon as there is more than one file in the program, the run command is usually no longer dependent on the file, you usually want to run the main program. You don't want to have to always switch back to the "main" file before selecting run, so the command needs to be able to be set somewhere that is file independent
I disagree with that. That's what a project/session is for. If there's no project open, it should be document-sensitive/filetype-sensitive (unfortunately that's not entirely the same).
Then don't set a run command in the preferences, it will still be filetype sensitive. Its entirely up to you.
To me, there's no such thing as a "main file" if I have various random files open. I use project if I'm to lazy for switching files and the run command is the same.
You should not *have* to use a project, that was a requirement of Enricos right from the beginning. Switching files isn't lazyness, its an annoyance that isn't needed.
For me a project is a collection of related files. I don't have a bunch of open files open and want the same run command for all if I do not have a project open.
As above.
Well it *should* still "just work" by default, the only problem you've got is that the configure dialog edits 3 not 2 and the more we talk about it the more obvious it is that there is a need to choose which one to edit rather than having it fixed (whichever way we fix it it will always be wrong for someone).
The combobox I described above would choose to edit 2 or 3 in the build menu "set build commands" dialog and 4 or 5 in the project dialog "build" tab.
I don't see a need for a checkbox here. a) use global run command per project, or b) filetype specific commands.
I agree with Enrico here. I stumbled on this quite a bit times already.
Then you should have complained and we would have been able to do something sooner, I can't fix what I don't know is broken :-D
Something just overrode my html run command (i.e. open in in a browser). I needed to change it back for no apparent reason (I had no project open).
Yes, the dialog edits something different to what it used to, whatever is decided that is likely to be changed.
But it should not only allow one way of working, it may make one group of people happy, but it makes another group unhappy. Just because you don't use the particular functionality doesn't mean it isn't needed, so I have proposed a way of allowing either instead of cutting off options.
Cheers Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
2009/10/14 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Sorry that I just ditch in, I just want to point something out from a user pov.
Don't worry, everyone has the right to express their opinion.
Lex Trotman schrieb:
- from user preference (geany.conf)
As soon as there is more than one file in the program, the run command is usually no longer dependent on the file, you usually want to run the main program. You don't want to have to always switch back to the "main" file before selecting run, so the command needs to be able to be set somewhere that is file independent
I disagree with that. That's what a project/session is for. If there's no project open, it should be document-sensitive/filetype-sensitive (unfortunately that's not entirely the same).
Then don't set a run command in the preferences, it will still be filetype sensitive. Its entirely up to you.
To me, there's no such thing as a "main file" if I have various random files open. I use project if I'm to lazy for switching files and the run command is the same.
You should not *have* to use a project, that was a requirement of Enricos right from the beginning. Switching files isn't lazyness, its an annoyance that isn't needed.
I thought the main requirement was to not change default behavior? And it wasn't behaving like this before. Also refer to Enrico's initial mail:
Thomas Martitz schrieb:
Lex Trotman schrieb:
You should not *have* to use a project, that was a requirement of Enricos right from the beginning. Switching files isn't lazyness, its an annoyance that isn't needed.
I thought the main requirement was to not change default behavior? And it wasn't behaving like this before. Also refer to Enrico's initial mail:
Argh, ctrl+enter too early, anyway...
Quoting Enrico (which is the exact opposite of what you said): "But then, I opened the Build settings dialog for a XML file and for some reason, it shows me the Python Run command as Run command for the XML file. And it does this probably for each other filetype as well, tested also with Shellscript and I got again the Python Run command. This completely contradicts the original idea of the build system: being easy to use to compile&run single files. Not sure whether this is a bug or actually intended behaviour of your code, but it is not what Geany should do and it is not what Geany did before! Run commands were and should be filetype-dependent except you have opened a project and the project has a Run command defined."
This is exactly what expect (and want also).
Thomas,
Also worth reading whole email before pressing send :-)
I said:
Yes, the dialog edits something different to what it used to, whatever is decided that is likely to be changed.
But it should not only allow one way of working, it may make one group of people happy, but it makes another group unhappy. Just because you don't use the particular functionality doesn't mean it isn't needed, so I have proposed a way of allowing either instead of cutting off options.
I am trying to discuss how to make the default behaviour the same as it was previously without losing access to the extra functionality.
The discussion is how to implement that.
2009/10/15 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Thomas Martitz schrieb:
Lex Trotman schrieb:
You should not *have* to use a project, that was a requirement of Enricos right from the beginning. Switching files isn't lazyness, its an annoyance that isn't needed.
I thought the main requirement was to not change default behavior? And it wasn't behaving like this before. Also refer to Enrico's initial mail:
Argh, ctrl+enter too early, anyway...
Quoting Enrico (which is the exact opposite of what you said): "But then, I opened the Build settings dialog for a XML file and for some reason, it shows me the Python Run command as Run command for the XML file. And it does this probably for each other filetype as well, tested also with Shellscript and I got again the Python Run command. This completely contradicts the original idea of the build system: being easy to use to compile&run single files. Not sure whether this is a bug or actually intended behaviour of your code, but it is not what Geany should do and it is not what Geany did before! Run commands were and should be filetype-dependent except you have opened a project and the project has a Run command defined."
This is exactly what expect (and want also).
The requirements were determined through "thousands of emails" to quote Enrico (again :-), that something was misunderstood has been acknowledged, constantly pointing things out with 20/20 hindsight is no help in defining a suitable solution.
To reiterate:
The build system does not do anything wrong, a dialog edits a different setting to what it used to and the build system does what that edit tells it to do.
I have suggested a change to the dialog that allows it to default to editing the settings as it used to so that the build system will behave as it used to, but still allows access to edit the other settings for those of us who want to use that functionality.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 15 Oct 2009 06:08:08 +1100, Lex wrote:
Hey guys,
I don't have time to intensively answer your mails although I'd like to. Though my answer will be rather short, hopefully still clear and concentrating to the important things. I guess you'll tell me if not, haha :).
Yes, the dialog edits something different to what it used to, whatever is decided that is likely to be changed.
But it should not only allow one way of working, it may make one group of people happy, but it makes another group unhappy. Just because you don't use the particular functionality doesn't mean it isn't needed, so I have proposed a way of allowing either instead of cutting off options.
I am trying to discuss how to make the default behaviour the same as it was previously without losing access to the extra functionality.
The discussion is how to implement that.
That's a ) normal and b) absolutely ok. It's almost always about finding a compromise between different needs and wishes when it is about implementing new features.
This is exactly what expect (and want also).
The requirements were determined through "thousands of emails" to quote Enrico (again :-), that something was misunderstood has been acknowledged, constantly pointing things out with 20/20 hindsight is no help in defining a suitable solution.
Full ACK. We already noticed there were small communication problems (:D), anyway, just let's concentrate on how to make it better for the future.
To reiterate:
The build system does not do anything wrong, a dialog edits a different setting to what it used to and the build system does what that edit tells it to do.
I have suggested a change to the dialog that allows it to default to editing the settings as it used to so that the build system will behave as it used to, but still allows access to edit the other settings for those of us who want to use that functionality.
I'd prefer the checkbox, at least it'd be better than a combo box. I see why you suggested the combo box and it's rationale but just not nice. A checkbox next to the title is probably less intrusive and less diverting, I think.
Regards, Enrico
On Tue, 13 Oct 2009 11:27:31 +1100, Lex wrote:
The problem is that can_compile and can_build have been combined into one, so for python it is wrong because it has a compile but no build. I had tried to copy the logic from the old build_menu_update and can_compile and can_build *seemed* to be the same tests so I used the same value.
Clearly they should be different. Fixed in SVN.
Thanks.
BTW should the set sensitive for widgets.compile_action, build_action and run_action be protected from NULL or do the actions always exist?
No worries, the actions always exist. It's only the actual widgets which only exist if the toolbar is visible and the widgets get destroyed/recreated sometimes when removed/added from/to the toolbar. To make it short, the actions always exist even if the toolbar isn't visible at all, so they are saved to be used.
Regards, Enrico
2009/10/16 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 15 Oct 2009 06:08:08 +1100, Lex wrote:
Hey guys,
I don't have time to intensively answer your mails although I'd like to. Though my answer will be rather short, hopefully still clear and concentrating to the important things. I guess you'll tell me if not, haha :).
Yes, the dialog edits something different to what it used to, whatever is decided that is likely to be changed.
But it should not only allow one way of working, it may make one group of people happy, but it makes another group unhappy. Just because you don't use the particular functionality doesn't mean it isn't needed, so I have proposed a way of allowing either instead of cutting off options.
I am trying to discuss how to make the default behaviour the same as it was previously without losing access to the extra functionality.
The discussion is how to implement that.
That's a ) normal and b) absolutely ok. It's almost always about finding a compromise between different needs and wishes when it is about implementing new features.
This is exactly what expect (and want also).
The requirements were determined through "thousands of emails" to quote Enrico (again :-), that something was misunderstood has been acknowledged, constantly pointing things out with 20/20 hindsight is no help in defining a suitable solution.
Full ACK. We already noticed there were small communication problems (:D), anyway, just let's concentrate on how to make it better for the future.
To reiterate:
The build system does not do anything wrong, a dialog edits a different setting to what it used to and the build system does what that edit tells it to do.
I have suggested a change to the dialog that allows it to default to editing the settings as it used to so that the build system will behave as it used to, but still allows access to edit the other settings for those of us who want to use that functionality.
I'd prefer the checkbox, at least it'd be better than a combo box. I see why you suggested the combo box and it's rationale but just not nice. A checkbox next to the title is probably less intrusive and less diverting, I think.
Ok, I'll make a prototype with checkbox
Oops, found a crash ... fixed in SVN, prototype tomorrow (maybe).
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,
I had a email directly from one of my colleagues who has been reading this thread and had a question about the project filetype execute commands.
Here is part of her email (project name obscured to protect the guilty :-)
This looked exactly like what we need for the XXX project where it has to still support Python 2.4.
Since most files are coded with "if __MAIN__ then:" test code for this module, we want to run both the individual file to run the test code and we want to run the overall application.
From what you said if I edited the project file directly we could have both a filetype dependant and a non-filetype dependant command for the project which ran Python2.4, and when that project was closed everything would use Python3 as usual, perfect!!
Unfortunately I can't get project filetype executes to work at all and looking at the code I can't see where they are handled.
This raised two points:
1. the project filetypes execute commands code is missing completely, I have it in an old version in my personal bazaar repository but it never made it into SVN.
2. because we have more than one execute command is it possible for one to be filetype dependent and one to be non-filetype dependent. In fact it is and it works fine when there is no project open, but as discussed previously the dialog won't edit the filetype ones at the moment.
for 1. I will fix it first since it is a pre-requisite for the suggested solution to 2., this may also allow some simplification of the implementation due to better consistency.
for 2. I had never considered having mixed filetype/non-filetype commands, but as my colleague has said it is reasonable, and she has identified a use for it already, and it already works for non-project commands (I tested it with HEAD)
But it did cause me to think about how the dialog should work. After much thought I suggest (I'll keep it as short as possible Enrico so I won't mention any alternatives)
There are four sets of execute commands to edit, project vs non-project which is addressed by having separate dialogs and for all filetypes vs for a specific filetype which is to be addressed by the "unobtrusive" check box selecting which is being edited.
In line with current practice if any command is overridden by a higher priority one then the higher priority one is shown but it will be insensitive. This ensures that the dialogs always show what will appear on the build menu when ok is selected.
If you edit a setting and switch the checkbox, the edit is saved in temporary storage until OK is clicked, so you can flick between all filetypes and filetype specific settings as many time as you want.
Cheers Lex
2009/10/16 Lex Trotman elextr@gmail.com:
2009/10/16 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 15 Oct 2009 06:08:08 +1100, Lex wrote:
Hey guys,
I don't have time to intensively answer your mails although I'd like to. Though my answer will be rather short, hopefully still clear and concentrating to the important things. I guess you'll tell me if not, haha :).
Yes, the dialog edits something different to what it used to, whatever is decided that is likely to be changed.
But it should not only allow one way of working, it may make one group of people happy, but it makes another group unhappy. Just because you don't use the particular functionality doesn't mean it isn't needed, so I have proposed a way of allowing either instead of cutting off options.
I am trying to discuss how to make the default behaviour the same as it was previously without losing access to the extra functionality.
The discussion is how to implement that.
That's a ) normal and b) absolutely ok. It's almost always about finding a compromise between different needs and wishes when it is about implementing new features.
This is exactly what expect (and want also).
The requirements were determined through "thousands of emails" to quote Enrico (again :-), that something was misunderstood has been acknowledged, constantly pointing things out with 20/20 hindsight is no help in defining a suitable solution.
Full ACK. We already noticed there were small communication problems (:D), anyway, just let's concentrate on how to make it better for the future.
To reiterate:
The build system does not do anything wrong, a dialog edits a different setting to what it used to and the build system does what that edit tells it to do.
I have suggested a change to the dialog that allows it to default to editing the settings as it used to so that the build system will behave as it used to, but still allows access to edit the other settings for those of us who want to use that functionality.
I'd prefer the checkbox, at least it'd be better than a combo box. I see why you suggested the combo box and it's rationale but just not nice. A checkbox next to the title is probably less intrusive and less diverting, I think.
Ok, I'll make a prototype with checkbox
Oops, found a crash ... fixed in SVN, prototype tomorrow (maybe).
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,
2009/10/18 Lex Trotman elextr@gmail.com:
Hi all,
I had a email directly from one of my colleagues who has been reading this thread and had a question about the project filetype execute commands.
Here is part of her email (project name obscured to protect the guilty :-)
This looked exactly like what we need for the XXX project where it has to still support Python 2.4.
Since most files are coded with "if __MAIN__ then:" test code for this module, we want to run both the individual file to run the test code and we want to run the overall application.
From what you said if I edited the project file directly we could have both a filetype dependant and a non-filetype dependant command for the project which ran Python2.4, and when that project was closed everything would use Python3 as usual, perfect!!
Unfortunately I can't get project filetype executes to work at all and looking at the code I can't see where they are handled.
This raised two points:
- the project filetypes execute commands code is missing completely,
I have it in an old version in my personal bazaar repository but it never made it into SVN.
- because we have more than one execute command is it possible for
one to be filetype dependent and one to be non-filetype dependent. In fact it is and it works fine when there is no project open, but as discussed previously the dialog won't edit the filetype ones at the moment.
for 1. I will fix it first since it is a pre-requisite for the suggested solution to 2., this may also allow some simplification of the implementation due to better consistency.
Done in SVN. Didn't get any simpler though :-)
for 2. I had never considered having mixed filetype/non-filetype commands, but as my colleague has said it is reasonable, and she has identified a use for it already, and it already works for non-project commands (I tested it with HEAD)
But it did cause me to think about how the dialog should work. After much thought I suggest (I'll keep it as short as possible Enrico so I won't mention any alternatives)
There are four sets of execute commands to edit, project vs non-project which is addressed by having separate dialogs and for all filetypes vs for a specific filetype which is to be addressed by the "unobtrusive" check box selecting which is being edited.
In line with current practice if any command is overridden by a higher priority one then the higher priority one is shown but it will be insensitive. This ensures that the dialogs always show what will appear on the build menu when ok is selected.
If you edit a setting and switch the checkbox, the edit is saved in temporary storage until OK is clicked, so you can flick between all filetypes and filetype specific settings as many time as you want.
I made a prototype of this dialog, its terrible, very confusing, hard to tell what you are editing.
So I have made a temporary change in SVN to make the dialog save to the fieltype execute command for the build menu->set build commands dialog. The project dialog still stores execute commands for all fieltypes. This is how it used to work.
I will now take some time to look at an alternative build-system configuration dialog.
Cheers Lex
Cheers Lex
2009/10/16 Lex Trotman elextr@gmail.com:
2009/10/16 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 15 Oct 2009 06:08:08 +1100, Lex wrote:
Hey guys,
I don't have time to intensively answer your mails although I'd like to. Though my answer will be rather short, hopefully still clear and concentrating to the important things. I guess you'll tell me if not, haha :).
Yes, the dialog edits something different to what it used to, whatever is decided that is likely to be changed.
But it should not only allow one way of working, it may make one group of people happy, but it makes another group unhappy. Just because you don't use the particular functionality doesn't mean it isn't needed, so I have proposed a way of allowing either instead of cutting off options.
I am trying to discuss how to make the default behaviour the same as it was previously without losing access to the extra functionality.
The discussion is how to implement that.
That's a ) normal and b) absolutely ok. It's almost always about finding a compromise between different needs and wishes when it is about implementing new features.
This is exactly what expect (and want also).
The requirements were determined through "thousands of emails" to quote Enrico (again :-), that something was misunderstood has been acknowledged, constantly pointing things out with 20/20 hindsight is no help in defining a suitable solution.
Full ACK. We already noticed there were small communication problems (:D), anyway, just let's concentrate on how to make it better for the future.
To reiterate:
The build system does not do anything wrong, a dialog edits a different setting to what it used to and the build system does what that edit tells it to do.
I have suggested a change to the dialog that allows it to default to editing the settings as it used to so that the build system will behave as it used to, but still allows access to edit the other settings for those of us who want to use that functionality.
I'd prefer the checkbox, at least it'd be better than a combo box. I see why you suggested the combo box and it's rationale but just not nice. A checkbox next to the title is probably less intrusive and less diverting, I think.
Ok, I'll make a prototype with checkbox
Oops, found a crash ... fixed in SVN, prototype tomorrow (maybe).
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 Thu, 22 Oct 2009 20:26:20 +1100, Lex wrote:
Hi,
2009/10/18 Lex Trotman elextr@gmail.com:
Hi all,
I had a email directly from one of my colleagues who has been reading this thread and had a question about the project filetype execute commands.
Here is part of her email (project name obscured to protect the guilty :-)
This looked exactly like what we need for the XXX project where it has to still support Python 2.4.
Since most files are coded with "if __MAIN__ then:" test code for this module, we want to run both the individual file to run the test code and we want to run the overall application.
From what you said if I edited the project file directly we could have both a filetype dependant and a non-filetype dependant command for the project which ran Python2.4, and when that project was closed everything would use Python3 as usual, perfect!!
Unfortunately I can't get project filetype executes to work at all and looking at the code I can't see where they are handled.
This raised two points:
- the project filetypes execute commands code is missing completely,
I have it in an old version in my personal bazaar repository but it never made it into SVN.
- because we have more than one execute command is it possible for
one to be filetype dependent and one to be non-filetype dependent. In fact it is and it works fine when there is no project open, but as discussed previously the dialog won't edit the filetype ones at the moment.
for 1. I will fix it first since it is a pre-requisite for the suggested solution to 2., this may also allow some simplification of the implementation due to better consistency.
Done in SVN. Didn't get any simpler though :-)
for 2. I had never considered having mixed filetype/non-filetype commands, but as my colleague has said it is reasonable, and she has identified a use for it already, and it already works for non-project commands (I tested it with HEAD)
But it did cause me to think about how the dialog should work. After much thought I suggest (I'll keep it as short as possible Enrico so I won't mention any alternatives)
There are four sets of execute commands to edit, project vs non-project which is addressed by having separate dialogs and for all filetypes vs for a specific filetype which is to be addressed by the "unobtrusive" check box selecting which is being edited.
In line with current practice if any command is overridden by a higher priority one then the higher priority one is shown but it will be insensitive. This ensures that the dialogs always show what will appear on the build menu when ok is selected.
If you edit a setting and switch the checkbox, the edit is saved in temporary storage until OK is clicked, so you can flick between all filetypes and filetype specific settings as many time as you want.
I made a prototype of this dialog, its terrible, very confusing, hard to tell what you are editing.
So I have made a temporary change in SVN to make the dialog save to the fieltype execute command for the build menu->set build commands dialog. The project dialog still stores execute commands for all fieltypes. This is how it used to work.
I will now take some time to look at an alternative build-system configuration dialog.
Sorry for so few feedback, real-life is biting, as you know.
I see your colleagues use-case but also please remind that not every user has such special needs. The goal of Geany's build system always was to provide a simple way of quickly compiling/build/running the current file for quick testing, not to fulfil a whole build setting requirement. The current build system just went into another direction and I think more and more if we shouldn't move some parts out either into plugins or something else, just to get it more to the previous way where it was usable without hours of reading...
Don't get me wrong, it's great what you have done but I'm just in doubt whether this is what we want in Geany. But also I realise that I'm kind of late and so probably changing it isn't worth at all. No idea.
Regards, Enrico
Hi,
Sorry for so few feedback, real-life is biting, as you know.
Life, you've just got to live with it :-)
I see your colleagues use-case but also please remind that not every user has such special needs. The goal of Geany's build system always was to provide a simple way of quickly compiling/build/running the current file for quick testing, not to fulfil a whole build setting requirement. The current build system just went into another direction and I think more and more if we shouldn't move some parts out either into plugins or something else, just to get it more to the previous way where it was usable without hours of reading...
Don't get me wrong, it's great what you have done but I'm just in doubt whether this is what we want in Geany. But also I realise that I'm kind of late and so probably changing it isn't worth at all. No idea.
Well this raises the question of what Geany is intended to be. Quoting from the About Geany website:
1. Fast lightweight IDE (not just editor!) 2. Minimal dependencies 3. language independent 4. platform independent 5. not tied to particular tools or philosophies
Nowhere does it say that Geany is intended to only support simple developments. Perhaps its a surprise (hopefully pleasant :-) to you that people want to use your little IDE for large and/or complex developments. That is because Geany seems to target something different to Eclipse, Netbeans, Anjuta, KDE or plain editors.
So it is a concern that you seem to be expressing a desire to limit the capability to support complex software developments (if I misread your above sorry).
I totally agree with you that simple things should be simple to do, but complex things should still be possible, not limited.
The fact that the current UI doesn't meet the "simple things are simple to do" requirement is exactly why I am looking at it again, sometimes you just have to have other people try a UI before you find its hard to use.
As for implementing parts as plugins vs built-in, don't care, but I would have thought it was difficult for a plugin to add *flexibility* that isn't already in the Geany core.
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 Mon, 26 Oct 2009 10:33:08 +1100, Lex wrote:
Hi,
Sorry for so few feedback, real-life is biting, as you know.
Life, you've just got to live with it :-)
I see your colleagues use-case but also please remind that not every user has such special needs. The goal of Geany's build system always was to provide a simple way of quickly compiling/build/running the current file for quick testing, not to fulfil a whole build setting requirement. The current build system just went into another direction and I think more and more if we shouldn't move some parts out either into plugins or something else, just to get it more to the previous way where it was usable without hours of reading...
Don't get me wrong, it's great what you have done but I'm just in doubt whether this is what we want in Geany. But also I realise that I'm kind of late and so probably changing it isn't worth at all. No idea.
Well this raises the question of what Geany is intended to be. Quoting from the About Geany website:
- Fast lightweight IDE (not just editor!)
- Minimal dependencies
- language independent
- platform independent
- not tied to particular tools or philosophies
Nowhere does it say that Geany is intended to only support simple developments. Perhaps its a surprise (hopefully pleasant :-) to you that people want to use your little IDE for large and/or complex developments. That is because Geany seems to target something different to Eclipse, Netbeans, Anjuta, KDE or plain editors.
You are right, still my concern is exactly that we move more and more into the direction of Eclipse, Netbeans and the others. Ok, especially to the both mentioned we still have (luckily!) a long long way and hopefully will keep this way that long :).
So it is a concern that you seem to be expressing a desire to limit the capability to support complex software developments (if I misread your above sorry).
I totally agree with you that simple things should be simple to do, but complex things should still be possible, not limited.
The fact that the current UI doesn't meet the "simple things are simple to do" requirement is exactly why I am looking at it again, sometimes you just have to have other people try a UI before you find its hard to use.
Ok, this sounds like a plan. Give it some work and share it with us. I try hard to be more responsive and especially more open :). If not, come on over here and hit me :).
As for implementing parts as plugins vs built-in, don't care, but I would have thought it was difficult for a plugin to add *flexibility* that isn't already in the Geany core.
I agree, to some extend. It's a little bit of both, basic things should be included in the core, very specialised or really heavy things (like spellcheck or the Lua integration) should be done rather in a plugin. Well, now the question would be whether the new build system changes are basic enough for the core or as complex as that it would make more sense to outsource them into a plugin. I can't answer it but based on the fact that it is already in the core, moving it to a plugin probably make things only worse, at least moving the code into a plugin would cause lots of even more efforts which are probably better invested into further optimising and UI-improving :).
Regards, Enrico
On Mon, 26 Oct 2009 10:33:08 +1100 Lex Trotman elextr@gmail.com wrote:
Sorry for so few feedback, real-life is biting, as you know.
Life, you've just got to live with it :-)
As a Brit, obligatory Hitchhiker's quotes:
* "Life! Don't talk to me about life." o Marvin
* "It's funny how just when you think life just can't possibly get any worse it suddenly does. o Marvin
* "Life, loathe it or ignore it, you can't like it." o Marvin
From: http://en.wikiquote.org/wiki/Douglas_Adams#Life
And Monty Python of course: http://www.youtube.com/watch?v=jHPOzQzk9Qo&feature=fvste3
Regards, Nick
2009/10/27 Nick Treleaven nick.treleaven@btinternet.com:
On Mon, 26 Oct 2009 10:33:08 +1100 Lex Trotman elextr@gmail.com wrote:
Sorry for so few feedback, real-life is biting, as you know.
Life, you've just got to live with it :-)
As a Brit, obligatory Hitchhiker's quotes:
Not just as a Brit, Mr Adams (or St Douglas as he is known in the more relaxed civilisations on the Outer Eastern Rim of the Galaxy) has fans outside the small damp island off the coast of what is known as France on an utterly insignificant little blue green planet orbiting a small unregarded yellow sun far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy. o Adapted from the intro to "Hitch Hiker's Guide to the Galaxy"
* "Life! Don't talk to me about life." o Marvin
* "It's funny how just when you think life just can't possibly get any worse it suddenly does. o Marvin
* "Life, loathe it or ignore it, you can't like it." o Marvin
And him with this terrible pain in all the diodes down his left side. :-D
From: http://en.wikiquote.org/wiki/Douglas_Adams#Life
And Monty Python of course: http://www.youtube.com/watch?v=jHPOzQzk9Qo&feature=fvste3
Well he's just a very naughty boy!
Cheers Lex (or if thats too confusing then, Bruce and I'll call you Bruce just to keep it clear)
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
