On 10/06/2013 23:36, Mattias Gaertner wrote:
On Mon, 10 Jun 2013 22:59:43 +0100
Martin <[email protected]> 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.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
