shp2pgsql-gui: Column contents have tangled values

[bmmpxf]

In shp2pgsql-gui:

Click on the schema name for a given table, where it says "public". Go to edit that value, but then immediately click on the Shapefile name right next to it. The name changes to say "public" too!

You can do this with all of the columns. Click on a value to edit it, then click on an adjacent field. That field changes to say what was being edited in the other column.

Doing this with certain columns causes the layer to autodelete from the list.

[mcayland]

I'm fairly sure I've fixed this in both trunk and 2.0 branch (see http://trac.osgeo.org/postgis/ticket/1468) so I'm going to mark this as a duplicate. If 2.0.1 comes out and you still experience the problem, then please re-open this ticket.

[bmmpxf]

Thanks, I'll look for it in the next build.

[robe]

bmmpxf — we have a newer windows build you can download from here:

​http://www.postgis.org/download/windows/experimental.php

If you don't want to test out the whole package — just use the POSTGIS ESRI Shapefile GUI ones which just have the postgisgui folder. You can replace your current folder with this one.

Mark — I just noticed that the revision number no longer shows on the About — it just shows PostGIS 2.0.1SVN. Is that an intentional change? I liked it a bit better the other ways since I do make interim builds and gives a sense of which release in case people have issues.

[bmmpxf]

Hi there. Okay, I grabbed the experimental build (32bit) from this link: ​http://www.postgis.org/download/windows/extras/postgisgui_pgadmin-2.0.1SVNw32.zip

The copied field issue has gone away, which is good. Now, however, when I click on the table name to edit it, and them click on the Schema name to its left, the entire entry row will immediately disappear. So something is still amiss.

As an aside, I'm curious why the new UI is inflexible (no app or column resizing allowed for example, except by the app itself). I made a list of desired UI/UX improvements for this tool, so if this is the proper forum for such things, I'd gladly make individual tickets for them.

Thanks again for all your help.

[robe]

bmmpxf - thanks for the feed back. yah I noticed the disappearing row too. I wonder if I forgot to ticket that or couldn't come up with a consistent set of steps to replicate it.

Anyway I think those items should be separate tickets (pushed to 2.0.2 and I'll close this one out). As far as adjusting it seems the shapefile field on import is adjustable but that seems to be the only field. None of the export ones are. Is that what you are noticing.

If you can file those issues and UI improvements (as enhancements), that would be super .

[mcayland]

Hmmmm good spot, I can actually reproduce this here and it only seems to occur with those 2 columns in that particular order. Will take a closer look and see if I can fix.

In terms of the UI layout, the issue is mainly one with GTK being a complete pain when trying to calculate the size of fields when resizing the outer form. There is no (easy) way I can find to enable you to turn off auto-resizing and calculate what the displayable width of the field should be (based upon font metrics or similar), and so I went for auto-resize for short columns whilst allowing custom resizing on long fields such as filename. I'm not against people suggesting changes about how this should work, however I can't necessarily promise to implement them if GTK doesn't want to play.

[mcayland]

Well after spending a few hours playing around, it seems that the bug manifests itself when clicking any column with editable text, and then clicking the first editable text column within the set. The cause is that something is causing the "Rm" tickbox "toggle" signal to be invoked outside of the text edit event handler.

I've double checked the column setup code several times and found nothing obvious. The strange thing is that if I temporarily remove the schema column, then the same bug occurs when editing another column and then selecting the table column instead. The fact that this bug is dependent upon the positioning of the columns makes me suspect it's a GTK bug

[robe]

Mark,

I put this in as a separate ticket #1881 and slated for 2.0.2. We might eventually have to make it a wontfix or see if there is a newer GTK that doesn't have the issue.

I'm sorry I didn't put in a ticket for it when I first noticed the issue. Even if we found a solution for it now, I wouldn't feel comfortable rushing to get this in for 2.0.1 without considerable testing.

[mcayland]

I suspect the chances of me getting a suitable answer out of the GTK guys before Friday is very small. In terms of testing, the only thing that would need to change would likely be the state of one or more GUI components - certainly nothing that wouldn't show up immediately. I'll move over to the new ticket now.

[bmmpxf]

Thanks again guys.

Another workaround idea: If the bug is being caused by the Rm column being toggled incorrectly (due to a GTK bug), why don't we just remove the Rm column? One of the tickets on my list of UX improvements to file was to have a different way of removing entries anyway. (It was certainly surprising to me to check that box and have the row immediately disappear!) A more standard workflow would seem to be a check box to select along with a "Remove selected" button. Two wins: improved UX and one more bug squashed.

Just an idea, can ticket separately if you like.

[bmmpxf]

Oh whoops, maybe I should have commented on the other ticket. Sorry about that.