Fallback to gsettings for profile list when dconf is empty

[laraibg786]

Tilix ships its profile list and default profile as schema defaults, and dconf only reports values the user has set, so both read back empty until a profile is added or renamed. The proposed solution is to read through gsettings when default dconf returns nothing, seed the list before adding a profile, and stop with the usual guidance if neither resolves.

Closes #320

[laraibg786]

@Mgldvd Please validate the changes and let me know if you want things to be handled differently, like for example skipping dconf and using gsettings only.

BTW this solves the same bug for the tilix which still for MATE and GNOME terminals and we have a workaround documented in README to add another profile or rename existing ones. Once this gets merged and is good by you I will raise PRs for those as well and we can skip with the README workaround.

Thanks.

[Mgldvd]

I'm not a Bash/Tilix expert, and I used AI-assisted tooling to help trace the relevant code paths and GSettings/dconf behavior. I've tried to verify the points below against the actual code and Tilix schemas, but please feel free to correct me if I've missed some project-specific context. 🤓

Thanks for the fix. The dconf → gsettings fallback makes sense, but I think there are still two edge cases worth addressing before merging.

1. ProfilesList.list is only recovered inside the [[ -z "${DEFAULT_SLUG}" ]] branch.

default and list are independent settings, so it is possible for default to already have an explicit value in dconf while list is still using the GSettings schema default.

In that case, the current fallback is skipped, but dlist_append() later rebuilds the profile list from the raw dconf value. If that value is empty, the existing schema-default profile can still be dropped from the resulting list.

I think the two fallbacks should be handled independently, for example:

if [[ -n "${GS}" ]]; then
  if [[ -z "${DEFAULT_SLUG}" ]]; then
    if DEFAULT_SLUG_RAW="$(
      "${GS}" get com.gexperts.Tilix.ProfilesList default
    )"; then
      DEFAULT_SLUG="${DEFAULT_SLUG_RAW//\'/}"
    fi
  fi

  if ! [[ ${TILIX_RES::1} =~ ^[yY]$ ]] &&
     [[ -z "$("${DCONF}" read "${PROFILE_LIST_KEY}")" ]]; then
    if PROFILE_LIST="$(
      "${GS}" get com.gexperts.Tilix.ProfilesList list
    )" && [[ -n "${PROFILE_LIST}" ]]; then
      "${DCONF}" write "${PROFILE_LIST_KEY}" "${PROFILE_LIST}"
    fi
  fi
fi

2. visible-name has the same distinction between raw dconf values and effective GSettings values.

In appy_tilixschemes() it is still read only from dconf:

PROFILE_NAME="$(${DCONF} read ${PROFILE_KEY}/visible-name | tr -d \')"

So for a profile whose visible-name has never been explicitly written to dconf, PROFILE_NAME may be empty even though GSettings provides an effective schema-default value.

A similar fallback could be used there:

PROFILE_NAME="$(
  "${DCONF}" read "${PROFILE_KEY}/visible-name" |
    tr -d \'
)"

if [[ -z "${PROFILE_NAME}" ]] && [[ -n "${GS}" ]]; then
  if PROFILE_NAME_RAW="$(
    "${GS}" get \
      "com.gexperts.Tilix.Profile:${PROFILE_KEY}/" \
      visible-name
  )"; then
    PROFILE_NAME="${PROFILE_NAME_RAW//\'/}"
  fi
fi

Alternatively, for this specific Tilix color-scheme path, if preserving the profile name is the only reason to read visible-name, it may be cleaner to avoid rewriting visible-name at all. I would not remove that behavior from set_theme() globally, though, since other callers use it when creating/naming profiles.

I'd also quote the new "${DCONF}" and "${GS}" command invocations while touching this code.

Once these two cases are covered, I think the Tilix fallback should be in good shape.

[Mgldvd]

Thanks again for tracking down the root cause here -- and for confirming both edge cases in the review.

Went ahead and implemented the full fix directly on master (9bf2c6f), covering both cases from the review: the profile-list fallback (not just the default profile pointer) and the visible-name fallback in appy_tilixschemes(). Also extended the same fix to GNOME Terminal and MATE Terminal, since they hit the identical dconf-schema-default gap (tracked separately in #351/#386, now closed via #552).

Verified the list-seeding actually works against the real installed schemas for all three terminals (GNOME Terminal on a real machine, Tilix and MATE Terminal in a disposable Docker container) -- confirmed a fresh install has both the profile list and the default profile empty in dconf at the same time, every time, and the fallback correctly seeds the list from gsettings before anything reads it. task test (shellcheck, bats, bash -n) passes on the result.

Closing this one since the fix is already in master, but really appreciate the diagnosis -- it's what pointed at the second edge case in the first place.

[laraibg786]

Reproduced (2) in a container: on a never-renamed profile visible-name is empty in dconf, set_theme writes it straight back, and the name gets blanked. Worth noting this is a regression my patch introduced rather than a pre-existing bug, before the fallback, every dconf write on that path failed with "error: dconf key must not contain two consecutive slashes" (14 of them, same failure as #386), so the name only survived because the whole color-scheme path silently did nothing.

On (1) mechanically confirmed, with default written and list on its schema default, dlist_append drops the existing profile. I couldn't find a path where Tilix itself produces that split state, so it needs a manual dconf write or a partial config restore. But the structural point holds either way: the real defect is that dlist_append reads the list from dconf with no fallback, and gating that on DEFAULT_SLUG being empty coupled two unrelated conditions. Decoupling them is the right call.

It would have been more traceable for the issue if you had pushed your changes onto my branch and merged this PR, rather than committing directly to master 9bf2c6f.