#1881 closed defect (fixed)
shp2pgsql-gui -- editing a field sometimes triggers removing row
| Reported by: | robe | Owned by: | mcayland |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 2.0.1 |
| Component: | utils/loader-dumper | Version: | 2.0.x |
| Keywords: | history | Cc: |
Description
when I click on the table name to edit it, and then click on the Schema name to its left, the entire entry row will immediately disappear.
See #1878 for more details.
Attachments (2)
Change History (15)
comment:1 by , 12 years ago
| Component: | postgis → loader/dumper |
|---|---|
| Owner: | changed from to |
comment:2 by , 12 years ago
by , 12 years ago
| Attachment: | gui-disable-resize.patch added |
|---|
comment:3 by , 12 years ago
Bug with test case has now been filed with the GTK crew: https://bugzilla.gnome.org/show_bug.cgi?id=678570.
Regardless of this, we still need a workaround as even if it is fixed tomorrow, it will take considerable time for the fix to reach ordinary users.
comment:4 by , 12 years ago
It's noticeable but doesn't bother me that much. I liked the auto-resize I think. Can we put this off? Besides I like bmmpxf proposal of having a confirm remove button which would make this a non-issue. We could use that checkbox for other things in fact like setting settings for multiple records etc.
bmmpxf you have an opinion on this matter? I just don't want to risk breaking something else or removing other functionality especially if we are going to change it again and I'm pretty satisfied with the functionality we have in the gui already and the issues we've already solved.
comment:5 by , 12 years ago
Have you actually tried the patch? Basically the form resizes upwards, but just doesn't collapse the columns back down again when items are deleted from the list.
+1 for 2.0 because the patch is minimally invasive, doesn't change any functionality and it's very obvious/irritating to users.
comment:6 by , 12 years ago
okay just commit it then. I'm sure I'll be sorry but don't have the energy to fight you this time :) I hate having to look up my notes on how to patch. If you commit I'll revert if I find an issue.
comment:7 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:8 by , 12 years ago
Seems fine. Not sure what you meant by not stretching though as I can stretch the fields still in fact seems better for some reason.
bmmpxf - if you want to give it a try to make sure I didn't miss anything (didn't try loading a file), I've attached the win32 latest compiled binary to this ticket.
comment:9 by , 12 years ago
Hey Mark,
I just noticed something odd which might be why I was confused about the stretching. On my mingw64 shp2pgsql-gui compiled, I can stretch all the columns, but on my 32-bit one I can only stretch the first column of import tab.
I thought I was using the same GTK build, but maybe my mingw64 gtk is newer. I'll verify that. Are you able to stretch all columns on the import tab?
comment:10 by , 12 years ago
Originally I allowed the first (filename) column to be resized but automatically resized all of the others, so perhaps your 32-bit build is not up to date?
Also: what version of GTK are you building against? They've asked me to try with a newer version to see if the bug is still there :/
comment:11 by , 12 years ago
| Milestone: | PostGIS 2.0.2 → PostGIS 2.0.1 |
|---|
I'll check next I'm near my build environment. Off-hand I know my mingw64 is using at least -- gtk+-bundle_2.22.1-20101229_win64 which I downloaded from ( http://ftp.gnome.org/pub/gnome/binaries/win64/gtk+/2.22/gtk+-bundle_2.22.1-20101229_win64.zip )
I thought my mingw32 is of the same vintage, but it's possible I didn't bother updating it so might be gtk 2.18.
Speaking of versioning, it would be really nice if we can get that r number back in the about box. I know it's not perfect, but it's better than just having that 2.0.1SVN. When did we decide to take the r out or was it accidental?
comment:12 by , 12 years ago
mcayland,
I think you are right about my win32 build being older (so bmmpxf, don't bother testing the attached file). I must have built it a little bit before you committed. It exhibits the bug. I thought the fact I could add and enter into the table field without it removing meant it was fixed, but now I realize the issue only happens if I actually try to overwrite the field content. My mingw64 doesn't exhibit this bug anymore though it did before (and the old mingw64 backup I have doesn't allow stretching the other columns).
comment:13 by , 12 years ago
| Keywords: | history added |
|---|
Aha - got it. It's setting the auto-resize on the text columns that's causing the event to fire, which in my mind definitely makes this a GTK bug.
The attached patch can be used to remove auto-resizing for testing, and I'd be happy to apply this to 2.0 branch before tomorrow (as it's a fairly noticeable bug). Thoughts?