Okay, so here's my problem. I want a basic calculator, at least the 4 functions, although I don't mind having other goodies, but I really just need a basic calculator for doing simple tasks like figuring out whether I have any money left in my account.
I got kcalc-trinity downloaded, managed to change the colors to make it more visible, but now I find that it cannot be resized, nor the size of characters in the display enlarged.
If not a Trinity program, then I'd be glad to try a non-TDE program, but there again I run into the same problem with every calculator I've tried. The only other one that I use sometimes is galculator, but while I can enlarge its size, the characters stay so tiny that I cannot read them, cannot make out the difference between x, +, and so on, and the keypad also has unreadable numbers.
There was one that I remembered, qalculate, of which there was supposed to be a Trinity version, but neither the Trinity version nor any others (Gnome, gtk, etc.) with download and install. Something about dependencies, it seems, but when I did a search for the deb package, I get only an error page.
Is there any calculator that I can resize both the gui frame of the program (not sure if that's the right terminology) as well as the size of the characters? Or is there some way that I could hack the Trinity version of kcalc to make it bigger?
See attached screenshot for comparsion of the two top underperformers.
Bill
Hi Bill!
Anno domini 2022 Mon, 21 Nov 03:55:20 -0800 William Morder via tde-users scripsit:
Okay, so here's my problem. I want a basic calculator, at least the 4 functions, although I don't mind having other goodies, but I really just need a basic calculator for doing simple tasks like figuring out whether I have any money left in my account.
I got kcalc-trinity downloaded, managed to change the colors to make it more visible, but now I find that it cannot be resized, nor the size of characters in the display enlarged.
Same here.
If not a Trinity program, then I'd be glad to try a non-TDE program, but there again I run into the same problem with every calculator I've tried. The only other one that I use sometimes is galculator, but while I can enlarge its size, the characters stay so tiny that I cannot read them, cannot make out the difference between x, +, and so on, and the keypad also has unreadable numbers.
I use qualc, the console versiomn of qualculate. It's quite what I expect from a calculator, including history, constants etc.
There was one that I remembered, qalculate, of which there was supposed to be a Trinity version, but neither the Trinity version nor any others (Gnome, gtk, etc.) with download and install. Something about dependencies, it seems, but when I did a search for the deb package, I get only an error page.
Is there any calculator that I can resize both the gui frame of the program (not sure if that's the right terminology) as well as the size of the characters? Or is there some way that I could hack the Trinity version of kcalc to make it bigger?
But you can install "xcalc" and use good old .Xresources to change fonts, colors etc.
Or you can use a modified GTK theme and then tell the GTK application to use that theme, like: $ GTK_THEME=Adwaita:dark bad-gnome-caculator
Or you may want to only use a scaling factor for GTK: $ GTK2_DPI_SCALE=4 bad-gnome-caculator
Have I mentioned the numerouse benefits of GNOME for satanists?
Nik
See attached screenshot for comparsion of the two top underperformers.
Bill
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
On Monday 21 November 2022 05:28:41 Dr. Nikolaus Klepp wrote:
Hi Bill!
Anno domini 2022 Mon, 21 Nov 03:55:20 -0800
I use qualc, the console versiomn of qualculate. It's quite what I expect from a calculator, including history, constants etc.
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.
But you can install "xcalc" and use good old .Xresources to change fonts, colors etc.
This might work, will look into it.
Or you can use a modified GTK theme and then tell the GTK application to use that theme, like: $ GTK_THEME=Adwaita:dark bad-gnome-caculator
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.
Or you may want to only use a scaling factor for GTK: $ GTK2_DPI_SCALE=4 bad-gnome-caculator
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.
Have I mentioned the numerouse benefits of GNOME for satanists?
Does it further their aims of world domination? ;-)
Nik
William Morder via tde-users composed on 2022-11-21 06:55 (UTC-0500):
Okay, so here's my problem. I want a basic calculator, at least the 4 functions, although I don't mind having other goodies, but I really just need a basic calculator for doing simple tasks like figuring out whether I have any money left in my account.
My spreadsheet program, always open while booted, is my calculator. In it there is no need to clear any prior operation before beginning others. Mistakes are evident and easily correctable. I have one multipage spreadsheet used as check register that makes reconciliations simple for each account, and tracking where the money went.
On Monday 21 November 2022 13:15:36 Felix Miata wrote:
William Morder via tde-users composed on 2022-11-21 06:55 (UTC-0500):
Okay, so here's my problem. I want a basic calculator, at least the 4 functions, although I don't mind having other goodies, but I really just need a basic calculator for doing simple tasks like figuring out whether I have any money left in my account.
My spreadsheet program, always open while booted, is my calculator. In it there is no need to clear any prior operation before beginning others. Mistakes are evident and easily correctable. I have one multipage spreadsheet used as check register that makes reconciliations simple for each account, and tracking where the money went.
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 Mon, 21 Nov 2022 13:48:34 -0800 William Morder via tde-users users@trinitydesktop.org wrote:
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.
The kcalc buttons use the General font from your TDE theme. So if you're willing to make *all* your text larger, you can enlarge what's on the buttons.
(Generally, I use perl -e as a calculator, but that's kind of inconvenient for most people.)
E. Liddell
On Monday 21 November 2022 16:09:00 E. Liddell wrote:
On Mon, 21 Nov 2022 13:48:34 -0800
William Morder via tde-users users@trinitydesktop.org wrote:
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.
The kcalc buttons use the General font from your TDE theme. So if you're willing to make *all* your text larger, you can enlarge what's on the buttons.
(Generally, I use perl -e as a calculator, but that's kind of inconvenient for most people.)
E. Liddell
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
On Monday 21 November 2022 16:50:25 William Morder wrote:
BIG BREAKING NEWS! Non-technical person makes somewhat amazing discovery!
So what I did is to go into the gui settings:
right-click on top window bar of kcalc-trinity
Advanced > Special Application Settings > Size
I clicked size, then you see that the display window to the right has values for the aspect ratio, height x width; mine were set for 364,357, which I just doubled, to 728,714, and voila! the interface itself is now doubled, though not the font size for buttons, nor the fonts in the interface itself.
See attached screenshot for proof.
Bill
William Morder via tde-users wrote:
I clicked size, then you see that the display window to the right has values for the aspect ratio, height x width; mine were set for 364,357, which I just doubled, to 728,714, and voila! the interface itself is now doubled, though not the font size for buttons, nor the fonts in the interface itself.
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
On Monday 21 November 2022 22:51:33 deloptes wrote:
William Morder via tde-users wrote:
I clicked size, then you see that the display window to the right has values for the aspect ratio, height x width; mine were set for 364,357, which I just doubled, to 728,714, and voila! the interface itself is now doubled, though not the font size for buttons, nor the fonts in the interface itself.
To change the display of the kcalc
- Open kcalc
- click Settings
- Choose Font Size as it fits
- 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
I already did this. To change the fonts in TCC, it would change the fonts on everything in my system, which is not necessarily desirable.
Bill
William Morder via tde-users wrote:
I already did this. To change the fonts in TCC, it would change the fonts on everything in my system, which is not necessarily desirable.
may be you have a very big screen - what is the resolution and size of screen?
Mine is 27" with 1920x1080
regards
On Monday 21 November 2022 23:11:22 deloptes wrote:
William Morder via tde-users wrote:
I already did this. To change the fonts in TCC, it would change the fonts on everything in my system, which is not necessarily desirable.
may be you have a very big screen - what is the resolution and size of screen?
Mine is 27" with 1920x1080
regards
Mine is a laptop, so not quite so big: 15.6" with 1920x1080.
Bill
William Morder via tde-users wrote:
Mine is a laptop, so not quite so big: 15.6" with 1920x1080.
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 11:39 (+0100), deloptes wrote:
William Morder via tde-users wrote:
Mine is a laptop, so not quite so big: 15.6" with 1920x1080.
in this case the resolution is too high
Heresy and rubbish! The higher the resolution, the better (to a point, anyway).
The problem is not the resolution (DPI). One problem, which may be what is affecting you, is that somewhere along the line someone apparently decided that having X report the correct DPI would require hard thinking, and so xorg started lying to us and saying the screen's DPI is 96, regardless of what it really is. So if your actual DPI is (say) 140, then your text will look small, unless somewhere you tell the font rendering library what the real DPI is (e.g., the X resource Xft.dpi), or you tell your desktop environment (or a specific program) to use larger fonts.
- I have similar and at 1920x1080 it is not readable
I assume because your fonts are too small.
If you run the command xdpyinfo | grep inch does it say resolution: 96x96 dots per inch ?
And further, if you run appres Xft | grep dpi does anything show up?
A while ago I got tired of all the lies, counter-lies, counter-counter-lies, and so on, and now when I log in before much of anything gets started I figure out the correct DPI and use xrandr to set it. And now, praise be, a PDF displayed at 100% scale is the correct width on my screen. And '()' in a 12pt font has a height on my screen about what I would expect. As it should be.
Unfortunately, some things are specified in pixels, which is understandable in some cases, but mostly the wrong thing to do in a world where there are Hi-DPI screens. In my case, having convinced fonts to show up on my screen at the size they should be, I do need to specify a suitable icon size, but with that effort things work pretty well. I can go from my laptop screen (141.7 DPI) to my TV (something like 69 DPI, ugh) to my 27" 4k monitor (157 DPI?).
In summary: high resolution: good X servers lying about the DPI: bad stupid programs that can't handle DPI != 96: ugly
Cheers.
Jim
On Tue, Nov 22, 2022 at 07:41:17PM -0400, Jim wrote:
A while ago I got tired of all the lies, counter-lies, counter-counter-lies, and so on, and now when I log in before much of anything gets started I figure out the correct DPI
And how do you do that, if X lies about the screen resolution?
Steven D'Aprano composed on 2022-11-22 13:50 (UTC+1100):
On Tue, Nov 22, 2022 at 07:41:17PM -0400, Jim wrote:
A while ago I got tired of all the lies, counter-lies, counter-counter-lies, and so on, and now when I log in before much of anything gets started I figure out the correct DPI
And how do you do that, if X lies about the screen resolution?
It doesn't lie about resolution. It lies about screen size and screen pixel density (reported as DPI). The usual report is that the screen size is larger than the screen itself reports in order to be able to report and apply 96 DPI instead of an accurate DPI. This size report is usually found in /var/log/Xorg.0.log, but can be found via various utilities.
Xft.dpi: is one tool to set DPI to any arbitrary value, but not every DE or application responds to the Xft.dpi value. In many environments, there is no Xft.dpi by default. Gnome per upstream default forces it to 96 if it fails to find a value in the environment. Some distros force it to 96 in any case not determined to be a HiDPI environment. Xft.dpi is the method by which TCC Fonts (tdecmshell fonts) configures DPI.
xrandr --dpi sets the DPI on Xorg's environment that some apps respond to that do not respond to Xft.dpi. xrandr's DPI only applies to startups subsequently occurring, so must be applied as an X startup process to apply across the board. This value is ignored by most GTK apps, such as Firefox.
tdecmshell xserver
reports the DPI in effect at the xserver level, which /can/ differ from the Xft.dpi value, found thus:
xrdb -query | grep dpi
Xft.dpi is the means by which Gnome and various other environments "scale" fonts, and may scale the entire desktop, not including those apps that do not respond to Xft.dpi.
On Tue, Nov 22, 2022 at 13:50 (+1100), Steven D'Aprano wrote:
On Tue, Nov 22, 2022 at 07:41:17PM -0400, Jim wrote:
A while ago I got tired of all the lies, counter-lies, counter-counter-lies, and so on, and now when I log in before much of anything gets started I figure out the correct DPI
And how do you do that, if X lies about the screen resolution?
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
Jim composed on 2022-11-23 11:41 (UTC-0400):
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:
Instead of all that work measuring and calculating, use a tool that does the work for you:
inxi -Gaz --vs
inxi 3.3.23-00 (2022-10-31) Graphics: Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel arch: Gen-9.5 process: Intel 14nm built: 2016-20 ports: active: DP-1,HDMI-A-2,HDMI-A-3 empty: DP-2,HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:5912 class-ID: 0300 Display: x11 server: X.Org v: 1.20.14 driver: X: loaded: modesetting alternate: fbdev,vesa dri: iris gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 3600x2640 s-dpi: 120 s-size: 762x558mm (30.00x21.97") s-diag: 944mm (37.18") Monitor-1: DP-1 pos: primary,bottom-l model: Acer K272HUL serial: <filter> built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes: max: 2560x1440 min: 720x400 Monitor-2: HDMI-A-2 mapped: HDMI-2 pos: top-right model: Dell P2213 serial: <filter> built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400 Monitor-3: HDMI-A-3 mapped: HDMI-3 pos: top-left model: NEC EA243WM serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2 size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes: max: 1920x1200 min: 640x480 API: OpenGL v: 4.6 Mesa 22.1.7 renderer: Mesa Intel HD Graphics 630 (KBL GT2) direct render: Yes
Each monitor's actual dimensions and DPI are accurately reported (from EDID, if it exists), and the entire screen's /logical/ dimensions and DPI (what the software uses: s-dpi: 120) are also reported.
On Wednesday 23 November 2022 11:01:26 Felix Miata wrote:
Instead of all that work measuring and calculating, use a tool that does the work
for you:
inxi -Gaz --vs
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
On Wed, Nov 23, 2022 at 14:01 (-0500), Felix Miata wrote:
Jim composed on 2022-11-23 11:41 (UTC-0400):
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:
Instead of all that work measuring and calculating,
It's no work, I let the computer do it. :-)
use a tool that does the work for you:
inxi -Gaz --vs
Neither inxi on Slackware64 15.0 nor Raspbian GNU/Linux 10 like the --vs option. What system are you using?
inxi 3.3.23-00 (2022-10-31) Graphics:
<snip>
Each monitor's actual dimensions and DPI are accurately reported (from EDID, if it exists), and the entire screen's /logical/ dimensions and DPI (what the software uses: s-dpi: 120) are also reported.
Thanks for that info (I'm no inxi guru). Unfortunately, inxi isn't always so informative. For example, on an RPi 4, hooked up to a Sony TV, I only get
$ inxi -Gaz Graphics: Device-1: bcm2711-vc5 driver: vc4_drm v: N/A Device-2: bcm2711-hdmi0 driver: N/A Device-3: bcm2711-hdmi1 driver: N/A Display: tty server: X.Org 1.20.4 driver: modesetting unloaded: fbdev resolution: 1920x1080~60Hz OpenGL: renderer: V3D 4.2 v: 2.1 Mesa 19.3.2
which isn't all that informative.
Cheers.
Jim
Jim composed on 2022-11-23 21:00 (UTC-0400):
On Wed, Nov 23, 2022 at 14:01 (-0500), Felix Miata wrote:
use a tool that does the work for you:
inxi -Gaz --vs
Neither inxi on Slackware64 15.0 nor Raspbian GNU/Linux 10 like the --vs option.
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
What system are you using?
x86_64s mostly.
inxi 3.3.23-00 (2022-10-31) Graphics:
In inxi versions prior to current the version can be output only via -I.
Thanks for that info (I'm no inxi guru). Unfortunately, inxi isn't always so informative. For example, on an RPi 4, hooked up to a Sony TV, I only get
TV's as a group aren't very good at providing complete and accurate EDID.
$ inxi -Gaz Graphics: Device-1: bcm2711-vc5 driver: vc4_drm v: N/A Device-2: bcm2711-hdmi0 driver: N/A Device-3: bcm2711-hdmi1 driver: N/A Display: tty server: X.Org 1.20.4 driver: modesetting unloaded: fbdev resolution: 1920x1080~60Hz OpenGL: renderer: V3D 4.2 v: 2.1 Mesa 19.3.2
which isn't all that informative.
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.
Jim wrote:
Heresy and rubbish! The higher the resolution, the better (to a point, anyway).
Really, I thought it is maths :) cause how many dots in which density I can display on 15" ... of course it is much smaller then the same displayed on 27". To read the same text on the 15" I must put glasses or lower resolution. On the 13" I really need glasses :) In math is truth :)
On Tuesday 22 November 2022 15:51:44 deloptes wrote:
Jim wrote:
Heresy and rubbish! The higher the resolution, the better (to a point, anyway).
Really, I thought it is maths :) cause how many dots in which density I can display on 15" ... of course it is much smaller then the same displayed on 27". To read the same text on the 15" I must put glasses or lower resolution. On the 13" I really need glasses :) In math is truth :)
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
... correcting a typo in the text which renders my words nonsensical: *was* ought to be *want* in my second paragraph.
On Tuesday 22 November 2022 15:51:44 deloptes wrote:
Jim wrote:
Heresy and rubbish! The higher the resolution, the better (to a point, anyway).
Really, I thought it is maths :) cause how many dots in which density I can display on 15" ... of course it is much smaller then the same displayed on 27". To read the same text on the 15" I must put glasses or lower resolution. On the 13" I really need glasses :) In math is truth :)
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 want 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:
On Tuesday 22 November 2022 15:51:44 deloptes wrote:
Jim wrote:
Heresy and rubbish! The higher the resolution, the better (to a point, anyway).
Really, I thought it is maths :) cause how many dots in which density I can display on 15" ... of course it is much smaller then the same displayed on 27". To read the same text on the 15" I must put glasses or lower resolution. On the 13" I really need glasses :) In math is truth :)
I will consider what Jim wrote,
Thanks. :-)
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 want a kind of one-size-fits-all solution is that I like to copy my working system and transfer it to other machines.
Me too. And part of what has made that tricky to do in a "seamless" way is the X server's treachery.
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.
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 Tuesday 22 November 2022 16:44:58 Jim wrote:
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.
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?
I wish I could tell you that I just did *this* [cue the magic dust!], but there is no method at work, only that I have kept tweaking* my settings, a little here, a little there, since about 2006, when I first started using KDE3. My system now looks practically identical to my system back then, except where I have changed the artwork on the desktop, etc. (See screenshots on the Trinity page where they have them posted.)
Otherwise, I saved my home folder, whole and complete, copied to an external drive, then copy it to the new home folder on the next machine. The only stuff I don't keep are all the hidden files as the bottom of the home folder, as they and mostly specific to the present machine, and will need to be redone. That is about all I can say, tweak, tweak, tweak* away!
Bill
P.S. I mean, of course, *tweak and tweaking in the hacker sense of these words. When people heard me use those words out here in California, I discovered that they meant something quite different.
The same thing, I hear, happens to the Irish when they come to over here to the States, and ask round about where they can find some really good crack. Means something different here.
On Tue, Nov 22, 2022 at 17:27 (-0800), William Morder via tde-users wrote:
On Tuesday 22 November 2022 16:44:58 Jim wrote:
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.
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?
I wish I could tell you that I just did *this* [cue the magic dust!], but there is no method at work, only that I have kept tweaking* my settings, a little here, a little there, since about 2006, when I first started using KDE3. My system now looks practically identical to my system back then, except where I have changed the artwork on the desktop, etc. (See screenshots on the Trinity page where they have them posted.)
Otherwise, I saved my home folder, whole and complete, copied to an external drive, then copy it to the new home folder on the next machine. The only stuff I don't keep are all the hidden files as the bottom of the home folder, as they and mostly specific to the present machine, and will need to be redone. That is about all I can say, tweak, tweak, tweak* away!
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 Wednesday 23 November 2022 07:46:19 you wrote:
I wish I could tell you that I just did *this* [cue the magic dust!], but there is no method at work, only that I have kept tweaking* my settings, a little here, a little there, since about 2006, when I first started using KDE3. My system now looks practically identical to my system back then, except where I have changed the artwork on the desktop, etc. (See screenshots on the Trinity page where they have them posted.)
Otherwise, I saved my home folder, whole and complete, copied to an external drive, then copy it to the new home folder on the next machine. The only stuff I don't keep are all the hidden files as the bottom of the home folder, as they and mostly specific to the present machine, and will need to be redone. That is about all I can say, tweak, tweak, tweak* away!
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
Sorry about that! Didn't mean to send to your personal email address, just hit reply without looking.
I definitely make a few adjustments with a new machine, but it doesn't involve changing my settings.
If you will look over the threads starting about December of last year, when I bought new laptop, you will find many posts and and other people's replies about various issues that arise; however, as I said, I don't need to change my actual settings (all that pretty stuff like layout, font sizes, etc.)
I do know a little something about pixels versus dpi, but that goes back to working with printed pages (newspapers and such), and doesn't really apply here to screen display.
About the only thing that gets changed is the screen size itself, and that happened automatically, nothing done on my part.
If I have time, I will review some of those old posts and point to some examples.
Believe me, I am no genius, especially when working with computers. As my old friend Aesop once said, slow and steady wins the race. I am the tortoise in that metaphor. All you need is 15 years or so to get your machine working the way you want.
Bill
On Tue, 22 Nov 2022 16:25:29 -0800 William Morder via tde-users users@trinitydesktop.org wrote:
... correcting a typo in the text which renders my words nonsensical: *was* ought to be *want* in my second paragraph.
On Tuesday 22 November 2022 15:51:44 deloptes wrote:
Jim wrote:
Heresy and rubbish! The higher the resolution, the better (to a point, anyway).
Really, I thought it is maths :) cause how many dots in which density I can display on 15" ... of course it is much smaller then the same displayed on 27". To read the same text on the 15" I must put glasses or lower resolution. On the 13" I really need glasses :) In math is truth :)
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.
My experience is that people are almost never sensible. ;)
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.
If it makes you feel any better, "Arabic" numerals actually originated in India.
E. Liddell
On Tuesday 22 November 2022 19:42:09 E. Liddell wrote:
If it makes you feel any better, "Arabic" numerals actually originated in India.
E. Liddell
I actually do know that. The reference was in fact bait, intended to catch pedants such as yourself - I mean myself - you know, us.
;-)
Bill
On Wed, Nov 23, 2022 at 00:51 (+0100), deloptes wrote:
Jim wrote:
Heresy and rubbish! The higher the resolution, the better (to a point, anyway).
Really, I thought it is maths :)
I think you did not read my email, or maybe you didn't understand it.
cause how many dots in which density I can display on 15" ... of course it is much smaller then the same displayed on 27".
(Or maybe I am misinterpreting what you write; I can't figure out with any certainty what the above is supposed to mean.)
To read the same text on the 15" I must put glasses or lower resolution. On the 13" I really need glasses :) In math is truth :)
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
Jim wrote:
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.
No, it is very simple. the same resolution on smaller screen size makes the symbols appear smaller, because it is the same number of pixels that is fitting to a smaller area.
On 2022-11-22 01:05:10 William Morder via tde-users wrote:
On Monday 21 November 2022 22:51:33 deloptes wrote:
William Morder via tde-users wrote:
I clicked size, then you see that the display window to the right has values for the aspect ratio, height x width; mine were set for 364,357, which I just doubled, to 728,714, and voila! the interface itself is now doubled, though not the font size for buttons, nor the fonts in the interface itself.
To change the display of the kcalc
- Open kcalc
- click Settings
- Choose Font Size as it fits
- 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
I already did this. To change the fonts in TCC, it would change the fonts on everything in my system, which is not necessarily desirable.
Bill
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
J Leslie Turriff 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.
it is changing only the font size in the calculator field, but not the buttons. The buttons are subject to the global font setting (and global DPI)
On Monday 21 November 2022 23:21:41 deloptes wrote:
J Leslie Turriff 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.
it is changing only the font size in the calculator field, but not the buttons. The buttons are subject to the global font setting (and global DPI)
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
William Morder via tde-users 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.
well, I wish I had the phone number of santa claus :)
the fonts in the GUI are managed in general, I am pretty sure you can not change it per application
On Tuesday 22 November 2022 02:40:27 deloptes wrote:
William Morder via tde-users 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.
well, I wish I had the phone number of santa claus :)
Santa Claus can only be contacted via telepathy.
the fonts in the GUI are managed in general, I am pretty sure you can not change it per application
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
Anno domini 2022 Tue, 22 Nov 10:20:53 -0800 William Morder via tde-users scripsit:
[...] 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.
I think I have a nice workaround for your "galculator" - not perfect but ok:
#!/bin/sh DPI=$(xrdb -get Xft.dpi) echo "Xft.dpi:300" | xrdb -override - galculator & sleep 1 echo "Xft.dpi:$DPI" | xrdb -override -
You'll need to press <ctrl>+<m> once to hide/show the oversized menu. You can usw "kcalc", too, but I have not found a way to hide the menu.
Nik
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
On Tuesday 22 November 2022 11:01:40 Dr. Nikolaus Klepp wrote:
Anno domini 2022 Tue, 22 Nov 10:20:53 -0800
I think I have a nice workaround for your "galculator" - not perfect but ok:
#!/bin/sh DPI=$(xrdb -get Xft.dpi) echo "Xft.dpi:300" | xrdb -override - galculator & sleep 1 echo "Xft.dpi:$DPI" | xrdb -override -
You'll need to press <ctrl>+<m> once to hide/show the oversized menu. You can usw "kcalc", too, but I have not found a way to hide the menu.
Nik
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
Dr. Nikolaus Klepp composed on 2022-11-22 20:01 (UTC+0100):
#!/bin/sh DPI=$(xrdb -get Xft.dpi) echo "Xft.dpi:300" | xrdb -override - galculator & sleep 1 echo "Xft.dpi:$DPI" | xrdb -override -
The following produces a usage message from xrdb, but does produce a larger KCalc: #!/bin/sh DPI=$(xrdb -get Xft.dpi) echo "Xft.dpi:220" | xrdb -override - /opt/trinity/bin/kcalc & sleep 1 echo "Xft.dpi:$DPI" | xrdb -override -
## existing environment $ xrdb -query | grep dpi Xft.dpi: $ xdpyinfo | egrep 'dimen|ution' dimensions: 1920x1200 pixels (406x254 millimeters) resolution: 120x120 dots per inch
On Tuesday 22 November 2022 17:04:15 Felix Miata wrote:
Dr. Nikolaus Klepp composed on 2022-11-22 20:01 (UTC+0100):
#!/bin/sh DPI=$(xrdb -get Xft.dpi) echo "Xft.dpi:300" | xrdb -override - galculator & sleep 1 echo "Xft.dpi:$DPI" | xrdb -override -
The following produces a usage message from xrdb, but does produce a larger KCalc: #!/bin/sh DPI=$(xrdb -get Xft.dpi) echo "Xft.dpi:220" | xrdb -override - /opt/trinity/bin/kcalc & sleep 1 echo "Xft.dpi:$DPI" | xrdb -override -
## existing environment $ xrdb -query | grep dpi Xft.dpi: $ xdpyinfo | egrep 'dimen|ution' dimensions: 1920x1200 pixels (406x254 millimeters) resolution: 120x120 dots per inch
Well, I can see what I will be doing tonight, and probably for the next few days (or weeks ... or months ...).
Bill
On Monday 21 November 2022 16:50:25 William Morder wrote:
Just wondering if it is possible to modify the config file for kcalc-trinity in order to change the size of the buttons, size of fonts in the gui itself?
/home/~/.trinity/share/config/kcalcrc
I did manage to enlarge the output display (that's in the settings), but it occurred to me that maybe a few lines could be added to this file to make it do what I want. I looked through the config files for other TDE applications, but I didn't see anything that could be copied and modified for this purpose.
Bill
P.S. Here is my current configuration:
[$Version] update_info=kcalcrc.upd:KDE_3_2_0
[Colors] BackColor=0,0,0 CurrentPalette=* Custom Colors * ForeColor=251,187,10 FunctionButtonsColor=64,52,46 HexButtonsColor=64,52,46 MemoryButtonsColor=64,52,46 NumberButtonsColor=64,52,46 OperationButtonsColor=64,52,46 StatButtonsColor=64,52,46
[Font] Font=FreeSans [GNU ],42,-1,5,75,0,0,0,0,0
[Precision] fixed=true
William Morder via tde-users composed on 2022-11-21 23:01 (UTC-0800):
/home/~/.trinity/share/config/kcalcrc
...
[Font] Font=FreeSans [GNU ],42,-1,5,75,0,0,0,0,0
... 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.
On Tuesday 22 November 2022 16:48:57 Felix Miata wrote:
William Morder via tde-users composed on 2022-11-21 23:01 (UTC-0800):
/home/~/.trinity/share/config/kcalcrc
...
[Font] Font=FreeSans [GNU ],42,-1,5,75,0,0,0,0,0
... 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.
Yeah, that was sort of my thinking from the start. I was hoping it might be solved my merely adding some extra lines to the config file I mentioned earlier. I'm sure you already know it, but for the sake of readers who may have joined late:
/home/~/.trinity/share/config/kcalcrc
In any case, it seem to be a pretty simple application, and if I had any real talent for working with these machines, I would do it myself. But I am one of them who uses my machine for other things that I do. For me it is success if I can make my machines obey me.
That would be the best solution, if kcalc could be improved just a little. It already exists as a TDE package; it's just that, as it stands now, kcalc-trinity belongs back in the year 2005.
Bill
On 2022-11-22 19:18:34 William Morder via tde-users wrote:
On Tuesday 22 November 2022 16:48:57 Felix Miata wrote:
William Morder via tde-users composed on 2022-11-21 23:01 (UTC-0800):
/home/~/.trinity/share/config/kcalcrc
...
[Font] Font=FreeSans [GNU ],42,-1,5,75,0,0,0,0,0
... 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.
Yeah, that was sort of my thinking from the start. I was hoping it might be solved my merely adding some extra lines to the config file I mentioned earlier. I'm sure you already know it, but for the sake of readers who may have joined late:
/home/~/.trinity/share/config/kcalcrc
In any case, it seem to be a pretty simple application, and if I had any real talent for working with these machines, I would do it myself. But I am one of them who uses my machine for other things that I do. For me it is success if I can make my machines obey me.
That would be the best solution, if kcalc could be improved just a little. It already exists as a TDE package; it's just that, as it stands now, kcalc-trinity belongs back in the year 2005.
Bill
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
On Tuesday 22 November 2022 20:29:07 J Leslie Turriff 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
Yes, it's a nice little calculator, that just does what it does. I used it back then when I first got into KDE3.
It's odd, too, that other usable calculators just disappeared. I was using qalculate, but it seems to have been removed from the repositories only recently.
Also I did a little searching for the newer KDE versions of kcalc, just to see if maybe there was some kind of standalone app that I could tinker with, to see if they had improved it at all. But alas, to install the KDE version of kcalc would install the whole KDE Plasma pile of krap.
As I was searching, I came across a lot of bug reports for that version (don't know if kcalc-trinity has similar bugs). It doesn't calculate hex correctly, and several other pages.
The main reason that I want a calculator for my computer desktop, by the way, instead of just using my handheld calculator or the calculator on my phone, is that I want to be able to cut and paste figures, rather than having to write them down or type them out.
Bill
William Morder via tde-users composed on 2022-11-22 22:31 (UTC-0800):
I was using qalculate, but it seems to have been removed from the repositories only recently.
???
# 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
On Tuesday 22 November 2022 22:58:46 Felix Miata wrote:
William Morder via tde-users composed on 2022-11-22 22:31 (UTC-0800):
I was using qalculate, but it seems to have been removed from the repositories only recently.
???
# 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
Yes, I just found the trinity version myself (mentioned in my previous post), but those other qalculate packages - while they come up when I do apt-cache search, are not actually available for download.
My guess is that it was removed recently, so they haven't got round to removing references to the package.
Bill
On Tuesday 22 November 2022 20:29:07 J Leslie Turriff 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
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
William Morder via tde-users wrote:
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.
as mentioned the font size etc in TDE is managed globally and applies to all applications
On Tuesday 22 November 2022 23:18:01 deloptes wrote:
William Morder via tde-users wrote:
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.
as mentioned the font size etc in TDE is managed globally and applies to all applications
Yes, I know. One problem at a time.
Bill
Dne st 23. listopadu 2022 08:12:01 William Morder via tde-users napsal(a):
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 ____________________________________________________
The package has definitely been part of the repository for a long time. The version found in the PTB repository was updated on June 23rd and has been part of the repository since then.
Cheers
On Tuesday 22 November 2022 23:53:12 Slávek Banko wrote:
Dne st 23. listopadu 2022 08:12:01 William Morder via tde-users napsal(a):
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 ____________________________________________________
The package has definitely been part of the repository for a long time. The version found in the PTB repository was updated on June 23rd and has been part of the repository since then.
Cheers
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
-
deloptes -
Dr. Nikolaus Klepp -
E. Liddell -
Felix Miata -
J Leslie Turriff -
Jim -
Slávek Banko -
Steven D'Aprano -
William Morder