[Lazarus] New compiler options page "Additions and Overrides"

[Martin]

On 11/06/2013 09:28, Mattias Gaertner wrote:
>>> And I don't see how the users can see that the storage takes higher
>>> precedence than the targets. Can you give an example for two targets?
>> My idea came from the understanding I got from initial layout. And that
>> did NOT include recognising the precedence.
> Maybe you misunderstood me. The storage encloses its targets. Each
> storage exists only once and can not be moved.
Yes, I understand that from what you wrote.

At the moment the storage is displayed as an enclosure. Technically I 
still do not see it as such.
It is an attribute to al the rows in it.
- The attribute is not stored as value, but derived from where the data 
is (but that is internals)
- The attribute also enforces a place (range) in the precedence list

> The targets are not really a group. Internally a target is merely a
> property of an option. But a target does not fit into a cell, it needs
> a line of space and most targets are the same I show them as groups.
That is ok

>> Another idea: do not put the storage as a row header: have it as a fixed
>> column:
>>
>> ________________
>> |IDE | /Target
>> |    |   [x]  [ ]  Custom
>> |    | /Target
>> |____|   [x]  [ ]  Custom
>> |LPI | /Target
>> |    |   [ ]  [x]  Custom
>> ....
>>
>> Then it is less disrupting to the checkbox columns
> The targets interrupts them already.
Yes, I know. But to the user (at least to me, and by that with all 
likelihood to at least some others) the target is more group-like than 
the storage-place

> A broader column means less space
> for the modes and options. The abbreviations IDE,LPI and LPS are not as
> clear as a sentence. It's not one grid, there are three, so some
> disruption is needed.
At the moment the grid usus a lot more vertical than horizontal space.  
If a user has so many build modes that horizontal space becomes so 
valuable that a 3 letter column is an issue, then he also will have the 
same issue in vertical direction (unless all the buildmodes are unused). 
To make a useful buildmode, it mus have options that differ from the 
other modes, therefore the amount of rows will be similar big.

Why should it be 3 grids. The options apply to the project/packages, 
never mind where they are stored.
See above, storage is an attribute. I agree for the need to make it 
distinguishable, because of the effects on e.g. other team members, if 
it is stored in e.g. the lpk.
The left most column will give a clear enough indication.

The "Stored in" part of the sentence goes into the header.
The words IDE,LPK and LPS (or abbreviations Glob, Proj, Sess)  can be 
explained in a hint, or at the bottom of the page. Or an icon con be used.

> To lessen the disruption we could give the columns a zebra background
> and paint that background in the targets and storage rows too.
That maybe ok. But I still think the disruption by extra rows should be 
avoided.

>> [...]
>> In the simplest case, it still has 2 columns (like now): Name and value.
>> The name changes from "Target" to "Options for project and packages"
>> The value is still * or Foo,Bar
>> I would prefer, the project to be a checkbox, and the packages a match
>> string (editable in place).
> Do you mean:
> | Options for project and packages | project: X | * |

Something like that yes. (if the "X" is a checkbox)

The checkbox, can also go earlier, making it 4 columns:

| Options for project | [X] | and packages | * |


>> Also an empty grid should always have one target present. Even, if the
>> target has NO options at all. So the info that you can add options to
>> packages, is *always* visible.
>>
>> If you always have all 3 storage sections , then maybe a empty "target"
>> in each....
> That could be done.
> Empty targets are not stored.
just an other thought an this. The empty "target" line could be painted 
in grey (low-lighted)


>> Then maybe a column with a numeric precedence?
> IMHO that's less intuitive and over engineering.

True, except if the rows will be sortable by other columns too.

As a User I may want to see:
- all OutDir or IdeMacro together (even if that mixes options from diff 
storages)
- all Options with the same Target (though that depends how many 
overlapping targets I have)

Of course that maybe better be done using filters.