https://bugs.documentfoundation.org/show_bug.cgi?id=163562
Dick Campbell <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #10 from Dick Campbell <[email protected]> --- (In reply to Mike Kaganski from comment #4) > (In reply to Timur from comment #3) > > I am unsure if it's valid for UX consideration - the command line arguments > are heavily used in existing apps (shell scripts, macros, external > applications), so their behavior change should be considered an API break. > > You can of course create an enhancement request to implement a *new* command > line switch doing what you want; but thinking about it, I would actually > expect that to be OS function (e.g., shell links on Windows have their own > "minimized" option, which definitely works; same with Windows' cmd.exe's > "start /MIN" command). You're absolutely right. Changing the behavior of existing command-line arguments would indeed be considered an API break. This is because it would likely break existing scripts, macros, and external applications that rely on the current behavior. Here's why this is important: Backward compatibility: Maintaining backward compatibility is crucial for software longevity. Breaking existing functionality can cause significant disruption for users and developers who rely on it. Ecosystem impact: APIs are often used by other software and tools. Changing an API can have cascading effects on the entire ecosystem. User experience: Unexpected changes in behavior can lead to frustration and confusion for users. Your suggestion for a new command-line switch is a great approach. This would allow users to choose the desired behavior while maintaining backward compatibility for existing scripts and applications. Regarding your mention of OS-specific features: Shell links on Windows: These are a good example of how operating systems can provide additional features or customization options without breaking existing APIs. Command-line options: Many command-line tools offer a variety of options and flags to control their behavior. Adding a new option to a tool's command-line interface would be a similar approach. In summary: Avoid API breaks: Changing the behavior of existing command-line arguments should be avoided if possible. Introduce new features: Consider adding new features or options to the tool's interface to provide the desired functionality without breaking existing usage patterns. Learn from OS examples: Look at how operating systems and other software handle similar scenarios to find inspiration for your approach https://basketballstarsfree.com -- You are receiving this mail because: You are the assignee for the bug.
