[Bug] Remaining hardcoded paths to /home/nemo and .config/cepiperez

[Olf0]

Oh, how I hate to revive this topic again, because I assumed it to be dealt with in #20, #47 and #50 (rsp. in the corresponding PRs #21, #48 and #51). But issue #99 made me consider this again, so I used GH code search in hope to exclude this as a reason; though "hope dies last", it ultimately often does:

Another code search for /home/nemo/

• Twice in src/playlist.cpp: line 264 and line 355
  These .config/cepiperez/ paths appear to be wrong, anyway (i.e. "doubly wrong"), because the configuration data was moved a while ago (PR Change the organisation name #51), correct?
• Once in line 437 of extras/Lockscreen.qml
  @dcaliste already dismissed this one as historic, unused code (a few more details in the last paragraph here): extras/Lockscreen.qml should be transformed into a Patch for Patchmanager, if someone has sufficient interest to revive this functionality. So I created the issue [Suggestion] Trying to revive the functionality of extras/Lockscreen.qml #102 to document this at a single, central location.
• Once in line 73 of src/utils.cpp
  This "hard-hardcoded path" is just "WTF?" IMO. Luckily the function startMafw seems to be unused. Still I have no idea what it was meant to be good for (hence no other idea, but to eliminate it). Maybe someone with more programming experience can provide more insight (or a well founded opinion that it is indeed superfluous, even as a coding example). As it appears more likely that the ultimate decision will be to eliminate it, I prepared PR Remove function startMafw … #104.

The first two hits in also made me search for .config/cepiperez/: Luckily that does not reveal additional hits.

TL;DR

Ultimately only the two hits in src/playlist.cpp (line 264 and line 355) should be rectified and a decision be met WRT the function startMafw: {Go|Stay} (see #104 for "Go")

[dcaliste]

The matchs in src/playlist.cpp are within commented parts of the code, so unused. As for the function startMafw() in utils.cpp. The full function is a no-op.

The last match is in the Lockscreen.qml file, which is completely unused at the moment.

So all these matches have no consequenses. For peace of mind, and in case these parts of the code may become uncommented, it could be ok to adapt these parts also. Or remove them since they are not used.

[Olf0]

For peace of mind, and in case these parts of the code may become uncommented, it could be ok to adapt these parts also.

Did that by PR #107, because it it less about "peace of mind" than "forgetting and then stumbling over it again and again" and "expecting others who have not seen this discussion to wonder, too".