Re: Regarding issue 1241 - Mailing list pgadmin-hackers
From | Dave Page |
---|---|
Subject | Re: Regarding issue 1241 |
Date | |
Msg-id | CA+OCxoy+w5PKJ1jgq-+QigONn7=hZHPHsUtOJ=u=p1Eabc-o2w@mail.gmail.com Whole thread Raw |
In response to | Re: Regarding issue 1241 (Ashesh Vashi <ashesh.vashi@enterprisedb.com>) |
Responses |
Re: Regarding issue 1241
|
List | pgadmin-hackers |
On Wed, Jun 15, 2016 at 1:49 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote: > On Thu, Jun 2, 2016 at 1:59 PM, Dave Page <dpage@pgadmin.org> wrote: >> >> >> >> On Tue, May 31, 2016 at 8:53 PM, Harshal Dhumal >> <harshal.dhumal@enterprisedb.com> wrote: >>> >>> Hi Dave, >>> >>> Regarding Issue 1241: >>> >>> We have added header section for parameter tab deliberately so that we >>> can force user to select parameter name (and therefore parameter's data >>> type) before adding new row. This is required because behavior of second >>> cell (Value cell) is dependent on what parameter name user has selected in >>> first cell (Name cell). See attached screen-shot. >>> >>> For example: >>> 1. If user selects parameter 'array_nulls' then value for this should be >>> either true or false (and hence switch cell). >>> 2. If user selects parameter 'cpu_index_tuple_cost' then value for this >>> should be Integer (and hence Integer cell). >>> >>> Without the custom header (and forcing user to select parameter) we >>> cannot decide what type of cell we need in second column. >>> >>> Let me know your opinion on this. >> >> >> We need to figure out a way to fix it. Our difficulties encountered >> writing code should not dictate usability compromises. >> >> In this case, something that needs some thought and maybe some tricky code >> has caused us to create an inconsistent UI workflow to side-step the >> problem, which is not appropriate as it leads to a poor look and feel and >> potentially confusion for the user. > > Agree - we should handle these cases gracefully. > We need to over come the limitation by brain storming, which we already > started offline. :-) > > To be honest - it is a time consuming work, and there is no quick fix for > this. > We can handle it as one case for each change instead of targeting all UI > changes as one whole problem. > And, we can utilize the same time to fix a lot more cases in beta 2. As far as I'm aware, this is the only case where there's a real problem. > I can ask Harshal to find out all possible places, where the similar changes > are required, and create a separate case for each (though - not without your > agreement). I don't think we need to. This one sub-node grid (parameters) is the only one that I've seen where we deviate from the intended design - and I think I've seen them all now! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgadmin-hackers by date: