Hi Kevin, > So: yes, it would be difficult. It would be extremely difficult. I wouldn't > hold my breath.
I was not actually suggesting porting Tk (or Tkinter). Rather, building a set of classes with the same names as those Tkinter uses, and similar methods, but these instead call the iOS GUI API classes and methods. In some cases, this might be easy, but in others difficult. I did a lot of this in the early days of GUIs, where I had to change GUIs quite often (starting 1990). I found it easier to provide an abstraction layer between my code and the actual underlying graphic engine. But yes, I can see problems, for instance if you used the pack geometry manager, it is unlikely that iOS would use similar. But windows are windows, buttons are buttons, and all GUI APIs need som way to specify that elements should exist, and where they are placed. Mick On Sun, Mar 3, 2013 at 9:10 PM, Kevin Walzer <k...@codebykevin.com> wrote: > > On 3/3/13 2:24 PM, Michael O'Donnell wrote: >> >> This may or may not be difficult, based on the kinds >> of metaphors Apple uses. > > > It took Daniel Steffen, the previous maintainer of Tk on the Mac, nine > months of full-time work (sponsored by Apple) to port Tk from its old Carbon > base to its current Cocoa one. > > Porting Tk to run on iOS would be a bigger job. First, there is not a > one-to-one mapping between the traditional Cocoa API's and their iOS > equivalents; there are differences. So there would be a lot of actual > porting work to be done, new code written, by someone who had in-depth > knowledge of Tk's internal API, its Cocoa API, and iOS's UI frameworks as > well. > > The second challenge is that there is no viable port of Tcl running on iOS > that I'm aware of. Even if that port is somewhat simpler, it would still > require time. Tk is not viable without a Tcl interpreter to undergird it. > (Deep down, much of Tkinter simply involves calls to the Tcl interpreter > from Python.) > > The third challenge is who would do it. Daniel Steffen was the maintainer of > Tk for nearly a decade, and had written a huge amount of the previous Carbon > implementation, and so was well-qualified to take it on; Apple contracted > with him to do the port on that basis. Daniel is now an Apple employee and > would not be able to undertake such a project. As the current maintainer of > Tk on the Mac, some might suggest that I take on the project, but I lack > Daniel Steffen's expertise and would not have the time to pursue it. I do a > lot of bug fixing and reviewing of patches--general maintainer stuff--but > rewriting large swaths of Tk's Mac implementation from scratch is outside my > brief. > > So: yes, it would be difficult. It would be extremely difficult. I wouldn't > hold my breath. > > --Kevin > > > -- > Kevin Walzer > Code by Kevin/Mobile Code by Kevin > http://www.codebykevin.com > http://www.wtmobilesoftware.com -- Not sent from my iPhone _______________________________________________ Tkinter-discuss mailing list Tkinter-discuss@python.org http://mail.python.org/mailman/listinfo/tkinter-discuss
