Hi Stephan, thank you for your reply.
I am asking because: - The commit fixes two bugs: https://bugs.freedesktop.org/show_bug.cgi?id=47892 and https://bugs.freedesktop.org/show_bug.cgi?id=36313 - The commit enables previously broken functionality in a very simple way. The user interface could be more user friendly as you pointed out. However, it is not clear how the user interface should be improved. Also, anything more sophisticated would likely be significantly more complex change I think. The commit finds a good balance with its simplicity & impact. - At the moment, it is not possible to use LibreOffice command line to convert to and from text formats, because the FilterOptions is not available. If users need to convert documents to and from text formats, they need to go via UNO. However, there are problems when using UNO: - There is no way to guarantee that a UNO connection releases allocated memory. Combined with memory leaks in LibreOffice, this makes it rather inconvenient when using it in a long running process. - UNO evolves, forcing us to follow the changes to the protocol. We can't simply use whatever the official LibreOffice for a given system is, we have to use a particular version. On Linux, we use v3.5. - On Windows, we still use OpenOffice, because UNO on LibreOffice does not properly close files, which combined with the mandatory locking mis-feature on Windows is fatal. - My prefered solution to our LibreOffice issues would be to to replace our dependency on UNO with simple command invocation. This should solve our problems at the cost of slower conversions due to slow LibreOffice startup. That trade-off is reasonable I think. There seems to be also general intention to improve LibreOffice startup in the future. - The fix will be released in about half a year so I have to either: - wait and stick to the old LibreOffice and OpenOffice for half a year; - build custom LibreOffice myself with the cherry-picked patch which is doable on Linux, but rather complex on Windows; - ask for the fix to be put into v4.3 already; it is a bugfix release after all It would definitely help us to have the bugfix earlier then in v4.4. It might also help the people who reported those bugs and it also might help people, who might want to use FilterOptions but silently give up when they find it broken. Thank you very much! Tomas On 09/09/14 10:20, Stephan Bergmann wrote: > On 09/08/2014 05:13 PM, Tomas Hlavaty wrote: >> Sorry, I meant 4.3.3 as 4.3.2 is in freeze already. >> >> On 08/09/14 17:10, Tomas Hlavaty wrote: >>> Hi all, >>> >>> would it be possible to cherry-pick >>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=45ba4d79d968f81f74ef0c4588fd15b1ce91153f >>> >>> to the 4.3.2 release? It is currently commited towards 4.4 (scheduled >>> for 2/2015) but as this is an old bug and 4.3.2 is called bugfix >>> release, I wonder if it was be acceptable? > > Given "That is, I am not sure whether the fix from comment 16 is > already a practical-enough solution?" at > <https://bugs.freedesktop.org/show_bug.cgi?id=36313#c17>, I'm not sure > whether it would actually help anybody to backport that to 4.3.3. > > Are you asking because you know about a specific scenario in which it > would help, or just on generic "it's a bugfix, so it should go into a > bugfix release" grounds? > > Stephan > _______________________________________________ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice