6:10 a.m.
Hi,
Please review/comment on the Custom Properties Sheet feature page:
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
----
Thanks,
Einav
6:32 a.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Gilad Chaplik" <gchaplik(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>, "Miki Kenneth"
<mkenneth(a)redhat.com>, "Simon Grinberg" <sgrinber(a)redhat.com>,
"Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
Hildesheim" <info(a)eldanet.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, May 17, 2012 8:10:50 AM
Subject: custom properties sheet feature page
Hi,
Please review/comment on the Custom Properties Sheet feature page:
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
It looks great.
Are all the keys going to be exposed in the dropdown, or will we have private keys that
the user has to know about?
----
Thanks,
Einav
7:08 a.m.
----- Original Message -----
From: "Andrew Cathrow" <acathrow(a)redhat.com>
Sent: Thursday, May 17, 2012 3:32:05 PM
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Gilad Chaplik" <gchaplik(a)redhat.com>, "Andrew
Cathrow"
> <acathrow(a)redhat.com>, "Miki Kenneth"
> <mkenneth(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>,
> "Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
> Hildesheim" <info(a)eldanet.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, May 17, 2012 8:10:50 AM
> Subject: custom properties sheet feature page
>
> Hi,
>
> Please review/comment on the Custom Properties Sheet feature page:
> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
>
It looks great.
Are all the keys going to be exposed in the dropdown, or will we have
private keys that the user has to know about?
All keys will be exposed; not sure what you mean by "private", but all keys are
treated the same today.
If we want some kind of differentiation between the keys, it is a another feature...
[I could, of course, be missing something, please clarify if I did]
> ----
> Thanks,
> Einav
>
7:23 a.m.
----- Original Message -----
> > > >
> > ----
> > > Thanks,
> > > Einav
> > >
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Gilad Chaplik" <gchaplik(a)redhat.com>,
"Miki Kenneth" <mkenneth(a)redhat.com>, "Simon
Grinberg" <sgrinber(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "Eldan Hildesheim" <info(a)eldanet.com>
Sent: Thursday, May 17, 2012 9:08:10 AM
Subject: Re: custom properties sheet feature page
> ----- Original Message -----
> From: "Andrew Cathrow" <acathrow(a)redhat.com>
> Sent: Thursday, May 17, 2012 3:32:05 PM
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Gilad Chaplik" <gchaplik(a)redhat.com>, "Andrew
Cathrow"
> > <acathrow(a)redhat.com>, "Miki Kenneth"
> > <mkenneth(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>,
> > "Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
> > Hildesheim" <info(a)eldanet.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Thursday, May 17, 2012 8:10:50 AM
> > Subject: custom properties sheet feature page
> > > Hi,
> > > Please review/comment on the Custom Properties
Sheet feature
> > page:
> > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > It looks great.
> Are all the keys going to be exposed in the dropdown, or will we
> have
> private keys that the user has to know about?
All keys will be exposed; not sure what you mean by "private", but
all keys are treated the same today.
if we're exposing all (which is preferable) then it's perfect.
If we want some kind of differentiation between the keys, it is a
another feature...
[I could, of course, be missing something, please clarify if I did]
4:50 p.m.
On 05/17/2012 04:08 PM, Einav Cohen wrote:
...
>> Hi,
>>
>> Please review/comment on the Custom Properties Sheet feature page:
>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
>>
>
> It looks great.
> Are all the keys going to be exposed in the dropdown, or will we have
> private keys that the user has to know about?
All keys will be exposed; not sure what you mean by "private", but all keys are
treated the same today.
If we want some kind of differentiation between the keys, it is a another feature...
[I could, of course, be missing something, please clarify if I did]
in the future, we may want to give permissions to which users are
allowed to use which custom properties.
not relevant for now.
9:53 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Andrew Cathrow" <acathrow(a)redhat.com>, "Eldan Hildesheim"
<info(a)eldanet.com>, engine-devel(a)ovirt.org, "Simon
Grinberg" <sgrinber(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>
Sent: Friday, May 18, 2012 1:50:17 AM
Subject: Re: [Engine-devel] custom properties sheet feature page
On 05/17/2012 04:08 PM, Einav Cohen wrote:
...
>>> Hi,
>>>
>>> Please review/comment on the Custom Properties Sheet feature
>>> page:
>>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
>>>
>>
>> It looks great.
>> Are all the keys going to be exposed in the dropdown, or will we
>> have
>> private keys that the user has to know about?
>
> All keys will be exposed; not sure what you mean by "private", but
> all keys are treated the same today.
> If we want some kind of differentiation between the keys, it is a
> another feature...
> [I could, of course, be missing something, please clarify if I did]
>
in the future, we may want to give permissions to which users are
allowed to use which custom properties.
not relevant for now.
Is this cool looking design be also available from the user portal?
If so how do you prevent any user that just have permission to Edit VMs to do damage? With
custom property you can do almost anything.
Consider the case where there is a hook that allows to directly attach a LUN/Add Tap/more
destructive options. It is intended for use of the sys admins but any user can use.
You would say correctly that this was always the case. But with the old textbox interface
the user would need to know that the option exists. Now we actually tell him what he can
use.
Cool for the webadmin / kind'a dangerous from the user portal until you get
permissions per users feature for it.
The minimum that is needed is an option to disable this properties tab in the user
portal.
Better have MLA for using properties at all if per property can't be accommodated.
9:58 a.m.
----- Original Message -----
From: "Simon Grinberg" <simon(a)redhat.com>
Sent: Wednesday, May 23, 2012 6:53:46 PM
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "Andrew Cathrow" <acathrow(a)redhat.com>, "Eldan
Hildesheim"
> <info(a)eldanet.com>, engine-devel(a)ovirt.org, "Simon
> Grinberg" <sgrinber(a)redhat.com>, "Eldan Hildesheim"
> <ehildesh(a)redhat.com>
> Sent: Friday, May 18, 2012 1:50:17 AM
> Subject: Re: [Engine-devel] custom properties sheet feature page
>
> On 05/17/2012 04:08 PM, Einav Cohen wrote:
> ...
> >>> Hi,
> >>>
> >>> Please review/comment on the Custom Properties Sheet feature
> >>> page:
> >>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> >>>
> >>
> >> It looks great.
> >> Are all the keys going to be exposed in the dropdown, or will we
> >> have
> >> private keys that the user has to know about?
> >
> > All keys will be exposed; not sure what you mean by "private",
> > but
> > all keys are treated the same today.
> > If we want some kind of differentiation between the keys, it is a
> > another feature...
> > [I could, of course, be missing something, please clarify if I
> > did]
> >
>
> in the future, we may want to give permissions to which users are
> allowed to use which custom properties.
> not relevant for now.
Is this cool looking design be also available from the user portal?
custom properties aren't available in the user portal.
If so how do you prevent any user that just have permission to Edit
VMs to do damage? With custom property you can do almost anything.
Consider the case where there is a hook that allows to directly
attach a LUN/Add Tap/more destructive options. It is intended for
use of the sys admins but any user can use.
You would say correctly that this was always the case. But with the
old textbox interface the user would need to know that the option
exists. Now we actually tell him what he can use.
Cool for the webadmin / kind'a dangerous from the user portal until
you get permissions per users feature for it.
The minimum that is needed is an option to disable this properties
tab in the user portal.
Better have MLA for using properties at all if per property can't be
accommodated.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
6:40 a.m.
Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
Hi,
Please review/comment on the Custom Properties Sheet feature page:
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
Just my $0.02:
The table could have always empty row at the bottom, eliminating one or
all [+] buttons and saving user one needless click:
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [-]
[ "please select a key..." |v]
The [+] buttons at first and second rows would allow user to insert a
row at specified location to make easy custom sorting of the properties
(not applicable if properties are auto-sorted, in that case, all [+]
buttons can be actually removed).
David
----
Thanks,
Einav
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
7:30 a.m.
----- Original Message -----
From: "David Jaša" <djasa(a)redhat.com>
Sent: Thursday, May 17, 2012 3:40:19 PM
Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
> Hi,
>
> Please review/comment on the Custom Properties Sheet feature page:
> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
>
Just my $0.02:
The table could have always empty row at the bottom, eliminating one
or
all [+] buttons and saving user one needless click:
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [-]
[ "please select a key..." |v]
The [+] buttons at first and second rows would allow user to insert a
row at specified location to make easy custom sorting of the
properties
(not applicable if properties are auto-sorted, in that case, all [+]
buttons can be actually removed).
Thanks for the input, David. This is an interesting idea.
Indeed, when choosing a key in the last row, we can automatically add a new "please
select a key..." row, which actually saves the user a button-click for adding a new
row.
On the other hand, from graphic-design point of view, it will look more consistent and
"pretty" if:
- The "please select a key..." row won't be displayed (unless, or course,
the user explicitly chose to add another row)
- All (full) rows will have both [+] and [-] buttons next to them
i.e., instead of your suggestion, which looks like this:
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [-]
[ "please select a key..." |v]
it will be "prettier" like this:
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [+] [-]
and only if clicking on [+], it will be:
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [+] [-]
[ "please select a key..." |v]
I believe that auto-sorting can be confusing, as it can result in rows "jumping"
up and down whenever changing the selection(s) in the Key drop-down(s), therefore I
don't think it is a good idea to implement it here.
David
> ----
> Thanks,
> Einav
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:44 a.m.
Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> ----- Original Message -----
> From: "David Jaša" <djasa(a)redhat.com>
> Sent: Thursday, May 17, 2012 3:40:19 PM
>
> Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
> > Hi,
> >
> > Please review/comment on the Custom Properties Sheet feature page:
> > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> >
>
> Just my $0.02:
>
> The table could have always empty row at the bottom, eliminating one
> or
> all [+] buttons and saving user one needless click:
>
> [ key1 |v] [ value ] [+] [-]
> [ key2 |v] [ value ] [+] [-]
> [ key3 |v] [ value ] [-]
> [ "please select a key..." |v]
>
> The [+] buttons at first and second rows would allow user to insert a
> row at specified location to make easy custom sorting of the
> properties
> (not applicable if properties are auto-sorted, in that case, all [+]
> buttons can be actually removed).
Thanks for the input, David. This is an interesting idea.
Indeed, when choosing a key in the last row, we can automatically add a new "please
select a key..." row, which actually saves the user a button-click for adding a new
row.
On the other hand, from graphic-design point of view, it will look more consistent and
"pretty" if:
- The "please select a key..." row won't be displayed (unless, or course,
the user explicitly chose to add another row)
- All (full) rows will have both [+] and [-] buttons next to them
If the [+] button in my proposal is just greyed out instead of ommited,
it could satisfy both requirements.
i.e., instead of your suggestion, which looks like this:
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [-]
[ "please select a key..." |v]
it will be "prettier" like this:
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [+] [-]
and only if clicking on [+], it will be:
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [+] [-]
[ "please select a key..." |v]
I believe that auto-sorting can be confusing, as it can result in rows
"jumping" up and down whenever changing the selection(s) in the Key
drop-down(s),
this could be sort of mitigated by sorting server-side upon
modification.
therefore I don't think it is a good idea to implement it here.
OTOH if we're to be manual sorting friendly, we should allow rearranging
of the rows by drag & drop or by some sort of move up/down buttons and
the dialog would start to be cluttered.
I don't really like either of these but auto-sort is slightly better IMO
as it is kept consistent accross various VMs without user interaction.
David
>
> David
>
> > ----
> > Thanks,
> > Einav
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> --
>
> David Jaša, RHCE
>
> SPICE QE based in Brno
> GPG Key: 22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
8:14 a.m.
----- Original Message -----
From: "David Jaša" <djasa(a)redhat.com>
Sent: Thursday, May 17, 2012 4:44:10 PM
Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> > ----- Original Message -----
> > From: "David Jaša" <djasa(a)redhat.com>
> > Sent: Thursday, May 17, 2012 3:40:19 PM
> >
> > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
> > > Hi,
> > >
> > > Please review/comment on the Custom Properties Sheet feature
> > > page:
> > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > >
> >
> > Just my $0.02:
> >
> > The table could have always empty row at the bottom, eliminating
> > one
> > or
> > all [+] buttons and saving user one needless click:
> >
> > [ key1 |v] [ value ] [+] [-]
> > [ key2 |v] [ value ] [+] [-]
> > [ key3 |v] [ value ] [-]
> > [ "please select a key..." |v]
> >
> > The [+] buttons at first and second rows would allow user to
> > insert a
> > row at specified location to make easy custom sorting of the
> > properties
> > (not applicable if properties are auto-sorted, in that case, all
> > [+]
> > buttons can be actually removed).
>
> Thanks for the input, David. This is an interesting idea.
>
> Indeed, when choosing a key in the last row, we can automatically
> add a new "please select a key..." row, which actually saves the
> user a button-click for adding a new row.
>
> On the other hand, from graphic-design point of view, it will look
> more consistent and "pretty" if:
> - The "please select a key..." row won't be displayed (unless, or
> course, the user explicitly chose to add another row)
> - All (full) rows will have both [+] and [-] buttons next to them
If the [+] button in my proposal is just greyed out instead of
ommited,
it could satisfy both requirements.
Almost; the "please select a key..." row is still always displayed; question is
if we want to save a button-click (your suggestion) or to have a "cleaner" sheet
(my suggestion).
>
> i.e., instead of your suggestion, which looks like this:
>
> [ key1 |v] [ value ] [+] [-]
> [ key2 |v] [ value ] [+] [-]
> [ key3 |v] [ value ] [-]
> [ "please select a key..." |v]
>
> it will be "prettier" like this:
>
> [ key1 |v] [ value ] [+] [-]
> [ key2 |v] [ value ] [+] [-]
> [ key3 |v] [ value ] [+] [-]
>
> and only if clicking on [+], it will be:
>
> [ key1 |v] [ value ] [+] [-]
> [ key2 |v] [ value ] [+] [-]
> [ key3 |v] [ value ] [+] [-]
> [ "please select a key..." |v]
>
> I believe that auto-sorting can be confusing, as it can result in
> rows "jumping" up and down whenever changing the selection(s) in
> the Key drop-down(s),
this could be sort of mitigated by sorting server-side upon
modification.
> therefore I don't think it is a good idea to implement it here.
OTOH if we're to be manual sorting friendly, we should allow
rearranging
of the rows by drag & drop or by some sort of move up/down buttons
and
the dialog would start to be cluttered.
I don't really like either of these but auto-sort is slightly better
IMO
as it is kept consistent accross various VMs without user
interaction.
Indeed, auto-sort will keep the order consistent across all VMs.
However, maybe the user would like to see the properties in the order in which he filled
them; in this case, your suggestion of "move up/down buttons" is probably
relevant here.
I believe that the majority of use-cases won't require more than 2 or 3 custom
properties per VM, so sorting won't be that critical, therefore I assume we can start
without it; I will add "sorting" to the "open issues" section in the
wiki page.
David
>
> >
> > David
> >
> > > ----
> > > Thanks,
> > > Einav
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> > --
> >
> > David Jaša, RHCE
> >
> > SPICE QE based in Brno
> > GPG Key: 22C33E24
> > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> >
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
2:33 a.m.
Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> ----- Original Message -----
> From: "David Jaša" <djasa(a)redhat.com>
> Sent: Thursday, May 17, 2012 4:44:10 PM
>
> Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> > > ----- Original Message -----
> > > From: "David Jaša" <djasa(a)redhat.com>
> > > Sent: Thursday, May 17, 2012 3:40:19 PM
> > >
> > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
> > > > Hi,
> > > >
> > > > Please review/comment on the Custom Properties Sheet feature
> > > > page:
> > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > >
> > >
> > > Just my $0.02:
> > >
> > > The table could have always empty row at the bottom, eliminating
> > > one
> > > or
> > > all [+] buttons and saving user one needless click:
> > >
> > > [ key1 |v] [ value ] [+] [-]
> > > [ key2 |v] [ value ] [+] [-]
> > > [ key3 |v] [ value ] [-]
> > > [ "please select a key..." |v]
> > >
> > > The [+] buttons at first and second rows would allow user to
> > > insert a
> > > row at specified location to make easy custom sorting of the
> > > properties
> > > (not applicable if properties are auto-sorted, in that case, all
> > > [+]
> > > buttons can be actually removed).
> >
> > Thanks for the input, David. This is an interesting idea.
> >
> > Indeed, when choosing a key in the last row, we can automatically
> > add a new "please select a key..." row, which actually saves the
> > user a button-click for adding a new row.
> >
> > On the other hand, from graphic-design point of view, it will look
> > more consistent and "pretty" if:
> > - The "please select a key..." row won't be displayed (unless,
or
> > course, the user explicitly chose to add another row)
> > - All (full) rows will have both [+] and [-] buttons next to them
I should have probably elaborated more on this. To me, UI with less
elements looks cleaner and prettier even when one of them stands out.
There's also nothing wrong with standing out if the element has
"special" meaning (one add vs bunch of modify).
Specifically, this looks cleaner to my eyes:
[ key1 |v] [ value ] [-]
[ key2 |v] [ value ] [-]
[ key3 |v] [ value ] [-]
[ "Please select a key..." |v]
than
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [+] [-]
>
> If the [+] button in my proposal is just greyed out instead of
> ommited,
> it could satisfy both requirements.
Almost; the "please select a key..." row is still always displayed; question is
if we want to save a button-click (your suggestion) or to have a "cleaner" sheet
(my suggestion).
>
> >
> > i.e., instead of your suggestion, which looks like this:
> >
> > [ key1 |v] [ value ] [+] [-]
> > [ key2 |v] [ value ] [+] [-]
> > [ key3 |v] [ value ] [-]
> > [ "please select a key..." |v]
> >
> > it will be "prettier" like this:
> >
> > [ key1 |v] [ value ] [+] [-]
> > [ key2 |v] [ value ] [+] [-]
> > [ key3 |v] [ value ] [+] [-]
> >
> > and only if clicking on [+], it will be:
> >
> > [ key1 |v] [ value ] [+] [-]
> > [ key2 |v] [ value ] [+] [-]
> > [ key3 |v] [ value ] [+] [-]
> > [ "please select a key..." |v]
> >
> > I believe that auto-sorting can be confusing, as it can result in
> > rows "jumping" up and down whenever changing the selection(s) in
> > the Key drop-down(s),
>
> this could be sort of mitigated by sorting server-side upon
> modification.
>
> > therefore I don't think it is a good idea to implement it here.
>
> OTOH if we're to be manual sorting friendly, we should allow
> rearranging
> of the rows by drag & drop or by some sort of move up/down buttons
> and
> the dialog would start to be cluttered.
>
> I don't really like either of these but auto-sort is slightly better
> IMO
> as it is kept consistent accross various VMs without user
> interaction.
Indeed, auto-sort will keep the order consistent across all VMs.
However, maybe the user would like to see the properties in the order in which he filled
them; in this case, your suggestion of "move up/down buttons" is probably
relevant here.
I believe that the majority of use-cases won't require more than 2 or 3 custom
properties per VM, so sorting won't be that critical, therefore I assume we can start
without it; I will add "sorting" to the "open issues" section in the
wiki page.
That seems as more argument in favor of auto sorting.
David
>
> David
>
> >
> > >
> > > David
> > >
> > > > ----
> > > > Thanks,
> > > > Einav
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > > --
> > >
> > > David Jaša, RHCE
> > >
> > > SPICE QE based in Brno
> > > GPG Key: 22C33E24
> > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> > >
> > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
>
> --
>
> David Jaša, RHCE
>
> SPICE QE based in Brno
> GPG Key: 22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
>
>
>
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
3:12 a.m.
----- Original Message -----
From: "David Jaša" <djasa(a)redhat.com>
Sent: Friday, May 18, 2012 11:33:44 AM
Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> > ----- Original Message -----
> > From: "David Jaša" <djasa(a)redhat.com>
> > Sent: Thursday, May 17, 2012 4:44:10 PM
> >
> > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> > > > ----- Original Message -----
> > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > Sent: Thursday, May 17, 2012 3:40:19 PM
> > > >
> > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
> > > > > Hi,
> > > > >
> > > > > Please review/comment on the Custom Properties Sheet
> > > > > feature
> > > > > page:
> > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > >
> > > >
> > > > Just my $0.02:
> > > >
> > > > The table could have always empty row at the bottom,
> > > > eliminating
> > > > one
> > > > or
> > > > all [+] buttons and saving user one needless click:
> > > >
> > > > [ key1 |v] [ value ] [+] [-]
> > > > [ key2 |v] [ value ] [+] [-]
> > > > [ key3 |v] [ value ] [-]
> > > > [ "please select a key..." |v]
> > > >
> > > > The [+] buttons at first and second rows would allow user to
> > > > insert a
> > > > row at specified location to make easy custom sorting of the
> > > > properties
> > > > (not applicable if properties are auto-sorted, in that case,
> > > > all
> > > > [+]
> > > > buttons can be actually removed).
> > >
> > > Thanks for the input, David. This is an interesting idea.
> > >
> > > Indeed, when choosing a key in the last row, we can
> > > automatically
> > > add a new "please select a key..." row, which actually saves
> > > the
> > > user a button-click for adding a new row.
> > >
> > > On the other hand, from graphic-design point of view, it will
> > > look
> > > more consistent and "pretty" if:
> > > - The "please select a key..." row won't be displayed
(unless,
> > > or
> > > course, the user explicitly chose to add another row)
> > > - All (full) rows will have both [+] and [-] buttons next to
> > > them
I should have probably elaborated more on this. To me, UI with less
elements looks cleaner and prettier even when one of them stands out.
There's also nothing wrong with standing out if the element has
"special" meaning (one add vs bunch of modify).
Specifically, this looks cleaner to my eyes:
[ key1 |v] [ value ] [-]
[ key2 |v] [ value ] [-]
[ key3 |v] [ value ] [-]
[ "Please select a key..." |v]
than
[ key1 |v] [ value ] [+] [-]
[ key2 |v] [ value ] [+] [-]
[ key3 |v] [ value ] [+] [-]
Note that in your suggestion above, you cannot insert a new key in between existing keys -
only at the end; so
although "cleaner", it has less functionality (depends also on the sorting,
which is another issue; if there is auto-sorting, it doesn't matter).
It is also a matter of taste, I guess, so no absolute right or wrong here IMO.
[Others - you are welcome to comment as well]
> >
> > If the [+] button in my proposal is just greyed out instead of
> > ommited,
> > it could satisfy both requirements.
>
> Almost; the "please select a key..." row is still always displayed;
> question is if we want to save a button-click (your suggestion) or
> to have a "cleaner" sheet (my suggestion).
>
> >
> > >
> > > i.e., instead of your suggestion, which looks like this:
> > >
> > > [ key1 |v] [ value ] [+] [-]
> > > [ key2 |v] [ value ] [+] [-]
> > > [ key3 |v] [ value ] [-]
> > > [ "please select a key..." |v]
> > >
> > > it will be "prettier" like this:
> > >
> > > [ key1 |v] [ value ] [+] [-]
> > > [ key2 |v] [ value ] [+] [-]
> > > [ key3 |v] [ value ] [+] [-]
> > >
> > > and only if clicking on [+], it will be:
> > >
> > > [ key1 |v] [ value ] [+] [-]
> > > [ key2 |v] [ value ] [+] [-]
> > > [ key3 |v] [ value ] [+] [-]
> > > [ "please select a key..." |v]
> > >
> > > I believe that auto-sorting can be confusing, as it can result
> > > in
> > > rows "jumping" up and down whenever changing the selection(s)
> > > in
> > > the Key drop-down(s),
> >
> > this could be sort of mitigated by sorting server-side upon
> > modification.
> >
> > > therefore I don't think it is a good idea to implement it
> > > here.
> >
> > OTOH if we're to be manual sorting friendly, we should allow
> > rearranging
> > of the rows by drag & drop or by some sort of move up/down
> > buttons
> > and
> > the dialog would start to be cluttered.
> >
> > I don't really like either of these but auto-sort is slightly
> > better
> > IMO
> > as it is kept consistent accross various VMs without user
> > interaction.
>
> Indeed, auto-sort will keep the order consistent across all VMs.
> However, maybe the user would like to see the properties in the
> order in which he filled them; in this case, your suggestion of
> "move up/down buttons" is probably relevant here.
>
> I believe that the majority of use-cases won't require more than 2
> or 3 custom properties per VM, so sorting won't be that critical,
> therefore I assume we can start without it; I will add "sorting"
> to the "open issues" section in the wiki page.
>
That seems as more argument in favor of auto sorting.
Or no sorting at all (i.e. simply display in order of filling)...
In any case, open issue has been added to the wiki.
David
> >
> > David
> >
> > >
> > > >
> > > > David
> > > >
> > > > > ----
> > > > > Thanks,
> > > > > Einav
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel(a)ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > > --
> > > >
> > > > David Jaša, RHCE
> > > >
> > > > SPICE QE based in Brno
> > > > GPG Key: 22C33E24
> > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > 3E24
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > >
> > > >
> >
> > --
> >
> > David Jaša, RHCE
> >
> > SPICE QE based in Brno
> > GPG Key: 22C33E24
> > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> >
> >
> >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3:25 a.m.
inline
Thanks,
Gilad.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "David Jaša" <djasa(a)redhat.com>, "Miki Kenneth"
<mkenneth(a)redhat.com>, "Andrew Cathrow" <acathrow(a)redhat.com>,
"Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "Eldan Hildesheim"
<info(a)eldanet.com>, "Gilad Chaplik" <gchaplik(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Friday, May 18, 2012 12:12:54 PM
Subject: Re: [Engine-devel] custom properties sheet feature page
> ----- Original Message -----
> From: "David Jaša" <djasa(a)redhat.com>
> Sent: Friday, May 18, 2012 11:33:44 AM
>
> Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> > > ----- Original Message -----
> > > From: "David Jaša" <djasa(a)redhat.com>
> > > Sent: Thursday, May 17, 2012 4:44:10 PM
> > >
> > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> > > > > ----- Original Message -----
> > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > Sent: Thursday, May 17, 2012 3:40:19 PM
> > > > >
> > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
> > > > > > Hi,
> > > > > >
> > > > > > Please review/comment on the Custom Properties Sheet
> > > > > > feature
> > > > > > page:
> > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > >
> > > > >
> > > > > Just my $0.02:
> > > > >
> > > > > The table could have always empty row at the bottom,
> > > > > eliminating
> > > > > one
> > > > > or
> > > > > all [+] buttons and saving user one needless click:
> > > > >
> > > > > [ key1 |v] [ value ] [+] [-]
> > > > > [ key2 |v] [ value ] [+] [-]
> > > > > [ key3 |v] [ value ] [-]
> > > > > [ "please select a key..." |v]
> > > > >
> > > > > The [+] buttons at first and second rows would allow user
> > > > > to
> > > > > insert a
> > > > > row at specified location to make easy custom sorting of
> > > > > the
> > > > > properties
> > > > > (not applicable if properties are auto-sorted, in that
> > > > > case,
> > > > > all
> > > > > [+]
> > > > > buttons can be actually removed).
> > > >
> > > > Thanks for the input, David. This is an interesting idea.
> > > >
> > > > Indeed, when choosing a key in the last row, we can
> > > > automatically
> > > > add a new "please select a key..." row, which actually
saves
> > > > the
> > > > user a button-click for adding a new row.
> > > >
> > > > On the other hand, from graphic-design point of view, it will
> > > > look
> > > > more consistent and "pretty" if:
> > > > - The "please select a key..." row won't be displayed
> > > > (unless,
> > > > or
> > > > course, the user explicitly chose to add another row)
> > > > - All (full) rows will have both [+] and [-] buttons next to
> > > > them
>
> I should have probably elaborated more on this. To me, UI with less
> elements looks cleaner and prettier even when one of them stands
> out.
> There's also nothing wrong with standing out if the element has
> "special" meaning (one add vs bunch of modify).
>
> Specifically, this looks cleaner to my eyes:
>
> [ key1 |v] [ value ] [-]
> [ key2 |v] [ value ] [-]
> [ key3 |v] [ value ] [-]
> [ "Please select a key..." |v]
>
> than
>
> [ key1 |v] [ value ] [+] [-]
> [ key2 |v] [ value ] [+] [-]
> [ key3 |v] [ value ] [+] [-]
>
>
Note that in your suggestion above, you cannot insert a new key in
between existing keys - only at the end; so
although "cleaner", it has less functionality (depends also on the
sorting, which is another issue; if there is auto-sorting, it
doesn't matter).
It is also a matter of taste, I guess, so no absolute right or wrong
here IMO.
[Others - you are welcome to comment as well]
+1
another tiny comment:
can the empty line contain all the fields from initial state
[["please select a key..."][field(empty)][+][-]]
instead of showing them only after selecting a key.
[["please select a key..."]]
both of these scenarios are liable,
I can select a key, regret (change back to [please select a key]) and the field and
buttons are still visible.
so for the sake of complexity, I prefer to have only one.
>
> > >
> > > If the [+] button in my proposal is just greyed out instead of
> > > ommited,
> > > it could satisfy both requirements.
> >
> > Almost; the "please select a key..." row is still always
> > displayed;
> > question is if we want to save a button-click (your suggestion)
> > or
> > to have a "cleaner" sheet (my suggestion).
> >
> > >
> > > >
> > > > i.e., instead of your suggestion, which looks like this:
> > > >
> > > > [ key1 |v] [ value ] [+] [-]
> > > > [ key2 |v] [ value ] [+] [-]
> > > > [ key3 |v] [ value ] [-]
> > > > [ "please select a key..." |v]
> > > >
> > > > it will be "prettier" like this:
> > > >
> > > > [ key1 |v] [ value ] [+] [-]
> > > > [ key2 |v] [ value ] [+] [-]
> > > > [ key3 |v] [ value ] [+] [-]
> > > >
> > > > and only if clicking on [+], it will be:
> > > >
> > > > [ key1 |v] [ value ] [+] [-]
> > > > [ key2 |v] [ value ] [+] [-]
> > > > [ key3 |v] [ value ] [+] [-]
> > > > [ "please select a key..." |v]
> > > >
> > > > I believe that auto-sorting can be confusing, as it can
> > > > result
> > > > in
> > > > rows "jumping" up and down whenever changing the
selection(s)
> > > > in
> > > > the Key drop-down(s),
> > >
> > > this could be sort of mitigated by sorting server-side upon
> > > modification.
> > >
> > > > therefore I don't think it is a good idea to implement it
> > > > here.
> > >
> > > OTOH if we're to be manual sorting friendly, we should allow
> > > rearranging
> > > of the rows by drag & drop or by some sort of move up/down
> > > buttons
> > > and
> > > the dialog would start to be cluttered.
> > >
> > > I don't really like either of these but auto-sort is slightly
> > > better
> > > IMO
> > > as it is kept consistent accross various VMs without user
> > > interaction.
> >
> > Indeed, auto-sort will keep the order consistent across all VMs.
> > However, maybe the user would like to see the properties in the
> > order in which he filled them; in this case, your suggestion of
> > "move up/down buttons" is probably relevant here.
> >
> > I believe that the majority of use-cases won't require more than
> > 2
> > or 3 custom properties per VM, so sorting won't be that critical,
> > therefore I assume we can start without it; I will add "sorting"
> > to the "open issues" section in the wiki page.
> >
>
> That seems as more argument in favor of auto sorting.
Or no sorting at all (i.e. simply display in order of filling)...
In any case, open issue has been added to the wiki.
>
> David
>
> > >
> > > David
> > >
> > > >
> > > > >
> > > > > David
> > > > >
> > > > > > ----
> > > > > > Thanks,
> > > > > > Einav
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel(a)ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > > --
> > > > >
> > > > > David Jaša, RHCE
> > > > >
> > > > > SPICE QE based in Brno
> > > > > GPG Key: 22C33E24
> > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > > 3E24
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel(a)ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > >
> > > > >
> > >
> > > --
> > >
> > > David Jaša, RHCE
> > >
> > > SPICE QE based in Brno
> > > GPG Key: 22C33E24
> > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> > >
> > >
> > >
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> --
>
> David Jaša, RHCE
>
> SPICE QE based in Brno
> GPG Key: 22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
3:35 a.m.
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
Sent: Friday, May 18, 2012 12:25:45 PM
inline
Thanks,
Gilad.
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "David Jaša" <djasa(a)redhat.com>, "Miki Kenneth"
> <mkenneth(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>,
> "Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, "Eldan Hildesheim"
> <info(a)eldanet.com>, "Gilad Chaplik" <gchaplik(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Friday, May 18, 2012 12:12:54 PM
> Subject: Re: [Engine-devel] custom properties sheet feature page
>
> > ----- Original Message -----
> > From: "David Jaša" <djasa(a)redhat.com>
> > Sent: Friday, May 18, 2012 11:33:44 AM
> >
> > Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> > > > ----- Original Message -----
> > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > Sent: Thursday, May 17, 2012 4:44:10 PM
> > > >
> > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> > > > > > ----- Original Message -----
> > > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM
> > > > > >
> > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Please review/comment on the Custom Properties Sheet
> > > > > > > feature
> > > > > > > page:
> > > > > > >
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > > >
> > > > > >
> > > > > > Just my $0.02:
> > > > > >
> > > > > > The table could have always empty row at the bottom,
> > > > > > eliminating
> > > > > > one
> > > > > > or
> > > > > > all [+] buttons and saving user one needless click:
> > > > > >
> > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > [ key3 |v] [ value ] [-]
> > > > > > [ "please select a key..." |v]
> > > > > >
> > > > > > The [+] buttons at first and second rows would allow user
> > > > > > to
> > > > > > insert a
> > > > > > row at specified location to make easy custom sorting of
> > > > > > the
> > > > > > properties
> > > > > > (not applicable if properties are auto-sorted, in that
> > > > > > case,
> > > > > > all
> > > > > > [+]
> > > > > > buttons can be actually removed).
> > > > >
> > > > > Thanks for the input, David. This is an interesting idea.
> > > > >
> > > > > Indeed, when choosing a key in the last row, we can
> > > > > automatically
> > > > > add a new "please select a key..." row, which
actually
> > > > > saves
> > > > > the
> > > > > user a button-click for adding a new row.
> > > > >
> > > > > On the other hand, from graphic-design point of view, it
> > > > > will
> > > > > look
> > > > > more consistent and "pretty" if:
> > > > > - The "please select a key..." row won't be
displayed
> > > > > (unless,
> > > > > or
> > > > > course, the user explicitly chose to add another row)
> > > > > - All (full) rows will have both [+] and [-] buttons next
> > > > > to
> > > > > them
> >
> > I should have probably elaborated more on this. To me, UI with
> > less
> > elements looks cleaner and prettier even when one of them stands
> > out.
> > There's also nothing wrong with standing out if the element has
> > "special" meaning (one add vs bunch of modify).
> >
> > Specifically, this looks cleaner to my eyes:
> >
> > [ key1 |v] [ value ] [-]
> > [ key2 |v] [ value ] [-]
> > [ key3 |v] [ value ] [-]
> > [ "Please select a key..." |v]
> >
> > than
> >
> > [ key1 |v] [ value ] [+] [-]
> > [ key2 |v] [ value ] [+] [-]
> > [ key3 |v] [ value ] [+] [-]
> >
> >
>
> Note that in your suggestion above, you cannot insert a new key in
> between existing keys - only at the end; so
> although "cleaner", it has less functionality (depends also on the
> sorting, which is another issue; if there is auto-sorting, it
> doesn't matter).
> It is also a matter of taste, I guess, so no absolute right or
> wrong
> here IMO.
> [Others - you are welcome to comment as well]
+1
another tiny comment:
can the empty line contain all the fields from initial state
[["please select a key..."][field(empty)][+][-]]
instead of showing them only after selecting a key.
[["please select a key..."]]
both of these scenarios are liable,
I can select a key, regret (change back to [please select a key]) and
the field and buttons are still visible.
so for the sake of complexity, I prefer to have only one.
* Note that the field input control type (text-box, drop-down) depends on the key anyway
(more accurately, on the validation regular expression of the key), so what are you going
to show in case of "please select a key..."?
* Need to make sure that validation fails in case field value is not empty and key is
"please select a key...".
Due to both of these reasons, I prefer to not show an input control at all in this case.
* No problem of having a "+" button there; however, need to make sure that in
case there is only one row in the sheet and it is with "please select a key...",
the "-" button should be either hidden or disabled (or non-responsive), since we
can't remove the last row.
>
> >
> > > >
> > > > If the [+] button in my proposal is just greyed out instead
> > > > of
> > > > ommited,
> > > > it could satisfy both requirements.
> > >
> > > Almost; the "please select a key..." row is still always
> > > displayed;
> > > question is if we want to save a button-click (your suggestion)
> > > or
> > > to have a "cleaner" sheet (my suggestion).
> > >
> > > >
> > > > >
> > > > > i.e., instead of your suggestion, which looks like this:
> > > > >
> > > > > [ key1 |v] [ value ] [+] [-]
> > > > > [ key2 |v] [ value ] [+] [-]
> > > > > [ key3 |v] [ value ] [-]
> > > > > [ "please select a key..." |v]
> > > > >
> > > > > it will be "prettier" like this:
> > > > >
> > > > > [ key1 |v] [ value ] [+] [-]
> > > > > [ key2 |v] [ value ] [+] [-]
> > > > > [ key3 |v] [ value ] [+] [-]
> > > > >
> > > > > and only if clicking on [+], it will be:
> > > > >
> > > > > [ key1 |v] [ value ] [+] [-]
> > > > > [ key2 |v] [ value ] [+] [-]
> > > > > [ key3 |v] [ value ] [+] [-]
> > > > > [ "please select a key..." |v]
> > > > >
> > > > > I believe that auto-sorting can be confusing, as it can
> > > > > result
> > > > > in
> > > > > rows "jumping" up and down whenever changing the
> > > > > selection(s)
> > > > > in
> > > > > the Key drop-down(s),
> > > >
> > > > this could be sort of mitigated by sorting server-side upon
> > > > modification.
> > > >
> > > > > therefore I don't think it is a good idea to implement it
> > > > > here.
> > > >
> > > > OTOH if we're to be manual sorting friendly, we should allow
> > > > rearranging
> > > > of the rows by drag & drop or by some sort of move up/down
> > > > buttons
> > > > and
> > > > the dialog would start to be cluttered.
> > > >
> > > > I don't really like either of these but auto-sort is slightly
> > > > better
> > > > IMO
> > > > as it is kept consistent accross various VMs without user
> > > > interaction.
> > >
> > > Indeed, auto-sort will keep the order consistent across all
> > > VMs.
> > > However, maybe the user would like to see the properties in the
> > > order in which he filled them; in this case, your suggestion of
> > > "move up/down buttons" is probably relevant here.
> > >
> > > I believe that the majority of use-cases won't require more
> > > than
> > > 2
> > > or 3 custom properties per VM, so sorting won't be that
> > > critical,
> > > therefore I assume we can start without it; I will add
> > > "sorting"
> > > to the "open issues" section in the wiki page.
> > >
> >
> > That seems as more argument in favor of auto sorting.
>
> Or no sorting at all (i.e. simply display in order of filling)...
> In any case, open issue has been added to the wiki.
>
> >
> > David
> >
> > > >
> > > > David
> > > >
> > > > >
> > > > > >
> > > > > > David
> > > > > >
> > > > > > > ----
> > > > > > > Thanks,
> > > > > > > Einav
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel(a)ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > > --
> > > > > >
> > > > > > David Jaša, RHCE
> > > > > >
> > > > > > SPICE QE based in Brno
> > > > > > GPG Key: 22C33E24
> > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > > > 3E24
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel(a)ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > > --
> > > >
> > > > David Jaša, RHCE
> > > >
> > > > SPICE QE based in Brno
> > > > GPG Key: 22C33E24
> > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > 3E24
> > > >
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> > --
> >
> > David Jaša, RHCE
> >
> > SPICE QE based in Brno
> > GPG Key: 22C33E24
> > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> >
>
3:44 a.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Gilad Chaplik" <gchaplik(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "David Jaša" <djasa(a)redhat.com>, "Miki
Kenneth" <mkenneth(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>, "Simon Grinberg" <sgrinber(a)redhat.com>,
"Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
Hildesheim" <info(a)eldanet.com>
Sent: Friday, May 18, 2012 12:35:34 PM
Subject: Re: [Engine-devel] custom properties sheet feature page
> ----- Original Message -----
> From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> Sent: Friday, May 18, 2012 12:25:45 PM
>
> inline
>
> Thanks,
> Gilad.
>
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "David Jaša" <djasa(a)redhat.com>, "Miki Kenneth"
> > <mkenneth(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>,
> > "Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, "Eldan Hildesheim"
> > <info(a)eldanet.com>, "Gilad Chaplik"
<gchaplik(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Friday, May 18, 2012 12:12:54 PM
> > Subject: Re: [Engine-devel] custom properties sheet feature page
> >
> > > ----- Original Message -----
> > > From: "David Jaša" <djasa(a)redhat.com>
> > > Sent: Friday, May 18, 2012 11:33:44 AM
> > >
> > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> > > > > ----- Original Message -----
> > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > Sent: Thursday, May 17, 2012 4:44:10 PM
> > > > >
> > > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> > > > > > > ----- Original Message -----
> > > > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM
> > > > > > >
> > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10 -0400:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Please review/comment on the Custom Properties
Sheet
> > > > > > > > feature
> > > > > > > > page:
> > > > > > > >
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > > > >
> > > > > > >
> > > > > > > Just my $0.02:
> > > > > > >
> > > > > > > The table could have always empty row at the bottom,
> > > > > > > eliminating
> > > > > > > one
> > > > > > > or
> > > > > > > all [+] buttons and saving user one needless click:
> > > > > > >
> > > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > > [ key3 |v] [ value ] [-]
> > > > > > > [ "please select a key..." |v]
> > > > > > >
> > > > > > > The [+] buttons at first and second rows would allow
> > > > > > > user
> > > > > > > to
> > > > > > > insert a
> > > > > > > row at specified location to make easy custom sorting
> > > > > > > of
> > > > > > > the
> > > > > > > properties
> > > > > > > (not applicable if properties are auto-sorted, in
that
> > > > > > > case,
> > > > > > > all
> > > > > > > [+]
> > > > > > > buttons can be actually removed).
> > > > > >
> > > > > > Thanks for the input, David. This is an interesting idea.
> > > > > >
> > > > > > Indeed, when choosing a key in the last row, we can
> > > > > > automatically
> > > > > > add a new "please select a key..." row, which
actually
> > > > > > saves
> > > > > > the
> > > > > > user a button-click for adding a new row.
> > > > > >
> > > > > > On the other hand, from graphic-design point of view, it
> > > > > > will
> > > > > > look
> > > > > > more consistent and "pretty" if:
> > > > > > - The "please select a key..." row won't be
displayed
> > > > > > (unless,
> > > > > > or
> > > > > > course, the user explicitly chose to add another row)
> > > > > > - All (full) rows will have both [+] and [-] buttons next
> > > > > > to
> > > > > > them
> > >
> > > I should have probably elaborated more on this. To me, UI with
> > > less
> > > elements looks cleaner and prettier even when one of them
> > > stands
> > > out.
> > > There's also nothing wrong with standing out if the element has
> > > "special" meaning (one add vs bunch of modify).
> > >
> > > Specifically, this looks cleaner to my eyes:
> > >
> > > [ key1 |v] [ value ] [-]
> > > [ key2 |v] [ value ] [-]
> > > [ key3 |v] [ value ] [-]
> > > [ "Please select a key..." |v]
> > >
> > > than
> > >
> > > [ key1 |v] [ value ] [+] [-]
> > > [ key2 |v] [ value ] [+] [-]
> > > [ key3 |v] [ value ] [+] [-]
> > >
> > >
> >
> > Note that in your suggestion above, you cannot insert a new key
> > in
> > between existing keys - only at the end; so
> > although "cleaner", it has less functionality (depends also on
> > the
> > sorting, which is another issue; if there is auto-sorting, it
> > doesn't matter).
> > It is also a matter of taste, I guess, so no absolute right or
> > wrong
> > here IMO.
> > [Others - you are welcome to comment as well]
>
> +1
>
> another tiny comment:
> can the empty line contain all the fields from initial state
> [["please select a key..."][field(empty)][+][-]]
> instead of showing them only after selecting a key.
> [["please select a key..."]]
>
> both of these scenarios are liable,
> I can select a key, regret (change back to [please select a key])
> and
> the field and buttons are still visible.
>
> so for the sake of complexity, I prefer to have only one.
* Note that the field input control type (text-box, drop-down)
depends on the key anyway (more accurately, on the validation
regular expression of the key), so what are you going to show in
case of "please select a key..."?
empty text-box
* Need to make sure that validation fails in case field value is not
empty and key is "please select a key...".
Due to both of these reasons, I prefer to not show an input control
at all in this case.
still, I don't see any difference, except adding complexity/devel-time/bugs later on.
plus I think it's nicer.
* No problem of having a "+" button there; however, need to make sure
that in case there is only one row in the sheet and it is with
"please select a key...", the "-" button should be either hidden or
disabled (or non-responsive), since we can't remove the last row.
>
>
> >
> > >
> > > > >
> > > > > If the [+] button in my proposal is just greyed out instead
> > > > > of
> > > > > ommited,
> > > > > it could satisfy both requirements.
> > > >
> > > > Almost; the "please select a key..." row is still always
> > > > displayed;
> > > > question is if we want to save a button-click (your
> > > > suggestion)
> > > > or
> > > > to have a "cleaner" sheet (my suggestion).
> > > >
> > > > >
> > > > > >
> > > > > > i.e., instead of your suggestion, which looks like this:
> > > > > >
> > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > [ key3 |v] [ value ] [-]
> > > > > > [ "please select a key..." |v]
> > > > > >
> > > > > > it will be "prettier" like this:
> > > > > >
> > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > [ key3 |v] [ value ] [+] [-]
> > > > > >
> > > > > > and only if clicking on [+], it will be:
> > > > > >
> > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > [ key3 |v] [ value ] [+] [-]
> > > > > > [ "please select a key..." |v]
> > > > > >
> > > > > > I believe that auto-sorting can be confusing, as it can
> > > > > > result
> > > > > > in
> > > > > > rows "jumping" up and down whenever changing the
> > > > > > selection(s)
> > > > > > in
> > > > > > the Key drop-down(s),
> > > > >
> > > > > this could be sort of mitigated by sorting server-side upon
> > > > > modification.
> > > > >
> > > > > > therefore I don't think it is a good idea to
implement
> > > > > > it
> > > > > > here.
> > > > >
> > > > > OTOH if we're to be manual sorting friendly, we should
> > > > > allow
> > > > > rearranging
> > > > > of the rows by drag & drop or by some sort of move up/down
> > > > > buttons
> > > > > and
> > > > > the dialog would start to be cluttered.
> > > > >
> > > > > I don't really like either of these but auto-sort is
> > > > > slightly
> > > > > better
> > > > > IMO
> > > > > as it is kept consistent accross various VMs without user
> > > > > interaction.
> > > >
> > > > Indeed, auto-sort will keep the order consistent across all
> > > > VMs.
> > > > However, maybe the user would like to see the properties in
> > > > the
> > > > order in which he filled them; in this case, your suggestion
> > > > of
> > > > "move up/down buttons" is probably relevant here.
> > > >
> > > > I believe that the majority of use-cases won't require more
> > > > than
> > > > 2
> > > > or 3 custom properties per VM, so sorting won't be that
> > > > critical,
> > > > therefore I assume we can start without it; I will add
> > > > "sorting"
> > > > to the "open issues" section in the wiki page.
> > > >
> > >
> > > That seems as more argument in favor of auto sorting.
> >
> > Or no sorting at all (i.e. simply display in order of filling)...
> > In any case, open issue has been added to the wiki.
> >
> > >
> > > David
> > >
> > > > >
> > > > > David
> > > > >
> > > > > >
> > > > > > >
> > > > > > > David
> > > > > > >
> > > > > > > > ----
> > > > > > > > Thanks,
> > > > > > > > Einav
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > David Jaša, RHCE
> > > > > > >
> > > > > > > SPICE QE based in Brno
> > > > > > > GPG Key: 22C33E24
> > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00
> > > > > > > 22C3
> > > > > > > 3E24
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel(a)ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > >
> > > > > David Jaša, RHCE
> > > > >
> > > > > SPICE QE based in Brno
> > > > > GPG Key: 22C33E24
> > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > > 3E24
> > > > >
> > > > >
> > > > >
> > > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > > --
> > >
> > > David Jaša, RHCE
> > >
> > > SPICE QE based in Brno
> > > GPG Key: 22C33E24
> > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> > >
> > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
> >
>
3:51 a.m.
Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "David Jaša" <djasa(a)redhat.com>,
"Miki Kenneth" <mkenneth(a)redhat.com>, "Andrew Cathrow"
> <acathrow(a)redhat.com>, "Simon Grinberg" <sgrinber(a)redhat.com>,
"Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
> Hildesheim" <info(a)eldanet.com>
> Sent: Friday, May 18, 2012 12:35:34 PM
> Subject: Re: [Engine-devel] custom properties sheet feature page
>
> > ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > Sent: Friday, May 18, 2012 12:25:45 PM
> >
> > inline
> >
> > Thanks,
> > Gilad.
> >
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > To: "David Jaša" <djasa(a)redhat.com>, "Miki
Kenneth"
> > > <mkenneth(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>,
> > > "Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan
Hildesheim"
> > > <ehildesh(a)redhat.com>, "Eldan Hildesheim"
> > > <info(a)eldanet.com>, "Gilad Chaplik"
<gchaplik(a)redhat.com>
> > > Cc: engine-devel(a)ovirt.org
> > > Sent: Friday, May 18, 2012 12:12:54 PM
> > > Subject: Re: [Engine-devel] custom properties sheet feature page
> > >
> > > > ----- Original Message -----
> > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > Sent: Friday, May 18, 2012 11:33:44 AM
> > > >
> > > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> > > > > > ----- Original Message -----
> > > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM
> > > > > >
> > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM
> > > > > > > >
> > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10
-0400:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Please review/comment on the Custom
Properties Sheet
> > > > > > > > > feature
> > > > > > > > > page:
> > > > > > > > >
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > > > > >
> > > > > > > >
> > > > > > > > Just my $0.02:
> > > > > > > >
> > > > > > > > The table could have always empty row at the
bottom,
> > > > > > > > eliminating
> > > > > > > > one
> > > > > > > > or
> > > > > > > > all [+] buttons and saving user one needless
click:
> > > > > > > >
> > > > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > > > [ key3 |v] [ value ] [-]
> > > > > > > > [ "please select a key..." |v]
> > > > > > > >
> > > > > > > > The [+] buttons at first and second rows would
allow
> > > > > > > > user
> > > > > > > > to
> > > > > > > > insert a
> > > > > > > > row at specified location to make easy custom
sorting
> > > > > > > > of
> > > > > > > > the
> > > > > > > > properties
> > > > > > > > (not applicable if properties are auto-sorted, in
that
> > > > > > > > case,
> > > > > > > > all
> > > > > > > > [+]
> > > > > > > > buttons can be actually removed).
> > > > > > >
> > > > > > > Thanks for the input, David. This is an interesting
idea.
> > > > > > >
> > > > > > > Indeed, when choosing a key in the last row, we can
> > > > > > > automatically
> > > > > > > add a new "please select a key..." row,
which actually
> > > > > > > saves
> > > > > > > the
> > > > > > > user a button-click for adding a new row.
> > > > > > >
> > > > > > > On the other hand, from graphic-design point of view,
it
> > > > > > > will
> > > > > > > look
> > > > > > > more consistent and "pretty" if:
> > > > > > > - The "please select a key..." row won't
be displayed
> > > > > > > (unless,
> > > > > > > or
> > > > > > > course, the user explicitly chose to add another row)
> > > > > > > - All (full) rows will have both [+] and [-] buttons
next
> > > > > > > to
> > > > > > > them
> > > >
> > > > I should have probably elaborated more on this. To me, UI with
> > > > less
> > > > elements looks cleaner and prettier even when one of them
> > > > stands
> > > > out.
> > > > There's also nothing wrong with standing out if the element has
> > > > "special" meaning (one add vs bunch of modify).
> > > >
> > > > Specifically, this looks cleaner to my eyes:
> > > >
> > > > [ key1 |v] [ value ] [-]
> > > > [ key2 |v] [ value ] [-]
> > > > [ key3 |v] [ value ] [-]
> > > > [ "Please select a key..." |v]
> > > >
> > > > than
> > > >
> > > > [ key1 |v] [ value ] [+] [-]
> > > > [ key2 |v] [ value ] [+] [-]
> > > > [ key3 |v] [ value ] [+] [-]
> > > >
> > > >
> > >
> > > Note that in your suggestion above, you cannot insert a new key
> > > in
> > > between existing keys - only at the end; so
> > > although "cleaner", it has less functionality (depends also on
> > > the
> > > sorting, which is another issue; if there is auto-sorting, it
> > > doesn't matter).
> > > It is also a matter of taste, I guess, so no absolute right or
> > > wrong
> > > here IMO.
> > > [Others - you are welcome to comment as well]
> >
> > +1
> >
> > another tiny comment:
> > can the empty line contain all the fields from initial state
> > [["please select a key..."][field(empty)][+][-]]
> > instead of showing them only after selecting a key.
> > [["please select a key..."]]
> >
> > both of these scenarios are liable,
> > I can select a key, regret (change back to [please select a key])
> > and
> > the field and buttons are still visible.
> >
> > so for the sake of complexity, I prefer to have only one.
>
> * Note that the field input control type (text-box, drop-down)
> depends on the key anyway (more accurately, on the validation
> regular expression of the key), so what are you going to show in
> case of "please select a key..."?
empty text-box
>
> * Need to make sure that validation fails in case field value is not
> empty and key is "please select a key...".
>
I would prefer to just disable the value input field and do
re-validation upon change of key (clear the value if it fails validation
against a new key) or server-side when it is changed (clear the
key-value pair altogether).
David
> Due to both of these reasons, I prefer to not show an input
control
> at all in this case.
still, I don't see any difference, except adding complexity/devel-time/bugs later
on.
plus I think it's nicer.
>
> * No problem of having a "+" button there; however, need to make sure
> that in case there is only one row in the sheet and it is with
> "please select a key...", the "-" button should be either hidden
or
> disabled (or non-responsive), since we can't remove the last row.
>
> >
> >
> > >
> > > >
> > > > > >
> > > > > > If the [+] button in my proposal is just greyed out
instead
> > > > > > of
> > > > > > ommited,
> > > > > > it could satisfy both requirements.
> > > > >
> > > > > Almost; the "please select a key..." row is still
always
> > > > > displayed;
> > > > > question is if we want to save a button-click (your
> > > > > suggestion)
> > > > > or
> > > > > to have a "cleaner" sheet (my suggestion).
> > > > >
> > > > > >
> > > > > > >
> > > > > > > i.e., instead of your suggestion, which looks like
this:
> > > > > > >
> > > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > > [ key3 |v] [ value ] [-]
> > > > > > > [ "please select a key..." |v]
> > > > > > >
> > > > > > > it will be "prettier" like this:
> > > > > > >
> > > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > > [ key3 |v] [ value ] [+] [-]
> > > > > > >
> > > > > > > and only if clicking on [+], it will be:
> > > > > > >
> > > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > > [ key3 |v] [ value ] [+] [-]
> > > > > > > [ "please select a key..." |v]
> > > > > > >
> > > > > > > I believe that auto-sorting can be confusing, as it
can
> > > > > > > result
> > > > > > > in
> > > > > > > rows "jumping" up and down whenever changing
the
> > > > > > > selection(s)
> > > > > > > in
> > > > > > > the Key drop-down(s),
> > > > > >
> > > > > > this could be sort of mitigated by sorting server-side
upon
> > > > > > modification.
> > > > > >
> > > > > > > therefore I don't think it is a good idea to
implement
> > > > > > > it
> > > > > > > here.
> > > > > >
> > > > > > OTOH if we're to be manual sorting friendly, we should
> > > > > > allow
> > > > > > rearranging
> > > > > > of the rows by drag & drop or by some sort of move
up/down
> > > > > > buttons
> > > > > > and
> > > > > > the dialog would start to be cluttered.
> > > > > >
> > > > > > I don't really like either of these but auto-sort is
> > > > > > slightly
> > > > > > better
> > > > > > IMO
> > > > > > as it is kept consistent accross various VMs without user
> > > > > > interaction.
> > > > >
> > > > > Indeed, auto-sort will keep the order consistent across all
> > > > > VMs.
> > > > > However, maybe the user would like to see the properties in
> > > > > the
> > > > > order in which he filled them; in this case, your suggestion
> > > > > of
> > > > > "move up/down buttons" is probably relevant here.
> > > > >
> > > > > I believe that the majority of use-cases won't require more
> > > > > than
> > > > > 2
> > > > > or 3 custom properties per VM, so sorting won't be that
> > > > > critical,
> > > > > therefore I assume we can start without it; I will add
> > > > > "sorting"
> > > > > to the "open issues" section in the wiki page.
> > > > >
> > > >
> > > > That seems as more argument in favor of auto sorting.
> > >
> > > Or no sorting at all (i.e. simply display in order of filling)...
> > > In any case, open issue has been added to the wiki.
> > >
> > > >
> > > > David
> > > >
> > > > > >
> > > > > > David
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > David
> > > > > > > >
> > > > > > > > > ----
> > > > > > > > > Thanks,
> > > > > > > > > Einav
> > > > > > > > >
_______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > David Jaša, RHCE
> > > > > > > >
> > > > > > > > SPICE QE based in Brno
> > > > > > > > GPG Key: 22C33E24
> > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125
CD00
> > > > > > > > 22C3
> > > > > > > > 3E24
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > David Jaša, RHCE
> > > > > >
> > > > > > SPICE QE based in Brno
> > > > > > GPG Key: 22C33E24
> > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > > > 3E24
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel(a)ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > > --
> > > >
> > > > David Jaša, RHCE
> > > >
> > > > SPICE QE based in Brno
> > > > GPG Key: 22C33E24
> > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > >
> > > >
> > >
> >
>
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
3:56 a.m.
----- Original Message -----
From: "David Jaša" <djasa(a)redhat.com>
To: "Gilad Chaplik" <gchaplik(a)redhat.com>
Cc: "Einav Cohen" <ecohen(a)redhat.com>, engine-devel(a)ovirt.org, "Miki
Kenneth" <mkenneth(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>, "Simon Grinberg" <sgrinber(a)redhat.com>,
"Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
Hildesheim" <info(a)eldanet.com>
Sent: Friday, May 18, 2012 12:51:43 PM
Subject: Re: [Engine-devel] custom properties sheet feature page
Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org, "David Jaša" <djasa(a)redhat.com>,
> > "Miki Kenneth" <mkenneth(a)redhat.com>, "Andrew
Cathrow"
> > <acathrow(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>,
> > "Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
> > Hildesheim" <info(a)eldanet.com>
> > Sent: Friday, May 18, 2012 12:35:34 PM
> > Subject: Re: [Engine-devel] custom properties sheet feature page
> >
> > > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > Sent: Friday, May 18, 2012 12:25:45 PM
> > >
> > > inline
> > >
> > > Thanks,
> > > Gilad.
> > >
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > > To: "David Jaša" <djasa(a)redhat.com>, "Miki
Kenneth"
> > > > <mkenneth(a)redhat.com>, "Andrew Cathrow"
> > > > <acathrow(a)redhat.com>,
> > > > "Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan
Hildesheim"
> > > > <ehildesh(a)redhat.com>, "Eldan Hildesheim"
> > > > <info(a)eldanet.com>, "Gilad Chaplik"
<gchaplik(a)redhat.com>
> > > > Cc: engine-devel(a)ovirt.org
> > > > Sent: Friday, May 18, 2012 12:12:54 PM
> > > > Subject: Re: [Engine-devel] custom properties sheet feature
> > > > page
> > > >
> > > > > ----- Original Message -----
> > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > Sent: Friday, May 18, 2012 11:33:44 AM
> > > > >
> > > > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> > > > > > > ----- Original Message -----
> > > > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM
> > > > > > >
> > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30 -0400:
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM
> > > > > > > > >
> > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 08:10
-0400:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > Please review/comment on the Custom
Properties
> > > > > > > > > > Sheet
> > > > > > > > > > feature
> > > > > > > > > > page:
> > > > > > > > > >
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Just my $0.02:
> > > > > > > > >
> > > > > > > > > The table could have always empty row at
the
> > > > > > > > > bottom,
> > > > > > > > > eliminating
> > > > > > > > > one
> > > > > > > > > or
> > > > > > > > > all [+] buttons and saving user one needless
click:
> > > > > > > > >
> > > > > > > > > [ key1 |v] [ value ] [+]
[-]
> > > > > > > > > [ key2 |v] [ value ] [+]
[-]
> > > > > > > > > [ key3 |v] [ value ]
[-]
> > > > > > > > > [ "please select a key..." |v]
> > > > > > > > >
> > > > > > > > > The [+] buttons at first and second rows
would
> > > > > > > > > allow
> > > > > > > > > user
> > > > > > > > > to
> > > > > > > > > insert a
> > > > > > > > > row at specified location to make easy
custom
> > > > > > > > > sorting
> > > > > > > > > of
> > > > > > > > > the
> > > > > > > > > properties
> > > > > > > > > (not applicable if properties are
auto-sorted, in
> > > > > > > > > that
> > > > > > > > > case,
> > > > > > > > > all
> > > > > > > > > [+]
> > > > > > > > > buttons can be actually removed).
> > > > > > > >
> > > > > > > > Thanks for the input, David. This is an
interesting
> > > > > > > > idea.
> > > > > > > >
> > > > > > > > Indeed, when choosing a key in the last row, we
can
> > > > > > > > automatically
> > > > > > > > add a new "please select a key..." row,
which
> > > > > > > > actually
> > > > > > > > saves
> > > > > > > > the
> > > > > > > > user a button-click for adding a new row.
> > > > > > > >
> > > > > > > > On the other hand, from graphic-design point of
view,
> > > > > > > > it
> > > > > > > > will
> > > > > > > > look
> > > > > > > > more consistent and "pretty" if:
> > > > > > > > - The "please select a key..." row
won't be displayed
> > > > > > > > (unless,
> > > > > > > > or
> > > > > > > > course, the user explicitly chose to add another
row)
> > > > > > > > - All (full) rows will have both [+] and [-]
buttons
> > > > > > > > next
> > > > > > > > to
> > > > > > > > them
> > > > >
> > > > > I should have probably elaborated more on this. To me, UI
> > > > > with
> > > > > less
> > > > > elements looks cleaner and prettier even when one of them
> > > > > stands
> > > > > out.
> > > > > There's also nothing wrong with standing out if the element
> > > > > has
> > > > > "special" meaning (one add vs bunch of modify).
> > > > >
> > > > > Specifically, this looks cleaner to my eyes:
> > > > >
> > > > > [ key1 |v] [ value ] [-]
> > > > > [ key2 |v] [ value ] [-]
> > > > > [ key3 |v] [ value ] [-]
> > > > > [ "Please select a key..." |v]
> > > > >
> > > > > than
> > > > >
> > > > > [ key1 |v] [ value ] [+] [-]
> > > > > [ key2 |v] [ value ] [+] [-]
> > > > > [ key3 |v] [ value ] [+] [-]
> > > > >
> > > > >
> > > >
> > > > Note that in your suggestion above, you cannot insert a new
> > > > key
> > > > in
> > > > between existing keys - only at the end; so
> > > > although "cleaner", it has less functionality (depends
also
> > > > on
> > > > the
> > > > sorting, which is another issue; if there is auto-sorting, it
> > > > doesn't matter).
> > > > It is also a matter of taste, I guess, so no absolute right
> > > > or
> > > > wrong
> > > > here IMO.
> > > > [Others - you are welcome to comment as well]
> > >
> > > +1
> > >
> > > another tiny comment:
> > > can the empty line contain all the fields from initial state
> > > [["please select a key..."][field(empty)][+][-]]
> > > instead of showing them only after selecting a key.
> > > [["please select a key..."]]
> > >
> > > both of these scenarios are liable,
> > > I can select a key, regret (change back to [please select a
> > > key])
> > > and
> > > the field and buttons are still visible.
> > >
> > > so for the sake of complexity, I prefer to have only one.
> >
> > * Note that the field input control type (text-box, drop-down)
> > depends on the key anyway (more accurately, on the validation
> > regular expression of the key), so what are you going to show in
> > case of "please select a key..."?
>
> empty text-box
>
> >
> > * Need to make sure that validation fails in case field value is
> > not
> > empty and key is "please select a key...".
> >
I would prefer to just disable the value input field and do
re-validation upon change of key (clear the value if it fails
validation
against a new key) or server-side when it is changed (clear the
key-value pair altogether).
+1 for disabling
-1 for clearing - it is not advised to clear a field if its fails on validation.
David
> > Due to both of these reasons, I prefer to not show an input
> > control
> > at all in this case.
>
> still, I don't see any difference, except adding
> complexity/devel-time/bugs later on.
> plus I think it's nicer.
>
> >
> > * No problem of having a "+" button there; however, need to make
> > sure
> > that in case there is only one row in the sheet and it is with
> > "please select a key...", the "-" button should be either
hidden
> > or
> > disabled (or non-responsive), since we can't remove the last row.
>
>
>
> >
> > >
> > >
> > > >
> > > > >
> > > > > > >
> > > > > > > If the [+] button in my proposal is just greyed out
> > > > > > > instead
> > > > > > > of
> > > > > > > ommited,
> > > > > > > it could satisfy both requirements.
> > > > > >
> > > > > > Almost; the "please select a key..." row is still
always
> > > > > > displayed;
> > > > > > question is if we want to save a button-click (your
> > > > > > suggestion)
> > > > > > or
> > > > > > to have a "cleaner" sheet (my suggestion).
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > i.e., instead of your suggestion, which looks
like
> > > > > > > > this:
> > > > > > > >
> > > > > > > > [ key1 |v] [ value ] [+]
[-]
> > > > > > > > [ key2 |v] [ value ] [+]
[-]
> > > > > > > > [ key3 |v] [ value ]
[-]
> > > > > > > > [ "please select a key..." |v]
> > > > > > > >
> > > > > > > > it will be "prettier" like this:
> > > > > > > >
> > > > > > > > [ key1 |v] [ value ] [+]
[-]
> > > > > > > > [ key2 |v] [ value ] [+]
[-]
> > > > > > > > [ key3 |v] [ value ] [+]
[-]
> > > > > > > >
> > > > > > > > and only if clicking on [+], it will be:
> > > > > > > >
> > > > > > > > [ key1 |v] [ value ] [+]
[-]
> > > > > > > > [ key2 |v] [ value ] [+]
[-]
> > > > > > > > [ key3 |v] [ value ] [+]
[-]
> > > > > > > > [ "please select a key..." |v]
> > > > > > > >
> > > > > > > > I believe that auto-sorting can be confusing, as
it
> > > > > > > > can
> > > > > > > > result
> > > > > > > > in
> > > > > > > > rows "jumping" up and down whenever
changing the
> > > > > > > > selection(s)
> > > > > > > > in
> > > > > > > > the Key drop-down(s),
> > > > > > >
> > > > > > > this could be sort of mitigated by sorting
server-side
> > > > > > > upon
> > > > > > > modification.
> > > > > > >
> > > > > > > > therefore I don't think it is a good idea
to
> > > > > > > > implement
> > > > > > > > it
> > > > > > > > here.
> > > > > > >
> > > > > > > OTOH if we're to be manual sorting friendly, we
should
> > > > > > > allow
> > > > > > > rearranging
> > > > > > > of the rows by drag & drop or by some sort of
move
> > > > > > > up/down
> > > > > > > buttons
> > > > > > > and
> > > > > > > the dialog would start to be cluttered.
> > > > > > >
> > > > > > > I don't really like either of these but auto-sort
is
> > > > > > > slightly
> > > > > > > better
> > > > > > > IMO
> > > > > > > as it is kept consistent accross various VMs without
> > > > > > > user
> > > > > > > interaction.
> > > > > >
> > > > > > Indeed, auto-sort will keep the order consistent across
> > > > > > all
> > > > > > VMs.
> > > > > > However, maybe the user would like to see the properties
> > > > > > in
> > > > > > the
> > > > > > order in which he filled them; in this case, your
> > > > > > suggestion
> > > > > > of
> > > > > > "move up/down buttons" is probably relevant
here.
> > > > > >
> > > > > > I believe that the majority of use-cases won't require
> > > > > > more
> > > > > > than
> > > > > > 2
> > > > > > or 3 custom properties per VM, so sorting won't be
that
> > > > > > critical,
> > > > > > therefore I assume we can start without it; I will add
> > > > > > "sorting"
> > > > > > to the "open issues" section in the wiki page.
> > > > > >
> > > > >
> > > > > That seems as more argument in favor of auto sorting.
> > > >
> > > > Or no sorting at all (i.e. simply display in order of
> > > > filling)...
> > > > In any case, open issue has been added to the wiki.
> > > >
> > > > >
> > > > > David
> > > > >
> > > > > > >
> > > > > > > David
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > David
> > > > > > > > >
> > > > > > > > > > ----
> > > > > > > > > > Thanks,
> > > > > > > > > > Einav
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > David Jaša, RHCE
> > > > > > > > >
> > > > > > > > > SPICE QE based in Brno
> > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278
B125
> > > > > > > > > CD00
> > > > > > > > > 22C3
> > > > > > > > > 3E24
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > David Jaša, RHCE
> > > > > > >
> > > > > > > SPICE QE based in Brno
> > > > > > > GPG Key: 22C33E24
> > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00
> > > > > > > 22C3
> > > > > > > 3E24
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel(a)ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > > --
> > > > >
> > > > > David Jaša, RHCE
> > > > >
> > > > > SPICE QE based in Brno
> > > > > GPG Key: 22C33E24
> > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > > 3E24
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel(a)ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
4:02 a.m.
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
Sent: Friday, May 18, 2012 12:56:00 PM
----- Original Message -----
> From: "David Jaša" <djasa(a)redhat.com>
> To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> Cc: "Einav Cohen" <ecohen(a)redhat.com>, engine-devel(a)ovirt.org,
> "Miki Kenneth" <mkenneth(a)redhat.com>, "Andrew Cathrow"
> <acathrow(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>,
> "Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
> Hildesheim" <info(a)eldanet.com>
> Sent: Friday, May 18, 2012 12:51:43 PM
> Subject: Re: [Engine-devel] custom properties sheet feature page
>
> Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > Cc: engine-devel(a)ovirt.org, "David Jaša"
<djasa(a)redhat.com>,
> > > "Miki Kenneth" <mkenneth(a)redhat.com>, "Andrew
Cathrow"
> > > <acathrow(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>,
> > > "Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
> > > Hildesheim" <info(a)eldanet.com>
> > > Sent: Friday, May 18, 2012 12:35:34 PM
> > > Subject: Re: [Engine-devel] custom properties sheet feature
> > > page
> > >
> > > > ----- Original Message -----
> > > > From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > > Sent: Friday, May 18, 2012 12:25:45 PM
> > > >
> > > > inline
> > > >
> > > > Thanks,
> > > > Gilad.
> > > >
> > > > ----- Original Message -----
> > > > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > > > To: "David Jaša" <djasa(a)redhat.com>, "Miki
Kenneth"
> > > > > <mkenneth(a)redhat.com>, "Andrew Cathrow"
> > > > > <acathrow(a)redhat.com>,
> > > > > "Simon Grinberg" <sgrinber(a)redhat.com>,
"Eldan Hildesheim"
> > > > > <ehildesh(a)redhat.com>, "Eldan Hildesheim"
> > > > > <info(a)eldanet.com>, "Gilad Chaplik"
<gchaplik(a)redhat.com>
> > > > > Cc: engine-devel(a)ovirt.org
> > > > > Sent: Friday, May 18, 2012 12:12:54 PM
> > > > > Subject: Re: [Engine-devel] custom properties sheet feature
> > > > > page
> > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > > Sent: Friday, May 18, 2012 11:33:44 AM
> > > > > >
> > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM
> > > > > > > >
> > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30
-0400:
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19
PM
> > > > > > > > > >
> > > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v
08:10 -0400:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > Please review/comment on the
Custom Properties
> > > > > > > > > > > Sheet
> > > > > > > > > > > feature
> > > > > > > > > > > page:
> > > > > > > > > > >
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Just my $0.02:
> > > > > > > > > >
> > > > > > > > > > The table could have always empty row
at the
> > > > > > > > > > bottom,
> > > > > > > > > > eliminating
> > > > > > > > > > one
> > > > > > > > > > or
> > > > > > > > > > all [+] buttons and saving user one
needless
> > > > > > > > > > click:
> > > > > > > > > >
> > > > > > > > > > [ key1 |v] [ value
] [+] [-]
> > > > > > > > > > [ key2 |v] [ value
] [+] [-]
> > > > > > > > > > [ key3 |v] [ value
] [-]
> > > > > > > > > > [ "please select a key..."
|v]
> > > > > > > > > >
> > > > > > > > > > The [+] buttons at first and second
rows would
> > > > > > > > > > allow
> > > > > > > > > > user
> > > > > > > > > > to
> > > > > > > > > > insert a
> > > > > > > > > > row at specified location to make easy
custom
> > > > > > > > > > sorting
> > > > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > properties
> > > > > > > > > > (not applicable if properties are
auto-sorted, in
> > > > > > > > > > that
> > > > > > > > > > case,
> > > > > > > > > > all
> > > > > > > > > > [+]
> > > > > > > > > > buttons can be actually removed).
> > > > > > > > >
> > > > > > > > > Thanks for the input, David. This is an
interesting
> > > > > > > > > idea.
> > > > > > > > >
> > > > > > > > > Indeed, when choosing a key in the last row,
we can
> > > > > > > > > automatically
> > > > > > > > > add a new "please select a key..."
row, which
> > > > > > > > > actually
> > > > > > > > > saves
> > > > > > > > > the
> > > > > > > > > user a button-click for adding a new row.
> > > > > > > > >
> > > > > > > > > On the other hand, from graphic-design point
of
> > > > > > > > > view,
> > > > > > > > > it
> > > > > > > > > will
> > > > > > > > > look
> > > > > > > > > more consistent and "pretty" if:
> > > > > > > > > - The "please select a key..." row
won't be
> > > > > > > > > displayed
> > > > > > > > > (unless,
> > > > > > > > > or
> > > > > > > > > course, the user explicitly chose to add
another
> > > > > > > > > row)
> > > > > > > > > - All (full) rows will have both [+] and
[-]
> > > > > > > > > buttons
> > > > > > > > > next
> > > > > > > > > to
> > > > > > > > > them
> > > > > >
> > > > > > I should have probably elaborated more on this. To me, UI
> > > > > > with
> > > > > > less
> > > > > > elements looks cleaner and prettier even when one of them
> > > > > > stands
> > > > > > out.
> > > > > > There's also nothing wrong with standing out if the
> > > > > > element
> > > > > > has
> > > > > > "special" meaning (one add vs bunch of modify).
> > > > > >
> > > > > > Specifically, this looks cleaner to my eyes:
> > > > > >
> > > > > > [ key1 |v] [ value ] [-]
> > > > > > [ key2 |v] [ value ] [-]
> > > > > > [ key3 |v] [ value ] [-]
> > > > > > [ "Please select a key..." |v]
> > > > > >
> > > > > > than
> > > > > >
> > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > [ key3 |v] [ value ] [+] [-]
> > > > > >
> > > > > >
> > > > >
> > > > > Note that in your suggestion above, you cannot insert a new
> > > > > key
> > > > > in
> > > > > between existing keys - only at the end; so
> > > > > although "cleaner", it has less functionality (depends
also
> > > > > on
> > > > > the
> > > > > sorting, which is another issue; if there is auto-sorting,
> > > > > it
> > > > > doesn't matter).
> > > > > It is also a matter of taste, I guess, so no absolute right
> > > > > or
> > > > > wrong
> > > > > here IMO.
> > > > > [Others - you are welcome to comment as well]
> > > >
> > > > +1
> > > >
> > > > another tiny comment:
> > > > can the empty line contain all the fields from initial state
> > > > [["please select a key..."][field(empty)][+][-]]
> > > > instead of showing them only after selecting a key.
> > > > [["please select a key..."]]
> > > >
> > > > both of these scenarios are liable,
> > > > I can select a key, regret (change back to [please select a
> > > > key])
> > > > and
> > > > the field and buttons are still visible.
> > > >
> > > > so for the sake of complexity, I prefer to have only one.
> > >
> > > * Note that the field input control type (text-box, drop-down)
> > > depends on the key anyway (more accurately, on the validation
> > > regular expression of the key), so what are you going to show
> > > in
> > > case of "please select a key..."?
> >
> > empty text-box
> >
> > >
> > > * Need to make sure that validation fails in case field value
> > > is
> > > not
> > > empty and key is "please select a key...".
> > >
>
> I would prefer to just disable the value input field and do
> re-validation upon change of key (clear the value if it fails
> validation
> against a new key) or server-side when it is changed (clear the
> key-value pair altogether).
+1 for disabling
-1 for clearing - it is not advised to clear a field if its fails on
validation.
>
> David
>
> > > Due to both of these reasons, I prefer to not show an input
> > > control
> > > at all in this case.
> >
> > still, I don't see any difference, except adding
> > complexity/devel-time/bugs later on.
> > plus I think it's nicer.
> >
> > >
> > > * No problem of having a "+" button there; however, need to
> > > make
> > > sure
> > > that in case there is only one row in the sheet and it is with
> > > "please select a key...", the "-" button should be
either
> > > hidden
> > > or
> > > disabled (or non-responsive), since we can't remove the last
> > > row.
Don't forget to take this ^^^ also under consideration.
> >
> >
> >
> > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > > >
> > > > > > > > If the [+] button in my proposal is just greyed
out
> > > > > > > > instead
> > > > > > > > of
> > > > > > > > ommited,
> > > > > > > > it could satisfy both requirements.
> > > > > > >
> > > > > > > Almost; the "please select a key..." row is
still
> > > > > > > always
> > > > > > > displayed;
> > > > > > > question is if we want to save a button-click (your
> > > > > > > suggestion)
> > > > > > > or
> > > > > > > to have a "cleaner" sheet (my suggestion).
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > i.e., instead of your suggestion, which
looks like
> > > > > > > > > this:
> > > > > > > > >
> > > > > > > > > [ key1 |v] [ value ]
[+] [-]
> > > > > > > > > [ key2 |v] [ value ]
[+] [-]
> > > > > > > > > [ key3 |v] [ value ]
[-]
> > > > > > > > > [ "please select a key..." |v]
> > > > > > > > >
> > > > > > > > > it will be "prettier" like this:
> > > > > > > > >
> > > > > > > > > [ key1 |v] [ value ]
[+] [-]
> > > > > > > > > [ key2 |v] [ value ]
[+] [-]
> > > > > > > > > [ key3 |v] [ value ]
[+] [-]
> > > > > > > > >
> > > > > > > > > and only if clicking on [+], it will be:
> > > > > > > > >
> > > > > > > > > [ key1 |v] [ value ]
[+] [-]
> > > > > > > > > [ key2 |v] [ value ]
[+] [-]
> > > > > > > > > [ key3 |v] [ value ]
[+] [-]
> > > > > > > > > [ "please select a key..." |v]
> > > > > > > > >
> > > > > > > > > I believe that auto-sorting can be
confusing, as it
> > > > > > > > > can
> > > > > > > > > result
> > > > > > > > > in
> > > > > > > > > rows "jumping" up and down
whenever changing the
> > > > > > > > > selection(s)
> > > > > > > > > in
> > > > > > > > > the Key drop-down(s),
> > > > > > > >
> > > > > > > > this could be sort of mitigated by sorting
> > > > > > > > server-side
> > > > > > > > upon
> > > > > > > > modification.
> > > > > > > >
> > > > > > > > > therefore I don't think it is a good
idea to
> > > > > > > > > implement
> > > > > > > > > it
> > > > > > > > > here.
> > > > > > > >
> > > > > > > > OTOH if we're to be manual sorting friendly,
we
> > > > > > > > should
> > > > > > > > allow
> > > > > > > > rearranging
> > > > > > > > of the rows by drag & drop or by some sort of
move
> > > > > > > > up/down
> > > > > > > > buttons
> > > > > > > > and
> > > > > > > > the dialog would start to be cluttered.
> > > > > > > >
> > > > > > > > I don't really like either of these but
auto-sort is
> > > > > > > > slightly
> > > > > > > > better
> > > > > > > > IMO
> > > > > > > > as it is kept consistent accross various VMs
without
> > > > > > > > user
> > > > > > > > interaction.
> > > > > > >
> > > > > > > Indeed, auto-sort will keep the order consistent
across
> > > > > > > all
> > > > > > > VMs.
> > > > > > > However, maybe the user would like to see the
> > > > > > > properties
> > > > > > > in
> > > > > > > the
> > > > > > > order in which he filled them; in this case, your
> > > > > > > suggestion
> > > > > > > of
> > > > > > > "move up/down buttons" is probably relevant
here.
> > > > > > >
> > > > > > > I believe that the majority of use-cases won't
require
> > > > > > > more
> > > > > > > than
> > > > > > > 2
> > > > > > > or 3 custom properties per VM, so sorting won't be
that
> > > > > > > critical,
> > > > > > > therefore I assume we can start without it; I will
add
> > > > > > > "sorting"
> > > > > > > to the "open issues" section in the wiki
page.
> > > > > > >
> > > > > >
> > > > > > That seems as more argument in favor of auto sorting.
> > > > >
> > > > > Or no sorting at all (i.e. simply display in order of
> > > > > filling)...
> > > > > In any case, open issue has been added to the wiki.
> > > > >
> > > > > >
> > > > > > David
> > > > > >
> > > > > > > >
> > > > > > > > David
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > David
> > > > > > > > > >
> > > > > > > > > > > ----
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Einav
> > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > David Jaša, RHCE
> > > > > > > > > >
> > > > > > > > > > SPICE QE based in Brno
> > > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D
0278 B125
> > > > > > > > > > CD00
> > > > > > > > > > 22C3
> > > > > > > > > > 3E24
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > David Jaša, RHCE
> > > > > > > >
> > > > > > > > SPICE QE based in Brno
> > > > > > > > GPG Key: 22C33E24
> > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125
CD00
> > > > > > > > 22C3
> > > > > > > > 3E24
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel(a)ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > > --
> > > > > >
> > > > > > David Jaša, RHCE
> > > > > >
> > > > > > SPICE QE based in Brno
> > > > > > GPG Key: 22C33E24
> > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > > > 3E24
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel(a)ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> --
>
> David Jaša, RHCE
>
> SPICE QE based in Brno
> GPG Key: 22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
>
>
>
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:15 a.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Gilad Chaplik" <gchaplik(a)redhat.com>
Cc: "Eldan Hildesheim" <info(a)eldanet.com>, engine-devel(a)ovirt.org,
"Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan
Hildesheim" <ehildesh(a)redhat.com>, "David Jaša"
<djasa(a)redhat.com>
Sent: Friday, May 18, 2012 1:02:03 PM
Subject: Re: [Engine-devel] custom properties sheet feature page
> ----- Original Message -----
> From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> Sent: Friday, May 18, 2012 12:56:00 PM
>
> ----- Original Message -----
> > From: "David Jaša" <djasa(a)redhat.com>
> > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > Cc: "Einav Cohen" <ecohen(a)redhat.com>, engine-devel(a)ovirt.org,
> > "Miki Kenneth" <mkenneth(a)redhat.com>, "Andrew
Cathrow"
> > <acathrow(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>,
> > "Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
> > Hildesheim" <info(a)eldanet.com>
> > Sent: Friday, May 18, 2012 12:51:43 PM
> > Subject: Re: [Engine-devel] custom properties sheet feature page
> >
> > Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > > Cc: engine-devel(a)ovirt.org, "David Jaša"
<djasa(a)redhat.com>,
> > > > "Miki Kenneth" <mkenneth(a)redhat.com>, "Andrew
Cathrow"
> > > > <acathrow(a)redhat.com>, "Simon Grinberg"
> > > > <sgrinber(a)redhat.com>,
> > > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"Eldan
> > > > Hildesheim" <info(a)eldanet.com>
> > > > Sent: Friday, May 18, 2012 12:35:34 PM
> > > > Subject: Re: [Engine-devel] custom properties sheet feature
> > > > page
> > > >
> > > > > ----- Original Message -----
> > > > > From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > > > Sent: Friday, May 18, 2012 12:25:45 PM
> > > > >
> > > > > inline
> > > > >
> > > > > Thanks,
> > > > > Gilad.
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > > > > To: "David Jaša" <djasa(a)redhat.com>,
"Miki Kenneth"
> > > > > > <mkenneth(a)redhat.com>, "Andrew Cathrow"
> > > > > > <acathrow(a)redhat.com>,
> > > > > > "Simon Grinberg" <sgrinber(a)redhat.com>,
"Eldan
> > > > > > Hildesheim"
> > > > > > <ehildesh(a)redhat.com>, "Eldan Hildesheim"
> > > > > > <info(a)eldanet.com>, "Gilad Chaplik"
<gchaplik(a)redhat.com>
> > > > > > Cc: engine-devel(a)ovirt.org
> > > > > > Sent: Friday, May 18, 2012 12:12:54 PM
> > > > > > Subject: Re: [Engine-devel] custom properties sheet
> > > > > > feature
> > > > > > page
> > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > > > > Sent: Friday, May 18, 2012 11:33:44 AM
> > > > > > >
> > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14 -0400:
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM
> > > > > > > > >
> > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 09:30
-0400:
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > > > > Sent: Thursday, May 17, 2012
3:40:19 PM
> > > > > > > > > > >
> > > > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012
v 08:10
> > > > > > > > > > > -0400:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > Please review/comment on the
Custom
> > > > > > > > > > > > Properties
> > > > > > > > > > > > Sheet
> > > > > > > > > > > > feature
> > > > > > > > > > > > page:
> > > > > > > > > > > >
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Just my $0.02:
> > > > > > > > > > >
> > > > > > > > > > > The table could have always empty
row at the
> > > > > > > > > > > bottom,
> > > > > > > > > > > eliminating
> > > > > > > > > > > one
> > > > > > > > > > > or
> > > > > > > > > > > all [+] buttons and saving user
one needless
> > > > > > > > > > > click:
> > > > > > > > > > >
> > > > > > > > > > > [ key1 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ key2 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ key3 |v] [
value ]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ "please select a
key..." |v]
> > > > > > > > > > >
> > > > > > > > > > > The [+] buttons at first and
second rows would
> > > > > > > > > > > allow
> > > > > > > > > > > user
> > > > > > > > > > > to
> > > > > > > > > > > insert a
> > > > > > > > > > > row at specified location to make
easy custom
> > > > > > > > > > > sorting
> > > > > > > > > > > of
> > > > > > > > > > > the
> > > > > > > > > > > properties
> > > > > > > > > > > (not applicable if properties are
auto-sorted,
> > > > > > > > > > > in
> > > > > > > > > > > that
> > > > > > > > > > > case,
> > > > > > > > > > > all
> > > > > > > > > > > [+]
> > > > > > > > > > > buttons can be actually removed).
> > > > > > > > > >
> > > > > > > > > > Thanks for the input, David. This is
an
> > > > > > > > > > interesting
> > > > > > > > > > idea.
> > > > > > > > > >
> > > > > > > > > > Indeed, when choosing a key in the last
row, we
> > > > > > > > > > can
> > > > > > > > > > automatically
> > > > > > > > > > add a new "please select a
key..." row, which
> > > > > > > > > > actually
> > > > > > > > > > saves
> > > > > > > > > > the
> > > > > > > > > > user a button-click for adding a new
row.
> > > > > > > > > >
> > > > > > > > > > On the other hand, from graphic-design
point of
> > > > > > > > > > view,
> > > > > > > > > > it
> > > > > > > > > > will
> > > > > > > > > > look
> > > > > > > > > > more consistent and "pretty"
if:
> > > > > > > > > > - The "please select a
key..." row won't be
> > > > > > > > > > displayed
> > > > > > > > > > (unless,
> > > > > > > > > > or
> > > > > > > > > > course, the user explicitly chose to
add another
> > > > > > > > > > row)
> > > > > > > > > > - All (full) rows will have both [+]
and [-]
> > > > > > > > > > buttons
> > > > > > > > > > next
> > > > > > > > > > to
> > > > > > > > > > them
> > > > > > >
> > > > > > > I should have probably elaborated more on this. To
me,
> > > > > > > UI
> > > > > > > with
> > > > > > > less
> > > > > > > elements looks cleaner and prettier even when one of
> > > > > > > them
> > > > > > > stands
> > > > > > > out.
> > > > > > > There's also nothing wrong with standing out if
the
> > > > > > > element
> > > > > > > has
> > > > > > > "special" meaning (one add vs bunch of
modify).
> > > > > > >
> > > > > > > Specifically, this looks cleaner to my eyes:
> > > > > > >
> > > > > > > [ key1 |v] [ value ] [-]
> > > > > > > [ key2 |v] [ value ] [-]
> > > > > > > [ key3 |v] [ value ] [-]
> > > > > > > [ "Please select a key..." |v]
> > > > > > >
> > > > > > > than
> > > > > > >
> > > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > > [ key3 |v] [ value ] [+] [-]
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Note that in your suggestion above, you cannot insert a
> > > > > > new
> > > > > > key
> > > > > > in
> > > > > > between existing keys - only at the end; so
> > > > > > although "cleaner", it has less functionality
(depends
> > > > > > also
> > > > > > on
> > > > > > the
> > > > > > sorting, which is another issue; if there is
> > > > > > auto-sorting,
> > > > > > it
> > > > > > doesn't matter).
> > > > > > It is also a matter of taste, I guess, so no absolute
> > > > > > right
> > > > > > or
> > > > > > wrong
> > > > > > here IMO.
> > > > > > [Others - you are welcome to comment as well]
> > > > >
> > > > > +1
> > > > >
> > > > > another tiny comment:
> > > > > can the empty line contain all the fields from initial
> > > > > state
> > > > > [["please select a key..."][field(empty)][+][-]]
> > > > > instead of showing them only after selecting a key.
> > > > > [["please select a key..."]]
> > > > >
> > > > > both of these scenarios are liable,
> > > > > I can select a key, regret (change back to [please select a
> > > > > key])
> > > > > and
> > > > > the field and buttons are still visible.
> > > > >
> > > > > so for the sake of complexity, I prefer to have only one.
> > > >
> > > > * Note that the field input control type (text-box,
> > > > drop-down)
> > > > depends on the key anyway (more accurately, on the validation
> > > > regular expression of the key), so what are you going to show
> > > > in
> > > > case of "please select a key..."?
> > >
> > > empty text-box
> > >
> > > >
> > > > * Need to make sure that validation fails in case field value
> > > > is
> > > > not
> > > > empty and key is "please select a key...".
> > > >
> >
> > I would prefer to just disable the value input field and do
> > re-validation upon change of key (clear the value if it fails
> > validation
> > against a new key) or server-side when it is changed (clear the
> > key-value pair altogether).
>
> +1 for disabling
> -1 for clearing - it is not advised to clear a field if its fails
> on
> validation.
>
> >
> > David
> >
> > > > Due to both of these reasons, I prefer to not show an input
> > > > control
> > > > at all in this case.
> > >
> > > still, I don't see any difference, except adding
> > > complexity/devel-time/bugs later on.
> > > plus I think it's nicer.
> > >
> > > >
> > > > * No problem of having a "+" button there; however, need
to
> > > > make
> > > > sure
> > > > that in case there is only one row in the sheet and it is
> > > > with
> > > > "please select a key...", the "-" button should
be either
> > > > hidden
> > > > or
> > > > disabled (or non-responsive), since we can't remove the last
> > > > row.
Don't forget to take this ^^^ also under consideration.
silence means agreement :)
> > >
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > If the [+] button in my proposal is just
greyed out
> > > > > > > > > instead
> > > > > > > > > of
> > > > > > > > > ommited,
> > > > > > > > > it could satisfy both requirements.
> > > > > > > >
> > > > > > > > Almost; the "please select a key..."
row is still
> > > > > > > > always
> > > > > > > > displayed;
> > > > > > > > question is if we want to save a button-click
(your
> > > > > > > > suggestion)
> > > > > > > > or
> > > > > > > > to have a "cleaner" sheet (my
suggestion).
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > i.e., instead of your suggestion, which
looks
> > > > > > > > > > like
> > > > > > > > > > this:
> > > > > > > > > >
> > > > > > > > > > [ key1 |v] [ value
] [+] [-]
> > > > > > > > > > [ key2 |v] [ value
] [+] [-]
> > > > > > > > > > [ key3 |v] [ value
] [-]
> > > > > > > > > > [ "please select a key..."
|v]
> > > > > > > > > >
> > > > > > > > > > it will be "prettier" like
this:
> > > > > > > > > >
> > > > > > > > > > [ key1 |v] [ value
] [+] [-]
> > > > > > > > > > [ key2 |v] [ value
] [+] [-]
> > > > > > > > > > [ key3 |v] [ value
] [+] [-]
> > > > > > > > > >
> > > > > > > > > > and only if clicking on [+], it will
be:
> > > > > > > > > >
> > > > > > > > > > [ key1 |v] [ value
] [+] [-]
> > > > > > > > > > [ key2 |v] [ value
] [+] [-]
> > > > > > > > > > [ key3 |v] [ value
] [+] [-]
> > > > > > > > > > [ "please select a key..."
|v]
> > > > > > > > > >
> > > > > > > > > > I believe that auto-sorting can be
confusing, as
> > > > > > > > > > it
> > > > > > > > > > can
> > > > > > > > > > result
> > > > > > > > > > in
> > > > > > > > > > rows "jumping" up and down
whenever changing the
> > > > > > > > > > selection(s)
> > > > > > > > > > in
> > > > > > > > > > the Key drop-down(s),
> > > > > > > > >
> > > > > > > > > this could be sort of mitigated by sorting
> > > > > > > > > server-side
> > > > > > > > > upon
> > > > > > > > > modification.
> > > > > > > > >
> > > > > > > > > > therefore I don't think it is a
good idea to
> > > > > > > > > > implement
> > > > > > > > > > it
> > > > > > > > > > here.
> > > > > > > > >
> > > > > > > > > OTOH if we're to be manual sorting
friendly, we
> > > > > > > > > should
> > > > > > > > > allow
> > > > > > > > > rearranging
> > > > > > > > > of the rows by drag & drop or by some
sort of move
> > > > > > > > > up/down
> > > > > > > > > buttons
> > > > > > > > > and
> > > > > > > > > the dialog would start to be cluttered.
> > > > > > > > >
> > > > > > > > > I don't really like either of these but
auto-sort
> > > > > > > > > is
> > > > > > > > > slightly
> > > > > > > > > better
> > > > > > > > > IMO
> > > > > > > > > as it is kept consistent accross various
VMs
> > > > > > > > > without
> > > > > > > > > user
> > > > > > > > > interaction.
> > > > > > > >
> > > > > > > > Indeed, auto-sort will keep the order consistent
> > > > > > > > across
> > > > > > > > all
> > > > > > > > VMs.
> > > > > > > > However, maybe the user would like to see the
> > > > > > > > properties
> > > > > > > > in
> > > > > > > > the
> > > > > > > > order in which he filled them; in this case,
your
> > > > > > > > suggestion
> > > > > > > > of
> > > > > > > > "move up/down buttons" is probably
relevant here.
> > > > > > > >
> > > > > > > > I believe that the majority of use-cases
won't
> > > > > > > > require
> > > > > > > > more
> > > > > > > > than
> > > > > > > > 2
> > > > > > > > or 3 custom properties per VM, so sorting
won't be
> > > > > > > > that
> > > > > > > > critical,
> > > > > > > > therefore I assume we can start without it; I
will
> > > > > > > > add
> > > > > > > > "sorting"
> > > > > > > > to the "open issues" section in the
wiki page.
> > > > > > > >
> > > > > > >
> > > > > > > That seems as more argument in favor of auto sorting.
> > > > > >
> > > > > > Or no sorting at all (i.e. simply display in order of
> > > > > > filling)...
> > > > > > In any case, open issue has been added to the wiki.
> > > > > >
> > > > > > >
> > > > > > > David
> > > > > > >
> > > > > > > > >
> > > > > > > > > David
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > David
> > > > > > > > > > >
> > > > > > > > > > > > ----
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Einav
> > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > >
> > > > > > > > > > > David Jaša, RHCE
> > > > > > > > > > >
> > > > > > > > > > > SPICE QE based in Brno
> > > > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72
7F0D 0278 B125
> > > > > > > > > > > CD00
> > > > > > > > > > > 22C3
> > > > > > > > > > > 3E24
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > David Jaša, RHCE
> > > > > > > > >
> > > > > > > > > SPICE QE based in Brno
> > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278
B125
> > > > > > > > > CD00
> > > > > > > > > 22C3
> > > > > > > > > 3E24
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > David Jaša, RHCE
> > > > > > >
> > > > > > > SPICE QE based in Brno
> > > > > > > GPG Key: 22C33E24
> > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00
> > > > > > > 22C3
> > > > > > > 3E24
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel(a)ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> > --
> >
> > David Jaša, RHCE
> >
> > SPICE QE based in Brno
> > GPG Key: 22C33E24
> > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> >
> >
> >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
6:50 a.m.
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "David Jaša" <djasa(a)redhat.com>, "Eldan Hildesheim"
<info(a)eldanet.com>, engine-devel(a)ovirt.org, "Eldan
Hildesheim" <ehildesh(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>
Sent: Friday, May 18, 2012 1:15:16 PM
Subject: Re: [Engine-devel] custom properties sheet feature page
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> Cc: "Eldan Hildesheim" <info(a)eldanet.com>, engine-devel(a)ovirt.org,
> "Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan
> Hildesheim" <ehildesh(a)redhat.com>, "David Jaša"
<djasa(a)redhat.com>
> Sent: Friday, May 18, 2012 1:02:03 PM
> Subject: Re: [Engine-devel] custom properties sheet feature page
>
> > ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > Sent: Friday, May 18, 2012 12:56:00 PM
> >
> > ----- Original Message -----
> > > From: "David Jaša" <djasa(a)redhat.com>
> > > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > Cc: "Einav Cohen" <ecohen(a)redhat.com>,
engine-devel(a)ovirt.org,
> > > "Miki Kenneth" <mkenneth(a)redhat.com>, "Andrew
Cathrow"
> > > <acathrow(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>,
> > > "Eldan Hildesheim" <ehildesh(a)redhat.com>, "Eldan
> > > Hildesheim" <info(a)eldanet.com>
> > > Sent: Friday, May 18, 2012 12:51:43 PM
> > > Subject: Re: [Engine-devel] custom properties sheet feature
> > > page
> > >
> > > Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:
> > > > ----- Original Message -----
> > > > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > > > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > > > Cc: engine-devel(a)ovirt.org, "David Jaša"
> > > > > <djasa(a)redhat.com>,
> > > > > "Miki Kenneth" <mkenneth(a)redhat.com>,
"Andrew Cathrow"
> > > > > <acathrow(a)redhat.com>, "Simon Grinberg"
> > > > > <sgrinber(a)redhat.com>,
> > > > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"Eldan
> > > > > Hildesheim" <info(a)eldanet.com>
> > > > > Sent: Friday, May 18, 2012 12:35:34 PM
> > > > > Subject: Re: [Engine-devel] custom properties sheet feature
> > > > > page
> > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Gilad Chaplik"
<gchaplik(a)redhat.com>
> > > > > > Sent: Friday, May 18, 2012 12:25:45 PM
> > > > > >
> > > > > > inline
> > > > > >
> > > > > > Thanks,
> > > > > > Gilad.
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > > From: "Einav Cohen"
<ecohen(a)redhat.com>
> > > > > > > To: "David Jaša" <djasa(a)redhat.com>,
"Miki Kenneth"
> > > > > > > <mkenneth(a)redhat.com>, "Andrew
Cathrow"
> > > > > > > <acathrow(a)redhat.com>,
> > > > > > > "Simon Grinberg"
<sgrinber(a)redhat.com>, "Eldan
> > > > > > > Hildesheim"
> > > > > > > <ehildesh(a)redhat.com>, "Eldan
Hildesheim"
> > > > > > > <info(a)eldanet.com>, "Gilad Chaplik"
> > > > > > > <gchaplik(a)redhat.com>
> > > > > > > Cc: engine-devel(a)ovirt.org
> > > > > > > Sent: Friday, May 18, 2012 12:12:54 PM
> > > > > > > Subject: Re: [Engine-devel] custom properties sheet
> > > > > > > feature
> > > > > > > page
> > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > Sent: Friday, May 18, 2012 11:33:44 AM
> > > > > > > >
> > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14
-0400:
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > > > Sent: Thursday, May 17, 2012 4:44:10
PM
> > > > > > > > > >
> > > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v
09:30 -0400:
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > > > > > Sent: Thursday, May 17, 2012
3:40:19 PM
> > > > > > > > > > > >
> > > > > > > > > > > > Einav Cohen píše v Čt 17. 05.
2012 v 08:10
> > > > > > > > > > > > -0400:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please review/comment on
the Custom
> > > > > > > > > > > > > Properties
> > > > > > > > > > > > > Sheet
> > > > > > > > > > > > > feature
> > > > > > > > > > > > > page:
> > > > > > > > > > > > >
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Just my $0.02:
> > > > > > > > > > > >
> > > > > > > > > > > > The table could have always
empty row at the
> > > > > > > > > > > > bottom,
> > > > > > > > > > > > eliminating
> > > > > > > > > > > > one
> > > > > > > > > > > > or
> > > > > > > > > > > > all [+] buttons and saving
user one needless
> > > > > > > > > > > > click:
> > > > > > > > > > > >
> > > > > > > > > > > > [ key1
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ key2
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ key3
|v] [ value ]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ "please select a
key..." |v]
> > > > > > > > > > > >
> > > > > > > > > > > > The [+] buttons at first and
second rows
> > > > > > > > > > > > would
> > > > > > > > > > > > allow
> > > > > > > > > > > > user
> > > > > > > > > > > > to
> > > > > > > > > > > > insert a
> > > > > > > > > > > > row at specified location to
make easy custom
> > > > > > > > > > > > sorting
> > > > > > > > > > > > of
> > > > > > > > > > > > the
> > > > > > > > > > > > properties
> > > > > > > > > > > > (not applicable if properties
are
> > > > > > > > > > > > auto-sorted,
> > > > > > > > > > > > in
> > > > > > > > > > > > that
> > > > > > > > > > > > case,
> > > > > > > > > > > > all
> > > > > > > > > > > > [+]
> > > > > > > > > > > > buttons can be actually
removed).
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the input, David. This
is an
> > > > > > > > > > > interesting
> > > > > > > > > > > idea.
> > > > > > > > > > >
> > > > > > > > > > > Indeed, when choosing a key in the
last row, we
> > > > > > > > > > > can
> > > > > > > > > > > automatically
> > > > > > > > > > > add a new "please select a
key..." row, which
> > > > > > > > > > > actually
> > > > > > > > > > > saves
> > > > > > > > > > > the
> > > > > > > > > > > user a button-click for adding a
new row.
> > > > > > > > > > >
> > > > > > > > > > > On the other hand, from
graphic-design point of
> > > > > > > > > > > view,
> > > > > > > > > > > it
> > > > > > > > > > > will
> > > > > > > > > > > look
> > > > > > > > > > > more consistent and
"pretty" if:
> > > > > > > > > > > - The "please select a
key..." row won't be
> > > > > > > > > > > displayed
> > > > > > > > > > > (unless,
> > > > > > > > > > > or
> > > > > > > > > > > course, the user explicitly chose
to add
> > > > > > > > > > > another
> > > > > > > > > > > row)
> > > > > > > > > > > - All (full) rows will have both
[+] and [-]
> > > > > > > > > > > buttons
> > > > > > > > > > > next
> > > > > > > > > > > to
> > > > > > > > > > > them
> > > > > > > >
> > > > > > > > I should have probably elaborated more on this.
To
> > > > > > > > me,
> > > > > > > > UI
> > > > > > > > with
> > > > > > > > less
> > > > > > > > elements looks cleaner and prettier even when one
of
> > > > > > > > them
> > > > > > > > stands
> > > > > > > > out.
> > > > > > > > There's also nothing wrong with standing out
if the
> > > > > > > > element
> > > > > > > > has
> > > > > > > > "special" meaning (one add vs bunch of
modify).
> > > > > > > >
> > > > > > > > Specifically, this looks cleaner to my eyes:
> > > > > > > >
> > > > > > > > [ key1 |v] [ value ] [-]
> > > > > > > > [ key2 |v] [ value ] [-]
> > > > > > > > [ key3 |v] [ value ] [-]
> > > > > > > > [ "Please select a key..." |v]
> > > > > > > >
> > > > > > > > than
> > > > > > > >
> > > > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > > > [ key3 |v] [ value ] [+] [-]
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Note that in your suggestion above, you cannot insert
a
> > > > > > > new
> > > > > > > key
> > > > > > > in
> > > > > > > between existing keys - only at the end; so
> > > > > > > although "cleaner", it has less
functionality (depends
> > > > > > > also
> > > > > > > on
> > > > > > > the
> > > > > > > sorting, which is another issue; if there is
> > > > > > > auto-sorting,
> > > > > > > it
> > > > > > > doesn't matter).
> > > > > > > It is also a matter of taste, I guess, so no absolute
> > > > > > > right
> > > > > > > or
> > > > > > > wrong
> > > > > > > here IMO.
> > > > > > > [Others - you are welcome to comment as well]
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > another tiny comment:
> > > > > > can the empty line contain all the fields from initial
> > > > > > state
> > > > > > [["please select a key..."][field(empty)][+][-]]
> > > > > > instead of showing them only after selecting a key.
> > > > > > [["please select a key..."]]
> > > > > >
> > > > > > both of these scenarios are liable,
> > > > > > I can select a key, regret (change back to [please select
> > > > > > a
> > > > > > key])
> > > > > > and
> > > > > > the field and buttons are still visible.
> > > > > >
> > > > > > so for the sake of complexity, I prefer to have only one.
> > > > >
> > > > > * Note that the field input control type (text-box,
> > > > > drop-down)
> > > > > depends on the key anyway (more accurately, on the
> > > > > validation
> > > > > regular expression of the key), so what are you going to
> > > > > show
> > > > > in
> > > > > case of "please select a key..."?
> > > >
> > > > empty text-box
> > > >
> > > > >
> > > > > * Need to make sure that validation fails in case field
> > > > > value
> > > > > is
> > > > > not
> > > > > empty and key is "please select a key...".
> > > > >
> > >
> > > I would prefer to just disable the value input field and do
> > > re-validation upon change of key (clear the value if it fails
> > > validation
> > > against a new key) or server-side when it is changed (clear the
> > > key-value pair altogether).
> >
> > +1 for disabling
> > -1 for clearing - it is not advised to clear a field if its fails
> > on
> > validation.
Actually while implementing it, having a disabled field makes the user think why it's
disabled, it is a bit confusing + less minimal :)
I suggest to leave it as Einav's initial proposal.
> >
> > >
> > > David
> > >
> > > > > Due to both of these reasons, I prefer to not show an input
> > > > > control
> > > > > at all in this case.
> > > >
> > > > still, I don't see any difference, except adding
> > > > complexity/devel-time/bugs later on.
> > > > plus I think it's nicer.
> > > >
> > > > >
> > > > > * No problem of having a "+" button there; however,
need to
> > > > > make
> > > > > sure
> > > > > that in case there is only one row in the sheet and it is
> > > > > with
> > > > > "please select a key...", the "-" button
should be either
> > > > > hidden
> > > > > or
> > > > > disabled (or non-responsive), since we can't remove the
> > > > > last
> > > > > row.
>
> Don't forget to take this ^^^ also under consideration.
silence means agreement :)
>
> > > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > If the [+] button in my proposal is
just greyed
> > > > > > > > > > out
> > > > > > > > > > instead
> > > > > > > > > > of
> > > > > > > > > > ommited,
> > > > > > > > > > it could satisfy both requirements.
> > > > > > > > >
> > > > > > > > > Almost; the "please select a
key..." row is still
> > > > > > > > > always
> > > > > > > > > displayed;
> > > > > > > > > question is if we want to save a
button-click (your
> > > > > > > > > suggestion)
> > > > > > > > > or
> > > > > > > > > to have a "cleaner" sheet (my
suggestion).
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > i.e., instead of your suggestion,
which looks
> > > > > > > > > > > like
> > > > > > > > > > > this:
> > > > > > > > > > >
> > > > > > > > > > > [ key1 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ key2 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ key3 |v] [
value ]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ "please select a
key..." |v]
> > > > > > > > > > >
> > > > > > > > > > > it will be "prettier"
like this:
> > > > > > > > > > >
> > > > > > > > > > > [ key1 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ key2 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ key3 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > >
> > > > > > > > > > > and only if clicking on [+], it
will be:
> > > > > > > > > > >
> > > > > > > > > > > [ key1 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ key2 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ key3 |v] [
value ] [+]
> > > > > > > > > > > [-]
> > > > > > > > > > > [ "please select a
key..." |v]
> > > > > > > > > > >
> > > > > > > > > > > I believe that auto-sorting can be
confusing,
> > > > > > > > > > > as
> > > > > > > > > > > it
> > > > > > > > > > > can
> > > > > > > > > > > result
> > > > > > > > > > > in
> > > > > > > > > > > rows "jumping" up and
down whenever changing
> > > > > > > > > > > the
> > > > > > > > > > > selection(s)
> > > > > > > > > > > in
> > > > > > > > > > > the Key drop-down(s),
> > > > > > > > > >
> > > > > > > > > > this could be sort of mitigated by
sorting
> > > > > > > > > > server-side
> > > > > > > > > > upon
> > > > > > > > > > modification.
> > > > > > > > > >
> > > > > > > > > > > therefore I don't think it is
a good idea to
> > > > > > > > > > > implement
> > > > > > > > > > > it
> > > > > > > > > > > here.
> > > > > > > > > >
> > > > > > > > > > OTOH if we're to be manual sorting
friendly, we
> > > > > > > > > > should
> > > > > > > > > > allow
> > > > > > > > > > rearranging
> > > > > > > > > > of the rows by drag & drop or by
some sort of
> > > > > > > > > > move
> > > > > > > > > > up/down
> > > > > > > > > > buttons
> > > > > > > > > > and
> > > > > > > > > > the dialog would start to be
cluttered.
> > > > > > > > > >
> > > > > > > > > > I don't really like either of these
but auto-sort
> > > > > > > > > > is
> > > > > > > > > > slightly
> > > > > > > > > > better
> > > > > > > > > > IMO
> > > > > > > > > > as it is kept consistent accross
various VMs
> > > > > > > > > > without
> > > > > > > > > > user
> > > > > > > > > > interaction.
> > > > > > > > >
> > > > > > > > > Indeed, auto-sort will keep the order
consistent
> > > > > > > > > across
> > > > > > > > > all
> > > > > > > > > VMs.
> > > > > > > > > However, maybe the user would like to see
the
> > > > > > > > > properties
> > > > > > > > > in
> > > > > > > > > the
> > > > > > > > > order in which he filled them; in this case,
your
> > > > > > > > > suggestion
> > > > > > > > > of
> > > > > > > > > "move up/down buttons" is probably
relevant here.
> > > > > > > > >
> > > > > > > > > I believe that the majority of use-cases
won't
> > > > > > > > > require
> > > > > > > > > more
> > > > > > > > > than
> > > > > > > > > 2
> > > > > > > > > or 3 custom properties per VM, so sorting
won't be
> > > > > > > > > that
> > > > > > > > > critical,
> > > > > > > > > therefore I assume we can start without it;
I will
> > > > > > > > > add
> > > > > > > > > "sorting"
> > > > > > > > > to the "open issues" section in
the wiki page.
> > > > > > > > >
> > > > > > > >
> > > > > > > > That seems as more argument in favor of auto
sorting.
> > > > > > >
> > > > > > > Or no sorting at all (i.e. simply display in order of
> > > > > > > filling)...
> > > > > > > In any case, open issue has been added to the wiki.
> > > > > > >
> > > > > > > >
> > > > > > > > David
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > David
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > David
> > > > > > > > > > > >
> > > > > > > > > > > > > ----
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Einav
> > > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > > Engine-devel mailing
list
> > > > > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > >
> > > > > > > > > > > > David Jaša, RHCE
> > > > > > > > > > > >
> > > > > > > > > > > > SPICE QE based in Brno
> > > > > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > > > > Fingerprint: 513A 060B D1B4
2A72 7F0D 0278
> > > > > > > > > > > > B125
> > > > > > > > > > > > CD00
> > > > > > > > > > > > 22C3
> > > > > > > > > > > > 3E24
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > David Jaša, RHCE
> > > > > > > > > >
> > > > > > > > > > SPICE QE based in Brno
> > > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D
0278 B125
> > > > > > > > > > CD00
> > > > > > > > > > 22C3
> > > > > > > > > > 3E24
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > David Jaša, RHCE
> > > > > > > >
> > > > > > > > SPICE QE based in Brno
> > > > > > > > GPG Key: 22C33E24
> > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125
CD00
> > > > > > > > 22C3
> > > > > > > > 3E24
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > > --
> > >
> > > David Jaša, RHCE
> > >
> > > SPICE QE based in Brno
> > > GPG Key: 22C33E24
> > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> > >
> > >
> > >
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> >
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:47 a.m.
[top posting]
Mock-ups have been updated according to this thread.
You can check it in the feature page:
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
If you have any further comments, please share.
----
Thanks,
Einav
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
To: "David Jaša" <djasa(a)redhat.com>
Cc: "Einav Cohen" <ecohen(a)redhat.com>, "Eldan Hildesheim"
<info(a)eldanet.com>, engine-devel(a)ovirt.org, "Eldan
Hildesheim" <ehildesh(a)redhat.com>, "Simon Grinberg"
<sgrinber(a)redhat.com>
Sent: Sunday, May 20, 2012 3:50:15 PM
Subject: Re: [Engine-devel] custom properties sheet feature page
----- Original Message -----
> From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "David Jaša" <djasa(a)redhat.com>, "Eldan Hildesheim"
> <info(a)eldanet.com>, engine-devel(a)ovirt.org, "Eldan
> Hildesheim" <ehildesh(a)redhat.com>, "Simon Grinberg"
> <sgrinber(a)redhat.com>
> Sent: Friday, May 18, 2012 1:15:16 PM
> Subject: Re: [Engine-devel] custom properties sheet feature page
>
>
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > Cc: "Eldan Hildesheim" <info(a)eldanet.com>,
> > engine-devel(a)ovirt.org,
> > "Simon Grinberg" <sgrinber(a)redhat.com>, "Eldan
> > Hildesheim" <ehildesh(a)redhat.com>, "David Jaša"
> > <djasa(a)redhat.com>
> > Sent: Friday, May 18, 2012 1:02:03 PM
> > Subject: Re: [Engine-devel] custom properties sheet feature page
> >
> > > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > Sent: Friday, May 18, 2012 12:56:00 PM
> > >
> > > ----- Original Message -----
> > > > From: "David Jaša" <djasa(a)redhat.com>
> > > > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > > Cc: "Einav Cohen" <ecohen(a)redhat.com>,
> > > > engine-devel(a)ovirt.org,
> > > > "Miki Kenneth" <mkenneth(a)redhat.com>, "Andrew
Cathrow"
> > > > <acathrow(a)redhat.com>, "Simon Grinberg"
> > > > <sgrinber(a)redhat.com>,
> > > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"Eldan
> > > > Hildesheim" <info(a)eldanet.com>
> > > > Sent: Friday, May 18, 2012 12:51:43 PM
> > > > Subject: Re: [Engine-devel] custom properties sheet feature
> > > > page
> > > >
> > > > Gilad Chaplik píše v Pá 18. 05. 2012 v 05:44 -0400:
> > > > > ----- Original Message -----
> > > > > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > > > > To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > > > > > Cc: engine-devel(a)ovirt.org, "David Jaša"
> > > > > > <djasa(a)redhat.com>,
> > > > > > "Miki Kenneth" <mkenneth(a)redhat.com>,
"Andrew Cathrow"
> > > > > > <acathrow(a)redhat.com>, "Simon Grinberg"
> > > > > > <sgrinber(a)redhat.com>,
> > > > > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"Eldan
> > > > > > Hildesheim" <info(a)eldanet.com>
> > > > > > Sent: Friday, May 18, 2012 12:35:34 PM
> > > > > > Subject: Re: [Engine-devel] custom properties sheet
> > > > > > feature
> > > > > > page
> > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Gilad Chaplik"
<gchaplik(a)redhat.com>
> > > > > > > Sent: Friday, May 18, 2012 12:25:45 PM
> > > > > > >
> > > > > > > inline
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Gilad.
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Einav Cohen"
<ecohen(a)redhat.com>
> > > > > > > > To: "David Jaša"
<djasa(a)redhat.com>, "Miki Kenneth"
> > > > > > > > <mkenneth(a)redhat.com>, "Andrew
Cathrow"
> > > > > > > > <acathrow(a)redhat.com>,
> > > > > > > > "Simon Grinberg"
<sgrinber(a)redhat.com>, "Eldan
> > > > > > > > Hildesheim"
> > > > > > > > <ehildesh(a)redhat.com>, "Eldan
Hildesheim"
> > > > > > > > <info(a)eldanet.com>, "Gilad
Chaplik"
> > > > > > > > <gchaplik(a)redhat.com>
> > > > > > > > Cc: engine-devel(a)ovirt.org
> > > > > > > > Sent: Friday, May 18, 2012 12:12:54 PM
> > > > > > > > Subject: Re: [Engine-devel] custom properties
sheet
> > > > > > > > feature
> > > > > > > > page
> > > > > > > >
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > > Sent: Friday, May 18, 2012 11:33:44 AM
> > > > > > > > >
> > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012 v 10:14
-0400:
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "David Jaša"
<djasa(a)redhat.com>
> > > > > > > > > > > Sent: Thursday, May 17, 2012
4:44:10 PM
> > > > > > > > > > >
> > > > > > > > > > > Einav Cohen píše v Čt 17. 05. 2012
v 09:30
> > > > > > > > > > > -0400:
> > > > > > > > > > > > > ----- Original Message
-----
> > > > > > > > > > > > > From: "David
Jaša" <djasa(a)redhat.com>
> > > > > > > > > > > > > Sent: Thursday, May 17,
2012 3:40:19 PM
> > > > > > > > > > > > >
> > > > > > > > > > > > > Einav Cohen píše v Čt
17. 05. 2012 v 08:10
> > > > > > > > > > > > > -0400:
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Please
review/comment on the Custom
> > > > > > > > > > > > > > Properties
> > > > > > > > > > > > > > Sheet
> > > > > > > > > > > > > > feature
> > > > > > > > > > > > > > page:
> > > > > > > > > > > > > >
http://www.ovirt.org/wiki/Features/CustomPropertiesSheet
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Just my $0.02:
> > > > > > > > > > > > >
> > > > > > > > > > > > > The table could have
always empty row at
> > > > > > > > > > > > > the
> > > > > > > > > > > > > bottom,
> > > > > > > > > > > > > eliminating
> > > > > > > > > > > > > one
> > > > > > > > > > > > > or
> > > > > > > > > > > > > all [+] buttons and
saving user one
> > > > > > > > > > > > > needless
> > > > > > > > > > > > > click:
> > > > > > > > > > > > >
> > > > > > > > > > > > > [ key1
|v] [ value ]
> > > > > > > > > > > > > [+]
> > > > > > > > > > > > > [-]
> > > > > > > > > > > > > [ key2
|v] [ value ]
> > > > > > > > > > > > > [+]
> > > > > > > > > > > > > [-]
> > > > > > > > > > > > > [ key3
|v] [ value ]
> > > > > > > > > > > > > [-]
> > > > > > > > > > > > > [ "please select a
key..." |v]
> > > > > > > > > > > > >
> > > > > > > > > > > > > The [+] buttons at first
and second rows
> > > > > > > > > > > > > would
> > > > > > > > > > > > > allow
> > > > > > > > > > > > > user
> > > > > > > > > > > > > to
> > > > > > > > > > > > > insert a
> > > > > > > > > > > > > row at specified
location to make easy
> > > > > > > > > > > > > custom
> > > > > > > > > > > > > sorting
> > > > > > > > > > > > > of
> > > > > > > > > > > > > the
> > > > > > > > > > > > > properties
> > > > > > > > > > > > > (not applicable if
properties are
> > > > > > > > > > > > > auto-sorted,
> > > > > > > > > > > > > in
> > > > > > > > > > > > > that
> > > > > > > > > > > > > case,
> > > > > > > > > > > > > all
> > > > > > > > > > > > > [+]
> > > > > > > > > > > > > buttons can be actually
removed).
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the input, David.
This is an
> > > > > > > > > > > > interesting
> > > > > > > > > > > > idea.
> > > > > > > > > > > >
> > > > > > > > > > > > Indeed, when choosing a key
in the last row,
> > > > > > > > > > > > we
> > > > > > > > > > > > can
> > > > > > > > > > > > automatically
> > > > > > > > > > > > add a new "please select
a key..." row, which
> > > > > > > > > > > > actually
> > > > > > > > > > > > saves
> > > > > > > > > > > > the
> > > > > > > > > > > > user a button-click for
adding a new row.
> > > > > > > > > > > >
> > > > > > > > > > > > On the other hand, from
graphic-design point
> > > > > > > > > > > > of
> > > > > > > > > > > > view,
> > > > > > > > > > > > it
> > > > > > > > > > > > will
> > > > > > > > > > > > look
> > > > > > > > > > > > more consistent and
"pretty" if:
> > > > > > > > > > > > - The "please select a
key..." row won't be
> > > > > > > > > > > > displayed
> > > > > > > > > > > > (unless,
> > > > > > > > > > > > or
> > > > > > > > > > > > course, the user explicitly
chose to add
> > > > > > > > > > > > another
> > > > > > > > > > > > row)
> > > > > > > > > > > > - All (full) rows will have
both [+] and [-]
> > > > > > > > > > > > buttons
> > > > > > > > > > > > next
> > > > > > > > > > > > to
> > > > > > > > > > > > them
> > > > > > > > >
> > > > > > > > > I should have probably elaborated more on
this. To
> > > > > > > > > me,
> > > > > > > > > UI
> > > > > > > > > with
> > > > > > > > > less
> > > > > > > > > elements looks cleaner and prettier even
when one
> > > > > > > > > of
> > > > > > > > > them
> > > > > > > > > stands
> > > > > > > > > out.
> > > > > > > > > There's also nothing wrong with standing
out if the
> > > > > > > > > element
> > > > > > > > > has
> > > > > > > > > "special" meaning (one add vs
bunch of modify).
> > > > > > > > >
> > > > > > > > > Specifically, this looks cleaner to my
eyes:
> > > > > > > > >
> > > > > > > > > [ key1 |v] [ value ]
[-]
> > > > > > > > > [ key2 |v] [ value ]
[-]
> > > > > > > > > [ key3 |v] [ value ]
[-]
> > > > > > > > > [ "Please select a key..." |v]
> > > > > > > > >
> > > > > > > > > than
> > > > > > > > >
> > > > > > > > > [ key1 |v] [ value ] [+] [-]
> > > > > > > > > [ key2 |v] [ value ] [+] [-]
> > > > > > > > > [ key3 |v] [ value ] [+] [-]
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > Note that in your suggestion above, you cannot
insert
> > > > > > > > a
> > > > > > > > new
> > > > > > > > key
> > > > > > > > in
> > > > > > > > between existing keys - only at the end; so
> > > > > > > > although "cleaner", it has less
functionality
> > > > > > > > (depends
> > > > > > > > also
> > > > > > > > on
> > > > > > > > the
> > > > > > > > sorting, which is another issue; if there is
> > > > > > > > auto-sorting,
> > > > > > > > it
> > > > > > > > doesn't matter).
> > > > > > > > It is also a matter of taste, I guess, so no
absolute
> > > > > > > > right
> > > > > > > > or
> > > > > > > > wrong
> > > > > > > > here IMO.
> > > > > > > > [Others - you are welcome to comment as well]
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > another tiny comment:
> > > > > > > can the empty line contain all the fields from
initial
> > > > > > > state
> > > > > > > [["please select a
key..."][field(empty)][+][-]]
> > > > > > > instead of showing them only after selecting a key.
> > > > > > > [["please select a key..."]]
> > > > > > >
> > > > > > > both of these scenarios are liable,
> > > > > > > I can select a key, regret (change back to [please
> > > > > > > select
> > > > > > > a
> > > > > > > key])
> > > > > > > and
> > > > > > > the field and buttons are still visible.
> > > > > > >
> > > > > > > so for the sake of complexity, I prefer to have only
> > > > > > > one.
> > > > > >
> > > > > > * Note that the field input control type (text-box,
> > > > > > drop-down)
> > > > > > depends on the key anyway (more accurately, on the
> > > > > > validation
> > > > > > regular expression of the key), so what are you going to
> > > > > > show
> > > > > > in
> > > > > > case of "please select a key..."?
> > > > >
> > > > > empty text-box
> > > > >
> > > > > >
> > > > > > * Need to make sure that validation fails in case field
> > > > > > value
> > > > > > is
> > > > > > not
> > > > > > empty and key is "please select a key...".
> > > > > >
> > > >
> > > > I would prefer to just disable the value input field and do
> > > > re-validation upon change of key (clear the value if it fails
> > > > validation
> > > > against a new key) or server-side when it is changed (clear
> > > > the
> > > > key-value pair altogether).
> > >
> > > +1 for disabling
> > > -1 for clearing - it is not advised to clear a field if its
> > > fails
> > > on
> > > validation.
Actually while implementing it, having a disabled field makes the
user think why it's disabled, it is a bit confusing + less minimal
:)
I suggest to leave it as Einav's initial proposal.
> > >
> > > >
> > > > David
> > > >
> > > > > > Due to both of these reasons, I prefer to not show an
> > > > > > input
> > > > > > control
> > > > > > at all in this case.
> > > > >
> > > > > still, I don't see any difference, except adding
> > > > > complexity/devel-time/bugs later on.
> > > > > plus I think it's nicer.
> > > > >
> > > > > >
> > > > > > * No problem of having a "+" button there;
however, need
> > > > > > to
> > > > > > make
> > > > > > sure
> > > > > > that in case there is only one row in the sheet and it is
> > > > > > with
> > > > > > "please select a key...", the "-"
button should be either
> > > > > > hidden
> > > > > > or
> > > > > > disabled (or non-responsive), since we can't remove
the
> > > > > > last
> > > > > > row.
> >
> > Don't forget to take this ^^^ also under consideration.
>
> silence means agreement :)
>
> >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > If the [+] button in my proposal
is just greyed
> > > > > > > > > > > out
> > > > > > > > > > > instead
> > > > > > > > > > > of
> > > > > > > > > > > ommited,
> > > > > > > > > > > it could satisfy both
requirements.
> > > > > > > > > >
> > > > > > > > > > Almost; the "please select a
key..." row is still
> > > > > > > > > > always
> > > > > > > > > > displayed;
> > > > > > > > > > question is if we want to save a
button-click
> > > > > > > > > > (your
> > > > > > > > > > suggestion)
> > > > > > > > > > or
> > > > > > > > > > to have a "cleaner" sheet (my
suggestion).
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > i.e., instead of your
suggestion, which looks
> > > > > > > > > > > > like
> > > > > > > > > > > > this:
> > > > > > > > > > > >
> > > > > > > > > > > > [ key1
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ key2
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ key3
|v] [ value ]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ "please select a
key..." |v]
> > > > > > > > > > > >
> > > > > > > > > > > > it will be
"prettier" like this:
> > > > > > > > > > > >
> > > > > > > > > > > > [ key1
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ key2
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ key3
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > >
> > > > > > > > > > > > and only if clicking on [+],
it will be:
> > > > > > > > > > > >
> > > > > > > > > > > > [ key1
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ key2
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ key3
|v] [ value ] [+]
> > > > > > > > > > > > [-]
> > > > > > > > > > > > [ "please select a
key..." |v]
> > > > > > > > > > > >
> > > > > > > > > > > > I believe that auto-sorting
can be confusing,
> > > > > > > > > > > > as
> > > > > > > > > > > > it
> > > > > > > > > > > > can
> > > > > > > > > > > > result
> > > > > > > > > > > > in
> > > > > > > > > > > > rows "jumping" up
and down whenever changing
> > > > > > > > > > > > the
> > > > > > > > > > > > selection(s)
> > > > > > > > > > > > in
> > > > > > > > > > > > the Key drop-down(s),
> > > > > > > > > > >
> > > > > > > > > > > this could be sort of mitigated by
sorting
> > > > > > > > > > > server-side
> > > > > > > > > > > upon
> > > > > > > > > > > modification.
> > > > > > > > > > >
> > > > > > > > > > > > therefore I don't think
it is a good idea to
> > > > > > > > > > > > implement
> > > > > > > > > > > > it
> > > > > > > > > > > > here.
> > > > > > > > > > >
> > > > > > > > > > > OTOH if we're to be manual
sorting friendly, we
> > > > > > > > > > > should
> > > > > > > > > > > allow
> > > > > > > > > > > rearranging
> > > > > > > > > > > of the rows by drag & drop or
by some sort of
> > > > > > > > > > > move
> > > > > > > > > > > up/down
> > > > > > > > > > > buttons
> > > > > > > > > > > and
> > > > > > > > > > > the dialog would start to be
cluttered.
> > > > > > > > > > >
> > > > > > > > > > > I don't really like either of
these but
> > > > > > > > > > > auto-sort
> > > > > > > > > > > is
> > > > > > > > > > > slightly
> > > > > > > > > > > better
> > > > > > > > > > > IMO
> > > > > > > > > > > as it is kept consistent accross
various VMs
> > > > > > > > > > > without
> > > > > > > > > > > user
> > > > > > > > > > > interaction.
> > > > > > > > > >
> > > > > > > > > > Indeed, auto-sort will keep the order
consistent
> > > > > > > > > > across
> > > > > > > > > > all
> > > > > > > > > > VMs.
> > > > > > > > > > However, maybe the user would like to
see the
> > > > > > > > > > properties
> > > > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > order in which he filled them; in this
case, your
> > > > > > > > > > suggestion
> > > > > > > > > > of
> > > > > > > > > > "move up/down buttons" is
probably relevant here.
> > > > > > > > > >
> > > > > > > > > > I believe that the majority of
use-cases won't
> > > > > > > > > > require
> > > > > > > > > > more
> > > > > > > > > > than
> > > > > > > > > > 2
> > > > > > > > > > or 3 custom properties per VM, so
sorting won't
> > > > > > > > > > be
> > > > > > > > > > that
> > > > > > > > > > critical,
> > > > > > > > > > therefore I assume we can start without
it; I
> > > > > > > > > > will
> > > > > > > > > > add
> > > > > > > > > > "sorting"
> > > > > > > > > > to the "open issues" section
in the wiki page.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > That seems as more argument in favor of
auto
> > > > > > > > > sorting.
> > > > > > > >
> > > > > > > > Or no sorting at all (i.e. simply display in
order of
> > > > > > > > filling)...
> > > > > > > > In any case, open issue has been added to the
wiki.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > David
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > David
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > David
> > > > > > > > > > > > >
> > > > > > > > > > > > > > ----
> > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > Einav
> > > > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > > > Engine-devel
mailing list
> > > > > > > > > > > > > >
Engine-devel(a)ovirt.org
> > > > > > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > >
> > > > > > > > > > > > > David Jaša, RHCE
> > > > > > > > > > > > >
> > > > > > > > > > > > > SPICE QE based in Brno
> > > > > > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > > > > > Fingerprint: 513A 060B
D1B4 2A72 7F0D 0278
> > > > > > > > > > > > > B125
> > > > > > > > > > > > > CD00
> > > > > > > > > > > > > 22C3
> > > > > > > > > > > > > 3E24
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > > Engine-devel mailing
list
> > > > > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > >
> > > > > > > > > > > David Jaša, RHCE
> > > > > > > > > > >
> > > > > > > > > > > SPICE QE based in Brno
> > > > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72
7F0D 0278 B125
> > > > > > > > > > > CD00
> > > > > > > > > > > 22C3
> > > > > > > > > > > 3E24
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > David Jaša, RHCE
> > > > > > > > >
> > > > > > > > > SPICE QE based in Brno
> > > > > > > > > GPG Key: 22C33E24
> > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278
B125
> > > > > > > > > CD00
> > > > > > > > > 22C3
> > > > > > > > > 3E24
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel(a)ovirt.org
> > > > > > > > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > > --
> > > >
> > > > David Jaša, RHCE
> > > >
> > > > SPICE QE based in Brno
> > > > GPG Key: 22C33E24
> > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3
> > > > 3E24
> > > >
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
4366
days inactive
4372
days old
21 comments
6 participants
participants (6)
-
Andrew Cathrow -
David Jaša -
Einav Cohen -
Gilad Chaplik -
Itamar Heim -
Simon Grinberg