> ----- Original Message ----- > From: "David Jaša" <dj...@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" <dj...@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel