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:)

[Alpha]

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.

Will do, as soon as I am able.

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

I thinks so, yes; however, it would be a one way (forwards only) conversion.

[oBFusCATed]

Alpha: any progress with the documentation?

I've added "double click to toggle" feature and want to push the initial implementation.
Any objections?

[Alpha]

Alpha: any progress with the documentation?

Oops, my apologies.  I completely forgot about this.  ...  Working on it now...

I've added "double click to toggle" feature and want to push the initial implementation.
Any objections?

I have not had a chance to test yet, but here is my personal opinion: wxPropGrid itself does not look the greatest (especially under some OS's/skins).  Because of this, I will some time in the future want to create my own custom panel (with grid sizers and individual components for dropdowns, checkboxes, labels, etc.).  With the way you have currently implemented it, do you think drop-in replacement would be possible in the future?

[oBFusCATed]

Are you sure you want to take this risky and dangerous path?
Writhing such control is quite serious endeavour.

I think it is better to improve wxPropGrid instead of doing another control from scratch.

In wx3.0 I think there is the list-tree control, but I've not used it and it will take one or two years until we can switch to wx3.0.

[Alpha]

Are you sure you want to take this risky and dangerous path?
Writhing such control is quite serious endeavour.

Not anytime soon, and perhaps never, if I come to like wxPropGrid.  But it is on the back of my mind.

Here is a draft of proposed updates for compiler options file.

[oBFusCATed]

I want to commit the current changes? Anyone against this move?

[BlueHazzard]

some nice additional feature would be to have a search/filter textctrl... You but in some words, and the PropertyGrid gets filtered with the entered string...

I think eclipse has something similar with the settings, and this is very useful...

[SteelRat]

I want to commit the current changes? Anyone against this move?

When are you going to commit propgrid? I can't wait. =)

[oBFusCATed]

At the end of the week, but are you sure what feature we are talking about here?

[SteelRat]

As I understand it will help me to create more flexible Android compiler XML.

[oBFusCATed]

Nope it will just present the options in a better ui and it will allow for future improvements.

[SteelRat]

There will be comboboxes for single choice?

[oBFusCATed]

Not with this commit... hopefully in the future.

[MortenMacFly]

I want to commit the current changes? Anyone against this move?

If it works, no. :-)

[oBFusCATed]

Done.... Test, report errors and post patches with enhancements :>)

[ollydbg]

Nice work!
I'm on WinXP, and I think the node text should be much darker. Currently it is a little light, see screen shot below.

[oBFusCATed]

This is how wxpropgrid draws them... I don't see why this is a problem?
The idea is probably to be less distracting than the real valuable information in the members of the category.

[TheRaven]

This is how wxpropgrid draws them... I don't see why this is a problem?
The idea is probably to be less distracting than the real valuable information in the members of the category.

Old post, but an on going dilemma...
The labels must contrast against any background color for accessibility purposes for those whom endure visual impairments. I have photosensitive eyes and am red-green color blind, but will program for the challenges regardless. I am not jumping your case oBFusCATed just enlightening anyone who reads this thread in the future.
 

[oBFusCATed]

TheRaven: Do you see the text or not? It is not clear from your post?