Author Topic: Add UI to store default values and descriptions of global variables in project  (Read 1150 times)

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3255

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 654
Good work. I like this and where it is heading.

Some feedback on the Project "Global variables" tab GUI:
1. The stored column is not intuitive as to what it means.  When I first opened the GUI I thought it was that the global variables is not stored in the C::B default.config file.     After looking at the code it is for saving the info into the project file if it is ticked.
2. It may be an idea to include the currently selected global config set name some where. This will allow users to find where  the value is from.
3. The columns do not automatically expand to use up the full width of the dialog. Attached is a dialog capture showing the default loading.
      3a) The Used and stores columns could be made smaller in width
      3b) Tee Name column needs to be expanded to show/fit the text.
      3c) The Description could be swapped with the Default value so that it would make comparing the values easier.
      3d) The values and description should be expanded to fill the rest of the dialog width.
4. If there is a missing global variable (in the project file, but not in the config) then the GUI does not let you know this has happened.
    This is for trouble shooting.
5. I am confident that this is NOT part of this change, but conversely what about the other case where there a global variables defined in the default.confg, but not used.
6. I saved two variables and then modified the project file to add text for the descriptions and default values. I also added a non existent variable.
    I modified the project file while C::B was closed.
    On opening the C::B workspace the project file only showed the first variable changes..
    The info in the project file is:
        <GlobalVariables>
            <Variable name="#BOOST.INCLUDE" description="Boost include" default="1111.boost" />
            <Variable name="#CB_BUILD.CFLAGS" description="CodeBlocks build cflags" default="not here" />
            <Variable name="#ZZZ_FAIL" description="Fail desc" default="failing more" />
        </GlobalVariables>
7. In item 6) above the #ZZZ_FAIL variable is not in the project file and I was trying to see what was going to be shown in the GUI so the end user could see that there is a variable configured, but not used.



Some thoughts about the future use of global variables:

a) When you get to loading the default values into the default.config file then what happens when in one project file
the default is different to the default in another project file for the same global variable?

b) For workspace files that are made up of multiple project files (like the C::B workspace) then it would be nice
to have a similar GUI that shows all of the global variables used in all of the projects loaded so you can see all of them in one GUI.

I have also attached the global variables I use for my local builds.

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3255
Thank you for the fast feetback:
1) Yea, this is a huge problem, but i could not come up with a better name. I have to test if i can use new line in the header so i would call it "stored in project"? Any better idea for UI, naming?
2) Can do that.
3) Yea, i am not that familiar with wxWidgets so i have to look into it, was definitely on my todo list
4) This should already work over the "normal" global variables. When you load the project you should get a error message and the possibility to enter the variable. But i can add it somehow...
5) We do not know if the variable is used in a non loaded project, so why should be warn the user about it in this project?
6) This is a bug. Thanks i will fix it
7) The idea would be that "used" column should not be ticked, and probably in addition the row should be marked in yellow or red. But from 6. this seems to not work. Will have to look into it. Thanks!


a) I think this should simply be ignored. The default value should only be used if the variable is not defined. We probably could display it somehow in the global variable dialog, but i would not like to add some nagging UI for this. For example i use "ud" for compiling codeblocks. The default value would be "u" so i do  not want a error message every time i load he codeblocks project...
b) This could be added in a third step We probably could reuse this UI...

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 654
If you have a branch on your github https://github.com/bluehazzard/codeblocks_sf repo then I can pull the branch and test it when you want me to test the changes.

BTW I grabbed the rework/move_global_var_diag_to_src/1 branch yesterday and looked at it before I seen the ticket and post this morning (I am in Australia, +8hrs ahead of you at the moment as we have daylight saving, so in your winter I am 10 hrs ahead the same day).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9657
Sorry, but I am clearly against this patch. It spoils completely what global variables are for. Additionally it introduces ambiguity and unexpected behaviour.

What you have in mind can be achieved with environment variables instead and this functionality is already there. Including saving these settings in project files. Additionally, I have a patch pending that allows to manage environment variables at workspace level which may do what you want.

...unless you clearly specify a need that cannot be solved with existing options this patch will be rejected. Sorry.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7300
    • My Best Post
Additionally, I have a patch pending that allows to manage environment variables at workspace level which may do what you want.

Workspace level setting of environment variables sounds very good to me. Never thought of that solution.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3255
It is not intended to change behaviour of global variables.
It is intended to give the user a hint, what a global variable is and what the developer intended.

For example if you open the codeblocks project with a fresh installation the user is asked for two global variables: cb and wx31 (or whatever)
But the user has absolute no clue what to do with this variables or even with this dialog.

With this patch (this is only part one of a series of patches) the developer can store some information in the project file. For example it could store for the cb variable in the description field:
Quote
This variable is used to pass additional compiler flags to the build process of codeblocks. For example if you want to build a fast codeblocks installation pass -O3, but if you want build with debug information pass a -g to this variable
Now when the user opens the project file and codeblocks can not find the global variable 'cb' it will open a dialog with the description the developer provided.
If the variable is already defined nothing would happen. (Note that this described dialog is not part of this patch, i am currently working on it. This patch adds only the possibility for the developer to store additional description information to the project file)
 If the developer passes a default value this value will be suggested to the user. For the 'cb' variable the dev would provide -O3 and in the ask dialog -O3 would be provided. For the wx31 variable it would not make any sense to provide a default value, but you could provide a description what is like:
Quote
Point this path to installation directory of your wxWidgets 3.1 installation

[edit:]
Quote
Additionally it introduces ambiguity and unexpected behaviour.
Can you describe this a bit more? I can not find any ambiguity  or unexpected behaviour

« Last Edit: June 20, 2022, 08:49:24 pm by BlueHazzard »