If you want others box not shifted, you can replace 3.a hidden content with display none ONLY AFTER 3.c new position set up.

is there any bin for win32?

i’m onto windows 7

do i have to build it myself? is that possible?

does python 3.2 will be supported in the future?

any answer would much appreciated, meanwhile i’ll stick with 3.6.7

best regards from argentina!!
jeremy

p.d.: as you can guess i begun learning python and Glade it’s the coolest toolkit i found.

Fair enough.

> It also may be helpful if someone could send me a link to the older glom code which was >
> doing this, admittedly I have not seen it.

I strongly believe that it’s better to take a fresh approach to this, but:
http://git.gnome.org/browse/glom/tree/glom/utility_widgets/flowtable_dnd.cc?h=glom-1-14
though that code’s requirements leaked all over many other source files.

I tried it so far without the locking, but as I mentioned in my other comment I’m getting some competition going on:
– Placeholder starts resizing (growing) at mouse position between 2
widgets
– Once the placeholder is large enough, the spread table reconfigures
– When the spread table reconfigures it leaves the mouse position
hovering over a new child widget
– Because the mouse position is now over a new widget, the current
placeholder starts to animate out and a new one starts animating in at
the new index.

And this happens repeatedly over and over causing a weird glitchy looking
effect (this problem happens particularly when dragging a tall widget through an area with many short widgets).

Maybe Johannes found a different solution to this problem ?

It also may be helpful if someone could send me a link to the older glom code which was doing this, admittedly I have not seen it.

Why?

Your stragegy of having a placeholder item sounds roughly like what Johannes did (for me) with the older FlowTable code in Glom, though that never quite worked properly and the code was mixed in with unrelated stuff. Hopefully yours will be even better.

I spiked on it today and came up with something half working, I wrote an EggPlaceholder object which basically gets inserted into the spread table at potential drop sites, the object comes with _animate_in() and _animate_out() apis and it’s basically a drawing area derived widget (so you could potentially connect to the “draw” signal and draw something appropriate in the drop zone).

I think having this separate object will at least help with code readability, but there are many things I still need to deal with, currently I have not implemented any “lock” which I mentioned in my post to keep widgets in their respective columns while DnD is happening, so I am still getting the expected “race”/”flicker” that happens when the spread table repositions it’s children at the same time as “drag-motion” callbacks are adding/removing these placeholders.

I’m not sure if my code will be so much better/more readable, I still have a dozen special cases to handle with regards to cleaning up the states when drags are finished and handling drag’n'drop from one spread table to another, but at least I’m quite sure that the approach will work after a couple more days focusing on this.