Proper console mode for LibreOffice on Windows

LibreOffice has always supported usage of command line switches that allow operations like conversion of documents to different file types, or batch-printing. Using LibreOffice CLI in various scripts is a very common scenario.

But until now, it had somewhat suboptimal support for this on Windows. The main executable module – soffice.bin – being a GUI subsystem application, it could not properly output its messages to the calling console, as well as return error codes to check ERRORLEVEL for success. The hacks used to redirect the output of the GUI application to the calling console were unreliable and didn’t work at all on some supported versions of Windows. Sometimes one could not even see why the entered command line was rejected as invalid.

I have just pushed a commit that changes the situation. Now LibreOffice has proper console mode on Windows. soffice.bin is now built for console subsystem, which allows using it in abovementioned scenarios, having the stdout and stderr output, as well as return code, properly sent to console (or redirected using normal means); in debug builds, the debug output is also visible on the console. To allow comfortable usage, a new console launcher executable is introduced, soffice.com, in LibreOffice installation’s program/ folder, alongside with familiar soffice.exe, which is retained for all GUI uses, as before. This allows to continue using command lines like
"c:\Program Files\LibreOffice\program\soffice" --convert-to odt file.doc
from cmd.exe command-line interpreter, without specifying the executable extension, and have the soffice.com launched to have proper console operation (subject to value of PATHEXT environment variable). The command properly “owns” the console (does not return to command prompt) until soffice finishes.

The change will be available in LibreOffice 6.3 scheduled for Summer 2019 (if testing does not reveal a major problem which would require to revert this). I hope this will make use of LibreOffice CLI more comfortable for Windows users, on par with other platforms. If you find any problems with the solution, please report bugs to our bug tracker. Early testing using daily builds is much appreciated!

Advertisements

LibreOffice MUFFIN

Recently, TDF has published its new MUFFIN concept. This publication has provoked a mixed response, with many negative reactions.

When we deal with UI, any possible change brings controversy, and it’s always very aggressive when someone finds that a function they are used to use some way had changed its position. OTOH, there is always a substantial part of community that aggressively promotes “modernization” of current UI.

We all remember how different projects made their UI changes. We remember cases when programs with huge user base made radical changes without an option to keep old UI for those who prefer it. And it forces many of us to resist any sign of possible UI changes in software we use.

Many believe that “design” and “marketing” are swearwords that are used when a company tries to make “purchasers” believe they need something they actually don’t. So, any use of these words in a press release makes yet another chunk of user base to get angry.

There are people that don’t care of UI changes, but have strong opinions that there are much higher-priority tasks to do, like improving stability, compatibility and so on. And when they hear of an effort in an area they regard as unimportant, they get upset. Some of them even have donated to TDF with hopes that donations would go to those goals, and now “see” that TDF wastes their money to pay some designers/marketologists instead of doing Right Things (TM).

Many see the news about UI and immediately realize that there’s indeed something new in UI that is announced. They don’t care to read (let alone comprehend), and so skip any text for screenshots/mockups, and get their views on the matter based on their perception of the graphics. And many of them are angry because they see something that disappoints their expectations of e.g. “ribbon-like” interface. Or they suppose that TDF fools them trying to make believe that there’s something new in the UI options (besides NotebookBar) when actually all that is presented is already possible for long time. “Ah, they try to show to you something old, and pretend that it recently have made a great work to create something new! Smart move!”

Some think that new UI elements are not ready for use and need to be polished in a different branch before inclusion into a LO release.

Many believe that UI changes must begin with UI implementation being rebased to some other library like QT, and that any effort that doesn’t do this is waste of time.

People seem to misunderstand what MUFFIN is.

Thankfully, there are some people in LO community who feel interested in design issues. They form our Design team. Those people are not necessarily developers, and if they are, they have their own interests and priorities, independent of TDF’s or some specific user’s. That’s a great feature of open source community, where each one is able to find an area of interests to apply their effort. And it doesn’t matter if you want LO to get a bug-fix/compatibility feature, and it doesn’t matter if I do some work on those fixes/features: those other people don’t need and aren’t forced to wait for me or help me; they volunteer to do their own contribution in their area in their spare time, and announce their results when they feel appropriate. So anyone who argues that some other things should have been done instead of this work, is misguided. If we would prevent the Design team from doing this, we wouldn’t get more man-power dedicated to your preferred tasks; rather, we would just had lost the man-power (and more important, we would loose those contributors, because there wouldn’t be any reason for them to stay with the project).

The Design team clearly sees the challenges that LO faces with regards to UI changes. On one hand, many want some “refresh”; on the other, many deny the very possibility of it and are afraid of it. There are issues in UI not following different OSes/DMs conventions (making LO to feel not native to these OSes/DMs). And with MUFFIN, the team had IMO made a very smart move.

MUFFIN isn’t a new interface itself. It is even not an interface concept in a usual sense of the term! What it actually is is a public statement, a promise made by LO to its users; and this statement and promise is that: LibreOffice believes that it should be pleasant and easy to use by anyone; and it will never take steps (like other softwares sometimes do) that will sacrifice one group of users’ preferences just to please another – instead, it promises to make its UI as much configurable and modular as it required to allow you, me and anyone to build their own UI of choice. The message is that LO will e.g. continue to provide toolbars: this is not a “first step after which some evil designer will inevitably drop support for good old UI”! And in the same time, LO will not ignore those numerous current and potential users that want another interface: their interests aren’t of lower importance.

If someone still believes in a conspiracy theory that will eventually deprive you from your dear toolbars, remember that LO is being developed by those developers who prefer toolbars themselves, and there’s no ultimate authority to make decision to drop it regardless of those developers’ PoV.

So, MUFFIN is not a NotebookBar or a Single Toolbar. It is a message to users, and a guideline to developers who make UI-related changes. MUFFIN is not the four presented UI options; rather, they are just demonstration of commitment to make it easy to any group to customize.

The four presented UI options are not meant to be necessarily something new. Of course, you can use standard toolbars, or customize them to let only one custom toolbar visible, or use sidebar with any combination of toolbars: the UI components and their combinations aren’t new. The UI components aren’t perfect, and the concept doesn’t claim they are. The concept is orthogonal to any framework used to implement UI components. So, those who are not pleased because the UI isn’t new or isn’t perfect aren’t right when they blame MUFFIN for that. MUFFIN is a promise – so it’s not something to be kept in a separate development branch; and it’s not something that needs screenshots. I’d say that providing screenshots in the press release actually distracted and misguided many readers from the real message.

TDF didn’t spend money to make this happen. It used a research that is publicly available. It doesn’t spend your money to pay some greedy designers: it uses its community’s great power. So no need to get angry that your money are wasted. (As a side note, I’d suggest people to get familiar with TDF role and understand that it doesn’t develop LO itself; instead, it provides home and shelter to community, and promotes the software. Understanding this can help you avoid disappointment when you find out that your donations go to other needs that you imagined.)

I believe that MUFFIN is a great message if you make an effort to hear it. Please do. And if you believe that there’s something to improve, please contribute and become part of community!