Re: [pgadmin-hackers] PoC: Little improvements to EditGrid - Enum ComboBox
Hi On Wed, Jun 6, 2012 at 7:33 AM, Dickson S. Guedes wrote: > Hello all, > > I'm starting some proof-of-concept working on frmEditGrid trying make > some "improvements" like: > > 1) show a combo box in columns of type enum; Nice. > 2) show a datetime picker in columns of type date/time/timestamp; Hmm, nice idea in principle, but I'm not sure if there's a suitable control that will allow the flexibility required (fractional seconds, timezones etc). Obviously that's not needed in all cases, but we should be consistent, otherwise we'd get people asking why they can use a picker for timestamp but not timestamptz for example. > 3) show a combo box in columns that has referential to another table; Also nice, but I think this one needs some careful handling. Perhaps limit the combo items to the first 500 or something, and still allow the user to manually type a value? We don't want to try to load 10 million values into the combo! > For the first item I have a very WIP patch (attached based on commit > 896dce8f744816385aa89013d7808960f15a5109) and a working example > (attached screenshots and sql) .. I'd like to see your opinions about > them, if it is a good idea, and if the initial implementation is > following the expectations of such feature. I'd like to know if anyone > is/was working in a feature like this, I wouldn't like to reinvent the > wheel. Looks like a great start to me. > For the second one I'm researching some interaction between > wxDatePicker, wxTimePicker and wxCalendarCtrl to create a new type of > CellEditor, so we could use some sqlGridDateTimeEditor that > encapsulates the logic. Is that a good approach? What is your opinions > about that? Right - see above. Maybe the answer is to develop a popup control that can handle date/time/timezone, and yet still allow the user to edit manually for things like fractional seconds. > Finally, for the last one, I see some challenges like: > > - Which field should be displayed in the combo? > Generally the value of a FK doesn't has enough information about > what it means, them you need another field (e.g a description or > person_name field) to make sense. Well, you could use a grid instead of a combo box to allow the user to choose, and display the FK value in the first column, and the PK value from the referenced table in the second and subsequent rows. I think anything more than that is probably too domain specific. > - How to play with composite referential keys? Should they be > supported, and if so how should be the behavior? > It seems pretty dark to me how to bring values from two fields from > a FK in distinct combo boxes. Yeah, I don't really like the idea of trying to support that case. I can't see any sensible way to make it work nicely. > - Caching the data for performance. Yes! :-) > Well, this is just a start point and your opinions is very important. > > What do you think guys? I think it'll be a nice addition to the tool - thanks for working on it. One additional suggestion you may want to include: bytea handling. For input, allow the user to select a local file as the contents of a bytea field. For output, it would be great if we could detect some common filetypes and offer viewers for them - e.g. detect that a bytea contains an image and allow the user to view it. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] PoC: Little improvements to EditGrid - Enum ComboBox
On Wed, 2012-06-06 at 09:33 +0100, Dave Page wrote: > Hi > > On Wed, Jun 6, 2012 at 7:33 AM, Dickson S. Guedes > wrote: > > Hello all, > > > > I'm starting some proof-of-concept working on frmEditGrid trying make > > some "improvements" like: > > > > 1) show a combo box in columns of type enum; > > Nice. > > > 2) show a datetime picker in columns of type date/time/timestamp; > > Hmm, nice idea in principle, but I'm not sure if there's a suitable > control that will allow the flexibility required (fractional seconds, > timezones etc). Obviously that's not needed in all cases, but we > should be consistent, otherwise we'd get people asking why they can > use a picker for timestamp but not timestamptz for example. > > > 3) show a combo box in columns that has referential to another table; > > Also nice, but I think this one needs some careful handling. Perhaps > limit the combo items to the first 500 or something, and still allow > the user to manually type a value? We don't want to try to load 10 > million values into the combo! > > > For the first item I have a very WIP patch (attached based on commit > > 896dce8f744816385aa89013d7808960f15a5109) and a working example > > (attached screenshots and sql) .. I'd like to see your opinions about > > them, if it is a good idea, and if the initial implementation is > > following the expectations of such feature. I'd like to know if anyone > > is/was working in a feature like this, I wouldn't like to reinvent the > > wheel. > > Looks like a great start to me. > > > For the second one I'm researching some interaction between > > wxDatePicker, wxTimePicker and wxCalendarCtrl to create a new type of > > CellEditor, so we could use some sqlGridDateTimeEditor that > > encapsulates the logic. Is that a good approach? What is your opinions > > about that? > > Right - see above. Maybe the answer is to develop a popup control that > can handle date/time/timezone, and yet still allow the user to edit > manually for things like fractional seconds. > > > Finally, for the last one, I see some challenges like: > > > > - Which field should be displayed in the combo? > > Generally the value of a FK doesn't has enough information about > > what it means, them you need another field (e.g a description or > > person_name field) to make sense. > > Well, you could use a grid instead of a combo box to allow the user to > choose, and display the FK value in the first column, and the PK value > from the referenced table in the second and subsequent rows. I think > anything more than that is probably too domain specific. > > > - How to play with composite referential keys? Should they be > > supported, and if so how should be the behavior? > > It seems pretty dark to me how to bring values from two fields from > > a FK in distinct combo boxes. > > Yeah, I don't really like the idea of trying to support that case. I > can't see any sensible way to make it work nicely. > > > - Caching the data for performance. > > Yes! :-) > > > Well, this is just a start point and your opinions is very important. > > > > What do you think guys? > > I think it'll be a nice addition to the tool - thanks for working on it. > +1 > One additional suggestion you may want to include: bytea handling. For > input, allow the user to select a local file as the contents of a > bytea field. For output, it would be great if we could detect some > common filetypes and offer viewers for them - e.g. detect that a bytea > contains an image and allow the user to view it. > And handling of big texts, and NULL values. But even without that, it would be great to see the enum, and simple FK handling. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin III commit: Update VC++ project files to 2010
Update VC++ project files to 2010 Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=95b8bacf8541baf9d933fc4cd7acbf3669e0c8ae Modified Files -- Makefile.am |7 +- docs/Docs.vcproj| 1139 -- docs/Docs.vcxproj | 293 ++ docs/Docs.vcxproj.filters | 793 pgAdmin3.rules | 17 - pgAdmin3.sln| 19 +- pgadmin/Makefile.am |3 +- pgadmin/pgAdmin3.vcproj | 7588 --- pgadmin/pgAdmin3.vcxproj| 2242 +++ pgadmin/pgAdmin3.vcxproj.filters| 4208 +++ pkg/win32/Installer.vcproj | 150 - pkg/win32/Installer.vcxproj | 71 + pkg/win32/Installer.vcxproj.filters | 44 + pkg/win32/Makefile.am |3 +- xtra/png2c/Makefile.am |3 +- xtra/png2c/png2c.vcproj | 635 --- xtra/png2c/png2c.vcxproj| 307 ++ xtra/png2c/png2c.vcxproj.filters| 19 + 18 files changed, 7994 insertions(+), 9547 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin III commit: Add a couple of files missed in the last commit, an
Add a couple of files missed in the last commit, and update the VC++ version in the INSTALL file. Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=dde05ef4fc6f6122410f1b9d07a050363b50c7d7 Modified Files -- INSTALL |4 +- pgAdmin3.props | 19 pgAdmin3.targets | 81 ++ pgAdmin3.xml | 127 ++ 4 files changed, 229 insertions(+), 2 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin III commit: README updates.
README updates. Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=a0b693a37caf9ba71051f24f58c61e8cc0b67330 Modified Files -- README |8 1 files changed, 4 insertions(+), 4 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Upgrading the VC++ solution/project files
On Sat, Jun 2, 2012 at 11:14 PM, Guillaume Lelarge wrote: > On Sat, 2012-06-02 at 22:24 +0100, Dave Page wrote: >> Hi >> >> We're building the PostgreSQL installers using VC++ 2010 for 9.2, and >> because I use the dependency set and pg_dump/psql/etc binaries from >> that distribution, I've also upgraded my build environment for pgAdmin >> 1.16 to VC++ 2010 (because we don't want to mix CRT versions). >> >> Any objections to me committing updates to the VC++ project & solution >> files to move them to the new version? >> > > Nope, go ahead. Done - thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] PoC: Little improvements to EditGrid - Enum ComboBox
2012/6/6 Dave Page : >> 2) show a datetime picker in columns of type date/time/timestamp; > > Hmm, nice idea in principle, but I'm not sure if there's a suitable > control that will allow the flexibility required (fractional seconds, > timezones etc). Obviously that's not needed in all cases, but we > should be consistent, otherwise we'd get people asking why they can > use a picker for timestamp but not timestamptz for example. Yep, I'll try some layouts and behaviors and come back to listen to you. >> 3) show a combo box in columns that has referential to another table; > > Also nice, but I think this one needs some careful handling. Perhaps > limit the combo items to the first 500 or something, and still allow > the user to manually type a value? We don't want to try to load 10 > million values into the combo! [... cut ...] >> - Which field should be displayed in the combo? >> Generally the value of a FK doesn't has enough information about >> what it means, them you need another field (e.g a description or >> person_name field) to make sense. > > Well, you could use a grid instead of a combo box to allow the user to > choose, and display the FK value in the first column, and the PK value > from the referenced table in the second and subsequent rows. I think > anything more than that is probably too domain specific. Nice idea. Maybe the workflow could be: 1. user starts edit on a field that is a simple FK 2. we open the field and show a little button "[...]" in the right side 3. user place the value by hand and the already existing behavior is used as expected 4. otherwise user click in the button 4.1. we open another frmEditGrid called with a special parameter 4.2. the special parameter enable double click in a record (or another event) 4.3. the new window shows data from referenced table 4.4. user search the field and double click it 4.5. this frmEdiGrid is closed and the primary key value is placed in the original frmEditGrid respective field Thoughts? >> - How to play with composite referential keys? Should they be >> supported, and if so how should be the behavior? >> It seems pretty dark to me how to bring values from two fields from >> a FK in distinct combo boxes. > > Yeah, I don't really like the idea of trying to support that case. I > can't see any sensible way to make it work nicely. +1. I'm queuing it. >> Well, this is just a start point and your opinions is very important. >> >> What do you think guys? > > I think it'll be a nice addition to the tool - thanks for working on it. Thanks Dave! > One additional suggestion you may want to include: bytea handling. For > input, allow the user to select a local file as the contents of a > bytea field. For output, it would be great if we could detect some > common filetypes and offer viewers for them - e.g. detect that a bytea > contains an image and allow the user to view it. I liked it and I'll try something. Best regards. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] PoC: Little improvements to EditGrid - Enum ComboBox
On Wed, Jun 6, 2012 at 2:38 PM, Dickson S. Guedes wrote: > >>> - Which field should be displayed in the combo? >>> Generally the value of a FK doesn't has enough information about >>> what it means, them you need another field (e.g a description or >>> person_name field) to make sense. >> >> Well, you could use a grid instead of a combo box to allow the user to >> choose, and display the FK value in the first column, and the PK value >> from the referenced table in the second and subsequent rows. I think >> anything more than that is probably too domain specific. > > Nice idea. Maybe the workflow could be: > > 1. user starts edit on a field that is a simple FK > 2. we open the field and show a little button "[...]" in the right side > 3. user place the value by hand and the already existing behavior is > used as expected > 4. otherwise user click in the button > 4.1. we open another frmEditGrid called with a special parameter > 4.2. the special parameter enable double click in a record (or another event) > 4.3. the new window shows data from referenced table > 4.4. user search the field and double click it > 4.5. this frmEdiGrid is closed and the primary key value is placed in > the original frmEditGrid respective field It sounds like that is worth prototyping, though, I think using another edit grid is too much (that's a pretty chunky bit of code, most of which wouldn't be needed). I'd be inclined to just use a listview or gridcontrol on a dropdown (so it works like an oversized combo box). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
