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

[Mattias Gaertner]

On Tue, 11 Jun 2013 00:12:44 +0100
Martin <lazarus at mfriebe.de> wrote:

> On 10/06/2013 23:36, Mattias Gaertner wrote:
> > On Mon, 10 Jun 2013 22:59:43 +0100
> > Martin <lazarus at mfriebe.de> wrote:
> >
> >> Within each target, the order would be kept.
> >> Instead of using a "in matrix group/header", each storage group could
> >> have a color
> >>
> >> If there where 3 radiobutton at the begin of each row
> >>
> >>     I | L | L  |  M | M
> >>     D | P | P  |  o | o
> >>     E | I | S  |  d | d
> >>       |   |    |  e | e
> >>       |   |    |  1 | 2
> >>     _______________
> >> / Targets: abc
> >> | * | o | o | [x] | [ ] | Custom -Cr
> >> | * | o | o | [x] | [ ] | Custom -Cr
> >> | o | * | o | [ ] | [x] | Custom -Cr
> >> | O | o | * | [x] | [x] | Custom -Cr
> >>
>[...]So maybe i is better to only move it, if you leave the 
> row...
> Then again, I have no problem if it moves immediately.

IMO it should immediately show the result.

 
> > 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.
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.


> All I understood was that they are displayed together, because they 
> share the same storage. There was/is no sign to me, that this also 
> indicates a priority/precedence.

The docs explain that the options are applied from top to bottom. IMO
that is a simple and intuitive rule.

 
> Then maybe a column with a numeric precedence?

IMHO that's less intuitive and over engineering.

 
> 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. 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.
To lessen the disruption we could give the columns a zebra background
and paint that background in the targets and storage rows too.

 
>[...]
> 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 | * |


> > Move the mouse over a target. The hint shows the targets as a
> > descriptive sentence.
> Too hidden, that info is way more important.

Yes. It was merely a hint that this sentence function already exists.

 
> 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.

 
>[...]

Mattias