CHUCKER23N  «In the Very Minor Gripe department, the alt-arrow now jumps to the bottom-most tweet, but the list of tweets doesn't scroll to reflect the new position (i.e. it still shows the top of the list). Twitteriffic displays this correctly without Twittereeze installed.»

I added a minor change in 1.0.2 that should fix this. Let me know.

«After jumping to the bottom of the list all the tweets in between (i.e. the entire list) are marked as read even though they haven't actually been displayed to the user. But that seems to be a feature/bug of Twitteriffic and not Twittereeze, so I won't bug you with that... :)»

Hm, yes. The way Twitterrific marks something as "new" as opposed to "read" occurs to me as rather random.

Thanks for the feedback.  
(Version 1.0.1)

CHUCKER23N  «Well, it's no biggie but it means that I can no longer use Twitteriffic's built in alt-arrow shortcut to jump to the first and last tweets, if I want to read them in chronological order.»

Oh!

1.0.1 fixes that. Let me know if it doesn't work as expected.

«And to move between tweets with the Twittereeze ctrl-arrow shortcut I have to press the combination for each move and can't e.g. hold down ctrl-down arrow to quickly scroll to the bottom of the list.»

Hm, yes. I need to look into that.  
(Version 1.0)

CHUCKER23N  Glad you like it.

"I can't seem to tab between the list of tweets and the post field any longer, though"

Indeed, Twittereeze currently keeps making the text field frontmost, unless the other text field (the currently selected "tweet", in light blue) is selected; this is intentional.

Out of curiosity, is there a particular reason you want the table to be frontmost, i.e. something you cannot do with this setup?  
(Version 1.0)

CHUCKER23N  1.5 brings up an alert asking if installing the kernel extension is okay, before attempting to do so. :-)  
(Version 1.5)

CHUCKER23N  I'd love to not use SpeedIt. Unfortunately, on Intel Macs, Apple does not provide an interface to access the necessary data — they did on PowerPC Macs (through the IO Registry). Alternatives to SpeedIt are generally poorly documented.  
(Version 1.5)

CHUCKER23N  You'll be happy to hear that 1.5 does not have an AuthHelper at all any more (which was always a temporary solution, and not one I was happy with), and is generally written in a much more reliable way. :-)  
(Version 1.5)

CHUCKER23N  "Speedit is GPL, not LGPL, which means that an application that uses it technically has to be GPL as well"

Nope. If that application (say, MenuTemperature) linked to SpeedIt, that would be the case, but it doesn't. SpeedIt is a kernel extension, not a framework or a library. It exposes an interface through sysctl, which you access; no linking is involved there, nor any direct access to any of SpeedIt's functions.  
(Version 1.0.5)

CHUCKER23N  The admin password is clearly readable as part of a process you launch, like here:

someMachine:~ someUser$ ps axww | grep 1fi

10568 ?? S 0:00.00 sh -c echo "" | sudo -S /Users/someUser/Desktop/hfsdebug -V / -f -t 200 > /Users/someUser/Desktop.hfsnew.txt

You should use Apple's security framework to launch hfsdebug with admin privileges, not sudo.  
(Version 0.72)

CHUCKER23N  I'd love to move to something more transparent or even open-source, but I'm not sure I have any such choices.

I haven't checked, but I believed Temperature Monitor's solution is not available to third parties.

Rolling out my own? Not something I'd like to do. :-/  
(Version 1.0.4)

CHUCKER23N  If anything, that freeze was likely caused by SpeedIt (almost certainly not by MenuTemperature itself). Did you possibly have an outdated version of SpeedIt installed, maybe from CoreDuoTemp or similar utilities?  
(Version 1.0.4)

CHUCKER23N  Hi,

thanks for your positive feedback :-) Glad you like the lightweight-ness — the original motivation of mine to create this was that an alternative utility was simply far too featureful for my needs!

Version 1.1 will add a few features and thus be /less/ lightweight, but it will also bring a few further optimizations, and I'm hopin some of the features (some of which have been requested by several users, too) may be of actual use. In any case, of course, 1.0.x is not going away, not to mention anyone could branch it off into a "MenuTemperature Lite" if they were so inclined.

I certainly agree that "n/a", an alert or similar would be much clearer to the user than the current "let's pretend it's 0 degrees C when really it's not", but unfortunately, with the way 1.0 is built (1.1 is heavily reengineered code-wise), there isn't a good solution to this. However, I'll come up with something eventually.

Again, thanks!  
(Version 1.0.4)

CHUCKER23N  Hi,

there's many different revisions of the PowerBook G4, many of which provide slightly different sensor data.

Please run "ioreg -lw 0 > ~/Desktop/ioreg.txt" on your iMac G5 and e-mail me the resulting file called "ioreg.txt" on your Desktop. I may then be able to add support for your particular machine.

Thanks!  
(Version 1.0.3)

CHUCKER23N  Hi,

please run "ioreg -lw 0 > ~/Desktop/ioreg.txt" on your iMac G5 and e-mail me the resulting file called "ioreg.txt" on your Desktop. I may then be able to add support for your machine.

Thanks!  
(Version 1.0.3)

CHUCKER23N  In case it happens to you again:

1) check if the SpeedIt kext is working ("kextstat | grep speedit" in Terminal should do),

2) try and get SpeedIt's reported temperature yourself ("sysctl kern.cpu_temp" in Terminal).

I suspect the former is the problem, that is, for whatever reason, the kernel extension wasn't loaded properly.

However, this wouldn't affect PowerPC users.

"I understand how a report like this can be frustrating, since it can't be be repeated" — yep! It's very hard for me to reproduce these problems or figure them out, since I only have one machine to work on. Still, I appreciate your response. :-)  
(Version 1.0.3)

CHUCKER23N  - How long have you waited?

- Is SpeedIt running? If so, does "sysctl kern.cpu_temp" in Terminal produce a Celsius temperature value?  
(Version 1.0.3)

CHUCKER23N  Ah, yes. You could consider this a bug in Cocoa. I use NSBundle's bundlePath and resourcePath methods in order to access files inside the bundle (such as from the Scripts/ directory), which apparently aren't updated properly.

I was able to reproduce this problem by running

NSLog([[NSBundle mainBundle] bundlePath]);

NSLog([[NSBundle mainBundle] resourcePath]);

every time the temperature is gauged, then moving the bundle around. Regardless of my moving, Console continued to report the original (and corrected when it had been launched) path.

I'm not sure I can find a clean way to work around this, but I will try! However, since many applications use these methods as they're rather basic Cocoa functionality, I would strongly advise not moving an application around while it is running.

I will see about reporting this problem with Apple.

Thanks for reporting!  
(Version 1.0.3)

CHUCKER23N  That shouldn't be considered inaccurate. Aside from averaging it (when there are multiple sensors), and converting to Fahrenheit if requested, I don't alter the data. The CPU temperature can vary greatly depending on the workload; without further evidence to the contrary, I would say this is perfectly normal. I have seen comparable data from alternative utilities from third parties.  
(Version 1.0.3)

CHUCKER23N  WDATKINSON,

per current design of the application, the temperature will always be recorded as "0 degrees C" (which in turn would be converted to 32 F) whenever no actual data is available; this will be improved soon.

However, I'm curious why this would cause problems on your MacBook. How long did you wait when you first had it open? It may take a few seconds until SpeedIt starts providing data.  
(Version 1.0.3)

CHUCKER23N  "I tried this on my quad G5, and it gives a temperature reading-of 32° F or 0°C."

Would you mind e-mailing me your IO Registry contents? (In Terminal, type "ioreg -lw 0 > ~/Desktop/ioreg.txt", then send me the resulting text file on your Desktop.)

"I don't think that's quite right... my machine runs cool, but it's not endothermic."

It's definitely not right, no.

"I'll try it on my MacBook, but can't say I'm too optomistic"

I know several people who are running it on their MacBooks just fine.  
(Version 1.0.1)

CHUCKER23N  MONOCLAST,

"That error message is misleading, because i doubt the app is really using the existence of temperature sensors as a gauge. Instead, I imagine the app simply looks at the model number and compares it to an internal list of certain supported model numbers. Please change the error message to one that actually reflects the method you use to determine whether your app will run (for instance "This model Macintosh is not supported by this app.")"

I can see where you're coming from, but the release notes make it rather clear which models are supported, and which aren't. I could improve the wording, and I will probably want to improve that alert for 1.1 anyways.

You are right; the application merely checks whether it has support for the specific hardware model *implemented*, not whether it would be possible hardware-wise.

"This app really should work on *all* PowerMac G5 towers, and all other Macintosh models with G5 processors, since they all (as far as I know) have temperature sensors."

The temperature sensors are named differently and, as such, often use different paths in the IOKit Registry. For example, some Power Mac G5s refer to the temperature sensor in question as the "DIE" sensor, whereas others call it the "CPU" sensor. Some PowerBooks have a "BOTTOMSIDE" sensor, and others have a "TOPSIDE" sensor. There is no unified naming, and no unified way that I know of to look. I could simply check multiple different strings, but that would be wasteful and not more ideal than the current solution either.

So far, several users have been willing to provide their ioreg output, and I was thus able to add support for many more machines.

"For example, have a look at the way the open source application called "X Resource Graph" determines if the host Mac has temperature sensors:"

Unfortunately, I cannot look at the source code; it is released under the GNU GPL, which is incompatible with the MIT which I'm using. I would be breaking their license agreement if I were to take a look in order to imitate their implementation.

"Or, you might examine the output of the "ioreg" utility to see if the host Mac has temperature sensors:"

I'm asking users that. It has worked okay so far.

It's not a perfect solution, but until Apple comes up with a more uniform means of gauging the CPU temperature (which they're not going to retroactively provide for old Macs anyway, so even that wouldn't help me out), such solutions will, I'm afraid, always be a bit imperfect.

Thanks for your feedback. If you want to send me the results of "ioreg -lw 0", as a text file, I can make your machine work. It's not unlikely that the sensor will be named ever-so-slightly-differently compared even to the PowerMac7,3.  
(Version 1.0.1)

CHUCKER23N  SHAWNBODH,

you should be able to use it with your MacBook as of version 1.0.1, which just got posted here. Sorry for the inconvenience.  
(Version 1.0.1)