OverRuled, screen ruler Options

[CSM]

OverRuled v2.4
-A Screen ruler. Download here


[Caption: May not accurately represent inch in photo if it is not full size]

• Fully Sizable
• Supports 0° and 90° (not switchable, currently)
• Labeled Tick Marks

Use: Click the "highlighted" bar at the end of the ruler to expand or contract the ruler. (you cannot have less than one inch)

Notes: If you expand/contract the ruler too fast, it will need to catch up. If it does not, move cursor a bit (while still clicked). Fixed, Version 2.0
Rotate button does not work.

To Come:

• Options menu for each ruler
  1. Color
  2. Inches vs pixels (vs centimeters, maybe)
  3. Height of ruler (not length of ruler).
  4. Width (of ruler components)
  5. Tick Density (less vs more) Will use standard ruler devisions.

Full 0° to 90° rotation

Ability to spawn/destroy rulers

Comments welcome.* Please read the list of coming features before you request one. For those interested when this is finished, I'll make a sister widget T-Squared, which will have a horizontal ruler and a vertical connected together. It will have the same features as OverRuled
*Yes I know the code is messy. I'll clean it up when most/all of the features are done.

[Rob Marquardt]

Notes: If you expand/contract the ruler too fast, it will need to catch up. If it does not, move cursor a bit (while still clicked).

You should see the funkiness when run under the next version of the engine.   

Instead of creating/deleting elements as you resize the ruler, I'd try creating them all at once (based upon current screen size, plus a bit) and then have the resize just change the bounds of a containing frame.

[CSM]

Let me see if I understand this...
I should make the ruler the width of the screen (and put ticks accordingly). And have the "grab-bar" reveal/hide more or less of the ruler? (Sounds good , just have to figure out how to go about it)
How would I do multiple screens?* (The current one should just keep going across.) Is suppose that the short term would be to spawn a new ruler where the old one leave off
*I can't pre-generate an infinitely long ruler.

You should see the funkiness when run under the next version of the engine.

Yeah, well, I suppose th effect just gets multiplied. The frame idea would eliminate that.

[CSM]

Okay. I updated the widget. Version 2.0
(Same link)

I now create the ruler once, then resize the frame to reveal or hide it.* (Thank you Rob)
The code still isn't pretty.
Now however, the vertical ruler loses its drag-bar during the first drag. Any help on this would be appreciated.

Also, now that the ruler is created only once, I can just attach the pictures to the frame without storing them. Thus reducing my triple dimentional array, with negative indexes . But, Again, I only know how to it by storing them. Any help here is good.

Once these are solved, I'll try to tackle rotation for 0° through 90° (rather than only 0° & 90°).
After rotation, I'll clean up the code and add all the "extra features", like ruler color, etc.


*The whole widget loads slower/longer this way, but I assume that in the next release, the storage of a picture only once (that is used multiple times), will make up for this (?, I hope...).

[CSM]

Should've seen it before. I was reseting the vertical drag-bar's hOffset to 0, not where it should've been.

Anyways, Version 2.1 corrects this issue. Now on to rotation!

[g6auc]

On the Macintosh, I get a one inch vertical ruler when I first start it. I can't see any way to make it horizontal.

If I start it a second time, nothing appears on the screen. I assume that it is somewhere off-screen. Here is the .plist after the first run:

CODE

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>DebugHistory</key>
    <array>
        <string></string>
    </array>
    <key>FirstDisplay</key>
    <string>YES</string>
    <key>LastPreferenceGroupShown</key>
    <string>_systemPrefGroup</string>
    <key>Pref-konfabulatorLockWindowPosition</key>
    <string>0</string>
    <key>Pref-konfabulatorWindowLevel</key>
    <string>normal</string>
    <key>Pref-konfabulatorWindowOpacity</key>
    <string>255</string>
    <key>WindowGeometries</key>
    <dict>
        <key>{{0, 0}, {1680, 1050}}</key>
        <string>{{840, -426}, {158, 76}}</string>
    </dict>
    <key>WindowGeometries-window002</key>
    <dict>
        <key>{{0, 0}, {1680, 1050}}</key>
        <string>{{855, -561}, {85, 84}}</string>
    </dict>
    <key>debugWindowFrame</key>
    <string>10 851 361 167 0 0 1680 1028 </string>
</dict>
</plist>

If I make it longer (vertically) with the drag bar, that works OK until it is about 14+ long, at which point the drag bar detaches from the ruler:


The Widget takes 5 to 7 seconds to start on my 2GHz Intel Core Duo iMac.

[CSM]

On the Macintosh, I get a one inch vertical ruler when I first start it. I can't see any way to make it horizontal.

Very strange. The program should start with 2 rulers: a horiz. and a vert. ruler, for testing purposes. Currently the rotate button doesn't rotate the rulers. And later you will be able to add or remove more rulers.

If I start it a second time, nothing appears on the screen. I assume that it is somewhere off-screen.

?? I don't have any idea why this is. The rulers are dynamically generated, so (for the moment), I could understand if the rulers don't re-assume their positions. (I will store that later).
I think I remember someone mentioning (somewhere) that negative placement of objects on Macs may cause them to generate fully off screen. I'll try setting the position of the rulers window and frame to (0,0)

If I make it longer (vertically) with the drag bar, that works OK until it is about 14+ long, at which point the drag bar detaches from the ruler:

I know why it detaches, I think. It is supposed to generate your screen height/width + an extra inch. For some reason, I may not have for your screen. I need to check that again.
I suppose that if you dragged the ruler to the left/top a lot after it was generated, you could "run out" or ruler.

The Widget takes 5 to 7 seconds to start on my 2GHz Intel Core Duo iMac.

Yes the program takes longer to load now. I will work on that. In the end, I plan to just attach the attributes to the frame rather than storing them as well.


Thanks for the help.

[CSM]

If may have figured out what is happening.
The ruler was expanded all the way (screen width) then it was moved up/over putting the beginning of the ruler off screen. When the widget was restarted, it it collapsed back to one inch (which was off screen).

This will be temporarly fixed be reseting the location to zero on loading the widget.
Later, the program will memorize all ruler position and length (and all other attributes). I will create an iKonic like ruler list. That will provide access to individual ruler preferences and reseting of ruler position.

If I can figure it out, I will implement a check that automatically resets ruler position of rulers that won't appear on screen due to length and potision.


Next on my list is to add to the ruler one inch at a time as the user nears the "end". This way the ruler can be infinitely expanded, like version 1.0 no matter where it is dragged.

[CSM]

• Verson 2.2 should fix losing the ruler off screen. Though their positions will reset each time it is loaded. (will fix later)
• I also have not fixed the > 14 inches error. I need to add the next inch after the one the ruler is currently revealing. (a look ahead of 2 might be better)
• If you still do not see the horizontal ruler, try turning off one ruler by // out lines 89, 92, 106, and 107. The rulers maybe overwriting each other.
  If that doesn't work try commenting out lines 88, 91, 100, and 101. Then change the rotation element on line 89 to 0.

1. How do I attach pictures/objects to a frame without storing them in an array first?
2. How can I do the "look ahead" without maxing out the CPU or slowing the widget down?*

* I have attempted a look ahead for the horizontal ruler, but it maxes out the CPU. Lines: 150-153

[g6auc]

Verson 2.2 should fix losing the ruler off screen. Though their positions will reset each time it is loaded. (will fix later)

It does - I'm now seeing both rulers.

How do I attach pictures/objects to a frame without storing them in an array first?

Frame.addSubview( object );

[Bill B]

Your efforts are appreciated. This type of tool I have used on a regular bases.
Bill B

[CSM]

It does - I'm now seeing both rulers.

Great!

Now I'll work on the "look ahead" option. This will also reduce load times if I do it correctly as I will only have to pre-generate one "look ahead" length.

After that, rotation.

Your efforts are appreciated. This is a tool I have used on a regular bases. For a screen shot see: For Webpage Click here
I have included a couple of additional programs - for ideas.
Bill B

I plan to have at least two modes: Inches and Pixels. I may also have an option to increase or decrease tick density.
I will also have a lock function, that when enabled, will prevent ruler rotation and expansion/contraction.

Thanks.

[g6auc]

After that, rotation.

When we use a ruler to draw a line (or measure the distance) between two points, we put the edge of the ruler against one point then rotate the ruler about that point until it also touches the second point. The ruler is then at the correct angle, and we may then slide it a little to align the calibration marks with the points.

To do that with a screen ruler, it needs to have a semi-transparent strip along its edges (say 10 pixels wide) so that you can place the inner side of the strip aginst the points. You can then mouse-down exactly on the first point to define a rotation point and drag left or right to rotate the ruler.

You need to be able to place the first point within the ruler so that you can get the mouse coordinates. It is no good if the point is (just) outside of the ruler.

While this would make the rotation a little more complex than rotating about the ruler's middle point (say), it would provide a much more natural user interface.

Harry.

This post has been edited by g6auc: Jan 25 2007, 11:18 AM

[jcmatador]

Humm, it's a neat idea but on my system at my resolution I am seeing that the onscreen ruler is nearly half an inch short over a 12 inch span. So, it is good for a rough estimate but cannot be used for truly accurate measurements.

FYI: I am on Windows XP Pro, with a 1600x1200 resolution.

[g6auc]

Humm, it's a neat idea but on my system at my resolution I am seeing that the onscreen ruler is nearly half an inch short over a 12 inch span. So, it is good for a rough estimate but cannot be used for truly accurate measurements.
FYI: I am on Windows XP Pro, with a 1600x1200 resolution.

As I mentioned in another thread, on my Intel iMac, screen.resolution reports 72dpi. However the screen is 17 x 10.75 inches, and the Macintosh system says the screen is 1680x1050. That means that the actual resolution is about 98dpi. If I measure with a real ruler, it is indeed near to 98dpi.

Without some sort of manual calibration, inch and centimetre scales are not going to be too useful.

Then there is the issue of whether something on the screen is transferred correctly to paper.

[Sentinel]

As I mentioned in another thread, on my Intel iMac, screen.resolution reports 72dpi. However the screen is 17 x 10.75 inches, and the Macintosh system says the screen is 1680x1050. That means that the actual resolution is about 98dpi. If I measure with a real ruler, it is indeed near to 98dpi.

Without some sort of manual calibration, inch and centimetre scales are not going to be too useful.

Then there is the issue of whether something on the screen is transferred correctly to paper.

That of course brings up the question of what are you really trying to measure? onscreen size or in the case of items which are to be transformed into hard copy, the actual final output size. <edit: yeah I guess you already said that />

For a simple manual calibration to have the on screen ruler match up with a physical ruler held up to the screen (measuring display size), it's simple enough to hold a physical ruler up to the screen and drag a registration mark to coincide with a corresponding mark on the physical ruler. You will want to do this twice, once with a horizonal ruler and once with a vertical ruler to account for the non square aspect ratio of your displays pixels. These two calibrated values should then be sufficient for calculating the display metrics at any arbitrary angle. On my system which reports a resolution of 96dpi, my calibrated horizontal resolution is 91.28571428571429dpi and my calibrated vertical resolution is 95.42857142857143dpi <aside>and I always thought they were taller than they were wide. /me shrugs.</aside>

One note is that on windows machines at least the screens report dpi can be changed by right clicking on the desktop and choosing Properties->Settings->Advanced->General->DPI Setting and choosing Custom at which point you will be presented with an on screen ruler that can be dragged to match a physical ruler.

[CSM]

Humm, it's a neat idea but on my system at my resolution I am seeing that the onscreen ruler is nearly half an inch short over a 12 inch span. So, it is good for a rough estimate but cannot be used for truly accurate measurements.

FYI: I am on Windows XP Pro, with a 1600x1200 resolution.

As I mentioned in another thread, on my Intel iMac, screen.resolution reports 72dpi. However the screen is 17 x 10.75 inches, and the Macintosh system says the screen is 1680x1050. That means that the actual resolution is about 98dpi. If I measure with a real ruler, it is indeed near to 98dpi.

Without some sort of manual calibration, inch and centimetre scales are not going to be too useful.

Then there is the issue of whether something on the screen is transferred correctly to paper.

This is still only beta. I will work on a system that relates Screen resolution/size (like 1280x1024) to figure out PPI. Maybe users can input their display measurements (17 x 10.5 in.) in the preferences for an even better guide.
I don't get the reference to paper. If you screen capture this, it will probably have a little distortion. Plus, yes printing is different (DPI does matter, whereas on screen it doesn't), but I can't make the ruler printer friendly when someone tries to print it.

When we use a ruler to draw a line (or measure the distance) between two points, we put the edge of the ruler against one point then rotate the ruler about that point until it also touches the second point. The ruler is then at the correct angle, and we may then slide it a little to align the calibration marks with the points.

To do that with a screen ruler, it needs to have a semi-transparent strip along its edges (say 10 pixels wide) so that you can place the inner side of the strip aginst the points. You can then mouse-down exactly on the first point to define a rotation point and drag left or right to rotate the ruler.

You need to be able to place the first point within the ruler so that you can get the mouse coordinates. It is no good if the point is (just) outside of the ruler.

While this would make the rotation a little more complex than rotating about the ruler's middle point (say), it would provide a much more natural user interface.

By way of illustration, here is an experimental Widget that does the rotation the awkward way.

Harry.

As for rotation, I had planned to rotate it around the rotate button. But now I plan to rotate it about the upper left point (in horizontal position, top right in vertical position)


Translation: Don't give up on this yet. I'll eventually get it to a position suitable to be used pretty accurately. Only after that will I work on the frills (color, ruler thickness ...)

[g6auc]

This is still only beta. I will work on a system that relates Screen resolution/size (like 1280x1024) to figure out PPI. Maybe users can input their display measurements (17 x 10.5 in.) in the preferences for an even better guide. I don't get the reference to paper. If you screen capture this, it will probably have a little distortion. Plus, yes printing is different (DPI does matter, whereas on screen it doesn't), but I can't make the ruler printer friendly when someone tries to print it.

What I said ws not intended as criticism, more a mulling over of the issues.

As for rotation, I had planned to rotate it around the rotate button. But now I plan to rotate it about the upper left point (in horizontal position, top right in vertical position)

That's a good idea - much better to have a fixed point on the edge of the ruler, although it does not have to be at the extreme left. You need to be able to place the rotation point against one of the two points you are trying to line up on.

[CSM]

What I said ws not intended as criticism, more a mulling over of the issues.

That's a good idea - much better to have a fixed point on the edge of the ruler, although it does not have to be at the extreme left. You need to be able to place the rotation point against one of the two points you are trying to line up on.

Sorry, it's just that this is slightly harder than I had envisioned. (and I won't let myself give up, because this is within my ability)

I could create an align function. This would allow users to click the corner they wish to align (highlighted* by a large black dot), then click where they wish the ruler to appear, and the ruler will snap to that position. It would be to hard to do that for the rotation though.

*The highlight would only appear when the align function is called.

I think I also have a better way to find PPI now. I use user input about monitor screen width and height in inches. If they cancel this option, I have a backup that approximates the PPI. This backup formula works well for horizontal, but not very well for vertical, because it uses a proportion.

I could also provide a preference that would allow users to change the PPI per ruler as opposed to using the calculated value. This would allow customization for special cases and allow correction if neither formula works right.

Once I get the "look ahead" done, I'll release version 2.3

[CSM]

I have "look ahead" working, barely. It only helps to extend the ruler a few more inches, because if I add too much at one time in the "look ahead" it makes ruler movement too jerky. (right now it is a little jerky).
I guess I can't preserve fluid motion and have an infinite ruler. So, how many inches do you want?

Once I attach pictures without storing them, that might improve look ahead performance. Tell me what you you think of it. If it could be done better, I would like to know.

Thanks for your patience, this is slow going.