Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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: 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)

gui-disable-resize.patch (2.5 KB ) - added by mcayland 10 years ago.
shp2pgsql-gui.zip (426.9 KB ) - added by robe 10 years ago.
win32 executable

Download all attachments as: .zip

Change History (15)

comment:1 by robe, 10 years ago

Component: postgisloader/dumper
Owner: changed from pramsey to mcayland

comment:2 by mcayland, 10 years ago

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?

by mcayland, 10 years ago

Attachment: gui-disable-resize.patch added

comment:3 by mcayland, 10 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 robe, 10 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 mcayland, 10 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 robe, 10 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 mcayland, 10 years ago

Resolution: fixed
Status: newclosed

Done. Committed as r9970 for 2.0 branch and r9971 for trunk.

comment:8 by robe, 10 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.

by robe, 10 years ago

Attachment: shp2pgsql-gui.zip added

win32 executable

comment:9 by robe, 10 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 mcayland, 10 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 robe, 10 years ago

Milestone: PostGIS 2.0.2PostGIS 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 robe, 10 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 robe, 10 years ago

Keywords: history added
Note: See TracTickets for help on using tickets.