[[APi]TheMan]

I've used several Linux window managers, GNOME for example, that have little dockling-type applets. One very cool one is an Odometer. I think that this would be a fun little addition to the dock... Any developers?

Thanks for listening.

[Thilo Ettelt]

What does the Odometer exactly?


- Thilo

[[APi]TheMan]

Originally posted by Thilo Ettelt:
<STRONG>What does the Odometer exactly?


- Thilo</STRONG>

An odemeter measures distance, for example in a car... so it would measure how far the mouse has traveled in live-time. I think it'd be neat.

[matthewmodern]

I would love to see something like this. I recently spent an entire day on google searching for just such a thing.

If someone can locate the source code for the Gnome one, that would simplify things... also, it would need to be determined what system calls were needed to get the equiv. info in OSX.

I think a good feature would be saving the data in an easily parsable text file somewhere (xml?) so that it could be processed by a script to include on a webpage, for example.

-m

[seb2]

i've seen exactly that on versiontracker a while ago. if i could remember what it was called, i'd post a link, but my brain sometimes is as useful as a sieve when it comes to its storage ability.

[matthewmodern]

I've decided to look into programming this one myself.. shouldn't be terribly difficult, even though my experience in Cocoa is limited.

One thing I cannot find anywhere in the documentation: How on earth do you retrieve the current mouse position coordinates from the window manager? I can't find mention of this anywhere.

[edit: Seb2, if you could attempt to confirm/deny the existence of such a program it would be fantastic. I do not have enough free time that I would want to duplicate an already existing program.]

[ 02-22-2002: Message edited by: matthewmodern ]

[seb2]

ok, i did my very best to try to find it. no success. either, i'm too stupid or they pulled it. chances are 50/50.

what i have found, though, is a nice app called magnify.app at stepwise's softrak. it includes source code, is easy to understand an amazing. (it just magnifies the area around the cursor. make the window big and slide it under the dock, then play with the dock's magnification. )

and as you learn the most by looking at other people's source, there are nice things you discover. getting the mouse coordinates is *so* easy: [NSEvent mouseLocation] returns a point... do i have to say more?

writing that odometer should be a matter of a few minutes. i'll do that tomorrow, i guess, got to go to bed now.

[seb2]

ok, it works. very quick and very dirty...

app + source is here:
http://www.uni-hildesheim.de/~skra0063/Odo.sit

Please tell me about the worst mistakes, ok?

[matthewmodern]

Great work Seb.. using your code as a starting point, I now have the app keeping track of both "trip" and "total" mileage.. it writes the total to the user's prefs before they quit.

I'm too tired to clean up my code at the moment, I'll work on it more tomorrow.

[davecom]

Well, that was easy!

[ksuther]

Hmm, it sure takes up a lot of CPU usage. Setting the timer interval to .1 instead of .05 more than halves it. I have a little floating window with trip and total right now. This would be cool if we merged all we have together later

I'll keep upload what I have currently at http://homepage.mac.com/ksuther/odometer/

[[APi]TheMan]

Originally posted by seb2:
<STRONG>ok, it works. very quick and very dirty...

app + source is here:
http://www.uni-hildesheim.de/~skra0063/Odo.sit

Please tell me about the worst mistakes, ok? </STRONG>

Wow... I forgot about this whole thread, and I come back a few days later to find projects started... and and pretty much finished. Great work, guys... Except, what units are the stats in? Pixels?

[ksuther]

Newest version from seb and I is at homepage.mac.com/ksuther/odometer Including a basic speedometer! have to have dev tools to compile it though.

[benh57]

Quick and dirty, yar. Not really a very accurate way to go about it. It's also polling, which is very bad for CPU usage.

It would be better to listen for mousemoved events and update your distance then instead of polling every .15 sec. It would also be much more accurate.

Look up stuff on event handling. The test will be Friday!

[Ghoser777]

Well, I'm away from my machine, so what if we override NSApp's sendEvent: method? We could have it inspect for mouse moved events (NSMouseMovedMask) and then postNotifications to the default notification queue with some wacky name like @"HeyLookTheMouseMoved" and then set up an observer for the notifications that will do all the adding and displaying and such. As an idea, it might be cool to have an option like velocity, acceleration, and displacement(distance from where you started... not very excited, but it'd be pretty easy to do ): both instantaneous and average.

I'm not sure if each application is notified if the mouse moved, but I guess we'll c...

F-bacher

[seb2]

Originally posted by Ghoser777:
<STRONG>Well, I'm away from my machine, so what if we override NSApp's sendEvent: method? We could have it inspect for mouse moved events (NSMouseMovedMask) and then postNotifications to the default notification queue with some wacky name like @"HeyLookTheMouseMoved" and then set up an observer for the notifications that will do all the adding and displaying and such.
...</STRONG>

the question is: do you think the cpu usage is going to get better when you use notifications?

i don't claim to know the answer to this, i just ask.

ben, i had just wanted to know whether it works, that's why i said "quick and dirty" -- you're right about the events. -- after friday

[Ghoser777]

A couple things:
1. In - (void)updateDistance NSTimer *)timer
a. The casts from floats to doubles is unnecessary
b. Calling abs is unnecessary. Because your multiply the distances by themselves (aka squaring them), the sign is irrelevant regardless.

2. You should add NSUIElement = 1 to the expert application settings of your target - that will get rid of the dock icon.

3. I always have trouble subclassing NSApp; has anyone got it to work? It usually take me a good couple of hours of banging my head against the wall for me to remember how to get it to work right,

That is all,
F-bacher

[[APi]TheMan]

Originally posted by Ghoser777:
<STRONG>2. You should add NSUIElement = 1 to the expert application settings of your target - that will get rid of the dock icon.
</STRONG>

I have no experience in coding for MacOSX, but it seems to me that you would want the dock icon, because in the builds of Odometer I've run, the stats are in the icon.

I have yet to try the newest builds, though, so this may have changed.

[ksuther]

NSUIElement has been set for a while now. I'll do those other sugggestions also ghoser, maybe i'll upload another version tonight if i finish my hw
TheMan, I'd suggest you see what's happened to the program, it's a bit different :-p
homepage.mac.com/ksuther/odometer/

[ksuther]

Hmm, making those changes lessens CPU usage a tad. Btw, anybody know how to remove the title from a window and make it draggable by the content rect?
Also, how do you make it so that you can toggle stay on top/don't stay on top in an NSWindow or NSPanel. setHidesOnDeactivate:YES makes the window actually disappear, which is bad. If I could use a combination of setHidesOnDeactivate:NO on an NSPanel and some way to reset it to the default setting would work, but I don't know how to reset it to the default setting of just being a normal window.
Oh well, back to stupid homework

[Ghoser777]

Remove the title? Do u mean set the title to be @""? Or do u want it to have a boarderless window mask (aka no title bar at all)? I think u mean the later. Here's a nifty example that I belive shows what you want to do:
http://developer.apple.com/samplecod...rentWindow.htm

HTH,
F-bacher

[ksuther]

Hmm, very helpful, thanks!
I'll do this when I get home from school and post again

[seb2]

ghoser, just for the records, an "explanation" for 1a + 1b:

look at the time when i wrote this, add 6 hours for cet and there you got the explanation. when i looked at it again the next day, i had noticed those two things myself...

which of course doesn't mean that you weren't absolutely right.

edit: sorry, thought it was pt.

[ 02-27-2002: Message edited by: seb2 ]

[ksuther]

Thanks for the pointer to the Apple example, I pretty much just copied their class, maybe someday I'll go back and clean it up
new version, has no title bar and drags by the content view, thanks to Apple...
Check it out I guess. For those who haven't noticed, access options via the contextual menu.
homepage.mac.com/ksuther/odometer/22702.tar

[Ghoser777]

Hey, I had an idea! Why not have a big window that's borderless and transparent fill up the whole screen, and when it recieves mouse moved events, it could post the appropriate notification! Er, it would need to have transparency of like .1, or it won't pick up anyting, but it still shouldn't be visible, and you still should be able to click through (we'd need it to be a frontmost floating panel like window).

Alright, so I'm a little deranged, but that's just because it's so freakin hard to make a nice two class swign app into a double-clickable java app on windows

F-bacher

[[APi]TheMan]

Originally posted by ksuther:
<STRONG>Thanks for the pointer to the Apple example, I pretty much just copied their class, maybe someday I'll go back and clean it up
new version, has no title bar and drags by the content view, thanks to Apple...
Check it out I guess. For those who haven't noticed, access options via the contextual menu.
homepage.mac.com/ksuther/odometer/22702.tar</STRONG>

Nice, man, very nice. I already grabbed it today before you had posted this.

I like the option to float above everything else, but I turn it off.. I just need all my space on my screen and can't have anything in the way. Very nice application, man.

Pretty soon here I'd start posting to VersionTracker... look into getting a developer ID now, I heard that it takes a week or so to get one, so you'd be better off getting one sooner than later.

[ksuther]

I already have a developer id at VT, as I made dockprefs, a silly little dockling. homepage.mac.com/ksuther/dockprefs
Maybe seb and I will post this on versiontracker as a joint project with the source avaliable :-p
I'll have to ask seb. Do you have any other suggestions for the app as it is currently? I might look into implementing the event watching architecture described by some other people earlier in this thread also, as it seems like a "prettier" way of doing it.

[matthewmodern]

Wow, I kinda forgot about this thread for a while; but kept working on my version. It looks like we went in very different directions.

I'll try to upload a preview of mine for you guys to look at sometime soon. I've unfortunately been too busy lately.

[ksuther]

Hmm, as far as I can tell, the popup menu opens only when the control key is held down or the right mouse button us clicked. I don't think that the Cocoa version of a contextual menu automatically displays.

How is the velocity off by that much? That's a HUGE velocity. If I set that to the speedometer, it simply maxes the bar out. I think that's wrong :-p

I'll think about the choice of units, but it take a bit of math to find the conversions to miles, inches, cm etc. What better graphics would you want? It's just a simple Cocoa program, just a progress indicator and two text fields... what do you want it to look like?

And isn't an accelerometer about the same as a speedometer?

[tie]

Originally posted by ksuther:
<STRONG>Do you have any other suggestions for the app as it is currently? I might look into implementing the event watching architecture described by some other people earlier in this thread also, as it seems like a "prettier" way of doing it.</STRONG>

Code things:
*I noticed that the velocity is off by a factor of 1/0.15 (should be move / timestep).
*I am not sure what the interface convention for floating applications is, but it might be nice to have the contextual menu pop up if you click and hold, without dragging, for some small period of time (if it doesn't do this already, I haven't checked).

Features:
*Choice of units, pixels or real-world units (inches/feet/miles or centimeters/meters/kilometers), for which user needs to set the screen dimensions.
*Better graphics, don't just use the standard interface elements.
*An optional accelerometer.

More features:
*History. I'd like to be able to see the graph (and output into a text file) of distance versus time for every second of today, or every minute of last month, every day of the last year.
*More graphics. Scalable, customizable graphics of different odometer types. For example, different styles, colors, different car models. Lit or unlit -- perhaps the cockpit lights turn on automatically at sunset.
*(if you stick with a polling approach) Intelligent CPU usage and precision. Distance is off by a constant factor, depending on the user, according to the sample frequency. The application can automatically detect the factor and multiply distances properly. (To do this, it needs to poll very frequently for a short period of time, and compare the distance readings to if it had been polling less frequently.)

[ 02-28-2002: Message edited by: tie ]

[tie]

Originally posted by ksuther:
<STRONG>Hmm, as far as I can tell, the popup menu opens only when the control key is held down or the right mouse button us clicked. I don't think that the Cocoa version of a contextual menu automatically displays.</STRONG>

Yes, I meant that you should add the code to show the menu yourself. Pure contextual menus weren't really designed for controlling this kind of application.

<STRONG>
How is the velocity off by that much? That's a HUGE velocity. If I set that to the speedometer, it simply maxes the bar out. I think that's wrong :-p</STRONG>

Velocity is pixels / second. Right now you have it as pixels / update interval. So you need to multiply by update intervals / second = 1 / seconds per update. For me, I think my mouse velocity probably peaks at around 1000 pixels per second, for moving it from one side of the screen to the other.

[/qb]I'll think about the choice of units, but it take a bit of math to find the conversions to miles, inches, cm etc. What better graphics would you want? It's just a simple Cocoa program, just a progress indicator and two text fields... what do you want it to look like?

And isn't an accelerometer about the same as a speedometer?[/QB]

It's very simply math to do the conversions. I think it should look like a car odometer -- use scalable graphics instead of Cocoa interface elements. There's a dial with a needle pointing to the velocity (in the desired units). There's the car mileage, and then there's a little button you press to reset the trip. You could have many different versions (or just a few to start with). White background or black, normal or lit green like a car with the lights on at night. You could have digital and analog versions (as well as the current "classic" version).

I agree that an accelerometer is not so interesting.

[Ghoser777]

Whoa there. Sayiing the acceleration isn't very interesting and that it's about the same as the speed is way wrong.

a) Acceleration is a vector (it has a direction), while speed is just a scalar
b) If I drag it at a contiuously slower rate, the speed vs time and acceleration vs time graphs will look very much different.


Also, he's right about the velocity being off by a factor (man, I should have saw that...). Your finding pixel per interval, so you need to divide by .15 (remember dimensional analysis? (pixel/interval) * (interva/sec)). If the velocity is going off of your ProgressBar, then you just need to change it's max hieght. Remember, if I have a screen resolution with one dimension over a thousand and I get from one side to the other in a sec, I'm going to move 1000+ pixels per second, which sounds fast, but pixels are really really small.

The conversions are REALLY easy. Displaying may take some careful thought, but doing the actual conversions is really simple.

F-bacher

[matthewmodern]

Okay, here's where I last left my version of the app:

binary at - http://faktory.org/m/macodometer.sit

The entire Statistics page isn't updated yet, just haven't gotten around to it. If something doesn't work, I probably haven't implemented it yet.

[[APi]TheMan]

Originally posted by matthewmodern:
<STRONG>Okay, here's where I last left my version of the app:

binary at - http://faktory.org/m/macodometer.sit

The entire Statistics page isn't updated yet, just haven't gotten around to it. If something doesn't work, I probably haven't implemented it yet.</STRONG>

That's a sweet application, man. Very well done. The only thing is, it takes up a lot of processor time.

[ksuther]

Statistics are very cool, but get rid of the dock icon, it uses lotsa CPU time. The version I've made uses quite a bit less CPU time, and I just don't like the dock icon :-p
I'll upload what I have right now tonight, but it's about the same as when I last posted.

[matthewmodern]

I'm personally not a big fan of the stats-in-dock-icon either, that's why I made it an option in the prefs (and turned off by default, if I recall)... people who like it can turn it on. I like to let the user decide. :-)

Re: cpu usage in general, if you close all GUI implements, its almost zero.. so I suspect the high CPU usage in doing something like this comes not from polling the mouse location and doing the math etc, but rather, the CPU usage is all coming from the updating of the GUI on screen.

[ksuther]

How do you detect mouse move events? Right now I'm polling, and as discussed earlier in the thread, maybe that's not such a good idea. But I dunno :-p
Btw, why is it whenever I build an application they are always a meg? I can't make it smaller! I haven't been able to figure it out.

[Ghoser777]

Originally posted by ksuther:
<STRONG>
Btw, why is it whenever I build an application they are always a meg? I can't make it smaller! I haven't been able to figure it out. </STRONG>

You probably have debug symbols and low optimization turned on - it's all changeable in the tabs under your target (I forget which tab exactly, but I think it's build settings).

[ksuther]

Yea, I figured it out, you need to Clean the target and then turn all of optimizations on, that made it smaller

[Arakageeta256]

Does this measure distance the arrow has moved across the screen or actual distance travelled by the mouse itself?

[Ghoser777]

Last I checked, it was only measuring how many pixels the mouse cursor has moved. To figure out how far the mouse has moved is a little trickier, because then you have to figure out how far the mouse moves for each pixel, and mouse movements that hit up against the screen and keep going (but the cursor doesn't move, obvously) won't be counted.

F-bacher