https://bugs.kde.org/show_bug.cgi?id=507217
--- Comment #30 from [email protected] --- I do want to apologize for not realizing that all my copied blocks of comments from the other thread didn't actually include the context by which there are terminal diagnostics to try to fix the GUI issue. I realize now that I did only mention the GUI in the comment #17 below it. I suppose based on the fact that my thread was marked as a duplicate and a message about that was created here for that, I assumed prematurely that my timing with that system message would make it self-evident without needing to explain the context for my command line diagnostics (after all, I figured, surely if any context is missing, they'd just go to the linked thread). But given that I offloaded a bunch of information, that more reasonable assumption might be that I actually did say everything important, so since I didn't mention the GUI in the pasted material, it would look like my problem isn't a GUI problem. I am sorry for leading that misunderstanding. To reiterate, what I posted was diagnostic work recommended to me by someone in my thread about fixing my Discover issues when closing and reopening through the start menu/taskbar. Multiple people asked me to perform things on the command line to see if my problems would get fixed, so I performed several tests to increase the amount of information and reduce the amount of back-and-forth. All my tests mentioned in the pasted material come with the given that I tried clicking the taskbar icon after every attempted fix. It was redundant to mention, however, in the actual thread this came from. I didn't fully consider the loss of context here. So again, I do apologize for that, Ken. In any case, it seems that Roke who had also been brought into this thread, as he has just mentioned, has Snap as an irrelevant factor to their otherwise identical symptoms. It feels fair to assume that there is a root issue that impacts both things, and the Snap reinstallation only hides it. At the very least, it would only be responsible to rule it out rigorously. A coincidence of multiple slightly different issues bubbling over time, that all have the same symptom of the GUI not opening after being closed the first time, being all actually caused by a different core issue seems deeply unlikely. We should find the core cause to fix it for good. And for this, I believe my extensive command-line testing may supply some important context going forward (even though the matter is initializing through the GUI). I need to confirm something, from those who might know. If I base myself on Windows experience, icons we click in the start menu and on the taskbar are actually shortcuts that call an executable in a defined manner, such as with libraries or using particular arguments. Basically, GUI operations ARE command-line operations, covered in a pretty wrapper. And I assume that in Solus (and Linux in general), this is the same. So as a ramp onto maybe solving this issue, I wanted to refer to my testing that found that having flatpak BEFORE fwupd in the argument order of the command fails after the first openings. This implies the GUI interaction is calling a command with that argument order -- something that we don't actually know for sure, but that contributors can likely check and prove or disprove. It would be an easy way to move onto that next suspicion. I have no experience contributing here and have no idea how I would verify this myself. Hence why I had made my bug report with my original thread. Is there a chance we can check this real quick? -- You are receiving this mail because: You are watching all bug changes.
