love
love copied to clipboard
love.system.getOS() should also return the OS version information
The information is returned after the OS version string. Various returns values of love.system.getOS()
in various OS:
-
Windows 10 1909:
Windows
,10
,0
,18363
,900
,1909
. Note that the last value (1909
) may not present in all Windows 10 versions, so that can benil
. -
Windows 7 SP1:
Windows
,6
,7
,7601
-
macOS 14.15:
OS X
,14
,15
. Should it returnmacOS
in 12.0 or keep itOS X
? -
iOS 13.5.1:
iOS
,13
,5
,1
-
Android 5.1:
Android
,22
. Note that22
correspond to the API level. -
Android 10.0:
Android
,29
If no version information is available, notably in Linux, then only the 1st return value is valid, which is the OS name. The 2nd value and so on simply doesn't exit. So love.system.getOS()
in Linux just return Linux
as it was.
https://github.com/love2d/love/issues/850 (https://bitbucket.org/rude/love/issues/845/lovesystemgetos-more-detailed-information)
Ah should've look at the issue tracker better next time. Should I close it?
To answer all bartbes's questions there:
concrete proposal about what to expose
For my proposal, just version numbers.
why it needs to be exposed why love would need to support it itself
In my game I have a special page which shows all information like the renderer info, all supported texture formats, and including the OS for bug reporting. Sadly I have to write lots of code for it in Lua side. Also after thinking about it, this is what love.system
is meant for, provide information about user system.
how to obtain the information
I have a code to retrieve the all of those necessary info for Windows at https://github.com/MikuAuahDark/livesim2/blob/e5496da47d128c4f9c6d21bb6f811ff84d9eaf63/game/systeminfo.lua#L36-L58
For Android, assume SDL 2.0.12, it's as simple as calling SDL_GetAndroidSDKVersion()
.
Personally I think numbers are way too version-specific to expose properly - if getOS were to return more information, I'd prefer it if it was a string (as a second return value). If you know what the numbers represent enough to use them, then you can probably also parse those numbers from a string if you need.
If that approach is also used, it's also possible to construct a string containing that information as shown later in the code I linked above. Sadly for Android, this means tables of Android codenames must be used.
I didn't mean only exposing codename strings for operating system versions, I meant that the OS- and version-specific numbers (and other info) should be a string rather than a series of Lua numbers.
Yeah, I completely understand. So, in Windows 7 SP1, love.system.getOS()
returns Windows
and 6.1.7601
right?
I guess that would depend on what people want to use it for - if it's for data collection or branching logic, having the internal version numbers makes sense. If it's for display purposes, having the 'pretty' name makes sense.
I was thinking of adding optional 1st argument for it which returns all the versions as Lua numbers when set to true, and version string otherwise. However that would bloat LOVE code significantly, so I think it's either version string for display purpose or series of Lua numbers for branching logic.
What about return OS, prettyname, internalversionstring
?
In that case, here's list of cases for love.system.getOS()
:
-
Windows 10 1909 build 10.0.18363.900:
Windows
,10 1909
,10.0.18363.900
-
Windows 7 SP1:
Windows
,7
,6.1.7601
(note that7
for the 2nd value is string, not number) -
macOS 14.16:
OS X
,Mojave
,14.16
-
iOS 13.5.1:
iOS
,(empty string)
,13.5.1
(I don't know what to put at 2nd returned value) -
Android 5.1:
Android
,Lollipop (5.1)
,22
-
Android 10.0:
Android
,10
,29
(note that10
for the 2nd value is string, not number)
If that looks good, then I'd need assistance on implementing it for macOS and iOS since I don't have those devices.
Of course it's also possible to return more structured data in a table:
{
os = "Windows",
majorVersion = 10,
displayVersion = "Windows 10, 1909"
fullVersion = {10, 0, 18363, 900}
}
Of course that raises the follow up question what to return and with what names, but it's extensible and forces the lover to make a choice what to display.