Brian's dashboard

Brian reported a problem in atebits on November 04, 2009 23:12:

24-hour times incorrectly displayed in timeline

Tweetie 2 on the iPhone incorrectly appends "AM" or "PM" to timestamps if the phone is set to use 24-hour time. So for instance, times on my phone appear as "21:45 PM".

Brian replied on November 04, 2009 23:07 to the question "Odd non-breaking spaces; potential encoding issue with drafts?" in atebits:

One other thing to throw into the mix I had previously forgotten about: the first time I attempted to save this tweet as a draft, it lost the draft somehow. Luckily, out of sheer habit I had done a select-all/copy on the iPhone before attempting to save it. Later, when I came back and revised it, I ended up pasting it, but still did save it as a draft, then edited and posted it from the draft views (as originally indicated).

I see the issue with losing drafts is already acknowledged, but wanted to point out this other part of the process in case someone attempts to reproduce this issue.

Brian started following the problem "Tweetie2 doesn't save my drafts correctly." in atebits.

Brian asked a question in atebits on November 04, 2009 23:01:

Odd non-breaking spaces; potential encoding issue with drafts?

Yesterday I posted a tweet using Tweetie 2 on the iPhone. I began by composing it, using cut/paste a bit to revise the wording, then saved it as a draft in Tweetie. I came back later, briefly revised it again, and then posted it.

Upon seeing my tweet in Tweetie's 2 stream wrap lines in the middle of some of my words, I went to the Twitter web site to see if it did the same thing there. It did not, but it actually displayed the entire tweet on one line, cutting off the rest of the text once it reached the maximum width of their tweet content div.

I wrote a small script that retrieved the tweet via the Twitter API and printed the ordinal of each character in the tweet. The results show that, instead of using normal ASCII spaces between each word, Tweetie used character codes 194 and 160, in that order, in lieu of the standard code 32 space. Only one of the original spaces remained intact.

I have no idea if these spaces were somehow substituted in the tweet composition view, or somewhere further down the line, like being saved into then subsequently retrieved and edited from the draft views. I suspect it may be an issue with drafts, however, as this is the only one I've ever stored with Tweetie 2's draft feature, and also the first time this issue has occurred for me.

Is this a known issue?

A comment on the problem "User Icons sometimes not appearing" in atebits:

You reply to every tweet? I never received a reply to mine. – Brian, on November 04, 2009 21:50

Brian reported a problem in Steepster on November 04, 2009 16:01:

10 copies of "what's new" email

I received 10 copies of the same "what's new" e-mail this morning. I've unsubscribed but someone ought to know about it.

Brian started following the problem "Possible bug with Direct and Mention count at launch" in atebits.

Brian started following the problem "Growl/Tweetie doesn't remember read/unread state between launches..." in atebits.

Brian started following the problem "Growl issues" in atebits.

Brian started following the problem "Growl Notifications show previously shown items" in atebits.

Brian replied on September 03, 2009 00:05 to the problem "Growl notification notifies of old tweets at startup" in atebits:

Looks like this bug is mistakenly marked as solved, but I am still experiencing this problem as well. I don't think it's technically accurate to say that Growl isn't flexible enough to fix this bug when none of the other Growl-compatible apps I use have never exhibited this issue.

Someone mentioned in another topic for the same issue that the app doesn't store any data when it is closed -- if that's the case, how is it keeping track of which accounts I've added and the preferences I've set? Additionally, how does it know that the @replies and DMs that I've read in prior sessions are not new and thus does not show the small blue badge for them, yet it still notifies Growl of them?

Guys, please update this topic as the problem is not solved.

Brian replied on March 31, 2009 18:33 to the question "Font Issues in Changeset Browser on Mac" in Beanstalk:

We're having this issue too. Unfortunately, BeanStalk doesn't seem to agree that reduced readability is an important problem. Hopefully they decide to fix it someday...

Brian replied on March 31, 2009 18:29 to the problem "Changeset view cuts off text; difficult to read" in Beanstalk:

Yes, that is the issue. I think it's more due to the very tight line height/spacing. And you're right, it is a small overlap, but it is enough to make semicolons appear as colons, 'y' characters appear as 'v', commas appear as periods, and so forth. It's become enough of a readability issue for us that we stopped using Beanstalk's changeset viewer and now use 'svn diff' on the command line instead. Even though we don't get the highlighting (unless we take it into vim), we can clearly read everything. To me, readability is way more important than highlighting.

Brian Cline started following the question "Font Issues in Changeset Browser on Mac" in Beanstalk.

Brian Cline reported a problem in Beanstalk on January 18, 2009 21:21:

Changeset view cuts off text; difficult to read

In the code browser, the lines overlap quite a bit and make it very difficult to read. This is especially problematic when viewing a Changeset diff, since the lines are highlighted; the backgrounds on each line overlap the previous line a lot, cutting off parts of the text.

Using Windows with Chrome, although the same problem can be seen in Firefox and Safari. Also use Beanstalk on my Mac and have the same issue with Safari and Firefox.

Brian Cline started following the problem "It has been an hour and I still can't re-post new updates" in Twitter.