1 files changed, 1 insertions, 4 deletions
diff --git a/helpcontent2/source/text/shared/01/01110100.xhp b/helpcontent2/source/text/shared/01/01110100.xhp
index 8728dff9d4..77874f6f8d 100644
--- a/helpcontent2/source/text/shared/01/01110100.xhp
+++ b/helpcontent2/source/text/shared/01/01110100.xhp
@@ -5,13 +5,10 @@
  *
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  * 
- * Copyright 2008 by Sun Microsystems, Inc.
+ * Copyright 2000, 2010 Oracle and/or its affiliates.
  *
  * OpenOffice.org - a multi-platform office productivity suite
  *
- * $RCSfile: 01110100.xhp,v $
- * $Revision: 1.8.4.1 $
- *
  * This file is part of OpenOffice.org.
  *
  * OpenOffice.org is free software: you can redistribute it and/or modify
Age	Commit message (Collapse)	Author
2019-10-25	tdf#42949 Fix IWYU warnings in vcl/unx/gtk3 and gtk3_kde5/	Gabor Kelemen
	Also recheck vcl/source after recent reworks and f-u-i updates. Some new blacklist entries were needed for keeping existing fw declarations in headers. Add blacklist entries for removals causing no-pch build failures that were reverted in: a3b03ba1316b1ec0a9b0a3b45b96dc0a49aa9f1f 75d924db95559cff5f699bad8fe34bb0aeac0ff6 b57052ec2bbe548ca495a32b4bfce1d1c71caf33 Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I71227806288b68ef2a2cd56244899fd56bd0db8d Reviewed-on: https://gerrit.libreoffice.org/81163 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-04-17	gtk3_kde5: No longer kill fpicker process on timeout	Michael Weghorn
	In some observed cases, 100 ms were not enough for the separate 'lo_kde5filepicker' process to terminate properly, in particular on slow or busy hardware. Drop the timeout here and just wait for the process to finish to avoid killing it unnecessarily, which could e.g. lead to file dialog settings/state not properly being saved by the native KDE Plasma QFileDialog (plasma-integration, e.g. in 'KDEPlatformFileDialogHelper::saveSize'), so that the last used mode or size would not be remembered. The assumption is that the separate fpicker process should now properly finish in all cases, in particular since commit 93815c2b04f1905e43c695caf5cc2c594bb897ce. Should that assumption not hold, let's rather fix the underlying issues than increasing the timeout here. Change-Id: I0a58c1425940fbfaecb5012a24fd9a0222cbaccb Reviewed-on: https://gerrit.libreoffice.org/70834 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-03-15	Fix build with older versions of Boost	Tomáš Chvátal
	Change-Id: Ic5fa7c703821c23e704d2c58f9a04d0ac8ce8ef2 Reviewed-on: https://gerrit.libreoffice.org/69308 Tested-by: Tomáš Chvátal <tchvatal@suse.cz> Tested-by: Jenkins Reviewed-by: Tomáš Chvátal <tchvatal@suse.cz>
2018-10-08	loplugin:external (--enable-gtk3-kde5)	Stephan Bergmann
	Change-Id: Id096bd25cd6df5941eaec45f7573f5887ae51d79
2018-10-08	tdf#120261 gtk3_kde5: Leave event handling on gtk3 side to gtk	Michael Weghorn
	This introduces a new thread that takes care of handling the IPC command and result for executing the file picker ('Commands::Execute'), which is the only command in the file picker that may block for a longer time until it receives its result from the kde5 side (namely, when the dialog has been closed). While the file dialog is being executed, activate a dummy GTK dialog that also takes care of handling events in its main loop as long as the file dialog is shown. The dummy dialog is closed together with the KDE file dialog. (Since the actual KDE file dialog is run as a separate process, this one is mostly "transparent" to the soffice process from the point of view of a dialog.) This allows dropping the custom event processing previously done in 'Gtk3KDE5FilePickerIpc::readResponse()' that had the potential to cause all kinds of problems, e.g. when another event related to the file picker was triggered from a Java process via UNO. Change-Id: I3d663253f09320f7a8e0d9ec32a8fd6ec191c189 Reviewed-on: https://gerrit.libreoffice.org/61253 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2018-09-06	tdf#119685 Fix infinite loop in gtk3_kde5 filepicker	Michael Weghorn
	Since 'string::find()' returns the position of the given character in the string and that was passed as the amount of characters to delete from the string, 'm_responseBuffer' would always be a string starting with a newline character afterwards, when this part of the code was reached. Subsequent calls to 'Gtk3KDE5FilePickerIpc::readResponseLine' therefore always returned an empty string and left 'm_responseBuffer' unchanged, resulting in the lambda function inside 'readResponse' in 'gtk3_kde5_filepicker_ipc.hxx' to loop infinitely. While at it, make a little more explicit that 'it' is of type 'size_t' here. Change-Id: I3b1c209f8307ab71465d9538a82616dff8656415 Reviewed-on: https://gerrit.libreoffice.org/60047 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2018-01-25	gtk3_kde5: port away from boost::process	Milian Wolff
	While this uglifies the code, it removes a dependency on newer boost 1.64+ which ships boost::process. This helps on systems where LO is linked against system boost and an older version of boost is used. Additionally, and this is the main motivation, this makes it easier to backport these changes to 5.2, where the bundled boost is also only at 1.60. To keep the required changes at a minimum, the osl_* API for reading from/writing to the stdout/stdin of the helper process, we buffer the responses on a line-by-line basis. Note that one cannot simply reuse osl_readLine on the non-seekable oslFileHandle. Instead, we have to roll our own simplistic readLine implementation... Change-Id: I1197e38cb2416e926d8ba985accd6c10d78bcc52 Reviewed-on: https://gerrit.libreoffice.org/48490 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-01-23	Various loplugin in --enable-gtk3-kde5 code	Stephan Bergmann
	Change-Id: Ic12464f01950a5037bb6819a2722aba5a7e3e2e6
2018-01-23	Introduce gtk3_kde5 vcl plugin	Milian Wolff
	This is a hybrid plugin which mostly wraps the GTK3 vclplug. Only the file and folder picker are replaced by KDE dialogs. This gives us a well-maintained GTK LO base with basic KDE integration with minimum effort. To prevent issues with nested event loops, the KDE dialogs are launched from a separate process, the new lo_kde5filepicker helper executable. A trivial stdin/stdout IPC mechanism transfers the data between LO and the Qt/KDE helper. The usage of an external process also allows us to copy'n'paste between LO and the KDE file dialog without freezing the UI, as would happen when one would do this in-process. This is in general also the architecture applied by the kmozillahelper, which is used to integrate KDE file dialogs into Firefox. While the KDE dialog is shown, the GTK3 main window is disabled and close requests are ignored. The KDE dialog in turn also sets the LO window as transient parent. Together, this makes the illusion perfect and the KDE dialog behaves like a modal dialog. This works properly also with multiple LO main windows, and only individual windows will get blocked as one would expect. Functionality wise, most of the features of the KDE4 dialog are supported. You can pick files and folders, and save files under a new name. Some custom checkbox widgets are supported, but lists, buttons and preview widgets are not yet implemented. Also, loading remote files via KIO is not possible yet. Change-Id: I1a97cf7c272307a19ace4222d5f12253bc722829 Reviewed-on: https://gerrit.libreoffice.org/47718 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>