Interface control arguments do not work as I would expect to start soffice from command line: --minimized does not start minimized, windows is always shown --nodefault and --invisible work when soffice is started without document, not with one Not sure if that is a bug or related to my Cinnamon Linux. Use case: when scripting bisect run with opening some file, LO window is popping and taking focus, wanted to minimize it.
(In reply to Timur from comment #0) > --minimized does not start minimized, windows is always shown Repro using Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 24; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded > --nodefault and --invisible work when soffice is started without document, > not with one A problem of expectation? --invisible and --nodefault do not hide documents, only hide the start center (--nodefault) and also change the program lifetime (--invisible).
(In reply to Mike Kaganski from comment #1) > (In reply to Timur from comment #0) > > --minimized does not start minimized, windows is always shown > > Repro using Version: 24.8.2.1 (X86_64) / LibreOffice Community > Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 > CPU threads: 24; OS: Windows 11 X86_64 (10.0 build 26100); UI render: > Skia/Vulkan; VCL: win > Locale: ru-RU (ru_RU); UI: en-US > Calc: CL threaded This, too, looks like wrong expectations, plus a documentation problem: the help shows "Starts minimized. The splash screen is not displayed", but the "Starts minimized" is misleading - the whole effect is *meant* to be "The splash screen is not displayed". And it is unclear what is the difference compared to --nologo. Maybe some historical difference, e.g. going to the times when there were things like first time activation wizard - which could be also affected?
I would not say that expectation for --minimized is wrong, there is --nologo for splash so --minimized should do what it says, minimize the window both with new and existing document. If those cases are separete, let this be for --minimized. But I also do not see yet why other arguments would not work with opening a document.
(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).
(In reply to Timur from comment #3) --invisible is meant to start an instance controlled via the API. It is *contradicting* the "open file" argument, which is for interactive work. Thus, either one or the other. --nodefault means "hide start center". When you open a file, the start center is not shown anyway.
(In reply to Mike Kaganski from comment #4) > 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). But OTOH, many programs do provide such command line arguments; it *seems* that different Linux DEs don't provide such function themselves out-of-the-box [1]; so having such a *new* command like argument would be valid. [1] https://askubuntu.com/questions/663187/how-can-i-run-a-program-on-startup-minimized
|User/programmatic interface control: | --nologo Disables the splash screen at program start. | --minimized Starts minimized. The splash screen is not displayed. | --nodefault Starts without displaying anything except the splash | screen (do not display initial window). | --invisible Starts in invisible mode. Neither the start-up logo nor | the initial program window will be visible. Application | can be controlled, and documents and dialogs can be | controlled and opened via the API. Using the parameter, | the process can only be ended using the taskmanager | (Windows) or the kill command (UNIX-like systems). It | cannot be used in conjunction with --quickstart. | --headless Starts in "headless mode" which allows using the | application without GUI. This special mode can be used | when the application is controlled by external clients | via the API. Whether these options make sense or naming could be better, it is likely part of many batch configurations and tinkering affect a lot of users with just little benefit. If we change something at all, it should be limited to documentation.
I still do not see why --minimized does not start minimized and how that could be documentation issue when it does not work, and what users it would affect.
(In reply to Timur from comment #8) -- minimized is not "start with the main window in minimized state", it's "start with minimal decorations like splash".
(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
(In reply to Mike Kaganski from comment #9) > (In reply to Timur from comment #8) > > -- minimized is not "start with the main window in minimized state", it's > "start with minimal decorations like splash". Let's just rephrase the info text. I'd be afraid of changing the workflow for these command line parameter and suggest to solve the use case, whatever it is beyond the unclear function - text relation, by other means. All OS/DE should offer ways to minimize applications. Code pointer: desktop/source/app/cmdlinehelp.cxx
We have 2 issues: - existing argument is not what is sounded, so this is Doc change - but I still need "start minimized". OS minimized is not practical, it comes later so it may flash. When looking for that, advice is: preferably use app option to minimize. While this ticket may be as marked, I do not see why there would not be another ticket to really start minimized. When doing bisects with GUI (no headless), LO flashes and takes focus, best way to avoid that seems to start minimized.
(In reply to Timur from comment #12) I agree (as in comment 6), so please create that new request.