Sun, Jan 29, 2006
Phantoms & Ghosts on my LCD
With recent events concerning the stability of my hardware I'm a little careful now whenever I see something strange or unusual... A few days ago I had a déjà vu on the LCD screen of my 20" iMac G5 (rev. B "ALS"). I looked at a browser window that displayed a dotted yellow line - and when I looked a little to the right, I saw a line of faint dots, too:
When I place a window with a dotted line like above on certain areas of the screen, these shadows or phantom images are absolutely reproducable. This seems to be a problem of the screen itself, not one of the graphics card or the video ram - because the phantom dots do not appear on screen shots (I had to take a photo to depict the shadow line).
Now, is this a common effect of LCDs? Or is this something to be afraid of, a first sign of a decaying screen? Well, we'll see, maybe time (or Google) will tell. But fortunately, this time I've got AppleCare.
Sat, Jan 28, 2006
iCab 3.0.2 Beta 386 in Session
The first iCab beta version in 2006 offers the option to save all open documents automatically (and restore them the next time iCab is started). It's called "auto-save session" and you'll find it at the end of the "File" menu. Oh, yes, and "Digest Authentication" is supported, finally. Other new features and fixes since beta 382 include:
- Better recognition of RSS feeds where the server sends a wrong "Content-Type"
- The "Content-Disposition: attachment" HTTP header will now force a download.
- Fixed a small memory leak.
- Small modification for the "Flip4Mac" Plugin (for WMV files). This plugin treats the origin setting slightly different than the other browser plugins, which caused WMV files to be displayed shifted to the bottom and to the right.
- When HTML "block" elements were nested in HTML "inline" elements (which is invalid), the "clearance" of floats could fail in certain circumstances.
- Fixed an issue with receiving gzip-compressed data from the server.
- Fixed an issue with the history menu. If a submenu of the history menu contains more than 400 items, iCab didn't list the newest items anymore.
- "about:"-URLs will no longer used for the URL completion.
- Fixed a small issue in the CSS properties min-width/max-width/min-height/max-height
- If a web page contains the BODY or HTML tags many times (which is invalid) nested deep insider other tags, there were some layout issues.
- An IFRAME document could not retreive the NAME attribute of its own IFRAME tag.
- Added some new workarounds for some new invalid HTML code on the Apple web page.
Alexander also mentions one special OS (Carbon?) bug that he's fixed (or found a workaround for):
Because of an error in MacOSX (at least in MacOS 10.3.x and 10.4.x)
when retrieving the location of the temporary items folder, iCab
sometimes get an invalid folder information from the MacOSX and so
downloads may fail and displaying a web site could result in only
displaying an error message "-43" (in very rare conditions the MacOSX
seems to put an invalid folder references into an internal cache and
if an application asks for the temporary items folder it will get the
invalid data from this cache. And because the MacOS seems to never
update its cache when after gets corrupt, the only fix is to relaunch
the application. This error is so rare that most users probably have
never seen this so far).
iCab tries to find out if this error occurs and then will try to find an alternative folder for its temporary files. But this did not always work in the past. Now iCab should work much better in this error condition. But to get some additional information, iCab will now display some debugging messages in its Console window (can be opend from within the "Tools" menu) when it find out that MacOSX starts to return invalid data about the temorary items folder. In case you notice some output about "LTemporaryFileStream" in the Console Window please send this output to <support ät icab.de>. In case you see an error -43 message in the browser window when loading a web page (which shouldn't happen anymore), please open the "Console" Window and send me its content as well.
Mon, Jan 23, 2006
Java applications can be launched like native Mac OS X applications if
their bytecode (usually a JAR archive) is packaged as a Mac
OS X application bundle. The actual launch code is a native
executable, usually called
Your.app/Contents/MacOS/ (if you want to use a
different name for the stub file, you'll have to change the value of the
The stub file changed from Java release to Java release, and
unfortunately some stub versions have been more capable of launching
Java applications on various system versions than others. Just recently,
after updating to QuickTime 7.0.4 on Mac OS X 10.3.9, certain old stub
files refused to launch Java applications any more (the fix is easy:
just copy a current stub file from
to your affected application bundles).
These problems led to a discussion on Apple's Java developer mailing list on how to ensure that always the latest stub version is used. We came up with the following solution: Don't use a copy of the stub file in your application bundle, but a symlink (not a Finder alias!) to the system's current stub instead:
The solution has a little drawback: You cannot use a different name than
which makes it hard to tell different Java processes apart in a Unix
shell (the Finder uses the bundle name from
which can still be whatever you want, so this seems acceptable in most
cases). And of course, the symlink will break if Apple decides to change
the framework structure some time. But until now, the framework
structure has proven to be more stable than a copy of the stub file
itself, so the symlink is likely the most elegant solution to always use
the latest stub in your Java application bundles.
[Update] There have been reports that this approach does not work as expected - you cannot use more than one Java application that uses the linked stub at the same time... So it seems we'll have to wait for Apple to provide a reliable solution.