| Code by Kevin | |||||
|
Subscribe to RSS Feed 2010 2009 2008 2007 2006 Categories Business Software General |
home :: software
Wed, 24 Feb 2010 I've released version 3.1 of Manpower, the GUI for viewing man pages on OS X. Version 3.1 is a pretty big update, building on 3.0's transition to 64-bit capabilities and Cocoa. 3.1 includes support for AppleScript and Services; it also includes a long-requested feature, the ability to bookmark specific man pages. I've also added the ability to input and display a single man page, which is something that probably should have been part of the application from the beginning. With these new features, I strongly believe that Manpower is the most complete GUI tool for browsing and viewing man pages on OS X. As part of the new release, I've also lowered Manpower's price a bit, from $24.95 to $19.95. This is motivated by a couple of factors. First, most of Manpower's competitors are free. While I believe Manpower's feature set surpasses any of its competitors and is well worth paying for, I can't completely ignore the market, and $24.95 may be a bit high for this particular niche. I also have actual data to support this change: Manpower was originally priced at $19.95 when it was first released two years ago, and it sold better at that price point than at a higher price point. So, I'm hopeful that the lower price will prompt you to take a closer look. Wed, 10 Feb 2010I'm pleased to announce the release of the macdrawer package for Tk on Mac OS X. This package implements Mac-native "drawer" windows for Tk. "Drawer" windows are windows are attached to the side of a toplevel window, and whose visibility can be toggled with a button. Drawers contain frequently accessed controls that do not need to be visible at all times. The package is available at http://tk-components.sourceforge.net and is licensed under Tcl's BSD-style license. Both file releases and SVN downloads are available. In addition to source code, the packages include demo scripts and man pages. This extension requires Tk-Cocoa to run; it is not compatible with the older version of Tk based on the Mac's Carbon framework. Tk 8.6 for the Mac is based on Cocoa, and a backport of Tk-Cocoa to 8.5 is available at http://github.com/das/tcltk/tree/de-carbon-8-5. Thu, 21 Jan 2010I've released version 2.1 of QuickWho, my domain-search GUI for OS X. The big new feature in this release is support for AppleScript and Services, opening up possiblities for inter-appliction communication between QuickWho and other apps. The other big feature is that QuickWho is now a fully 64-bit application; I solved the build issues that previously prevented this from happening. This version also incorporates much of the work I've done recently in Tk itself for a better UI, and also includes a good deal of under-the-hood optimization to reduce the application's size and startup time. One other major change: I've lowered the price for QuickWho from $24.95 to $12.95. Previous versions of QuickWho haven't sold very much, and what sales I did receive most often came when I ran a discount campaign. I think this fact shows that the market judged QuickWho to be overpriced at $24.95, especially when you compare its relative simplicity to some of my other, better-selling programs that also have a $24.95 price tag (such as PortAuthority). I still believe that QuickWho's polish, documentation, and its system-wide integration via AppleScript and Services make it a superior alternative to command-line and freeware tools--it offers value that is worth paying for. But I think $12.95 is a more accurate reflection of its value. Tue, 12 Jan 2010This is a bit late, but I'm pleased to announce the long-awaited availability of TkDND on the Mac. This package allows you to drag files and text from other Mac applications to Tk applications. This basic GUI functionality has been a sore omission from Tk on the Mac, but George Petasis (with some assistance from myself) has done a major update of the package, including Mac support. I'm looking forward to integrating this essential library into my applications.
Inter-application communication on OS X: AppleScript and Services
One of the nicest features of Mac OS X is the operating system's support for inter-application communication. Of course, OS X's Unix underpinnings do a great deal in this respect, but the application level also provides many useful features as well. Specifically, OS X includes AppleScript and Services. AppleScript is the Mac's system scripting language, allowing different applications that support AppleScript to communicate with each other, exchange data, and more. AppleScript can be used to combine applications in unusual and unique ways, leveraging the strengths of each application to build complex workflows. It's not unusual to see AppleScript-based workflows that combine Microsoft Word, Adobe InDesign, and the FileMaker database to create elaborate publications, for instance. And AppleScript hooks into the lower levels of OS X as well, with a Unix-level command-line tool. No other scripting language touches as many aspects of the Mac as AppleScript. My applications make extensive use of AppleScript internally to communicate with various aspects of the OS. Services are a smaller, but still powerful, aspect of OS X. Services allow an application to expose part of its functionality to other applications, which can then be accessed from a system-wide menu. In accessing Services, you might highlight some text in TextEdit, select "Search with Google" from the Services menu, and then watch Safari fire up and run the selected term in the Google site. You can't really chain Services together into complex workflows the way you can with AppleScript--but, on the other hand, Services are just a menu click away. Most professional-level applications on OS X support AppleScript and Services to at least some degree. Not only is it a sign of the application's polish and integration with the Mac OS, it's just an added dimension of usability, of utility. My own applications have lacked this dimension, and that My own applications have not done so. As I've given this more thought, I've come to regard this as a pretty serious omission. How much more useful would NameFind be if you could highlight a search term and launch a search for a filename with that term in a specific directory? Or if you could write an AppleScript that would search for a particular software package in both PortAuthority and Phynchronicity? I've spent the last few weeks exploring ways to add AppleScript and Services support for my programs, and after some trial and error, I think I have the hooks in place to provide basic support for both. It will take some time--and imagination--to figure out what types of functionality to export via AppleScript and Services, but that's the fun part. And, once I'm finished, my applications will be better Mac OS citizens. Fri, 11 Dec 2009I'm pleased to announce the release of three Mac-platform-native Tk-extensions that build on the Cocoa frameworks to integrate with the new Cocoa-based version of Tk for the Mac. Macsheet This package implements Mac-native "sheet" windows for Tk. "Sheet" windows are dialogs or toplevel windows that slide down from the top of a Mac toplevel window, and then slide back up when they are dismissed. Tk on the Mac has long supported the "sheet" effect for system dialogs, such as tk_messageBox, when a "-parent" option is passed to the call. The macsheet package adds the ability to create customized dialogs or windows with a similar effect. Tkdock The tkdock package allows a Tcl/Tk application to manipulate the Dock icon. The package allows an application to change its icon on the OS X Dock while running; it also allows the application to set a badge label to the Dock. Tkmacicon The tkmacicon package renders platform-native icons on OS X as Tk images. The ::tkmacicon::retrieveicon command takes three arguments: a file path or file extension, width, and height. If a file path is specified, then the package will return the specific icon for that file as defined by the Mac OS, in the width and height specified in the arguments. If a file extension is specified, then the package will return the specific icon for that file type as defined by the Mac OS, in the width and height specified in the arguments. Specifying the file extension rather than the actual file can yield faster performance for large numbers of files. All three packages are available at http://tk-components.sourceforge.net/ and are licensed under Tcl's BSD-style license. Both file releases and SVN downloads are available. In addition to source code, the packages include demo scripts and man pages. These extensions require Tk-Cocoa to run; they are not compatible with the older version of Tk based on the Mac's Carbon framework. Tk 8.6 for the Mac is based on Cocoa, and a backport of Tk-Cocoa to 8.5 is available at http://github.com/das/tcltk/tree/de-carbon-8-5. Thu, 26 Nov 2009
More progress on adding features to Tk-Cocoa
First, the good news... Drag-and-drop. I'm making some good progress on my project to port TkDND to OS X: I've successfully gotten Tk widgets to recognize files and strings of text that are dragged to it. I still have to do some work on integrating my code with TkDND itself, which will take some time--but the hardest part is over. I won't be implementing drags from Tk windows to other Mac windows or the Finder/desktop, because that's considerably more complicated. Even with this limitation, being able to drag files and text directly to Tk windows will be a big improvement in usability and Mac-native integration. Custom sheets. Tk has long supported "sheets"--dialogs that slide down from the window--with standard system dialogs, file choosers, and so on. It hasn't supported custom dialogs that a programmer may choose to implement, such as a password dialog. With just a couple of days of work, I've got a decent implementation put together. The slide-down of custom dialogs isn't as smooth as system dialogs (because of some differences in how Tk draws windows and how Cocoa manages the "sheet" effect), but it's good enough for my requirements--and again, a nice improvement in usability and integration. I've gotten the Cocoa-level code working fine; I have to add some additional script-level code (based on the prototype code I've been hacking on) to make the package complete. Next, the bad news... Native Cocoa printing/dialogs. I've decided not to attempt to develop a Tk extension that provides system-native (Cocoa-based) printing. The command-line tools to support printing on OS X are superb, as I've discussed before, and native printing dialogs simply won't offer a huge improvement over what I am already doing. My one serious motivation for exploring native printing was the inability of the command-line tools to print HTML well. I've been using an open-source tool called HTMLDoc to generate a PDF file from HTML, which I can then print via the command-line. HTMLDoc does a good job, but it is a large program, and because it is licensed under the GPL, I have to include the source code for the program with my applications; the combination of these two things greatly increases the size of my applications. However, more recently I've run across a command-line tool called wkpdf--a Cocoa-native WebKit (HTML)-to-PDF tool that uses the Cocoa frameworks for the conversion. It's much smaller than HTMLDoc and works a bit better, to boot, so this solves my HTML-printing problem. As a result, I have no real need for a Cocoa-native printing solution, and won't be pursuing this. Finally, on the to-do list... Dock icons and native Mac icons. I've developed several packages in the past year to integrate native Mac icons in my applications, to modify the Dock icon of my programs, and to add a badge to the Dock icon. Some of these I've released as open-source, and some I haven't. I plan to do a bit more work on expanding and polishing the capabilities of these extensions; then I will do a big release of them. It's my hope that others will find my work on these projects beneficial, but I'm doing them first and foremost to improve the capabilities of my commercial applications: that's why I have to pick and choose among the many possibilities for (unpaid) open-source work that I run across. I've been working on these projects for several weeks now, and eventually I need to get back to working on applications that users pay for. After this round of projects is done, my applications will have several new capabilities, which will make them more pleasant to use. Tue, 20 Oct 2009I now have no doubt that my Tk-Cocoa applications are "real" Cocoa applications: they are susceptible to input managers. An input manager is an arbitrary Cocoa extension that loads into every running Cocoa application (because it loads into the Mac's Objective-C runtime). Originally designed to allow for alternate methods of text input, it is now more commonly used to inject code into any or all Cocoa applications. While this is most frequently done to add functionality to a specific application, it can pose a security risk for your system by allowing the injection of malicious code into the Cocoa runtime. Even if it doesn't do that, input managers can also have unintended side effects on random Cocoa applications. I got a bug report about such an unintended side effect over the weekend. An application user mentioned to me that Manpower was crashing. After reviewing some crash logs provided by the user, I found a reference to an input manager installed on the user's system, along with the error message "GC capability mismatch." ("GC capability" refers to whether an application was compiled with garbage collection--a method of automated memory management--or not; Tk-Cocoa makes use of GC, but many Cocoa applications do not.) This is an example of an unintended side effect. Neither Manpower nor Tk-Cocoa itself had anything to do with the input manager in question, but because the input manager was exposed to every application that makes use of the Cocoa runtime, this conflict caused Manpower to crash. I advised the user that, as with AppleScript osax extensions, the only solution is to uninstall the input manager. So, if you're experiencing crashes with any of my applications, input manager conflicts are something else to look for. Ah, the brave new world of Cocoa! Tue, 13 Oct 2009
The big bang: Tk-Cocoa integration complete
Today's a milestone: the migration of my applications to Tk-Cocoa is complete, and I'm releasing all of them on the same day. A couple of years ago, when Apple announced that Carbon was going to be deprecated, I worried about the future of my software business. My toolkit of choice, Tk, was built on Carbon, and no clear roadmap for integrating Tk and Cocoa existed. Would I have to abandon Tk and rewrite my applications from scratch in Cocoa or another toolkit? Happily, two years later, those fears have proven to be unfounded. Apple itself sponsored the porting of Tk to run on top of Cocoa, and Daniel Steffen, the maintainer of Tcl/Tk on the Mac, capably handled the port. As I've written before, Tk-Cocoa offers many improvements over its previous Carbon-based incarnation: better native integration with the OS's UI guidelines, more UI polish, and (most of all) better performance, because it is 64-bit capable. I've done some UI freshening of my applications, and have fixed numerous bugs in them, but the major feature is simply their migration to Tk-Cocoa. All of my Tcl/Tk applications are fully 64-bit, and their performance is notably better. Because of some issues with Python's application deployment tools, my Python applications are hybrid 32-bit/64-bit (the Tk part is 64-bit, the Python part is 32-bit), but I anticipate this will be fixed in the near future. In every case, the applications have more UI polish. Every release is now a version upgrade (2.0 to 3.0), not just a point release (2.0 to 2.1). Despite the improvements, I'm holding the line on prices, so my applications are a better value than ever. I'm very grateful to Apple and Daniel for bringing Tk on the Mac to the next level. Tk-Cocoa will provide a stable platform for my applications for years to come, and I am very near the day when I can focus exclusively on application features and not banging against the limitations of my chosen toolkit. In turn, I expect this will lead to more and better application development, and growth of my software business. I'm so excited! If you want to celebrate with me, check out the applications, and let me know what you think... Mon, 05 Oct 2009I've continued to get some reports of PortAuthority crashing on Snow Leopard. As I discussed in a previous blog entry, these crashes are often the result of AppleScript conflicts caused by 32-bit "osax" files. The most common offenders that I've run across are osax files installed by Adobe in support of its Photoshop program. Not surprising, given that Adobe is the heavyweight vendor of graphic and publishing software for the Mac. I was pleasantly surprised today to hear from a user that Adobe has quietly updated some of its osax files to support 64-bit. You can see the details and file downloads in this technical note. So, if you're having problems with PortAuthority or any of my other programs and traced the problem to conflicts with Adobe osax files, try updating the offending files and see if that solves the problem. |
||||