Opened 6 years ago

Closed 6 years ago

Last modified 6 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 6 years ago.
shp2pgsql-gui.zip (426.9 KB) - added by robe 6 years ago.
win32 executable

Download all attachments as: .zip

Change History (15)

comment:1 Changed 6 years ago by robe

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

comment:2 Changed 6 years ago by mcayland

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?

Changed 6 years ago by mcayland

Attachment: gui-disable-resize.patch added

comment:3 Changed 6 years ago by mcayland

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 Changed 6 years ago by robe

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 Changed 6 years ago by mcayland

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 Changed 6 years ago by robe

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 Changed 6 years ago by mcayland

Resolution: fixed
Status: newclosed

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

comment:8 Changed 6 years ago by robe

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.

Changed 6 years ago by robe

Attachment: shp2pgsql-gui.zip added

win32 executable

comment:9 Changed 6 years ago by robe

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 Changed 6 years ago by mcayland

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 Changed 6 years ago by robe

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 Changed 6 years ago by robe

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 Changed 6 years ago by robe

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