Use wxPropGrid for compiler flags

[oBFusCATed]

In this branch https://github.com/obfuscated/codeblocks_sf/tree/compiler/propgrid

You can see the initial work to convert the compiler flags UI from wxCheckListBox to wxPropertyGrid.
Using wxPropGrid will allow us to have comboboxes and other advanced controls there.
At the moment I've recreated the old UI, so there are only checkboxes.

It is tested on linux only, with wx28. Someone should provide the changes for windows cbp files.
I've tried to retain all features of the old UI, so please test.

The only problem is that the minimal size of the dialog is smaller than before and I don't know how to fix it, so help in this regard is welcome.

Future additions:
1. I'd like to group -std, -O and -march options in single parameter. The -std and -march options could be implemented by grouping optons that start with -blabla=, but the -O options are more complicated.
2. I'd like to add another category "General", because the -std, -ansi and some other options are incorrectly group under the "Warnings" category. Is this safe to do?

Please test and comment...

Screen shot: http://cmpt.benbmp.org/codeblocks/screens/compiler.flags.propgrid.png

[MortenMacFly]

Nice one. But it what I don't like is the long way to the checkbox. You are easily getting lost and select the wrong option. Is it possible to have the checkbox on the left?
Probably not due to the plus sign if you have grouped parameters...

[oBFusCATed]

Is it possible to have the checkbox on the left?

No. I could probably make double click on the text to toggle the option.
If you don't want to get lost you can click on the option to see which one you'll select and then click on the checkbox.
I've just tried wx3.0 and there it requires two clicks, which is unpleasant. I try to see why is this happening.

Have you tried to compile it?

[stahta01]

Patch to get it to compile on Windows 32-bit.

Other than running it, I have done no testing.
Maybe, when I wake up tomorrow.

Tim S.

Code

diff --git a/src/CodeBlocks.cbp b/src/CodeBlocks.cbp
index 87e8d64..93af7bd 100644
--- a/src/CodeBlocks.cbp
+++ b/src/CodeBlocks.cbp
@@ -375,6 +375,7 @@
 					<Add library="codeblocks" />
 					<Add library="wxmsw$(WX_VERSION)$(WX_SUFFIX)" />
 					<Add library="depslib" />
+					<Add library="wxpropgrid" />
 					<Add directory="devel" />
 					<Add directory="plugins/compilergcc/depslib" />
 				</Linker>

Tim S.

[oBFusCATed]

Thank you.

[BlueHazzard]

it would be nice to have a search field, which filters the options. The search scope should be on the description (or name) and the flag. Some thing like the "find file" dialog.

greetings

[oBFusCATed]

This might be possible, but it is out of scope of the current modifications.
And if we can combine the CPU arch flags in a single setting the number of options would probably be halved.

[Alpha]

I have been browsing the source of this branch, and am in the process of some testing with it to see what wxPropGrid is capable of.

So far, your modifications seem to be quite helpful in readability of the compiler flags.

[oBFusCATed]

You can check the sample/propgrid in wxWidgets. It shows some of the features of propgird.

What we could (should) do is to merge some options (optimizations), cpu architecture, std in single choice property.
The main question is how to handle the xml format change?

[MortenMacFly]

Well to be backward compatible you could add an optional group attribute to each compiler flag. Then evaluate this at runtime...

[oBFusCATed]

Yes, I've thought about it, but I want to consult with Alpha who has done the original format.

[Alpha]

I agree that a 'group' attribute would work.  (And the files will remain backwards compatable.)

Code

    <Category name="CPU architecture tuning"
              exclusive="true"
              group="cpu_arch;7">
        <Option name="Intel i386"
                option="-march=i386"/>
        <Option name="Intel i486"
                option="-march=i486"/>
        <Option name="Intel Pentium"
                option="-march=i586"/>
        <Option name="Intel Pentium (MMX)"
                option="-march=pentium-mmx"/>
    </Category>

Code

    <Option name="Intel i386"
            option="-march=i386"
            group="cpu_arch;7"/>
    <Option name="Intel i486"
            option="-march=i486"
            group="cpu_arch;7;11"/>

The first part of the string is the group ID, and the second part, (optionally left blank), is the number of characters to skip from the beginning of the string ("-march=" in this case), the rest of which will go in the combo box.  (An optional third part is the can be specified to skip characters from the end of the string.)  Ideally, changing the combo box would update the label associated with the group of options.

We could consider extending the functionality, so that

Code

    <Option name="Tune for architecture $(CPU_ARCH)"
            option="-march=$(CPU_ARCH)"
            group="cpu_arch;7;free_form"/>
    <Option name="Tune for architecture $(CPU_ARCH)"
            option="-march=$(CPU_ARCH)"
            group="cpu_arch;7;18;free_form"/>

    <Option name="generate pre-compiled header (set PCH_FILE in custom variables)"
            option="-fh=$(PCH_FILE)"
            group="pch_file;4;free_form/>
    <Option name="set code group name (define CODEGROUP in custom variables)"
            option="-g=$(CODEGROUP)"
            group="3;free_form/>

would not show up in the combo box, but would instead make the combo box user editable.  (This remains backwards compatible, some compilers already have switches in that form.)  If there is only one item in a group, or the group name is omitted, then make the entry user editable text.

[oBFusCATed]

I don't like the index/skip-characters idea. I'd prefer to have make it something like ...group_id="cpu_arch" group_option="-march="...

Would it be a problem for you to document all the features for the xml files in a wiki page?
This way we can consider all option we have and what we can change and what we can't.

Also if we decide to break the compatibility can we automatically upgrade the files in the user's directory?

[MortenMacFly]

I don't see a reason for breaking compatibility. The only thing is that you could create groups by something like
<group name="FOO" flag="BAR">
<option>...</option>
<option>...</option>
</group>
...But IMHO there is no real benefit.

But I agree with Teodor that we should not need a parser for the flags. You can just create more flags with different names as needed, not combine them into a single one separated by semicolon...

[oBFusCATed]

The main benefit will be cleaner files for sure and less hacks needed:)