Sun, 02 Jun 2013

Fullscreen 1.1

I've released version 1.1 of my "fullscreen" open-source library for Tcl/Tk apps on the Mac. This package adds native a "fullscreen" button to Tk windows on Mac OS X 10.7 and later. This release, which is a fairly major under-the-hood rewrite, fixes a major bug with window geometry when the app took fullscreen status (widgets such as buttons would not respond to mouse clicks but instead the click would register a few pixels underneath the widget). For more information, and to download, see http://opensource.codebykevin.com/native.html. Thanks to Andrew Stein for the bug report.

[/software] permanent link

Tweet

0 Comments

URLs in comment text will be treated as spam.

Name:
Web Site (optional):
Comments:

Sat, 18 May 2013

Mac integration: what matters most?

Earlier this month I talked about recent changes in UI fashion on OS X, away from bright colors and icons toward a more muted look. This general trend is going to help guide me as I do a significant round of updates on my apps.

I wanted to talk about a related topic as I decide how to update my apps, in terms of how they integrate with OS X. I've always believed that a high level of OS integration is very important in my apps even though I develop using a cross-platform toolkit. The question is, what type of OS-level integration is the most important--visual integration, integration under the hood, or some combination of the two? Until very recently, even though I do strive to integrate with the OS on several different fronts, my answer to this question would have focused on visual integration. Most of my work in recent years has focused on visual integration: native toolbars, printing dialogs, manipulation of the Dock icon, a status icon in the menubar, and more. And my apps have done well on this front.

Yet I am beginning to wonder if the time I've spent on visual integration has been well-spent. In terms of functionality, my apps have advanced at a much slower pace than their visual fidelity to Mac UI conventions. And the increasing pace of change and complexity in Mac UI conventions--especially to support Retina displays--mean that I will have to spend yet more time on UI integration, at the expense of other features.

I'll be honest: I'm getting a bit tired of this treadmill. So I'm starting to look in another direction for an example of how to proceed, NeoOffice, a Mac-optimized version of the open-source OpenOffice office suite, developed for the past decade by Patrick Luby and Ed Peterlin.

A bit of background: OpenOffice is essentially a cross-platform, open-source clone of Microsoft Office. It was originally developed as a commercial product, was bought and open-sourced by Sun Microsystems, and then became a fully independent, open-source project after Sun was acquired by Oracle, the database company. A large community of volunteers and some professional developers maintain OpenOffice and several variants, including LibreOffice (which forked from OpenOffice after it was acquired by Oracle and before Oracle divested the project) and NeoOffice.

NeoOffice came into being because, back in 2003, OpenOffice only ran as a Unix-style X11 application on the Mac: powerful and functional, but not integrated in any way whatsoever. Patrick Luby and Ed Peterlin have gradually enhanced the OpenOffice code base with Mac optimizations, to the point where their version is far superior on the Mac to standard OpenOffice (which now runs natively, but has no special Mac optimizations beyond running as a standard app and not in the X11 environment). They have chosen a different, incompatible open-source license for NeoOffice (GPL) so their code changes cannot be merged back into the standard OpenOffice code suite.

A list of differences between NeoOffice and OpenOffice is instructive. The most recent version of NeoOffice supports the new Mac fullscreen mode introduced in 10.7; supports the Mac document "Versions" feature introduced in 10.7; is much faster than OpenOffice because it uses the latest Mac text-rendering framework, Core Text; supports OS X Services; and more. OpenOffice supports none of these features.

This high degree of OS-level integration may not be immediately apparent if one looks at a screenshot of NeoOffice, such as below, because NeoOffice does not invest heavily in visual integration with Mac UI conventions:

The icons fit reasonably well with the Mac, but toolbars are definitely not native, and the general UI design--i.e. putting tons of buttons in a toolbar--does not follow Mac-optimized guidelines either. While the under-the-hood integration is superior, the visual integration of NeoOffice from a design standpoint is little different from the other variants of OpenOffice. In response to user questions about the UI, the NeoOffice developers have said that, because of limited resources, rewriting the UI of NeoOffice is not in their plans; they prefer to focus on under-the-hood integration, application performance, and so on.

What I find very interesting about NeoOffice is that its under-the-hood integration with the OS is not just better than OpenOffice; it is also arguably better than Microsoft Office's. Microsoft Office 2011 does not support the "Versions" feature either, and I suspect it still uses the same older text-rendering engine that OpenOffice does. Microsoft Office 2011 is, from a general performance standpoint, much slower, less snappy, more sluggish, than NeoOffice, as well.

In terms of visual integration, however, Microsoft Office far surpasses NeoOffice, using a native toolbar, native search field, and, in general, an overall design that well adheres to Mac UI guidelines. Microsoft has taken its "Ribbon" UI concept and, rather than doing a straight port of it from Windows, has implemented in a way that makes sense on the Mac:

Microsoft is to be commended for its work in visual integration. It also goes without saying that Microsoft Office is very powerful. However, as one who uses both Microsoft Office and NeoOffice frequently, I have to suggest that Microsoft's superior visual integration does not offset its sluggishness. I find that NeoOffice is generally easier to use, despite its lack of visual integration. (In fairness, one significant under-the-hood area where Microsoft Office does greatly surpass NeoOffice is in its support for AppleScript, but I don't make much use of this feature.)

So what lessons am I drawing from this discussion? An important one is that I have come to conclude that perfect visual integration is overrated. The likely overhead of continuing to provide a high level of visual integration in my own apps, i.e. to comply with Retina display requirements, does not seem worth it if the apps are sluggish and slow--a complaint I've increasingly heard in the past year or so, which also coincides with an unexpected decline in sales. I want to have reasonable visual integration, but it has to be done in a manner that is easily maintained and allows me to focus on other kinds of optimization and integration as well.

The NeoOffice developers recognize their limits, and are focusing on the types of optimizations and integrations that will give them the most bang for their buck. And I say "buck" literally; the developers earn their living from NeoOffice work, charging an annual $10 download fee to get the app from their website and a year's worth of updates. They have enough users that this is feasible from a business standpoint, and they manage this in spite of the competition from the free OpenOffice variants, such as LibreOffice and the original OpenOffice.

So I will work to maintain a reasonable level of visual integration--I fully intend to support Retina displays--but this will be done in a way that allows me to use my limited time for other, arguably more important, optimizations and integrations. I want my apps to be fast and pleasant to use, and I want them to integrate with the OS in ways other than just visually. They have a ways to go on that front, but I'm taking my first steps in that direction.

One Tcl/Tk app I like for its clean, basic UI is WaveSurfer, an open source tool for sound visualization and manipulation. Its UI is very simple, providing a visual representation of a sound's waveform, with a single set of toolbar buttons that get out of the user's way:

The lack of a standard Mac "unified toolbar" here is not problematic for me, and I imagine the overhead of adding one to the app's UI design would not be worth it for the developer. This app gets its job done in a clean, simple way, and, as with NeoOffice, I'm taking instruction from it for the future development of my own apps.

[/software] permanent link

Tweet

0 Comments

URLs in comment text will be treated as spam.

Name:
Web Site (optional):
Comments:

Fri, 17 May 2013

Three new Tk-Cocoa integration packages

I'm pleased to announce three new Tk-Cocoa integration packages for Mac OS X.

Fullscreen: This package adds native a "fullscreen" button to Tk windows on Mac OS X 10.7 and later. The package adds the fullscreen button that, when pressed, will smoothly animate the window to fullscreen status. The window can be restored to its previous state by clicking the upper right-hand part of the screen and locating the button in the menubar. This package has no relationship to the standard Tk command "wm attributes $w -fullscreen 1," which also implements a fullscreen window and tracks its state internally through Tk. Under OS X, the "wm attributes" command uses different API's and its state can be tracked and configured via Tk. The "::fullscreen::fullscreen" only adds the fullscreen button to the window, and does not track the window's state; setting the window to fullscreen state is triggered by the user. The benefit of this command is that it provides better integration with modern Mac API's.

I've been wanting to implement something like this ever since OS X 10.7 "Lion" came out; I think the fullscreen button is a neat, and useful, effect if you want to immerse yourself in a single app. I could never figure out how to integrate the functionality into Tk's core, especially in a way that played well with existing Tk commands, but the functionality itself is very simple and, once I decided to implement it as an extension library, everything came together quickly.

TclGrowl: This package implements native support for the Growl desktop notification system on OS X. It provides Tcl support via a SWIG wrapper for the gntp-send library, which implements Growl's custom network protocol.

Growl is a popular third-party notification for the Mac, and in the past year or so it has been modernized to play well with recent Mac technologies for Lion and later, such as sandboxing and the Mac App Store. Various Tcl bindings for Growl have been deployed over the years, including more than one written by me, but these older packages are either obsolete (Growl has undergone significant internal changes) or, at a minimum, incompatible with one or more modern Mac features (the Mac App Store has made it much harder to use AppleScript to glue together various applications; my last Growl binding was based on Growl's AppleScript API). I found a third-party library written primarily for Linux, gntp-send, that implemented Growl's notification protocol, and developed a Tcl binding for it. This approach brings Tcl's Growl bindings up to date and sidesteps the limitations of AppleScript, so it's a useful addition to the toolbox.

TkWebView: This package adds a native WebKit display in Tk apps on OS X, using the same rendering engine that powers Safari. It is designed for display of local HTML files. Links to remote sites (i.e., those beginning with http) will launch the user's default browser. TkWebView does not display remote URL's; this is not a technical constraint but rather a design decision, to encourage a separation between local display of HTML content and an external browser. TkWebView also does not provide direct access to the HTML content, browsing history, etc. from Tk; it delegates all management of browsing history and HTML content to WebKit. HTML navigation can be built into the HTML pages themselves via JavaScript, href links, and so on.

TkWebView is perhaps the most significant of these packages, as it displays HTML content using the exact same engine as Safari. I posted a query on the Tcl-Mac mailing list about four years ago asking if anyone could provide some guidance in integrating Tcl/Tk with WebKit, and Daniel Steffen, my predecessor as Tk's maintainer on the Mac, threw together a very basic implementation. It was a bit unstable (though that was more because of WebKit bugs on OS X 10.5 rather than in Daniel's code), and so I set it aside. In the past year I came back to the code, added some additional logic to it that would allow the package to serve nicely as a viewer for local HTML content, and polished it up enough for release. This new package supersedes an earlier, pure-Tcl package also called "TkWebView," that I put together based on some truly ancient (mid-1990s) Tk code, and I have removed the older package from my website.

These packages all scratch long-standing itches for me, and should improve the integration of any modern Tk app on OS X. I know they will mine. For more information, and to download them, visit my open-source site.

[/software] permanent link

Tweet

2 Comments

URLs in comment text will be treated as spam.

Name:
Web Site (optional):
Comments:

Thu, 09 May 2013

Modernizing the UI

As I mentioned a couple of months ago, I'm in the middle of a large group of updates to my Mac apps. As I've delved into these updates (which focus on implementing libraries and frameworks that will improve all of my apps), I've come to the conclusion that it's time to update their user interface.

The last significant UI update to the apps came in 2011, when I implemented a native Cocoa toolbar for my programs, which, in my view, made them better integrated with OS X. At that point, I was taking a lot of UI inspiration from apps like NetNewsWire, the leading RSS reader for OS X, and which influenced a large number of Mac apps over the years.

Here's a screenshot of NetNewsWire:

Note the clean three-pane interface, the large, easy-to-understand icons in the toolbar, and other details.

And here's my implementation of this interface style in Manpower, my man page reader for OS X:

Note the three-pane interface, the large toolbar icons, and so on. By way of contrast, see this blog entry for some before-and-after comparisons of my apps with an older UI design and the new UI design using the native Cocoa toolbar.

I was very proud of this UI design when I completed it. However, I'm not as happy with it anymore. Several significant changes have come about in the Mac ecosystem, just since 2011: Apple's introduction of high-resolution Retina display technology in its MacBook Pro machines; and the increasing influence of iOS interface design on the Mac UI.

In terms of the Retina display, it has twice the pixel density of standard monitors, so that means that standard images look pixellated when displayed on it; Apple has implemented several API's and best practices to make images look sharp on the high-resolution machines. This requires to make several changes to their applications to work well with the Retina display, including bundling higher-resolution images with their applications.

In terms of iOS UI design, this is reflected in Apple's moving to a much more subdued color and icon scheme in the applications deployed on OS X since 10.7, Lion; buttons are muted, icons are smaller in size and monochrome in layout, and so on. Consider the Mail app in Lion:

What this means for my own apps is that their bright, large-icon interfaces now look somewhat dated, and they also need to be updated to support Retina displays.

A significant part of the work I'll be doing over the next several months is implementing these UI updates, and I've spent a significant amount of time in recent weeks mulling over options on how to proceed on these updates. These updates will require changes under the hood (code) and in the visuals and layout of the apps; it's much more than a simple matter of swapping out images.

While I haven't made a final decision about this yet, one approach I'm actively researching is based on my work on my iPhone apps: using font icons instead of actual image files for icons. A "font icon" is a font character that actually renders an icon image rather than a letter or number; it's a very recent development in web design, and it can translate fairly easily into desktop apps. Font icons offer several advantages over regular images. The most important one is that they are resolution independent, meaning that they scale up and down automatically with the resolution of the computer screen; this will greatly simplify the process of supporting the Retina display. Another advantage of font icons is that they are most commonly designed in the simple, muted style that is now the prevailing mode in both iOS and Mac UI design; this means that they will fit in better. Finally, there are several free, high-quality, open-source font icon sets that I can choose from; this will make the process of modernizing the appearance of my apps much smoother.

I don't have any mockups or other screen shots of my apps with a new UI design to share yet; I'm still very early in the process. But I will share more in coming weeks as I hit specific milestones in UI design. It's also important to note that a UI overhaul is not the only thing my apps will have as new features; I'm working on other framework/library improvements that will make my apps more pleasant to use, and each app will also have app-specific improvements as well.

Given the size of the task I've taken on for myself, it's likely that I will work for much of the rest of this year on these updates, and do a large-scale release of all of them, rather than rolling them out one by one. I've previously said that I want to do more frequent releases of my apps, and it's likely that I won't be following that advice here; but I don't see another way to proceed. In any event, keep watching this space for more updates.

[/software] permanent link

Tweet

2 Comments

URLs in comment text will be treated as spam.

Name:
Web Site (optional):
Comments:

Fri, 12 Apr 2013

Perl isn't a pearl

Most of my work with scripting languages has been with Tcl and Python. Both are powerful languages, work well on OS X, have nice support for the Tk GUI toolkit, and well-defined libraries for deploying desktop apps in an easy-to-install fashion for end users.

Partly out of a desire for a new challenge, and partly to access a different range of capabilities than Python and Tcl offer, I've tried two different languages: Ruby and Perl. Ruby, while a powerful language and with excellent Tk bindings, proved to be a disappointment for reasons outlined here: poor desktop deployment tools for OS X. In that same blog entry, I added that I would be giving Perl a try next.

My time with Perl has been less of a disappointment than Ruby--I enjoy the language and have made it a part of my software business, particularly with enhancing my websites and providing the server side of one of my iPhone apps. I don't regret learning the language. But I've found Perl to be less effective as a desktop development language.

Perl's support for the Tk framework, which is one reason I decided to try it, is quirky and less robust than I expected. Perl's native support for Tk is primarily maintained by ActiveState, an excellent software company that provides commercial support for many scripting languages and which earns a good deal of income from its developer tools. While ActiveState's Perl Tkx module is open-source, it seems to work best with ActiveState's own proprietary tools; it has less of a constituency among developers who use Perl's open-source deployment tools, such as pp. Trying to wrap simple Perl scripts, I've had unexpected results (such as the script linking to the first version of Tk it finds on my system, even though it wasn't built against that version; or crashing unexpectedly when it finds a different version of Tk). Unexpected results aren't necessarily a surprise, but significantly, I've also been able to find little online discussion of the issues I've found; my queries to mailing lists on some of these issues have gone unanswered. That's a bad sign.

As a result, I have decided to stick with my current development languages, Tcl and Python; both have better community support for desktop Mac deployment, and troubleshooting, than either Perl or Ruby.

[/general] permanent link

Tweet

0 Comments

URLs in comment text will be treated as spam.

Name:
Web Site (optional):
Comments:

Wed, 20 Mar 2013

New site feature: Screencasts

I've joined the ranks of developers running promotional screencasts of their apps on their website. The first screencast, for PacketStream, is below.

Screencasts can range in quality from the strictly bare-bones--someone recording a session of an app running on their machine while narrating over an echo into the computer's built-in mike--to highly sophisticated videos with lots of animation, special effects, slick background tracks, and more. It was the latter type, produced by MacUpdate in support of a promotion for FileMorph, which inspired me to give screencasting a try.

The result of my efforts is somewhere between rank amateur and highly slick commercial production--I wanted something with a little polish but don't have the budget for uber-slick--and I'm reasonably pleased with it. My toolset, similar to what I use with my own software, was mainly open-source software (Audacity for mixing the soundtrack, Avidemux for editing the video, and ffmpeg for post-processing for upload to YouTube). I tried a couple of commercial Mac tools on a demo basis; while these tools seemed quite powerful, their learning curve was a bit steep, as was their cost. The open-source toolchain fit both my budget, and my brain, better.

I plan to do screencasts for all my apps over the coming year, and now that I have an idea of how the process works, I think it will be a bit simpler to proceed. I'm looking forward to it.

[/business] permanent link

Tweet

0 Comments

Comments are closed for this story.

Fri, 15 Mar 2013

The update treadmill

After spending a few months working on mobile apps, I am now back working on Mac desktop apps in earnest. The challenge when working on multiple apps, as I do, is how to prioritize updates in such a way that I can actually ship releases at semi-regular intervals.

It's easy to develop a long laundry list of new things to add to an app--it's hard to exhaust that list. Even if an app is fairly mature, it's easy to identify small improvements to make or bugs to fix. However, limiting the scope of such changes is necessary to keep the update treadmill in check; some changes can be deferred until a later release.

Historically, in my apps I've tended to alternate between app-specific changes and improvements--new features for a single app--and more general framework improvements, which can be implemented across all my apps. A rewrite of an app's underlying engine for improved speed is an app-specific improvement. Implementing a Cocoa-based toolbar integrated from Tk is a framework improvement that can be rolled into every app.

At present I'm working more in the framework mode. I have a large list of app-specific improvements to add, but I would like to add some of the framework features first--these will improve all of my apps in meaningful ways. Shifting afterward to more app-specific features and improvements will allow for more than a single release per year. Looking back last year, I see that I tended to combine both library and app-specific features into larger, monolithic releases, and that reduced the frequency of my app updates. Making more regular releases seems to be a better way to keep your apps in the public eye. So, that's what I plan to do this year.

[/general] permanent link

Tweet

0 Comments

Comments are closed for this story.

Wed, 06 Mar 2013

New open-source site

I've consolidated all my open-source code packages into a separate subdomain, with a different look-and-feel, to make them easier to access and download. The new site is http://opensource.codebykevin.com. Please check it out.

[/software] permanent link

Tweet

0 Comments

Comments are closed for this story.

Thu, 17 Jan 2013

Site search

In response to customer feedback, I've implemented a search engine for all of the sites I maintain, including http://www.wordtechcommunications.com and http://www.codebykevin.com based on some clever code documented at Build a Search Engine in PERL. My own code was heavily modified, but this example was exceptionally helpful in helping me get started.

I've also implemented a similar feature at my blogs using the find plugin for Blosxom by Fletcher Penney. This plugin, unlike the other search engine I developed, is a drop-in module that required no configuration on my part. It works beautifully.

Both search tools enhance the usability of my sites, and both are written in a programming language I'm having fun learning: Perl. Perl is well-suited for website programming, and I look forward to doing more with it.

[/software] permanent link

Tweet

0 Comments

Comments are closed for this story.

Mon, 03 Dec 2012

TextSweep in Mac App Store

I'm pleased to report that TextSweep has been approved for the Mac App Store. It was rejected a couple of weeks ago because of a crash, but I suspected that the crash was a freak occurrence unrelated to the app itself; after resubmitting the program, it went through without a hitch.

I guess patience pays off! I'm pleased that I now have two new apps in the App Store; this doubles the number I have there, and I'm hopeful that my sales will increase as well.

[/software] permanent link

Tweet

0 Comments

Comments are closed for this story.