[PD] Help with OSX App minefield

[Hans-Christoph Steiner]

On Nov 4, 2013, at 1:42 PM, Jonathan Wilkes wrote:

> On 11/04/2013 09:51 AM, Hans-Christoph Steiner wrote:
>> On 10/22/2013 12:55 PM, Jonathan Wilkes wrote:
>>> On 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote:
>>>> On 10/21/2013 03:59 PM, Jonathan Wilkes wrote:
>>>>> On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
>>>>>> Carbon has been deprecated by Apple and might have been removed entirely.  It
>>>>>> will only ever be 32-bit, and starting in 10.7, everything is 64-bit.
>>>>>> Anything Carbon is dead, unless you're happy working with 10.6 and older.
>>>>> I'm running Pd-extended and my Pd-l2ork port on 10.7.5.  Both link
>>>>> to the Carbon system libraries.  Both run.
>>>> Considering that Apple has dropped support even for some older 64-bit Macs, I
>>>> think using Carbon is surely a dead end.
>>>> 
>>>> http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-bit-macs-gently-into-that-good-night/
>>>> 
>>> What is the relevance of what you've written and linked to?
>>> 
>>> When I have time to look at what's required to get tkpath to use
>>> the updated tkMac headers found in newer versions of tcl/tk, I'll do it.
>>> Meanwhile people will have a working version of Pd-l2ork on OSX
>>> to play with.
>>> 
>>> -Jonathan
>> I think I confused tkZinc and tkpath.  tkpath seems to use CoreGraphics, which
>> is 64-bit.
> 
> Yes.  AFAICT, getting it to work with Cocoa is a matter of revising tkpath to use the revised TkMacOSXInt.h header functions and structures in the newer versions of tcl/tk instead of the old ones. There are some hints by looking at the rest of tk that uses that header and seeing how they changed their code.
> 
>> 
>> Your determination is admirable, I just think there are better areas to focus
>> your efforts.  Last I checked, tkpath is not really maintained.  We should
>> really be talking about pulling the GUI functions out of the Pd core, then
>> people can do things like write a GUI in C++, which will be dramatically
>> faster than anything written in Tcl/Tk.
> 
> But "people" aren't going to write a gui for Pd.  There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that.  (Though I'm sure there are a lot of projects that do cool things with it.)
> 
> Writing a development environment is a gargantuan task, and testing out tkpath was literally 3 lines of code added to pdtk_canvas.tcl. Ivica said getting it to work fully was more effort than that, but the fact that it supports tk canvas commands allows a lot of improvements to the interface without having to do a complete rewrite of everything g_*.[ch]
> 
> And of course removing GUI function from the Pd core can be done in addition to the tkpath improvements.  Once you get FUDI messages in both directions, you'll still have a fully-functional gui dev environment in tcl/tk.
> 
> I'm not convinced there are the resources in the Pd community to fund doing all the work required to use a different GUI toolkit, plus making all the redesign and testing speed improvements that another toolkit would bring.
> 
> -Jonathan

I'm not proposing that we spend more time on this, but rather that we coordinate efforts and work smartly.  Sure, we can keep patching up the existing Pd GUI stuff, and  hacking in old Tk code, there has been a lot of that over the years.  If we instead invest in the up front work of ripping out the GUI code from pd core, then it becomes drastically easier to write a modern, efficient GUI in whatever toolkit.  libpd has not addressed this particular issue, but it will become more valuable if the GUI was truly separate from the core.

But the Pd dev community has always been not so good at coordinated efforts.  There is a history of lots of effort going into semi-compatible dev forks which mostly die out after a run (pd-devel, desiredata, vibrez, etc. etc.)  Perhaps Pd-extended or pd-l2ork will be the next one to die out...

.hc