Script library namespace change from ::tk::table to ::tktable breaks backwards compatibility

[pointsman]

Older versions of tktable had the script library in the ::tk::table namespace (I've checked this for tktable 2.10 and 2.11). The new tktable 2.12 has the script library in the ::tktable namespace (that was done with e76ac7f). For people like me poking around in the namespace (e.g. my code looks at (and set sometimes) ::tk::table::Priv) and call some library procs (as ::tk::table::CancelRepeat or ::tk::table::MoveCell in my case) this breaks backwards compatibility.

Well, perhaps that ship has sailed now since the software is released. But what was the rationale to do this?

[bohagan1]

The main rationale was to move out of the tk namespace so any changes there would not impact tktable. I could change it back, but I'm working on some significant changes for 3.0 that may make that OBE. The changes include fixing the long standing arrow key navigation issues, add more bindings, Mac compatible bindings, fix see jumping issue, allow for selecting text in a cell, copy and paste working for clipboard regardless of export selection, etc. So this will significantly change the tktable.tcl file contents.

It would be useful to know how you are using those functions so I can see about including them in the next release. Thanks.

[pointsman]

The reason for poking around with tk::table::Priv (or now ::tktable::Priv) is this: The tktable in question still allows the user to resize interatively column widths or row hights by grabing the small "spread sheet lines" and drag them with Button-1 pressed. The same tktable is a drag source of an application internal drag'n drop feature (the user is able to drag "a row" of the table and to drop it over another GUI element of the same application; this is build with the BWidget drag'n drop facilities). To prevent the two different drags (the one for rezising columns and the one for "row drag") to trap on their feed I have to look in to Priv.