Solipsism Gradient

Rainer Brockerhoff’s blog

Preciousss…

No comments

In the midst of a traumatic move, The Dowbrigade waxes rhapsodically about his iBook:

…Meanwhile, we are amazed at the capacity of this little machine to find, acquire and store the essence of what passes for “culture” in the Dowbrigade’s world. After thinking about this we have concluded that it would be theoretically possible to recreate almost all of Western civilization exclusively from the contents of a single 60 gig hard drive…

Meanwhile it is scary the degree to which my worldview and emotional well-being are becoming dependent on this five-pound slab of plastic, metal and silicon. Over the next three months it will be our companion, our post office, our library, our TV, our newsstand, our juke box, our confidant, our journal, our game chest, our worthy opponent in games and puzzles, our cookbook, our darkroom, our calculator, our telephone, our scrapbook, our window on the world and our lifeline to our past. It seems a miracle that one object can fill so many roles and desires. Our preciouuusss.

Indeed.

Re: Packing…

No comments

We’re back from São Paulo. Catching up. Must run. More later.

Posted by taliesin’s log:
taliesin’s log linked to this post

Avoidance therapy

The Wildcat has placed her latest order for things wanted from Paris, but will have to wait.

Packing…

No comments

…because tomorrow we’ll be off on a 4-day trip to São Paulo, for some personal visits, a wedding, and business contacts. Friday I’ll probably be at the Macmania magazine offices.

In the aftermath of the major data loss I had a few days ago, I plan to buy a new external FireWire drive. Today I found an offer of the Iomega HDD250 at a relatively low price – R$1500, slightly more than US$500. Unless I find something better in São Paulo I will buy this when I come back…

In the meantime, expect light blogging until Sunday.

Avoid arguments

No comments

Simon Willison points at Charles Millers’ Rules of Argument. This excellent article teaches how to avoid online arguments:

Rule one is scarily simple. You will never change anyone’s mind on a matter of opinion. Someone going into an argument believing one thing, and coming out the other side not believing it is a freak occurrence ranking somewhere alongside virgin birth and victorious English sporting teams. People change their minds gradually, and if anything a prolonged argument only serves to back someone into a corner, huddling closer to the security blanket of what they believe.

…Once you have stated your case, there’s no point re-stating it. Going over the same ground repeatedly will damage your case: nobody likes reading the same interminable debate over and over again. Similarly, if people read what you have to say, understand it, but continue to disagree anyway, there’s nothing more you can do unless you suddenly come up with a totally new argument. The only productive thing you can add is if people clearly don’t understand what you?re saying, and you need to clarify.

…Sometimes, you’ll ignore all these rules, and get into a month-long argument about RDF with a fundamentalist gun-nut emacs-user. What then?

The ideal attitude to project during any argument is one of calm disinterest.

I find that I subconsciously already deduced Charles’ rules for several years; I can’t even remember getting into a heated online argument. I suppose I can thank my faithful readers for already being calmly disinterested – hopefully not just disinterested icon_lol.gif.

Nevertheless, it seems that there’s been a seasonal increase in the number of arguments I read about. Even such an amiable fellow as the AccordionGuy recently had to post a comment etiquette notice. Shelley Powers posted on blog commenters’ hostility on the same day. So did John Walkenbach, who put his finger on the main issue: a weblog (or nearly any other publicly accessible page) isn’t a democracy. The owner decides what to put on it, what to cut, which comments to allow. Anyone who disagrees is welcome to publish his views elsewhere. If you read the comments in the above links, you’ll see that, while a majority of commenters agree with that, by no means all do.

The situation on the Internet contrasts to what many people are used to regarding other media. If a newspaper or TV station publishes something you disagree with, they’re often obliged to allow you equal time or space to disagree; after all, very few people can open their own newspaper or TV station to do so. The Internet and the explosion of free weblog providers changed all that; anyone with the resources to read something also has resources to publicly disagree with it.

So it goes…

No comments

An aggravating agglomerated aggregate of glitches glommed onto me yesterday. After nearly 10 years without losing any significant data, an errant shell script (in an Open Source project I had just downloaded from the net) removed a goodly part of my Home folder. I noticed things crashing and disappearing, finally deduced what must have been happening, and killed the miscreant task.

Of course, Murphy decreed that no recent backup of these data existed… the external FireWire drive I had been using for backups turned out to be unreliable over a mont ago and I’m still searching for a replacement.

The BSD/Unix underpinnings of Mac OS X imply that many actions that involve command-line stuff fail when confronted with file and folder names that contain characters classic Mac users are prone to use: hyphens, spaces and accented characters all make naïve shell commands go astray. (This rarely if ever affects BSD tools called directly from normal applications, as there’s no parsing of the actual file names involved, and by Mac OS X all filenames use UTF-8 encoding).

In the days of the public betas and Mac OS X 10.0.x, I recall running into several such glitches, mostly while running Apple’s now-obsolete Project Builder programming environment. Project Builder (and its successor Xcode) invoke the gcc compiler and associated tools through complex shell scripts, and I still run into snags now and then when accented characters are involved. Still, Xcode has been remarkably tolerant of embedded spaces and for the past year I’ve consistently used spaces in my current folder names without any trouble; mainly for having the projects I’m working on list first in my somewhat bloated Home folder.

The leading space, unfortunately, was the cause of the aforementioned shell script interpret a “remove all nested folders from /Users/rainer/ Test Project/subfolder/” command as “remove all nested folders from /Users/rainer/, from Test, and from Project/subfolder” (paraphrased). There are two ways of writing such things correctly: one is to precede embedded spaces with a backslash, another is to enclose the whole file name in quotes. Because of the somewhat convoluted nature of the shell script, which passed a list of search results to the actual remove command, the author did not consider that the list might not be properly formatted…

Besides my current project folders my Desktop and Documents folders were removed. On the desktop I kept mostly recently-downloaded items, which can always be downloaded again as soon as I need them. The Documents folder was more painful to lose, as it contained my address book, e-mail folders and several other files that contained ongoing corresponce.

So I spent most of yesterday and today trying to restore my working environment. I tried some disk rescue utilities without success. I wrote a disk image of the volume I keep my Home folder on to an improvised external drive, only to find later that this doesn’t copy unallocated blocks and is therefore unsuitable for data rescue.

Fortunately, my Home volume was nearly full, meaning my working files had a good chance of having been allocated near the end of the volume – and indeed some judicious albeit tedious scanning allowed me to recover most of the source files I had been working on for the past month. Whew.

Unfortunately, the same trick won’t work for e-mail; there’s just too much of it and the fragments can’t be fitted together as easily; and a CDR backup I did last month proved unreadable, too. So, if you e-mailed me anything important since Christmas, please send it again; sorry.

Quick update.

A few hours after posting the lamentation below I found out how avoid the text cursor. Both selecting and editing have to be disabled. Turning editing on (as I do, briefly, when inserting new stuff) turns selecting on again.

Turning all that off messed up some other functionality but I’m happy to report it was all easy to fix, and I now seem to be where I should have been a month ago.

Ah yes, and the contextual menu itself turned out to be a piece of cake… most of the code from Zingg! and Nudge could be reused.

So I hope to have something publishable Real Soon Now™…

This will take some explaining, and may not make much sense unless you’re a Cocoa developer. So feel free to skip this.

In early February – about a month and a half ago – someone asked an obscure question on the developer lists and, by chance, I had a code sample that did almost exactly what that guy wanted. So I sent it to him. So far so good… warm fuzzy feelings all around…

…it turned out that this gave me an idea for a new contextual menu for the Finder. So I thought, the new CM will be just that code sample with some padding, so let me start first on the application to configure stuff for the CM. Shouldn’t take more than a week or two.

As usual, I started out by designing the application icon first, which sidetracked me into a long investigation about the habits and aspect of a certain mammal. That done, I decided the user interface should consist only of a list of items. Fixed-size items each consisting of a few icons and a name. Of course, the first choice was using a NSTableView.

It turns out that the icons were too dissimilarly sized, so a table with one row per item showed too few items, and the UI looked ugly. So my next idea was to use a NSMatrix of cells, each cell with the subitems artfully arranged. This looked better, but…

I soon noticed that a NSMatrix operates with rows and columns of cells (duh!). I wanted a view that adapted itself to the window size the user wanted, but having to scroll both horizontally and vertically was ugly as soon as there were more than a dozen items. So I messed around for a couple of days with adapting the number of columns to the window width, and couldn’t get it to work reliably.

So I decided that I wanted something like iPhoto’s browser window, where there’s only a vertical scrollbar, and the view adapts instantly to width variations. So I started to write a custom view that would be inserted into a NSScrollView and do automatic layout of as many items fit into the current width.

After a week of this it was almost working… however, I was getting some strange behavior in certain conditions; when the window was resized very rapidly, or when the scroller had to appear during insertions, or, and so forth. It appeared that I wasn’t managing the communications between the NSScrollView and my own view correctly under all circumstances.

So I was trying to trace when NSTextViews communicate with their NSScrollViews, when it hit me that I could simply use a NSTextView and insert the item as specialized NSTextAttachmentCells. Bliss! This would give me all the required scrolling and resizing behavior automatically, and I would just have to write the specialized cell code and disable some of the NSTextView’s functions… it wouldn’t do to allow the user to insert actual text there, for instance.

There I went off into another two-week-long detour of writing and debugging the cell code. My cells consist of several subentities which are actually NSViews themselves – images and text – and they in turn have to be editable, selectable, and so forth. I’ll leave the saga of how I finally solved this for another post – it involves adding a subview to the NSTextView, something not normally done.

So after that I had to decide which text behaviors I wanted to leave in the NSTextView. No editing, OK. Selecting multiple items with the text cursor? Hmm… it looked interesting. The user could select several items and drag them somewhere! Perhaps for backing up the items into a Finder window – or to make a list of his items into a text windows. I happily set to work implementing routines for copying and dragging the current selection in various formats, which in turned allowed me to exercise my code under unforeseen conditions and decide how the items would be stored and saved.

Then when it was nearly finished I started to run into snags again. Suddenly I wanted to select two non-adjacent items, which NSTextView doesn’t allow. I changed my system-wide selection color (for a non-related reason) and suddenly selections in my NSTextView began to look ugly – worse, the way selections were made called the user’s attention to the fact that this was a NSTextView with much reduced functionality. This is never a good idea; it leads the user to expect certain things to work, and when they won’t work, it’s a negative experience.

So today I disabled all text selections wholesale, as well as all related functionality. This enabled me to throw out several chunks of code and someday might allow me to implement discontinuous item selections, too. So the NSTextView really just handles reflowing of my item list, and all the remaining functionality is shuffled off into my specialized NSTextAttachmentCell class.

So far so good; I expected to finally freeze my UI and get to work on the shareware related aspects – registration, trial expiration, and so forth. However, I still have to extirpate the final clue that I’m using a text view, namely the I-beam (text insertion) cursor. So far I’ve hammered away at this for the whole day without finding a solution that works all of the time.

As usual. 😥

Stay tuned…

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2025 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.