On Monday 21 November 2022 05:28:41 Dr. Nikolaus Klepp wrote: I had not tried that one before, wasn't sure if it was gui or command-line, but had not got there yet; however, qalc is okay as a backup. It is a little peculiar, sort of like returning to my early schooldays, doing sums with paper and pencil. At least it is more visible. This might work, will look into it. I use lxappearance and qt5ct to force other applications to use my TDE colors, and it works for a lot of stuff, but not some Gnomish stuff like galculator. These suggestions will take some more work, but that is what winter is for, to get to all those things I put off during summer months. Does it further their aims of world domination? ;-)

On Monday 21 November 2022 13:15:36 Felix Miata wrote: I have always hated using spreadsheets. I had to use them to keep track of newspaper circulation when I was the distribution manager. Once I got out of that job, I haven't needed to use them. But anyway, it wouldn't suit my needs. I just want a basic calculator, only BIGGER, in size, in fonts, in other words, visible for my old eyes. Bill

On Monday 21 November 2022 16:09:00 E. Liddell wrote: Actually, that might work, since *all* the text (on both buttons and interface) is about the same size, which is too small for comfort. The kcalc-trinity interface is better than the alternatives, but for me, bigger would still be better. On re-reading your words, however, I suspect that what you mean is, not just that all text would be larger on the calculator (buttons, interface, maybe display), but rather, ALL text would be larger (on all screens, on all TDE and possibly also non-TDE programs, etc.); am I right? If that's what you mean, then no, it wouldn't do, because I have got everything just right after using KDE3/TDE since 2006 or so, and I don't want to change now. The output display window is big enough, but I would mind a little larger. That seems like it would be something different from the font size on buttons and interface. As for perl -e, that seems like too much trouble for a simple calculator. Bill

William Morder via tde-users wrote: To change the display of the kcalc 1. Open kcalc 2. click Settings 3. Choose Font Size as it fits 4. press OK For the buttons, you may also try setting the DPI from the control center (TCC) I have it set to enforced 120 it is under Fonts

William Morder via tde-users wrote: may be you have a very big screen - what is the resolution and size of screen? Mine is 27" with 1920x1080 regards

William Morder via tde-users wrote: in this case the resolution is too high - I have similar and at 1920x1080 it is not readable what happens if you try lower resolution (it will get probably blurrish, but the size will be bigger)

On Tue, Nov 22, 2022 at 07:41:17PM -0400, Jim wrote: And how do you do that, if X lies about the screen resolution? -- Steve

On Tue, Nov 22, 2022 at 13:50 (+1100), Steven D'Aprano wrote: Here's a long answer to a very short question, just in case other people find this information useful. Since some people use "resolution" to mean "pixels per unit dimension" and others use it to mean "total number of pixels", I will try to stay away from using the word "resolution" to avoid confusion. The X server lies about the DPI. (As someone else pointed out, it lies about the physical size, but the bottom line for the "my fonts are too small" complaint is *not* that there are too many pixels but rather that the DPI value reported by X is smaller than the actual DPI value.) Anyway, xrandr can be asked to report the EDID information for an attached screen. And that can be parsed to get information such as the (alleged) physical screen size (in mm). Knowing the number of pixels on the screen, the DPI value can be calculated. Here is a (zsh, but may work with other shells) to get the information of the (first only?) attached screen: my_get_edid_as_ascii_hex () { while read -r output hex conn do echo "$hex" done < <(xrandr --prop | awk ' !/^[ \t]/ { if (output && hex) print output, hex, conn output=$1 hex="" } /ConnectorType:/ {conn=$2} /[:.]/ && h { h=0 } h {sub(/[ \t]+/, ""); hex = hex $0} /EDID.*:/ {h=1} END {if (output && hex) print output, hex, conn} ' ) } When I run it on my laptop, I get 00ffffffffffff0006af8ac400000000001d0104a5221378036e8593585892281e505400000001010101010101010101010101010101963780c8703826406c30aa0058c2100000180f2580c8703826406c30aa0058c21000001800000000000000000000000000000000000000000002001040ff0f3c7d0f13287d20202000cd Pipe that through xxd -p -r and parse-edid as follows: my_get_edid_as_ascii_hex | xxd -p -r | parse-edid and on mu laptop I get Checksum Correct Section "Monitor" Identifier "" ModelName "" VendorName "AUO" # Monitor Manufactured week 0 of 2019 # EDID version 1.4 # Digital Display DisplaySize 340 190 Gamma 2.20 Option "DPMS" "false" Modeline "Mode 0" 142.30 1920 2028 2076 2120 1080 1090 1100 1118 -hsync -vsync Modeline "Mode 1" 94.87 1920 2028 2076 2120 1080 1090 1100 1118 -hsync -vsync EndSection which tells me that the display size is 340 mm by 190 mm (and a bunch of other stuff, as you see). Having said all that, I have found that I get a more accurate DPI value for some of my screens by just testing the screen/machine combination to see if I have hard-coded a preferred width, and otherwise using the EDID value. I then take this width, do some arithmetic to get the DPI, and then do xrandr --output $1 --dpi $dpi_x where $dpi_x is the calculated DPI value and $1 is the particular output device I am setting. Oddly, setting Xft.dpi seems to behave differently on Slackware64 15.0 than on Raspbian. On Slackware the following does the right thing: echo Xft.dpi: $dpi_x | xrdb -screen -merge - but on Raspbian, that makes the fonts way too small, so I do echo Xft.dpi: 120 | xrdb -screen -merge which makes the fonts a reasonable size on that system. I have all this code in a shell script which is run from my .Xsession before the window manager starts up, so that when the window manager starts the correct DPI has been set. Cheers. Jim

On Wednesday 23 November 2022 11:01:26 Felix Miata wrote: It's still interesting to hear how another person does it. I would rather use such a tool, of course, but knowing what is going on under the hood (so to speak, meaning all that work of measuring and calculating) helps me to grasp what is going on. I try to appreciate everybody's contributions, whether I myself can actually use them or not. And thanks for the tool, Felix. Bill

Jim composed on 2022-11-23 21:00 (UTC-0400): Apparently they don't provide the current inxi version. New releases don't happen according to any schedule, but have been averaging monthly over the past year or two. Use the -U switch to upgrade. Edit or remove /etc/inxi.conf to disable the -U disabler if necessary, or just get it from upstream: https://smxi.org/docs/inxi-installation.htm#inxi-manual-install x86_64s mostly. In inxi versions prior to current the version can be output only via -I. TV's as a group aren't very good at providing complete and accurate EDID. Inxi's author doesn't get enough feedback from users of hardware he doesn't have. Inxi simply omits some information it can't get, reports N/A for other it can't get. Use inxi --debug 22 to send him the data from yours for improving the tool. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On Tuesday 22 November 2022 15:51:44 deloptes wrote: I will consider what Jim wrote, as my own problem is similar. I haven't stated it explicitly before, because I assumed others (being sensible) would do as I do. The reason I was a kind of one-size-fits-all solution is that I like to copy my working system and transfer it to other machines. I do very little in the way of changing my settings when I move from laptop > desktop > laptop > the next miracle device. About the only obvious difference is that I have to hit Ctrl-+ two or three times when I view webpages; otherwise, my system is pretty much identical on my laptop as it was only seven or eight earlier machines, each of them quite different in specs. As for the maths side of things, I believe that has something to do with numbers, right? And these are Arabic numbers, and I don't want to accept anything from those Arabs. ;-) I like to do all my calculations the old-fashioned way, with Roman numerals. Bill

On Tue, Nov 22, 2022 at 16:25 (-0800), William Morder via tde-users wrote: Thanks. :-) Me too. And part of what has made that tricky to do in a "seamless" way is the X server's treachery. And that is a good accomplishment (it would be better if you didn't have to hit Ctrl-+, but it is still pretty good). I have solved this problem by correcting the lie that the X server tells us. Might I ask how you have made your settings work across a wide variety of systems? Cheers. Jim

On Tue, Nov 22, 2022 at 17:27 (-0800), William Morder via tde-users wrote: So, just to be clear... are you saying that these carefully tweaked settings work across a variety of DPI values, physical screen sizes, and different numbers of pixels, or are you saying that when you move to a new machine with different parameters, you need to do some more tweaking (but much less than starting from scratch)? Thanks. Jim

On Tue, 22 Nov 2022 16:25:29 -0800 William Morder via tde-users &lt;users(a)trinitydesktop.org&gt; wrote: My experience is that people are almost never sensible. ;) If it makes you feel any better, "Arabic" numerals actually originated in India. E. Liddell

On Wed, Nov 23, 2022 at 00:51 (+0100), deloptes wrote: I think you did not read my email, or maybe you didn't understand it. (Or maybe I am misinterpreting what you write; I can't figure out with any certainty what the above is supposed to mean.) The reason the text is so small is that the X server (probably) lies to your font rendering library about the actual DPI, so the font rendering library uses a smaller number of dots to render (say) a 12pt font **than it should** at your actual DPI. And so since your dots are closer together than what the font rendering library has been led to believe, the letters appear too small for you to read easily. If the truth was told to the font rendering library, it would know that it need to use more dots than what it is actually using. You don't want lower resolution on your laptop screen. You want the font rendering library to know what the actual DPI is, so that it can draw each glyph with enough dots to make readable text. And just in case you think so, I'm not going on a theoretical rant. I have this working on my systems (Slackware64 15.0 and various Raspbian/Raspberry Pi OS versions). For example, I have told my terminal emulator to use Inconsolata at 10 points. And the text in my terminal windows looks pretty much the same actual size (as measured by a ruler) on my three wildly-varying DPI screens. So I don't need to change my eyewear when going from one screen to the other. If you think it is "of course" that the text is smaller on a higher DPI screen, you are missing the essential point that a 12pt font is defined by a number of points, not a number of pixels. Cheers. Jim

On 2022-11-22 01:05:10 William Morder via tde-users wrote: But as deloptes says, you can change the font size in the Settings for kcalc itself without affecting the rest of TDE; only changing the DPI is system-wide. Leslie -- Platform: GNU/Linux Hardware: x86_64 Distribution: openSUSE Leap 15.4 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.13 tde-config: 1.0

On Monday 21 November 2022 23:21:41 deloptes wrote: Right (I believe). I already changed the output display. It is the size of buttons, and the numbers and characters on the buttons. I want to change those, but without changing everything else on my system. Bill

On Tuesday 22 November 2022 02:40:27 deloptes wrote: Santa Claus can only be contacted via telepathy. This might be another problem to occupy those long winter months. At the moment, I can find no calculator application for desktop that really serves my own needs (i.e., visibility, configurable interface, etc.). I have downloaded every single application available for Devuan/Debian/Linux, and none of them is right. So far, top candidates are still kcalc-trinity, galculator (but only because it works, as visibility sucks). Of course there is qalculate (or one of its relatives, -gtk or -qt), which would work, if there were actually a package to download. Information online is vague about what's happening with that project. My phone has a decent enough calculator, true, and it's an open source version that I got from F-Droid, but I still would prefer not to use my phone as a calculator except maybe when I am out there in physical space, that place that is beyond the front door. For the moment, I have adopted a rather unconventional solution, which might possibly make me look uncool to the latter-day hipsters out there. I remembered that I do have some old handheld calculators somewhere in a box or a drawer. In particular, I have an old Texas Instruments solar-powered scientific calculator (with hard shell case), which can do almost anything except cook breakfast. It really was/is a great calculator. Unfortunately, I can't find it, not even after tearing up the whole house. But I did find an obscenely cheap Chinese-made solar calculator (brand name, LeWORLD) from 2008, and it still works, has basic functions and constants, etc., which will serve me for now, until I find a decent application for my computer desktop. I don't recommend that the kids try this. These small handheld proto-computers are like vinyl records or person-to-person conversations, something that us old guys talk about. Bill

On Tuesday 22 November 2022 11:01:40 Dr. Nikolaus Klepp wrote: Thanks, Nik! Looks interesting, so I might tinker a bit with that just to see what happens. You might see some further emails on the list, regarding that bash script, but at least there is hope, maybe even a ray of light. Bill

On Tuesday 22 November 2022 17:04:15 Felix Miata wrote: Well, I can see what I will be doing tonight, and probably for the next few days (or weeks ... or months ...). Bill

William Morder via tde-users composed on 2022-11-21 23:01 (UTC-0800): ... ... This desire belongs in an enhancement bug report. The existing setting affects only the small output display section of the app. All the rest is using a TDE global UI font setting. It's a bit silly that a mere nominal portion of the app's screen space is affected by a so-called "font size" setting. Whether the devs would agree with you is another matter. Presumably if the button text needs to be bigger, so does the main menu text, which is the exact same size. The thing is, when "Show All" is selected, the app roughly doubles in size. If you doubled the nominal button text size (which quadruples the area occupied by a glyph) while keeping the perspectives the same, the minimum size of the app could wind up being more than half of total screen space. Asking for adjustable text size would probably complicate the apps design more than our current fleet of devs would want to spend time on. I'd rather ask for a simple big button mode option, such as is common among stand alone calculators. The meaning of big button would need to be determined, but I'd expect at most a 16pt font where the configured UI size is 10pt. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On 2022-11-22 19:18:34 William Morder via tde-users wrote: It almost looks like it might have been a quick-and-dirty proof-of-concept tool for KDE that the KDE folks let escape into the wild. :-) Leslie -- Platform: GNU/Linux Hardware: x86_64 Distribution: openSUSE Leap 15.4 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.13 tde-config: 1.0

William Morder via tde-users composed on 2022-11-22 22:31 (UTC-0800): ??? # zypper se -s | grep qalculate | kde3-qalculate | package | 0.9.7-lp154.43.2 | x86_64 | KDE3 | libqalculate14 | package | 2.2.1-bp154.1.68 | x86_64 | OSS | libqalculate20 | package | 2.8.1-lp154.1.3 | x86_64 | KDE3 | qalculate | package | 2.2.1-bp154.1.68 | x86_64 | OSS | qalculate | package | 2.8.1-lp154.1.3 | x86_64 | KDE3 # dnf info *qalculate* | grep -A1 Name Name : libqalculate Version : 4.4.0 -- Name : libqalculate Version : 4.4.0 -- Name : libqalculate-devel Version : 4.4.0 -- Name : libqalculate-devel Version : 4.4.0 -- Name : qalculate Version : 4.4.0 -- Name : qalculate-gtk Version : 4.4.0 -- Name : qalculate-qt Version : 4.4.0 # apt-cache showpkg qalculate-trinity Package: qalculate-trinity Versions: 4:14.0.13-0debian12.0.0+0~a (/var/lib/apt/lists/mirror.ppa.trinitydesktop.org_trinity-sb_dists_bookworm_main-r14_binary-amd64_Packages)... # apt-cache showpkg qalculate-gtk Package: qalculate-gtk Versions: 4.2.0-1 (/var/lib/apt/lists/ftp.debian.org_debian_dists_bookworm_main_binary-amd64_Packages) # aptitude search qalculate p cantor-backend-qalculate - Qalculate! backend for Cantor p libqalculate-data - Powerful and easy to use desktop calculator - data p libqalculate-dev - Powerful and easy to use desktop calculator - developmen p libqalculate-doc - Powerful and easy to use desktop calculator - documentat p libqalculate20-data - Dummy transitional package for transition to new name p libqalculate22 - Powerful and easy to use desktop calculator - library p qalculate-gtk - Powerful and easy to use desktop calculator - GTK+ versi p qalculate-trinity - Powerful and easy to use desktop calculator - TDE versio p qalculate-trinity-dbgsym - debug symbols for qalculate-trinity -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On Tuesday 22 November 2022 20:29:07 J Leslie Turriff wrote: Now this is getting weird. I just discovered that there is a TDE calculator that somehow I overlooked: qalculate-trinity. I swear, I just did a search specifically for any kind of qalculate packages, and saw nothing for Trinity that came up. On closer inspection, it's not bad, a little more configurable than kcalc-trinity, yet still suffers from the same basic defects, namely that the size of buttons, and fonts in app's interface, do not get changed. Well, so there is another that is interesting, but not quite *there* for my own needs. And as I am writing this, just about to send, I see that Felix has also posted something that mentions it. Did this just now appear in the repos? because I am sure that I copied the whole list of calculators that came up with apt-cache search, and I didn't see that just the day before yesterday. Bill

On Tuesday 22 November 2022 23:18:01 deloptes wrote: Yes, I know. One problem at a time. Bill

On Tuesday 22 November 2022 23:53:12 Slávek Banko wrote: Huh. Well, I'm stumped. I will mark it off to my old eyes. I notice that I miss many mistakes now that I always used to catch, for example sloppy typos. New glasses would probably be a good idea, too. Bill