Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: stahta01 on October 06, 2018, 02:57:59 am
-
Where could I add option to disable auto compiler detection?
I am thinking a check box that defaults to checked in
Setting -> Environment
Inside the "On Application Start-up" box/area
Is there a better place?
Tim S.
-
If it belongs to compiler plugin, is it possible to put in the compiler setting dialog? (in Menu->Settings->Compiler)
-
If it belongs to compiler plugin, is it possible to put in the compiler setting dialog? (in Menu->Settings->Compiler)
Do you mean adding another icon in the left hand box the holds "Batch Builds" and "Global Compiler Settings"?
Or do you mean somewhere in the "Global Compiler Settings"?
Tim S.
-
Why do you want to do it in the first place?
-
Why do you want to do it in the first place?
I dislike the feature and wish to submit a patch to allow a person to disable it.
I currently have a project that stores the CB config used with in an git repo; and, the config changes differently on both of the Windows computer I use it on.
Tim S.
-
I dislike the feature and wish to submit a patch to allow a person to disable it.
Not sure this is a valid reason to introduce more options.
Storing config files is not a good idea!
-
Not sure this is a valid reason to introduce more options.
What is it with your obsession about configuration options? Options are userfriendly...
I see the reason for such a option....
How about no UI and only a line in the config file? Advanced user can modify the config file and there is no entry that clutters the UI. The code changes are minimal (probably 2 lines?).
I have no idea where such a option should go... There is no "general compiler" options entry in any UI...
-
What is it with your obsession about configuration options?
I, as a user, don't want to tweak stuff. I want it to work out-of-the-box.
Also maintaining is easier if there are smaller number of different code paths.
Options are userfriendly...
No they are not. They are unfriendly and a competing project with less options would be considered user friendlier.
Hidden options are even less useful, because they will be used only by the person who requested them. So the added maintenance cost is less justified.
-
I, as a user, don't want to tweak stuff. I want it to work out-of-the-box.
For this you have to set reasonable defaults. But don't degrade ALL user to an blob of incapable noobs, and cripple the software to exactly one predefined path...
i see the maintaining point, but not for things that are literally one or two lines of code that make no branches.
this will be my last post to the settings topic, i know your point, and you know mine and i don't think we come to one point ;)