PortTk is based on X's philosophy in drawing and in event handling. The drawing resources are included in the graphical context, which is passed by every drawing function. In PortTk this is the case also in other UI environments. All the resources in graphical context is not needed by every drawing function, but every UI environment can use the necessary recourses for its specific use.
In the final implementation there are many X definitions. Graphical contexts, events, colors and fonts are imported from X Window System. Importing seemed to be a good idea: the functionality of Tk could be preserved, so the feel of Tk is original. The remaining, not finished widgets should be easily restructured with portable interface.
PortTk does not change the ideas presented in John Ousterhout's book of Tcl and Tk. The syntax of Tcl and the commands of Tk are the same in PortTk. However if widgets are being written by instructions from the book, mapping of X definitions to proper PortTk definitions is necessary.
The final result can be critized that the result isn't really to make Tk portable, more likely to make some of the X definitions and functions portable. Tk is not made to be portable, many of its fine details are very much based on X Window System. The project group consireded to rewrite Tk, but a working rewritten Tk would have been a unreasonable goal in our project schedule.
Continuing PortTk can be meaningful in the case that there are not enough project resources to write the whole Tk again. However the project group thinks that the final PortTk will look like SRA's twin, which has implemented completely by emulating X calls and definitions.
One interesting subject of development could be attaching native widgets from different user interfaces to PortTk. The interface of native widgets could be on the level of Tcl commands. The syntax of these commands should be different, because normal Tk configuration and event handling can't be directly used. Interconnection between native user interface widgets and Tk's widgets is likely to be difficult problem.
Portability can be one of the important features of Tk in the future. In order to maintain portability - and continous development of Tk - Tk needs probably to be rewritten. The event handling and the interconnection require a new approach. The portability does not come cheap, but it can be worth it.