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

Martin lazarus at mfriebe.de
Tue Jun 11 01:12:44 CEST 2013


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
>>
>> And each radio (column) had a different color, that would only show if the radio is set.
>> Changing the radio, will change the order. That could be deferred, until the user ends editing the TArget.
> Does that mean the user can not see the final result until he closes
> and reopens the dialog?

  No, of course not.
Technically the entry can be sorted immediately, but that may be 
annoying to some. So maybe i is better to only move it, if you leave the 
row...
Then again, I have no problem if it moves immediately.

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

Then maybe a column with a numeric precedence?

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

Looking at this, I would still not guess the signify a precedence. Maybe 
there should be a numeric priority column? Then the grid could be sorted 
in different ways, if a user wants to find/compare things....


>> ---------------------------
>> Then the next thing is "Target", maybe that could be more descriptive
>> "Apply to packages:"
>> "Apply to project [x], packages: '*'"
>> "Options for project [x] and packages: '*'"
> Move the mouse over a target. The hint shows the targets as a
> descriptive sentence.
> At the moment you can edit the targets in place.
> A descriptive sentence can not be edited in place. How do you want to
> edit it?
You misunderstood.

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

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

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


>> With the storage as radio, if the grid is empty, an empty (dummy) "Target" could be displayed.
>>
>> Since the name of that line contains the description, users may realize that they can set options for packages.
>>





More information about the Lazarus mailing list