Panic is pleased to announce the availability of Coda 1.5.
This is a major feature update to Coda, and it's free for all existing Coda users.
So, what's new? Here are the big new things:
For local files, it's now possible to do a multi-file find and replace. You can choose to search all open files, all files in a particular folder, or all files in your current Site.
All of the regular single-file find and replace options apply to multi-file finds as well.
You asked for it. Then you asked for it again. Then you asked for it a thousand more times. So, here it is!
Coda 1.5 provides integrated support for Subversion operations. Without leaving the Coda environment, you can checkout, commit, revert, update, and rollback files.
This feature is configured via the Sites interface. If the Local Path of your Site contains Subversion metadata files, you will automatically get Subversion support. Otherwise, you can checkout a working copy from the Sites edit dialog.
Status flags are shown next to each individual file in the file browser (when necessary), or you can open the Source Control overview window for a list of all files with interesting status.
You'll note that we call this "Source Control" rather than just "Subversion". Although only Subversion is supported at the moment, we have implemented these functions in an abstract way, so that over time we have the option of supporting your other favorite source control systems.
Clips can now be grouped into folders for better organization. We've also added the ability to import and export clips. A new codaclips: URL handler allows you to create a web page link that adds a clip to Coda.
Our built-in reference books are an indispensable resource for programmers, but until now you didn't benefit if you used a language that we didn't provide a book for. To remedy this, Coda 1.5 introduces custom books.
To create a book, all you need is a title and a content URL. You can optionally provide an image to be used as a book cover. Provide a specially formatted search URL and you can associate your custom book with a particular syntax mode, such as Ruby, ASP, ColdFusion, or Lasso, enabling instant keyword lookups from within Coda's editor for that language.
You can also override any built-in reference book with a custom book, so if you have a preferred reference for HTML, CSS, JavaScript, or PHP, you can use it!
Coda 1.5 benefits from improvements made in the latest version of the Subetha Engine. Of particular note, we now correctly handle syntax coloring and completion in nested syntax modes (such as inline JavaScript and CSS within HTML).
Performance of the editor is also improved, especially on Leopard.
With a greatly expanded scripting dictionary, Coda is more flexible than ever. Enable the Scripts menu in Coda's preferences, and we'll create a Coda folder in ~/Library/Scripts/Applications/Coda with some examples that show you how to get useful information in and out of Coda.
Little icons in Coda's tabs now show you which mode a given tab is in, and for editor tabs whether the file is local or remote.
Sites can now be sorted alphabetically or by last access time.
And of course there's a huge list of many, many smaller tweaks and bug fixes, too long to list here. But check the release notes if you have a pet bug that you're looking for.
We spent quite a bit of time on this release to make sure we covered all the features that our users expressed the greatest desire for, and to substantially improve the value of your 1.x purchase. There are no doubt some smaller features that you're still clamoring for, but we would have literally never shipped if we'd tried to do everything at once. So we hope you'll believe us that there will continue to be more updates with more improvements.
As always, the best place to send feedback and bug reports is: coda@panic.com
Thanks for your patience while we put this together. We hope you find it was worth the wait!
Nothing important to say right now. I just wanted to share this video with you:
The opinions expressed in this blog post are mine alone. They DO NOT represent the opinions or policies of Panic, Inc., any of my co-workers, or any other company or person. They are my thoughts, and you can't have them. OK?
I don't think I've ever been as conflicted about something as I am about the iTunes App Store. There are so many intersections at which it is both the best and worst at the same time that I'm having an incredibly hard time sorting out how I feel about it.
Some of my most inviolable principles about developing and selling software are:
I work in the software industry so I can (A) solve problems that annoy me, and (B) make money on which to live. While I respect the GPL and Open Source movements, I believe that commercial software is a necessary and important part of the ecosystem -- however NOT at the expense of the above basic freedoms.
The iTunes App Store distribution model mangles almost every one of those tenets in some way, which is exasperating to me.
But, the situation's not that clear-cut.
Apple's approval process ensures at least a basic adherence to expected UI behaviors and acts as an effective filter for malicious software.
The App Store puts my product directly in front of EVERY SINGLE person who is capable of using it. Let's not understate the value of that. There has never really been a true equivalent to this in the traditional distribution model. They also cover hosting and payment-processing fees and associated strife.
Apple's restrictions on what applications can and cannot do (with respect to sandboxing and not running in the background) prevent exactly the kind of terrible experiences I've had with other (crashy and slow) mobile devices.
And, although inconvenient, Apple's non-repeal of the NDA on iPhone development probably does protect information about iPhone technology from their competitors. At least, the ones who are concerned about not getting sued. Which, in a backhanded and perverted way, protects the very platform that the developers depend on.
So, it's all good, right?
Well, no.
What I have here is a list of what I consider to be basic developer rights and a distribution model that uses that list as toilet paper, while in return presenting me with an equally long list of genuine and tangible benefits. How do I respond to that?
Despite the store's restrictive terms, Apple's generally a "good guy" about things, right?
One thing that haunts me is the specific case of the "I Am Rich" application, which cost $999 and served no function other than providing you with bragging rights that you had enough disposable income to buy it in the first place.
Yes, it's a silly and diabolically clever idea, and I've been outspoken (especially on Twitter) about my feelings on frivolous iPhone apps. But silly ideas have a right to exist. After a tidal wave of negative comments, Apple appears to have removed the app, citing a "judgement call".
The most cited argument against I Am Rich seems to have been that someone might "accidentally purchase" the application, and there is anecdotal eveidence that this actually happened. You have to be dumber than a box of dried-out paintbrushes to "accidentally purchase" something, and even if you're unwilling to accept personal responsibility for your own actions, it should be an open-and-shut case of giving the unwitting user a refund and moving on. The fact that it's so difficult/impossible to issue a refund for an iPhone application merely highlights another glaring problem with the App Store.
Although silly, the application did not violate any of the App Store's terms of sale, to the best of my knowledge, and sat proudly amongst the menagerie of equally useless flashlights, dice-rollers, and tip calculators. Nobody was forced at gunpoint to lay down their credit card. The mere notion that software I write may be subject not just to a set of written guidelines but also arbitrary undocumented "judgement calls" after it has already been approved for sale quite frankly sends chills up my spine. I'm not sure I could ever be truly comfortable publishing software into such an environment.
I've been trying to reconcile the App Store with my beliefs on "how things should be" ever since the SDK was announced. After all this time, I still can't make it all line up. I can't question that it's probably the best mobile application distribution method yet created, but every time I use it, a little piece of my soul dies. And we don't even have anything for sale on there yet.
Here's an awesome tip on how you can preview your web site in Internet Explorer from within the Coda environment:
Step 1
Download and install VMWare Fusion 2 (currently in beta). If you don't already own VMWare Fusion, use their provided beta serial number, also shown on that page.
Step 2
Install whatever version of Windows you happen to have lying around. I created two virtual machines: an XP installation running IE7 and a Windows 2000 installation running IE6.
Step 3
Make sure you install the VMWare Tools on the guest operating system.
Step 4
For maximum impact, set VMWare Fusion to Unity mode:
Step 5
Flip over to Coda and preview a random URL:
Step 6
Press and hold the External Preview popup button in Coda. You should see entries for Internet Explorer for each Windows virtual machine:
Step 7
Be amazed as IE appears with your URL!
Now that you have set IE as your preferred external browser for Coda, you only have to single-click the External Preview button in Coda to load it up.
This seems like it should save web designers a lot of time. VMWare Fusion was a great product already -- 2.0 is shaping up to be even better!
A pet "evenings and weekends" project of mine for a while has been trying to get Mac OS X to run stably on an HP TC1100 tablet PC. I've had mixed luck, and so decided to start an entry on here to keep track of the various things I've tried that do and don't work -- mostly for my own reference, but just in case anyone else is searching for this type of information.
Why not? The TC1100 is a lightweight (2.5 lbs lighter than the ModBook) slate tablet with a great form factor that's available secondhand relatively cheaply. In my opinion, it's the best industrial design of any Tablet PC ever made. Mac OS X is the world's best operating system. Seems like they deserve each other! Plus I love tinkering.
As with any Hackintosh, you have to know the specs of the system you're working with. Note that these are for the TC1100, not the older and less capable TC1000.
ACPI_SMC_PlatformPlugin dependenciesAppleBCM440XEthernet kextWith stock installation options, JaS 10.4.6 gets you a bootable 10.4.6 system with working graphics, sound, USB, and bluetooth. WiFi and tablet digitizer are non-functional. All other hardware untested. Power management does not seem to work as the system runs very hot with full fans after a few minutes, and no battery status indicator is present in the menu bar.
Installing iwidarwin enabled WiFi, but it would only associate with a neighbor's un-passworded network. I could not get any other networks to even appear in the network list. Why it insisted on picking this network, I don't know, as the signal strength is very low, and thus it has very poor performance. But it was encouraging to see WiFi working at all.
I ended up using an AT&T USBConnect 881 cellular modem to get the tablet online, which installed and worked just as it would on a real Mac.
There are two steps to getting the ISDV4 tablet digitizer to work. So far nobody, including myself, seems to have been able to get past step 1. An extensive thread covers the issues.
The IONameMatch key in /System/Library/Extensions/Apple16X50Serial.kext/
Contents/PlugIns/Apple16X50ACPI.kext/Contents/Info.plist must be modified to match the hardware ID of the digitizer. The Wacom digitzer is on a serial (not USB!) connection to the board. The correct vendor ID for the TC1100 appears to be WACF005. Scott Lahteine maintains a script that attempts to make this modification for you.
Install Scott's TabletMagic driver for serial-based Wacom tablets.
The problem with the TC1100 is that even though the modified kext detects the WACF005 device and attaches to it (confirmed via the kextstat command line tool), no new entry is created in /dev for the serial port.
Typically the 16X50 driver will add a /dev/cu.* or /dev/tty.* or /dev/serial0 access point for the port. No such luck here.
And without the serial port visible in /dev, TabletMagic will not work. So far, I've not heard of any TC1100 user successfully getting the digitizer to appear in /dev.
The biggest clue I've seen so far is this page which discusses getting Linux to recognize tablet PC digitizers. It says that by default, the UART controlling the digitizer often isn't mapped to a serial port. He shows a Linux command for making this happen: setserial /dev/ttyS2 port 0x93f8 autoconfig. What the Mac OS X equivalent to this would be, I haven't been able to figure out.
The article goes on to specifically mention the TC1100 and even shows some apparently HP-provided source code for enabling the digitizer before setserial is executed:
/*
* HP TC1100 Touchscreen Enable
* Copyright (c) 2004 Hewlett-Packard Co.
*
* Compile with `cc -O2 -o tc1100ts tc1100ts.c',
* and run as root with `./tc1100ts'.
*
* This standalone program enables the Serial Port 1
* (SP1) of the NS LPC Super I/O, where the Wacom
* Digitizer is connected to on the HP TC1100 Tablet PC.
*
* The serial device is mapped to 0x3e8 IRQ0-4 to match
* the default /dev/ttyS2 port and IRQ mapping on Linux.
*
* To proof that the Wacom Digitizer is enabled by this
* standalone, do the following:
* - Change to superuser mode, i.e. root
* - setserial /dev/ttyS2
* it should return:
* /dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
* - ./tc1100ts
* - setserial /dev/ttyS2 autoconfig
* - setserial /dev/ttyS2
* now returns:
* /dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4
*
*/
#include <stdio.h>
#include <unistd.h>
#include <sys/io.h>
#include <stdlib.h>
const int cfgindex = 0x4e;
const int cfgdata = 0x4f;
#define wsio(i,d) {outb(i,cfgindex); outb(d,cfgdata);}
int main()
{
/* Get access to the ports */
if (iopl(3)) {perror("iopl"); exit(1);}
// See the SuperIO Specificatio for details of each register
wsio(0x07,0x03); // Select Logical Device - Serial Port 1
wsio(0x30,0x00); // De-activate Logical Device
wsio(0x60,0x03); // I/O Port Base [15-08]
wsio(0x61,0xe8); // I/O Port Base [07-00]
wsio(0x70,0x14); // Enables Wake-up on IRQ4
wsio(0x71,0x03); // Level IRQ Req, Hi priority
wsio(0x74,0x04); // DMA Channel Select 0 - no DMA
wsio(0x75,0x04); // DMA Channel Select 1 - no DMA
wsio(0x30,0x01); // Activate Logical Device
/* We don't need the ports anymore */
if (iopl(0)) {perror("iopl"); exit(1);}
exit(0);
}
/* end of tc1100ts.c */
To workaround the non-existence of iopl() on Mac OS X, I tried making a dummy KEXT that did nothing but issue those outb() commands when loaded, then loading the Apple16X50 KEXT. Unfortunately, I still didn't get a new serial port in /dev so I'm not sure what to try next.
I've not yet begun to research how to fix this. Here's a big thread on the PowerManagement bundle
Linux patches for enabling various TC1100 hardware, including RF and digitizer.