3:50 p.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