rul3r v1.3

[SFR]

1) My screen is 1200px wide, but what I get is only 1040px. Not enough to measure large screen elements. Your screenshot shows 1200px, so I guess it's not a deliberate limitation.

Actually it is. The ruler's width is:
SCREEN_WIDTH - 100 (to leave some margins for a window) - 50 (gap for Px/Cm/In text on the left) - some space on the right - window decorations.
But like I said earlier, this ruler was intended for measuring objects from the outside of the monitor. measur3r is the app designed for the other purpose.

2) The cm calculation is wrong. The 35cm on your ruler actually is only 26cm, measured with a "real" ruler. And since 26cm would be about 10 inches, inches are also not correct

I think I see what's the problem in your case - whereas your display's resolution is 1200x1600, xrandr reports its physical size as 408mm x 306mm (your previous screenshot), but shouldn't it be 306mm x 408mm..?
So, I've added this condition:
[ $SCREEN_WIDTH -lt $SCREEN_HEIGHT ] && [ $MM_WIDTH -gt $MM_HEIGHT ] && MM_WIDTH=$MM_HEIGHT
which hopefully fix this. Please try.
Same done to measur3r, btw.

In other words: The ruler exaggerates. I hope you didn't use it to measure important parts

It's better to exaggerate than shorten, isn't it?

Greetings!

[MochiMoppel]

Longer or shorter, at least you are quicker. I just finished my calculation and it now produces the desired results:

Code: Select all

SCREEN_WIDTH=$(xrandr | grep -oP '(?<=current )[0-9]*')
SCREEN_HIGHT=$(xrandr | grep -oP '[0-9]*(?=, maximum)')
MM_DIMENSION=($(xrandr | grep -oP '[0-9]*?(?=mm)'))
MM_WIDTH=${MM_DIMENSION[0]}
MM_HIGHT=${MM_DIMENSION[1]}
[ $SCREEN_HIGHT -gt $SCREEN_WIDTH ] && MM_WIDTH=$MM_HIGHT

Look Ma', no cut !

xrandr reports its physical size as 408mm x 306mm (your previous screenshot), but shouldn't it be 306mm x 408mm..?

Should be, but xrandr doesn't like math. Instead it indicates the current orientation:
DVI-0 connected 1200x1600+0+0 left (normal left inverted right x axis y axis) 408mm x 306mm

[SFR]

Code: Select all

SCREEN_WIDTH=$(xrandr | grep -oP '(?<=current )[0-9]*')
SCREEN_HIGHT=$(xrandr | grep -oP '[0-9]*(?=, maximum)')
MM_DIMENSION=($(xrandr | grep -oP '[0-9]*?(?=mm)'))

Look Ma', no cut !

Yeah, nicely done, perl-regexp rulez!
Unfortunately, in Fatdog (my main system now) grep is compiled without it, so FD users would have to install another version from repo...

Anyway, I just figured how to do it with awk (which is not my strong suit, so came to it mainly by trial & error):

Code: Select all

# xrandr | awk 'match($0,"current ([0-9]+) x [0-9]+",a) {print a[1]}'
1366
# xrandr | awk 'match($0,"current [0-9]+ x ([0-9]+)",a) {print a[1]}'
768
# 
# xrandr | awk 'match($0,"([0-9]+)mm x [0-9]+mm",a) {print a[1]}'
344
# xrandr | awk 'match($0,"[0-9]+mm x ([0-9]+)mm",a) {print a[1]}'
193
# 

Instead it indicates the current orientation

Thanks, didn't notice.

Greetings!

[MochiMoppel]

Not so nice: I discovered that xrandr is extremely slow. Takes 0.4s on my machine to load, so calling xrandr 3 times as in my example will take more than a full second. This is a noticeable time lag. Calling it only once, as you do in your script, and then feed the output to a variable is a better idea.

Considering that xwininfo is 100 times faster than xrandr I try to avoid xrandr whenever I can, but I'm now puzzled by the results I get from xwininfo. As you can see, both tools report correct pixel dimensions, but millimeter dimensions for width/height are not only mixed up, they are different. The ones reported by xwininfo seem to be wrong. Any idea how they are calculated?

[SFR]

Yep, xwininfo was my first choice when I began to write rul3r, but noticed the same thing and after small research it turned out that there was a change in Xorg at some point:

The 'screen size' as reported in the core protocol now respects the DPI value given by the user or config file and ignores the actual monitor DPI of any connected monitor.

The real monitor size is reported through the RandR extension if you really need to know the physical size of the display.

This is intentional and follows the practice seen in many other desktop environments where the logical DPI of the screen is used as an application and font scaling factor.

Greetings!