| Code by Kevin | |||||
|
Subscribe to RSS Feed 2008 2007 2006 Categories Business Software General |
home :: software
Fri, 08 Aug 2008
Phynchronicity 2.2
I want everyone to know that, despite my frequent ruminations about Apple essentially forcing developers to migrate to their privileged Cocoa frameworks, I haven't been neglecting my products. Today I released a new version of PortAuthority, and major and/or minor updates of all of my other products are also in the works. For my products, updates tend to fall into two categories: application-specific improvements; and infrastructure improvements that can be added to each of my programs. This means that I often release updates in clusters, because they reflect improvements in frameworks and extensions that I use across my applications. PortAuthority 2.6, my GUI for the MacPorts Unix software management system, is now out. It's been seven months since the last release. PortAuthority is fairly mature and bug-free as a product, so there is less need to update it frequently. However, the new release contains some useful new features, including a faster display of all MacPorts packages; Growl support; and various UI improvements to give the user greater control of application windows, product updates, and display of their serial number. 2.6 is a free update to registered users. If you use PortAuthority, you'll want to install the new version. Fri, 25 Jul 2008I've taken a step back from Aaron Hillegass' Cocoa programming book to learn the foundational language of Cocoa: C. Yes, I know the actual core language of Cocoa is Objective-C. And yes, I have Stephen Kochan's book on Objective-C on my list of books to work through. But Objective-C, at its heart, is a small suite of extensions to C that add object-oriented capabilities to the language. What this means is that, despite the very different approaches to programming between Objective-C and C, you really need to know C. Problem is, C is hard if you are coming to the language from a higher-level "scripting" language, as I am. In general, programming languages work like math. If you remember algebra, you'd have an equation and some variables--x and y--and you've have to find the value of x or y. Programming languages use variables in a similar fashion, to perform manipulations on data. The difference between a scripting language such as Tcl and C is how those variables, and the operations on them, are established. A scripting language is also called an "interpreted" language--the code in the language is executed by a separate program called an "interpreter." In the case of Tcl, the interpreter is a small program called tclsh. In an interpreted language, variables can be created and manipulated very easily, and the interpreter takes care of all the details of executing the code--making sure there's enough memory for your data, for instance, and making sure that numbers and words are handled appropriately (you can't perform math operations on something that isn't a number!). In C, and in other compiled languages such as Objective-C, you have to handle a lot of details yourself. When setting up a variable, you have to make sure it's identified as a number (such as an "int," for integer) or word ("char," short for "character"). You have to set up memory for the various tasks your program is going to perform. And then you have to compile your code into an executable program. There's no interpreter involved. (Most interpreted langauges, in fact, are themselves written in a lower-level compiled language such as C--Tcl is written in C.) So I've been working through an introduction to C programming, co-written by a noted Mac developer, and trying to map what I already know about programming into C. The translation process is an imperfect one, because scripting languages have allowed me to work at a fairly high level of abstraction. I can write code that solves my problems and not worry too much about how my code is actually executed by the computer; the interpreter takes care of that. Picking up a second scripting language (Python) wasn't terribly difficult after I gained proficiency in one (Tcl), because they operate at the same level of abstraction. Learning C requires a lower level of abstraction. Programming in C requires a lot more interaction with how the computer actually executes your code: allocating memory, for instance. I have to take more steps to allocate and release memory, to make sure all my variables are correctly defined, and so on. It's also slower to develop in C: the code I write in C is actually compiled into machine language, the binary executable that is actually run by the computer's CPU. That explicit compilation step is unnecessary in scripting languages. Now that I've spent a couple of weeks working through various exercises, it's time to start something real--that's the only way I truly learn something. The current project I'm working on is porting the code I use for generating and validating serial numbers (currently written in a scripting langauge) to C. It's proving harder than I expected, but thanks to some assistance on the comp.lang.c newsgroup, I'm making progress. Once I get a bit further along, I will be ready to tackle Cocoa more in-depth, because I'll have more of a foundation on the compiled-language level of abstraction. After that, who knows? If I want to do any enhancements to Tcl or Tk, that will have to be done in C. (Note: I didn't read this article until after I started learning C, but I certainly recognize the attitude contained therein: "Real programmers" program in, or at least know, C. Or, to directly quote the article: "Yep, we C programmers are elitist and proud of it.") Sun, 18 May 2008I've just released Manpower, which provides a GUI for viewing man pages on OS X. This isn't the first program of this type that I've developed. For two years I developed VuMan, another man page viewer--first as open source, then as commercial software, then put out to pasture as open source again. If you download and play with VuMan, you'll see that it has a somewhat clunky interface. I could never decide what I wanted the program to be--a viewer? A browser? A complete listing of man pages on your system? A tool for saving man pages in various formats? It did all of these things, but it made the program somewhat difficult to use. VuMan was also sluggish, calling out to multiple Mac command-line tools any time a user pressed a button. Manpower is significantly different than VuMan. It lists all the man pages on your system, but it uses a more coherent design: it uses the same three-pane interface that Apple's Mail program, and iTunes, use. Man pages come up with a click of the mouse, not with selecting and pushing multiple buttons. Manpower also saves man pages, but only in basic text format. Simplicity is the key here. By simplifying the feature set and design of the program, I think I've made it much easier and more pleasant to use. I have a few ideas of additional features to add, but they will be added sparingly--in a way that is consistent with the lightweight design of the program. Not coincidentally, Manpower's simplicity and elegance is why I think the program justifies a $19.95 price tag. There are a lot of free man page viewers out there, but they either do less than Manpower, or are (in my view) more complicated to use. I don't think there's a free man page viewer out there (including VuMan) that is as clean and elegant as Manpower. I hope you'll agree. Sun, 24 Feb 2008A couple of weeks ago I got an e-mail from a member of the Oxygen icons team, my primary source for application and toolbar icons, asking me to clarify the terms of use of the icons. Because I'm using the icons freely under an open-source license (see the credits page on my website for details), I gladly complied. Open-source code is a terrific resource for commercial developers, because it can save a lot of time and cost--I don't have to develop these items myself. Of course, it's incumbent on me to use the software in a manner that's consistent with their license. Some open-source code can only be used in other open-source projects, while others can be used in commercial products as well. The components I use come with commercial-friendly licensing terms. I think it's important to do more than simply comply with the terms of an open-source license, however. I try to contribute to open-source projects as well. I've contributed documentation, bug reports, code patches, and code samples to the Tcl/Tk and Python software communities. In addition, I maintain an entire suite of software extensions and packages here. Whenever I develop a code package that improves my software and that I think can benefit others as well, I release it under an open-source license. (See http://tk-components.sourceforge.net/mactoolbar/index.html for one component that worked its way into my products over the past few months.) In fact, that's what I've been working on the for the past few weeks--some open-source components that will eventually become part of new commercial products and my existing products as well. These components are geared toward improving the user interface of my programs, and will allow me to develop more polished products. It's my hope that other developers will be able to make use of my projects, much as I've been able to make use of the open-source work of others as well. That's what giving back is all about. Thu, 24 Jan 2008After a final push, new versions of PortAuthority, Phynchronicity, and PacketStream are ready. Enjoy. Tue, 09 Oct 2007I've released Phynchronicity 2.0, my GUI for the Fink Unix software management system. As I noted previously, this new version incorporates the many improvements I've made to the design, usability and documentation of my other programs as well. If you use Fink and are looking for an intuitive GUI for it, Phynchronicity is worth trying out. Mon, 24 Sep 2007I've released an update to PortAuthority, my GUI for MacPorts. This release focuses on improving the user experience for those trying out the program for the first time. Previous versions of PortAuthority would throw up a huge number of windows on first launch--a preferences window, a "do you want to buy" dialog, and so on--that made it hard to get started. Version 2.4 streamlines this process greatly by reducing the number of startup windows and fixing several bugs. This release also fixes some minor glitches with scrolling the tree view, and adds a "contact the developer" command to the help menu, to improve user support. If you use PortAuthority regularly or want to try it out, this new release will interest you. Thu, 13 Sep 2007
VuMan and NameFind now open-open source
I have released free, open-source versions of NameFind and VuMan, two commercial applications I recently discontinued. I've done this in response to a query from a registered user of one of these programs. I also continue to make use of both programs; although they did not attract much of a commercial user base, I believe they are still useful. The only real update for these new versions was to remove some proprietary components, such as icons, code for managing software updates, and so on; I also updated the documentation of each program. However, neither has undergone the extensive redesign I've given to programs such as PortAuthority, and I do not anticipate updating these programs further in the future. NameFind can be downloaded at http://ireveal.sourceforge.net, and VuMan can be downloaded at http://vuman.sourceforge.net. Enjoy. |
||||