[Bug 163562] Interface control arguments (--minimized etc) do not work in Linux

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=163562

Dick Campbell <audreyjustice16 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO
     Ever confirmed|0                           |1

--- Comment #10 from Dick Campbell <audreyjustice16 at gmail.com> ---
(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 on the CC list for the bug.