1Password for iPhone/iPod was released today. It’s a life-saver on the desktop and I was waiting for the native mobile application.
Meanwhile I really believe it must be my karma or something, maybe I killed a fly by accident recently, I’m sorry!
Again, I downloaded the app, installed it, finished the initial setup and it kept crashing each time I tried to access my passwords. Not quite what I expect from software which holds a good part of my confidential information.
At the support forums I found the thread dealing with exactly the same problem. The developers already released version 1.1 and 1.2, both of them are sitting at Apple and waiting for approval:
Version 1.1/1.2 is a lot more stable and we’re just waiting for it to be approved in the App Store.
That’s good, basically, but we remember, the last time it took Apple 23 days to approve a 1.0 to 1.1 update containing a few bugfixes. Let’s see if they have speed up approval processes and will release an updated 1Password before summer ends…
Another point that won’t work well in my WordPress 2.1 is Firefox’s spell check functionality. It only works after enabling manually each time you edit a post using the rich text editor. Kind of annoying.
But, thanks to Otto there is a workaround: to automatically enable Firefox’s built-in spell checking functionality in WordPress 2.1 again, just head over and get the FFSpell-plugin.
Just a quick list of some issues I experienced after I upgraded to WordPress 2.1 Ella:
Insert a link/image into your post won’t work: an old cached version of the Rich Text Editor’s JavaScript file causes the problem. Clear your browser cache to reload the new JavaScript file and everything works fine (found here).
Ultimate Tag Warrior (UTW 3.1415926) tags vanish after comments are added to a post: resolved here.
Same happens to GeoPress locations, they disappear after comments are posted. To fix it search for
function update_post($id)
within the file geopress.php and add the following lines right after the opening curly bracket:
if (!is_admin()) return $id;
if (!isset($_POST['addr'])) return $id;
if (!isset($_POST['locname'])) return $id;
(obviously the same issue as above with UTW tags)
In my case those fixes worked perfectly and I’m a happy WordPress user again.
Hmm, I’m missing an icon here. The Sharing icon in my System Preferences has disappeared. Instead of the icon I see this half-switch-picture:
So, first I thought some images were messed up and checked the Sharing-package. Strangely enough, everything looks fine there. The image file (SharingPref.tiff 
) is where it should be and contains the right icon. Frankly, I have no idea why the application won’t show me the correct picture. Anyhow, it’s not a big problem since it didn’t affect any functionality yet (crossed fingers!!), but it’s annoying and I’d like to fix it. Any hints resolving this issue will be highly appreciated!
Btw, what would be the reason for placing QuickTime-preferences in between Network- and Sharing-preferences? Considering another than a random system preferences arrangement…
Maybe I’m completely wrong but is it possible that after upgrading to Mac OS 10.4.7 my Wi-Fi (Airport) is not working properly anymore?
Last week I ran into problems while uploading some picture to Flickr. Once the process was completed all of my uploaded images were full of weird distortions like colored stripes, shifted image parts or just where half grey. Nothing helped: I tried to reduce image size, changed the image format and uploaded them with different tools (iPhoto plugin, browser and uploadr), no luck.
Finally I emailed the Flickr support team (which is very responsive!) and they told me that it seems to be a connection issue where the end of my uploaded image is being truncated due to slow connections.
So I did 2 more tests, hoping that I’m able to track down the problem:
- upload by email – success, no image distortions
- shut down airport and connect via a good old cable to the router – success, no image distortions
and a final 3rd one:
- turn on airport and unplug the cable – failure, broken image online
Conclusio
I’m no network specialist nor do I know too many details about how Mac OS X works inside. But I do know that after I upgraded to Mac OS 10.4.7 I wasn’t any longer able to successfully upload my images up to Flickr.
It’s annoying, that’s all. It’s not a crucial issue as long as it only affects image upload to Flickr (even if it bothers me a lot that I’m not able to upload and participate easily on Flickr… hmm… maybe I should talk to someone professional why some Flickr-abstinence makes me nervous, but that’s probably another story…).
MacFixIt has already a collection of workarounds for many (!) issues caused by 10.4.7, but apparently not for my little Airport problem. Basically is my MacBook’s Airport working, except this annoying truncated image upload problem (and I’m not thinking of reseting all my favorite/recent networks because of that bug!).
Update #1
I was wrong, this bug isn’t the result of 10.4.7. A MacBook running 10.4.6 had the same problem with the picture upload to Flickr. It must be a malfuntion of my router (Netgear WGT624 v3). I doubt it’s an Airport problem because I was able to successfully upload images logged into other Wi-Fi’s…
I should consult more often ESRI’s support forums, user to user help is working well there. This morning I found a workaround for an annoying ArcPublisher bug: opening a folder with a .pmf in it froze my explorer, almost every time. Here is the workaround. ESRI please fix it, this bug is known and documented longer than 1 1/2 years now!
ArcGIS 9.1 Service Pack 1 was released last week. A day before Christmas holidays I had the chance to install it and run a quick test. A PDF-export made some problems that day, minor problems: certain lines remained for some unknown reasons grey while they should have been white, people kept asking if we could color the line white, somebody had to explain why the line is grey and not white, followed by another attempt to export the PDF. So in the end this “minor problem” cost a lot of time and money. Once I had Service Pack 1 installed this behaviour was gone and the line was exported white as it should – sort of early Christmas present.
Especially the various adressed export-to-vector-graphics-issues called my attention. As far as I can remember Illustrator export for instance was more reliable before 9.1. Regularly we encountered problems with CMYK colors and the listed font-size-issue. I still have to check if all those problems are gone with Service Pack 1 and ArcGIS now proper exports to Illustrator.
However, in my quick test I focused on one bug. Besides reproducible bugs that cause full system crashes is this the most annoying one I’ve ever seen since I use computers:
I’m or better I was using the non-US regional setting for numbers on my system. Outside US we tend to use a “.” as thousend delimiter and “,” as comma. For some reason ArcGIS is the only application on my machine which doesn’t want to take this system wide setting over. It ignores them and only accepts US settings (“.” as comma and “,” as thousand delimiter). Still more confusing is that it only happens on my machine! The other ArcGIS installations work fine with non-US settings. The problem is that every time I want to edit a number in ArcGIS it gets confused about thousand delimiter and comma. For instance a stroke width of 1,00 points which is reasonable for non-US-settings (meaning 1.00 points) is considered by ArcGIS as 1,000 points as it would be entered in an US-system because it takes “,” as a thousand delimiter and not as comma.
So it gives me two of this popups, every time on every single input box on every opened window. I don’t know how much time I already spent on clicking those popups away until I changed my regional settings to US standards (as the only one in my company). So far I didn’t run into problems with other applications or data exchange with some colleagues. On certain formats we have to mind that we’re using different comma-settings.
Funny thing is that our local ESRI support first denied the problem, after I insisted that I’m not blind and if he wanna come over to see it our local ESRI support admitted that he believes he can remind that he has seen this behavior one time before. Finally he told me that they already knew the problem, that it apparently depends on certain hardware combinations and that ESRI developers know it for about 2 years. Due to the fact that they can’t reproduce that behavior it has not been fixed yet.
