Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'Show this dialogue at startup': ambiguous and ineffective #67

Open
LinuxOnTheDesktop opened this issue Aug 1, 2024 · 4 comments
Open

Comments

@LinuxOnTheDesktop
Copy link

I write about mintwelcome 2.5.9, on Mint 22 Cinnamon.

Does, 'Show this dialogue at startup' refer to (1) the startup of the Welcome application? Or does it refer to (2) the logon of the user?

image

I had though that the answer was 1 - because, after ticking the box, I loaded the Startup Applications program and mintwelcome showed therein as disabled. Equally, though, whether the box is ticked seems to make no difference to what mintwelcome displays (or does) once it is loaded. I conclude that 2 is meant but that the tick-box is ineffective.

It seems to me two things are needed. First, 'Show this dialogue at startup' should become, 'Show this window at log-on'. Second, ticking the box should undo any disabling (of mintwelcome) worked by Startup Applications.

@stoyandg
Copy link

I completely agree that the current phrasing of "Show this dialogue at startup" can be confusing, as it’s not immediately clear whether it refers to the application's startup or the user's logon session. A more precise wording, like "Show this window at log-on," would definitely make the intention clearer. Additionally, I think using the term "dialogue" here might be misleading, as the interaction is more one-sided. Perhaps "window" or "screen" would be more appropriate.

Regarding your second point, I have a different perspective. The Startup Applications tool is generally used as the central place to manage which applications start when a user logs in. If mintwelcome were to override this behavior based on its own checkbox, it could potentially lead to confusion and unexpected behavior for users trying to manage their startup applications. Consistency in how startup applications are handled is important for user expectations and experience.

That being said, I do think there's value in ensuring that mintwelcome's behavior is clear and intuitive. Maybe we could add a tooltip or additional information in the UI to explain that checking the box will add mintwelcome to the Startup Applications list. This way, users can be informed about where to control this setting centrally.

What are your thoughts on this approach?

@clefebvre
Copy link
Member

I think we can use something simpler like "Always show this window".

Regarding xdg-autostart (Startup applications), it's not something casual users should mess with. It's really clunky and prone to issues. When a user uses this tool, he basically overrides .desktop files with local ./desktop files, exposing himself to missing changes on updates.

Although xdg-autostart is handy for distributors and developers, the way Startup Applications works is a real mess. This is the reasons apps such as mintwelcome use gsettings instead.

If we wanted to centralize this we'd have to rewrite the way Startup Applications work.

@LinuxOnTheDesktop
Copy link
Author

@stoyandg : thanks.

@clefebvre : on the matter of wording, changing the relevant text to, 'Always show this window' seems to suffice, except that sometimes (yes?), the ticking of the box is not honoured. (Hence the presence of the word 'ineffective' in the title I gave to this issue.) If so, then that is not good. Also not good is, as you acknowledge, that the startup tool - which is surely an important tool - has the (other) problems that you mention.

@stoyandg
Copy link

@clefebvre "Always show this window" sounds pretty clean. Should I make that change? I'm not sure what the procedure is as I'm quite new.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants