Back in the era this is talking about, I ported the Tk text widget over to GTK+ which became GTK's still-used text widget (GtkTextView).
I think the author is right that it was a mistake to ignore Linux. It didn't have the desktop user marketshare, but it did have the developers that were doing a lot of the work on open source code.
Even at that time (just before GTK+ 2.0, around 2001), expected toolkit features had jumped ahead of Tk quite a bit; in porting the widget I think I added model-view separation, pixel-based (vs. line-based) scrolling, international text layout, input methods, accessibility, lots of optimizations, support for non-XPM images... likely more I can't remember.
Tk lacked all that stuff, and various GTK-related companies and Troll Tech (Qt) were investing in building all of it for GTK and Qt. That led to a situation where only those two toolkits, that had been modernized, were acceptable to lots of decision-makers who were deciding what to ship with Linux distributions or GNOME or KDE. Nobody could afford to go modernize Tk also, it was easier to just get all the apps on one or two toolkits. The modernization work was being funded or volunteered-for with Linux in mind, nobody cared to do it for open source toolkits on Windows or Mac.
Swing was probably the only cross-platform toolkit that had the same modernization work done. (Ignoring "wrapper" toolkits like wxWindows or SWT that have whatever modernization is found in the toolkit they wrap.)
The Tk text widget was a solid piece of work, I mean, it's an accomplishment to write code good enough that it makes sense to port it to another toolkit. The core btree data structure from Tk is in GTK to this day with extensions but no real major overhaul: http://git.gnome.org/browse/gtk+/tree/gtk/gtktextbtree.c
I think Ousterhout may have written it.
It's an interesting data structure if you like that sort of thing. The older GTK text widget had various operations that were O(n), and so people kept writing O(n^2) or worse code accidentally; with the new one, one of the goals was to try to keep everything below O(n) so it was harder for developers to hose themselves. The core of this was the btree from Tk. One place we declared defeat was in very long lines; some stuff is still O(n) where n is the line length, and that's hard to fix without massive overhaul. The btree is about storing lines and related metadata so that things aren't O(n) in number of lines. There's also a useful trick in http://git.gnome.org/browse/gtk+/tree/gtk/gtktextiter.c where an incrementing "change stamp" is used to keep an iterator valid even though the iterator caches some pointers that can become invalid as the btree changes.
Sorry for the "used to walk both ways in the snow"-flavored post ;-)
"One place we declared defeat was in very long lines"
This still haunts me today. IDLE, the IDE-like editor that comes with Python, struggles with long lines. Execute something like this:
print list(range(10000))
...and your whole Python Shell window (which is essentially a Tk text control) becomes so slow and unresponsive that it's better to close it, and/or restart IDLE.
Yeah, it sucks. It's pretty hard to fix though, one of those bugs where the multi-week or even multi-month effort to fix it probably isn't ever going to make sense to anybody. (Say IDLE in particular is bothering you; you could probably spend a very short time just hacking it to truncate that string before putting it in the widget, vs. the likely gigantic task of fixing the widget. Everyone is making that same calculation whenever they get annoyed by this.)
I think the author is right that it was a mistake to ignore Linux. It didn't have the desktop user marketshare, but it did have the developers that were doing a lot of the work on open source code.
Even at that time (just before GTK+ 2.0, around 2001), expected toolkit features had jumped ahead of Tk quite a bit; in porting the widget I think I added model-view separation, pixel-based (vs. line-based) scrolling, international text layout, input methods, accessibility, lots of optimizations, support for non-XPM images... likely more I can't remember.
Tk lacked all that stuff, and various GTK-related companies and Troll Tech (Qt) were investing in building all of it for GTK and Qt. That led to a situation where only those two toolkits, that had been modernized, were acceptable to lots of decision-makers who were deciding what to ship with Linux distributions or GNOME or KDE. Nobody could afford to go modernize Tk also, it was easier to just get all the apps on one or two toolkits. The modernization work was being funded or volunteered-for with Linux in mind, nobody cared to do it for open source toolkits on Windows or Mac. Swing was probably the only cross-platform toolkit that had the same modernization work done. (Ignoring "wrapper" toolkits like wxWindows or SWT that have whatever modernization is found in the toolkit they wrap.)
The Tk text widget was a solid piece of work, I mean, it's an accomplishment to write code good enough that it makes sense to port it to another toolkit. The core btree data structure from Tk is in GTK to this day with extensions but no real major overhaul: http://git.gnome.org/browse/gtk+/tree/gtk/gtktextbtree.c I think Ousterhout may have written it.
It's an interesting data structure if you like that sort of thing. The older GTK text widget had various operations that were O(n), and so people kept writing O(n^2) or worse code accidentally; with the new one, one of the goals was to try to keep everything below O(n) so it was harder for developers to hose themselves. The core of this was the btree from Tk. One place we declared defeat was in very long lines; some stuff is still O(n) where n is the line length, and that's hard to fix without massive overhaul. The btree is about storing lines and related metadata so that things aren't O(n) in number of lines. There's also a useful trick in http://git.gnome.org/browse/gtk+/tree/gtk/gtktextiter.c where an incrementing "change stamp" is used to keep an iterator valid even though the iterator caches some pointers that can become invalid as the btree changes.
Sorry for the "used to walk both ways in the snow"-flavored post ;-)