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-b...
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
.hc
.hc
An update to the Pd-l2ork port:
- figured out how to build tkpath against the Carbon stuff. It runs fine now.
- got some basic libraries compiled and installed to ship with the app.
(zexy, hcs, cyclone, and a few others).
- currently working on an issue with the Shift key "sticking"-- that is, if I
do <Shift-RightArrow> to move an object by 10 pixels, when I release Shift and then do <RightArrow> it continues moving the object by 10 pixels instead of 1 pixel. Once I fix that it should be usable.
Best, Jonathan
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
- I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that?
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
- I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this?
- key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet.
Best, Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote: > Hello, > I'm hoping some MacOSX gurus can help me traverse this mine-field. > > What I'm trying to do: > Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app > > Minefields: > * Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa. > So I > must use tcl/tk Framework that uses Carbon instead of Cocoa. That > should be > ok because Pd-extended.app is currently set up to use Carbon. > * Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the > gui-rewrite > > What I've done so far: > * updated the configure file successfully > * made a workaround for statbuf from stat.h not existing on OSX (in > s_main.c) > * made a workaround for RTLD not existing after ./configure and trying to > make (s_loader.c) > * successfully compiled Pd-l2ork > * checked that tkpath actually works on OSX. It seems to work, using > tcl/tk > w/Carbon > instead of Cocoa. > * used otool and install_name_tool to change libPdTcl.dylib libraries to > point at the > App's Framework directory instead of system directories > * changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does > successfully) > > What crashes so far: > * inside pd.tk, I'm trying to do this: > load $pd_guidir/bin/libPdTcl.dylib > It finds the dylib fine but then it crashes, with the crash report > referencing the first line > of the following function of t_tkcmd.c in the backtrace: > > int Pdtcl_Init(Tcl_Interp *interp) > { > const char *argv = Tcl_GetVar(interp, "argv", 0); > > *** > > Any ideas where to begin to debug this? Is there some code I can add to > Pdtcl_Init to print out some info I can use to tell where it's going wrong? > > I put the full error log here: > http://pastebin.com/duHdRrsY > > Any suggestions appreciated. > > -Jonathan > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list