dmitriy.kazimirov/inxi
1
0
Fork 0
mirror of https://github.com/smxi/inxi.git synced 2024-11-16 16:21:39 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

changelog edits

Browse source
This commit is contained in:
Harald Hope 2018-07-12 15:47:03 -07:00
parent faead0eb54
commit 86814a06c8
1 changed files with 19 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
inxi.changelog
View file

@ -10,10 +10,10 @@ New version, new man. Changes, bug fixes, enhancements! Don't delay!
Bugs:
1. A real bug, the detection for true path of /dev/root had a mistake in it and
would only have worked in half the cases. This was an easy fix, but a significant
but since it also would lead to the actual root / partition showing in Unmounted.
one since it also would lead to the actual root / partition showing in Unmounted.
2. Related to the item Fixes-2, if two USB networking devices were attached,
the second one's bus and chip ID would go on the wrong line of data if -n or -i
option were used. Since that would be the line belonging to the one above,
option were used. Since that would be the line belonging to the previous device,
that obviously was weird and wrong.
3. NEW: latest kernel can show hwmon data in sensors, for example from wifi chip.
This broke CPU temp detection and showed way too high cpu temp, so this fix is
@ -65,24 +65,24 @@ string if it's unique. I couldn't think of a clean field name that meant:
vendor OR vendor + basic product info OR motherboard + board version OR full
product name, including vendor, so in the end, I just used vendor: but it's not
quite the right term, but nothing else seemed to work better. Testers responded
very enthusiastically about this feature so I guess the vendor: name is ok.
very enthusiastically about this feature so I guess the vendor: feature is ok.
Changes:
1. Biggest change: Drives: HDD: total: the HDD: is now changed to: Local Storage:
This was part of issue #153 and is a good suggestion because HDD generally was used
to refer to hard disks, spinning, but with nvme, m.2, ssd, etc, that term is a bit
This was part of issue #153 and is a good suggestion because HDD generally was used to
refer to hard disks, spinning, but with nvme, m.2, ssd, mmc, etc, that term is a bit
dated. 'Local' is because inxi does not include detected remote storage in the totals.
2. The recent --wm option which forced ps as data source for window manager detection
has been reversed, now --wm forces wmctrl and ps aux is preferred. Still falls back
to wm ctrl in case the ps test is null, this is better because I have to add the wm
to wmctrl in case the ps test is null, this is better because I have to add the wm
data manually for each one, whereas wmctrl has an unknown set and probably variable
set of wm. Note that I reversed this because I saw several cases where wmctrl was
wrong, and reported a generic source wm instead of the real one. Since most uses are
wrong, and reported a generic source wm instead of the real one. Since most users are
not going to even be aware of the wm: feature as enhanced with --wm switch, this
should have no impact on users in general. Since the detected wm name needs to be
know to get assigned to wm: and wm version data, I think it will work better to
have the known variants match with the wm data values, then just fallback to
unknown ones that can get fille in over time as we find wm that people actually
known and handled to get assigned to wm: and wm version data, I think it will work
better to have the known variants match with the wm data values, then just fallback to
unknown ones that can get filled in over time as we find wm that people actually
use and that you can get version info on and detect.
Removed:
@ -91,15 +91,15 @@ was always wrong because it did not have any necessary relation to the actual
gtk version the desktop was built out of, and it also almost always returned no
data. Since this is an expensive and slow test, and is always going to be wrong
or empty anyway, I've removed it. My tests showed it taking about 300ms or so
to generate no data, heh.
That's the tk: feature in -S. Note I also found that gnome-shell takes
an absurdly long time to give --version info, the slowest of all such things, 300ms
again, just to show version? Someone should fix that, there's no possible reason
why it should take 300 milliseconds to give a simple version string. Note that
this returns tk: to only returning real data, which in this case means only xfce,
kde, and trinity, which are the only desktops that actually report their toolkit
data. I'll probably remove that code in the future unless I can think of some real
use for gtk version elsewhere, but it's just junk data which doesn't even work.
to generate no data, heh. That's the tk: feature in -S.
Note I also found that gnome-shell takes an absurdly long time to give --version
info, the slowest of all such things, 300ms again, just to show version? Someone
should fix that, there's no possible reason why it should take 300 milliseconds
to give a simple version string. Note that this returns tk: to only returning
real data, which in this case means only xfce, kde, and trinity, which are the
only desktops that actually report their toolkit data. I'll probably remove
that code in the future unless I can think of some real use for gtk version
elsewhere, but it's just junk data which doesn't even work.
In the future, I will not try to emulate or guess at desktop toolkits, either they
show the data in a direct form like XFCE or Trinity or KDE do, or I won't waste