On 27 February 2016 at 13:53, Robert Chalmers wrote: > I don’t mean to mis-lead anyone. The issues I”m talking about are part of > Audacity 2.1.2. Things like not being able to drag-highlight-scroll right in > editing a track, and drag+highlight-dcroll left+edit only works sometimes. > There also appears to be something about it that interferes with other > running apps, in this case, iBooks running at the same time over the course > of about half an hour gets slower and slower to scroll, untill it gives up > all together and becomes unusable. If I close down Audacity 2.1.2, and close > iBooks, then open iBooks again. It starts working as it should. Start up > 2.1.2, and after half an hour there abouts - it caries - back comes the > problem with iBooks.
These are most likely problems that have been introduced with transition to wxWidgets 3.0. You should certainly report them to upstream developers. It might help to check whether this is also a problem on Linux or on wxGTK flavour (on Mac). It might be slightly easier to debug then. (I have an impression that most developers work on Linux or occasionally on Windows and Mac is just something that has to be done by someone.) > So, I’m not talking about the macports build of Audacity - the current port > installed fine, and lives in the macports folder in Applications, although > it does read the cfg file in the “default” location of course. Which doesn’t > seem to trouble it. > . It does however exhibit the same problems with > scrolling/editing/highlighting as the Audacity build by the Audacity > Developers. And probably other issues that I gave up tracking. AS I said. > I’m back on 2.1.1, because it’s at least fully functional for what I want. These problems have to be resolved sooner or later, or you'll end up with some version of OS X that will refuse to run i386 binaries :), or you will at some point want to use the latest features, and then you'll have no choice. > While I’m thinking of it - does the port install session create a log file > anywhere of what it does when “port installing” - I’d like to see what’s > happening. sudo port -v install audacity But most likely you got a binary from MacPorts. If you want to see the complete process, you need "sudo port -vs install audacity" or perhaps "sudo port -v destroot audacity". You can also use "-d" for debug rather than "-v" for verbose to get even more [nasty] output. >> I didn't even look at it, but from what I understand the Xcode project >> has the 10.6 SDK hardcoded and it might become tricky to get it to >> build under later OSes. (Official build instructions start with tricks >> about how to install an ancient Xcode on your machine.) >> >> What is your main reason/motivation to get the Xcode build working? > > I’ll probably keep tinkering with this unless someone beats me to it. I > would like to get the build going with the XCode project, using the latest > versions of the SDK, and XCode etc, because trying to use the now almost > ancient 10.6 SDK seems counter productive, and is begging for built in > instabilities. 10.6 was in fact needed until Audacity depended on wxWidgets 2.8. This is no longer the case, so there is no reason why it wouldn't build with the latest Xcode on the latest OS now that they made the switch (just keep in mind that you'll probably get the same "buggy" version). However I have almost no experience with xcode projects and what little experience I have, the project would generally hardcode both the SDK and architectures when one creates a new project by clicking different buttons. I remember that I was manually replacing parts of text in .xcodeproject to avoid hardcoded SDK. > So the reason/motivation is to “make it work” and remove that pesky hard > coding so that updates to XCode and SDKs can be more easily followed and > checked in the actual project. > I know it’s difficult, but it shouldn’t be im possible, if I can create a > “map” or a tree diagram of where and what everything is in Audacity’s base > source code. I don’t see a source code map anywhere, and the code it’self is > minimally commented. Whick is one thing XCode is good for, Sou can see where > everything is at a glance pretty much. It might be easier to create a new project from scratch, but I'm just speculating. > Does anyone know exactly what the calls are that require the 10.6 SDK? wxWidgets 2.8 which is no longer needed (but you have problems with version 3.0). > Shouldn’t it then just be a mission to update that code to the new SDK? It already was by the time of the 2.1.2 release. But now someone has to step in to fix the xcodeproject. On top of that you might experience some problems with the 64-bit build. René included some patches in MacPorts and we need to submit those patches upstream, but we need some proper testing first. Mojca _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
