| About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack | |
Home » Products » Reviews » The Very Ugly
BBEdit/BBEdit LiteBare Bones Software (Rich Siegel) Yes it does suck.
According to the Bare Bones site 'in 1993 veteran Mac developer Rich Siegel released two new text editors for the Macintosh - BBEdit 2.5 and BBEdit Lite' [sic]. But 1993 was then with a different Mac operating system; twelve years later is now with OS X.
BBEdit is a text editor that costs more for a single user than the entire OS X operating system - and by a mile too: it retails for $199 [sic], which is over 50% more than the platform it runs on. And still it's only a text editor. OS X already has a text editor: TextEdit, which dates from 1995 and was developed by Ali Ozer formerly of NeXT Computer. TextEdit made the changes through to Jaguar and Panther and basically managed well. The Tiger version even adds a very intelligent HTML exporter that puts Microsoft to shame. And then we have SubEthaEdit and Jedit X, both Cocoa products - with the latter completely rewritten for OS X so as to 'manage'. They're both capable products. Has BBEdit done the same? Has it managed well - to get over the humps as MacOS came out of the Dark Ages? Is it today a tool that is fully integrated with OS X? Rather than spend the $199 to find out, why not download the 'lite' version and go for a ride? The DownloadThe download is hopelessly bloated: 4.5MB of a self-mounting disk image (SMI) file with around 125 KB in resource forks. Clearly we are not out of the woods yet. [Native OS X applications do not use resource forks. Only outdated un-updated Carbon/toolbox applications use them. Ed.] Opening the package further reveals that this OS X application is not Cocoa, but only Carbon. Once again, traditional Macintosh software vendors are caught lagging behind, and reluctantly struggling to catch up. Copying BBEdit Lite to a new location is a breeze. Time to open it and see what it does. If you are looking for - or hoping for - a dazzling Cocoa app, this one is not for you. The appearance bespeaks Mac operating systems of times gone by: the toolbar is small, with raised buttons, with pithy graphics within, a far cry from the photo-realistic images used on Apple platforms today. But what can BBEdit do?
It's nice to have an editor that does not insist on wrapping lines, but if you start looking for a way to turn line wrap back on, your heart will sink: there are tons of options on the Text menu, but nothing so simple and straightforward as 'just turn the danged line wrap back on please'. Line wrap is an easy technology, but was not always so. Line wrap simply means - as we all take self-evident today - that when you get to the right margin of your container, text continues on the next line. There are no additional characters inserted into the text; there are no so-called 'hard line wraps' or 'soft line wraps' - the text is just made to wrap inside its view. Nothing about the text changes; in fact nothing may change - that is essential. But it wasn't always like this. Surprisingly, computers and word and text processing haven't always been with us either. Things that are self-evident today may have been murky back in the fogs of time - or in 1993. Back to BBEdit: what do you get to (possibly) toggle line wrap? What do you (possibly) get instead of something so simple and obvious? Still on the Text menu, you get Balance, Exchange Characters (select two adjacent characters and BBEdit will switch their order - WOW and Hello! this is available ANYWHERE in OS X today - try it: ⌃T anywhere - it comes from something called 'NeXTSTEP'), and Change Case; you get Shift Left and Shift Right; and then come the doozies. Hard Wrap, Add Line Breaks, Remove Line Breaks. These can be essential, but why not just call them 'Break' and 'Join' as they're most often called? But doing things the streamlined way is not necessarily the way Mac users like to do things. Remove line breaks is cool: select it, and the entire file turns into one long line! Not so practical, but... There's a funny line in the toolbar area: it represents the width of your printed page if you decide to print your document. To the right of the toolbar glyphs is a document icon, a 'Last Saved' date/time stamp, and the actual location of the file - given - natch - in the old style Mac format with: colons: between: all: the: path: components. What this is supposed to prove is a mystery; it: comes: off: as: downright: dumb. Back again to the menu where now follow four 'quote' options, presumably to indent and unindent text, entab and detab (handy), and something called 'Zap Gremlins'. As the menu item has an ellipsis, it should lead to a dialog, and sure enough, there's the dialog. Veteran Mac developer Rich Siegel should study OS X guidelines for GUI design: his dialogues are all wrong. Worse, they're ugly and look clumsy. Gremlins?But the Zap Gremlins dialog: the options are divided into two categories, Zap Action and Zapped Characters. (The obvious choice for ergonomic grouping here is NSBox; Siegel uses text with colons - rather weak.) The actions are Filter Line Feeds, Zap Non-ASCII Characters, Zap Control Characters, and Zap Null (ASCII 0) Characters. The Zapped Characters duo seems to group actions, for they are Delete, Replace with Code, and Replace with [], where a '¥' is kept in a little swatch. A final checkbox, Selection Only, rounds off this bizarre dialog. It's obvious what some of these things do; what is not obvious is why they have to be dealt with or why they are grouped in this fashion. A good guess for what 'gremlins' are might be characters Rich Siegel assumes you don't want in your files; but what you didn't want ten years ago is a far cry from what you don't want today. TextEdit can embed graphics; worrying about null bytes is hardly an issue. Now Crashing on Error -5615Whatever you do, don't click by accident on the icon in the title bar of a saved document window: you'll crash a thread somewhere. You'll repeatedly get the following alert. 'This action couldn't be completed, because an error occurred:' Anyone have an error code manual handy? This alert was a lot of help. And OS X only allows for positive error values up to 88. There are no minus values anymore. There is no error code -5615 in OS X - only in Carbon. Resolve URLThe final item on this, the most interesting of the menus, is Resolve URL, and it does just that: select a URL in the text, and BBEdit will launch your browser. Wow. Move back, Camino! Leave town, Safari! It's a simple hack with NSWorkspace code - or the Carbon equivalent - and the operative word is 'simple'. The program doesn't even have to know what program is going to launch. [[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:selectedText]]; That's it: it's done. Big deal. But worse: your browser's already put it on the Services menu. For those - like Siegel - who don't know: Services are a 'NeXTSTEP' thing. NeXTSTEP is another operating system. It's OS X.
But this brings up another point, and a particularly sensitive one too, for it doesn't matter how many if any awards Rich Siegel wins for his 'software' - because they are not text editors and this is bad program design - and it goes against the very philosophy that is Unix and OS X. You don't go mixing program functionality like this: if you want a text editor, you build a text editor; if you want to open URLs, then you build a program that opens URLs. Knowing how to distinguish between the one and the other, and knowing what is germane to a programming assignment and what is not is the hallmark of a good programmer, and it doesn't matter how many copies you sell at $199 - it's still wrong: you fail Comp Sci 101. This program makes your tea, your cucumber sannies, polishes your car, waters your lawn, bakes your bread, picks your flowers, does your laundry, fluffs your pillow... Hey we got more cruft here than Redmond have in Word! We got backup options; lots of printing stuff; gremlin zapping; selecting all, line, or paragraph; previous, present, and next clipboard [sic]; text options, more printing options, menu keys; Find, Find Again, Find Selection, Enter Search String; Replace, Replace All, Replace and Find Again; Find in Next File, Open All Matches, Find & Replace All Matches; Go To Line - and then finally the crowning achievement. Go To Center Line [sic] A better choice would have been to go to the centre column and line, calculate everything in TWIPs, and then call it: Go To Center Geocentric Floating Point Nano-Pixel Even better would have been to connect the program to a GPS dongle so you can read your latitude and longitude continually in the status bar. For text editing, things like that can be very important - and worth the $199 all by themselves, even if the app isn't updated for the OS. FeaturitisUsers profit not by applications with too many unwieldy features but by simple yet elegant applications. So says Doug McIlroy, the boss of the two guys who wrote Unix (what you're running today). Good programming is discipline and the application BBEdit suffers fatally from a lack of it. Here is where you see what that Jargon file term 'creeping featuritis' really means. There's a Tools menu too. This represents all the plugins you got for free and which are currently resident on your disk. Let's go through them briefly.
['Educate Quotes' is any professional developer's pet peeve. There are only so many characters allowed on the Internet - John Walker pointed this out long ago, and wrote the excellent 'demoronizer'. Now when we've got sensible characters (and sensibility) back, this guy Siegel wants to introduce them again - in a text editor to boot? Flight bag anyone?]
Some of these are comical, such as Reverse, which simply reverses the line order in the file. Now how many times have you needed that through the years? Exactly zero times, right. And many of these plugins do not deal with the text file at hand, but go to disk to play around, and there is no distinction made. Creeping featuritis - heck, it's not even creeping anymore. It's out to kill Steven McQueen! Ready For The SlaughterEvery effort has been made to fatten this pig so the consumer never tires of the slaughter. There's even a 'globe' on the menu bar. Clicking it reveals the Internet menu. You just knew you needed an Internet menu to write a plain text file, didn't you? Here we can invoke several killer apps for the Internet, such as a news reader, an email client, a text editor (it's grayed out), and editors/viewers for FTP, HTTP, Gopher, WAIS, and Telnet. Who uses Gopher anymore? WAIS? Can't we have a DECNET login console instead? And how did this all start? Looking for a way to turn line wrap on and off. But without ever finding that feature, you end up looking at fifty million ways to kill butterflies with a cannon - and you still can't toggle line wrap. The OS X text engine is one of the most powerful technologies in Cocoa. A simple text editor takes no more than a fifteen minute hack to put together. Aaron Hillegass shows how to write a specialised editor for writing his book. Andrew Stone does it online at his site too. Ray Anguish is doing it at his site. Rixstep has a hack. And so on. Fifteen minutes - tops. With Cocoa, writing text editors is a 'build it, use it, then throw it away' business. It wasn't always this way of course. There was a time when just getting the cursor to move around on screen was a gargantuan feat. But that is ages ago, a bygone era. To produce all this technology as Rich Siegel does, not with but alongside the OS X text engine, not using the text engine at all, just goes to show dramatically how one product that may at one time have been a killer app gradually falls by the wayside, a forgotten soon extinct dinosaur. And if Rich Siegel is such a 'veteran', why can't he code for the new operating system? Why:doesn't:he:understand:OS X:and:Unix:better? 'If it ain't Cocoa, it's a waste of time.' The Bottom LineSo is it worth it? Is $199 a reasonable price for a text editor, any text editor - this text editor? Get serious: it's 'no' on all three counts. Asking more than the operating system itself for a single program is not only outrageous, it's puerile; no text editor can ever merit such exaggerated relevance in an operating system - and BBEdit is definitely not that kind of product anyway - it's not even native OS X code. In fact things are so bad that the mere waste of 4.5MB of disk space is enough to make you want this free version called BBEdit Lite gone forever and fast. Bottom line: You don't buy text editors - not anymore. You have TextEdit and you have Project Builder and you have Xcode and all are excellent. You have SubEthaEdit and Jedit X. Or you could try Rixedit in the ACP. It costs less than $1. Or you could write your own - even if you're not a programmer. Postscript: Summer 2015Ten years after the first review, the latest version of BBEdit is still, after all these years, a compost of legacy Carbon code. Key: Carbon Contains: YES Ignore Case: YES Found in 39 of 854 items. BBEdit.app/Contents/Frameworks/UpdateKit.framework/Versions/A/Headers/SUSoftwareUpdate.h BBEdit.app/Contents/Info.plist BBEdit.app/Contents/MacOS/BBEdit BBEdit.app/Contents/Resources/BasicWindows.nib/objects.xib BBEdit.app/Contents/Resources/BBEditEditingOptions.nib/objects.xib BBEdit.app/Contents/Resources/CompletionPanel.nib/objects.xib BBEdit.app/Contents/Resources/ConfirmCloseDialog.nib/objects.xib BBEdit.app/Contents/Resources/ConfirmCloseSheet.nib/objects.xib BBEdit.app/Contents/Resources/ConfirmDelete.nib/objects.xib BBEdit.app/Contents/Resources/ConfirmMultiCloseDialog.nib/objects.xib BBEdit.app/Contents/Resources/ConfirmMultiCloseSheet.nib/objects.xib BBEdit.app/Contents/Resources/DualRevisionPickerDialog.nib/objects.xib BBEdit.app/Contents/Resources/DualRevisionPickerSheet.nib/objects.xib BBEdit.app/Contents/Resources/EditingOptions.nib/objects.xib BBEdit.app/Contents/Resources/English.lproj/FTPGetInfo.nib/objects.xib BBEdit.app/Contents/Resources/FindDialog.nib/objects.xib BBEdit.app/Contents/Resources/Format.nib/objects.xib BBEdit.app/Contents/Resources/FTPBrowser.nib/objects.xib BBEdit.app/Contents/Resources/FTPPut.nib/objects.xib BBEdit.app/Contents/Resources/HTMLToText.nib/objects.xib BBEdit.app/Contents/Resources/InsertEmacsBlock.nib/objects.xib BBEdit.app/Contents/Resources/InsertFolderListing.nib/objects.xib BBEdit.app/Contents/Resources/InteractiveFormat.nib/objects.xib BBEdit.app/Contents/Resources/InteractiveHTMLToText.nib/objects.xib BBEdit.app/Contents/Resources/InteractiveTextToHTML.nib/objects.xib BBEdit.app/Contents/Resources/MPTextFileSaver.nib/objects.xib BBEdit.app/Contents/Resources/NetworkSerialNumber.nib/objects.xib BBEdit.app/Contents/Resources/OpenFileByName.nib/objects.xib BBEdit.app/Contents/Resources/P4ShowRevisionHistory.nib/objects.xib BBEdit.app/Contents/Resources/PerforceDualRevisionPickerDialog.nib/objects.xib BBEdit.app/Contents/Resources/PerforceRevisionPickerDialog.nib/objects.xib BBEdit.app/Contents/Resources/PrintOptions.nib/objects.xib BBEdit.app/Contents/Resources/QTWindows.nib/objects.xib BBEdit.app/Contents/Resources/RevisionPickerDialog.nib/objects.xib BBEdit.app/Contents/Resources/RevisionPickerSheet.nib/objects.xib BBEdit.app/Contents/Resources/SourcePickerSheet.nib/objects.xib BBEdit.app/Contents/Resources/TextEngine.nib/objects.xib BBEdit.app/Contents/Resources/TextToHTML.nib/objects.xib BBEdit.app/Contents/Resources/XTNibDialogTests.nib/objects.xib The Info.plist makes it perfectly clear what's going on. <key>LSRequiresCarbon</key> <true/> <key>NSAppleScriptEnabled</key> <true/> So does the linkage in the binaries. 0000000000000e1c /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 00000000005c9802 NSCarbonWindow 0000000000818561 .objc_class_name_NSCarbonWindow 0000000000820c90 _WebInitForCarbon The Resources directory contains 36 (thirty-six) XIBs - a Carbon concession to beige box programmers over fifteen years ago. <object class="IBCarbonRootControl" id="4">
<string name="viewFrame">0 0 717 847 </string>
<string name="bounds">0 0 847 717 </string>
</object>
<object class="IBCarbonRootControl" id="10">
<string name="viewFrame">0 0 717 847 </string>
<string name="bounds">0 0 847 717 </string>
</object>
<object class="IBCarbonWindow" id="9">
<boolean name="autoDragTracking">TRUE</boolean>
<boolean name="hasHorizontalZoom">FALSE</boolean>
<boolean name="isResizable">FALSE</boolean>
<boolean name="hasVerticalZoom">FALSE</boolean>
<boolean name="liveResize">TRUE</boolean>
<boolean name="compositing">TRUE</boolean>
<int name="scalingMode">1048576</int>
<string name="title">Window</string>
<reference name="rootControl" idRef="10"/>
<unsigned_int name="WindowRods">15</unsigned_int>
<string name="windowRect">100 100 947 817 </string>
<string name="ScreenRectAtEncodeTime">91 0 1028 1680 </string>
</object>
<object class="IBCarbonWindow" id="3">
<boolean name="autoDragTracking">TRUE</boolean>
<boolean name="liveResize">TRUE</boolean>
<boolean name="compositing">TRUE</boolean>
<int name="scalingMode">1048576</int>
<string name="title">Window</string>
<reference name="rootControl" idRef="4"/>
<unsigned_int name="WindowRods">15</unsigned_int>
<string name="windowRect">100 100 947 817 </string>
<string name="ScreenRectAtEncodeTime">91 0 1028 1680 </string>
</object>
There's even a development header file in there - nobody cared much about packaging. Thanks to 17.245.76.99 for pointing out the need for this update. |
| About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack |
| Copyright © Rixstep. All rights reserved. |