Question of implementation details

[CarterLi]

I'm implementing Windows support for fastfetch, and encountered a few questions

1. What does this function do? When should I use it?

uint32_t ffdsParseRefreshRate(int32_t refreshRate)
{
    if(refreshRate <= 0)
        return 0;

    int remainder = refreshRate % 5;
    if(remainder >= 3)
        refreshRate += (5 - remainder);
    else
        refreshRate -= remainder;

    //All other typicall refresh rates are dividable by 5
    if(refreshRate == 145)
        refreshRate = 144;

    return (uint32_t) refreshRate;
}

2. There are multiple names in FFTerminalShellResult. What's the difference between shellProcessName, shellExe and shellExeName?

typedef struct FFTerminalShellResult
{
    FFstrbuf shellProcessName;
    FFstrbuf shellExe;
    const char* shellExeName; //pointer to a char in shellExe
    FFstrbuf shellVersion;

    FFstrbuf terminalProcessName;
    FFstrbuf terminalExe;
    const char* terminalExeName; //pointer to a char in terminalExe

    FFstrbuf userShellExe;
    const char* userShellExeName; //pointer to a char in userShellExe
    FFstrbuf userShellVersion;
} FFTerminalShellResult;

I found that we use shellExeName when printing shell while we use terminalProcessName (the comment reads if exeName starts with processName, print it. Otherwise print processName which eventually prints processName I suppose?) which seems strange to me. Why the difference?

[LinusDierheimer]

I am back from vacation, so i can finally work on fastfetch again:

What does this function do? When should I use it?

Resolution detection on linux often returns values like 59.7264876728 herz, so this function rounds to the nearest multiple of 5, because that is what the user expects to see.

There are multiple names in FFTerminalShellResult. What's the difference between shellProcessName, shellExe and shellExeName?

Groups:

• shell*: bash, zsh, etc currently in use
• terminal*: konsole, gnome-terminal, etc currently in use
• userShell*: Default shell of the user, usually set in /etc/passwd

Entries:

• *ProcessName: current process name, can be changed by the process, so it has its own field
• *Exe: full path of the executable, for example /usr/bin/zsh
• *ExeName: executable name, for example zsh
• *Version: installed version

I found that we use shellExeName when printing shell while we use terminalProcessName (the comment reads if exeName starts with processName, print it. Otherwise print processName which eventually prints processName I suppose?) which seems strange to me. Why the difference?

On linux process names are truncated after 16 characters, so printing the exe name is often the better option. For example gnome-terminal-s vs gnome-terminal-server. Some terminals change their process name (python -> kitty for example), so i print process name if the exe name doesn't start with the process name.

[CarterLi]

I see.

There is a case that we needs a pretty shell name. For example pwsh.exe is the exe name of PowerShell

https://github.com/CarterLi/fastfetch/blob/msys2/src/detection/terminalshell/terminalshell_windows.cpp#L72

Currently I reused shellProcessName to store the pretty name. Should I add a new field shellPrettyName?

[LinusDierheimer]

Yes i think we can do that. We can then move the decision to use process or exe name in the linux specific code.

[CarterLi]

Encountered a case with ffStrbufEnsureFree(strbuf, 0).

With if(strbuf->allocated == 0) return 0; in ffStrbufGetFree and if(ffStrbufGetFree(strbuf) >= free) return in ffStrbufEnsureFree, if strbuf.allocated == 0, ffStrbufEnsureFree(strbuf, 0) won't allocate memories. Then the program crashed with strbuf[strbuf.length] = '\0'

I think if(strbuf->allocated == 0) return 0; in ffStrbufGetFree is problematic. Since ffStrbufGetFree doesn't count the trailing \0, it should return -1 when strbuf.allocated == 0 because there is no space to store the \0. But we can't do that since ffStrbufGetFree returns uint32_t

What do you think about this? @LinusDierheimer

https://github.com/LinusDierheimer/fastfetch/blob/488986e42eb039250c31fcf9b635b81cbaffb6fb/src/util/FFstrbuf.c#L40

[LinusDierheimer]

I think we should set never set the null byte from outside strbuf methods if possible. If we do it, we can just ensure length 1. From inside, we can set the char pointer to CHAR_NULL_PTR, similar to how ffStrbufClear handles it.