Stepping down from ESC & Developer certification committee
Hi all, Today is my last day at Collabora Productivity, and I have no intention to continue LibreOffice development as a volunteer (unless the environment around TDF becomes less toxic), so effective immediately, I'm stepping down from ESC and from the Developer certification committee. Please also change my affiliation to "Unaffiliated" in the list of Certified developers. This is a very sad day for me - the next month it would be 20 years since I started contributing to the codebase that we call LibreOffice now - but I've burnt out, and I was wrong when I thought I could contribute to the code as if nothing was happening in the community [1]. Thanks to all the people who were kind, helpful & inspiring during my OOo and LibreOffice journey! All the best, Kendy [1] https://www.mail-archive.com/board-discuss@documentfoundation.org/msg06236.html
[Libreoffice-commits] core.git: configure.ac
configure.ac |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) New commits: commit 4132bd5477c25a505f7bfbee1e7dcf6602c927d3 Author: Jan Holesovsky AuthorDate: Mon Jan 23 17:56:31 2023 +0100 Commit: Jan Holesovsky CommitDate: Tue Jan 24 11:28:53 2023 + No need for openssl in the cross build's instdir_for_build So disable it from the configure & make sure it is not brought in by the non-iOS check. Change-Id: I9bbf1c593d1d48197951002e04e7f925d35ecba9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146034 Tested-by: Jenkins Reviewed-by: Jan Holesovsky diff --git a/configure.ac b/configure.ac index 8bad8873443d..921853e2f8b3 100644 --- a/configure.ac +++ b/configure.ac @@ -5734,6 +5734,7 @@ if test "$cross_compiling" = "yes"; then --disable-nss \ --disable-online-update \ --disable-opencl \ +--disable-openssl \ --disable-pdfimport \ --disable-postgresql-sdbc \ --disable-skia \ @@ -5741,9 +5742,9 @@ if test "$cross_compiling" = "yes"; then --enable-dynamic-loading \ --enable-icecream="$enable_icecream" \ --without-doxygen \ +--without-tls \ --without-webdav \ --without-x \ ---with-tls=openssl \ " # single quotes added for better readability in case of spaces echo "Running CONF-FOR-BUILD/configure" \ @@ -5798,7 +5799,6 @@ if test "$cross_compiling" = "yes"; then LIBXSLT MDDS NATIVE -OPENSSL ORCUS PYTHON SCRIPTING @@ -10632,7 +10632,7 @@ if test "$enable_fuzzers" != "yes" -a "$enable_nss" = "yes"; then libo_CHECK_SYSTEM_MODULE([nss],[NSS],[nss >= 3.9.3 nspr >= 4.8],,system-if-linux) AC_DEFINE(HAVE_FEATURE_NSS) ENABLE_NSS=TRUE -elif test $_os != iOS ; then +elif test $_os != iOS -a "$enable_openssl" != "no"; then with_tls=openssl fi AC_SUBST(ENABLE_NSS)
Re: Re: [board-discuss] [DISCUSS] Approve in-house developers proposal v.3.1
> > Hi all, I have unsubscribed from this mailing list, but it was brought to my attention that Paolo claims that I have signed off the latest version of the Developers proposal. That is not true. That version is not balanced, and Paolo’s unwillingness to find balance there was one of the main reasons to my resignation. For many years, TDF was celebrated as an organization that is always able to find balance of many interests. I’m afraid this is not true any more - which is very sad :-( Wish you all good luck. All the best, Kendy > > -- Forwarded message -- > From: Paolo Vecchi > To: Florian Effenberger , Board Discuss < > board-discuss@documentfoundation.org> > Cc: > Bcc: > Date: Fri, 25 Nov 2022 14:57:02 +0100 > Subject: Re: [board-discuss] [DISCUSS] Approve in-house developers > proposal v.3.1 > Hi Florian, > > On 25/11/2022 14:04, Florian Effenberger wrote: > > Hello, > > > > me and many others from the team would be very happy to finally see > > the developer proposal come to life. > > > > We believe that would do a lot of good for TDF, its mission, and the > > LibreOffice community at large. It's been taking a long time, so if > > the board is ready to vote and trusts the team to handle the project, > > my teammates and I would be more than happy to support these efforts. > > I'm very pleased to see that the team supports the efforts that many of > us put in this proposal. > > All directors also expressed their support for the proposal which, as > agreed, has been finalised by both myself and Jan so I'm sure the > community is expecting that they follow through with their votes. > > > > > Florian > > > > Ciao > > Paolo > > -- > Paolo Vecchi - Member of the Board of Directors > The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE > Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts > Legal details: https://www.documentfoundation.org/imprint > >
[Libreoffice-commits] core.git: Branch 'distro/collabora/co-22.05' - oox/source sw/qa
oox/source/drawingml/fillproperties.cxx |6 +-
sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx |binary
sw/qa/extras/ooxmlexport/ooxmlexport18.cxx| 15 +++
3 files changed, 20 insertions(+), 1 deletion(-)
New commits:
commit dc62b698f7a57b244dc80e0b607922505af233e9
Author: Jan Holesovsky
AuthorDate: Thu Nov 24 11:22:49 2022 +0100
Commit: Miklos Vajna
CommitDate: Fri Nov 25 10:50:58 2022 +0100
tdf#152199: Don't crop twice
We have a "GraphicCrop" property that is supposed to roundtrip the
cropping in OOXML, but there is no core feature backing it (ie. the
image is not shown cropped when this is imported and set).
Instead, to show the image "cropped", we crop the image physically on
import (throw away pixels that are 'outside' of the cropped area).
But - the "GraphicCrop" is then saved on export, together with the image
already physically cropped, which leads to garbled DOCX on re-import.
Given that the core feature to show image cropped when the "GraphicCrop"
is set, let's avoid setting it when we physically crop the image.
Change-Id: Ia1090ea9c6d22e60c77d52bf65281f6588d07d4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143214
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Miklos Vajna
diff --git a/oox/source/drawingml/fillproperties.cxx
b/oox/source/drawingml/fillproperties.cxx
index 3fb6b4ca372e..80ba3ba7664d 100644
--- a/oox/source/drawingml/fillproperties.cxx
+++ b/oox/source/drawingml/fillproperties.cxx
@@ -818,7 +818,6 @@ void FillProperties::pushToPropMap( ShapePropertyMap&
rPropMap,
aGraphCrop.Right = static_cast< sal_Int32 >( (
static_cast< double >( aOriginalSize.Width ) * aFillRect.X2 ) / 10 );
if ( aFillRect.Y2 )
aGraphCrop.Bottom = static_cast< sal_Int32 >(
( static_cast< double >( aOriginalSize.Height ) * aFillRect.Y2 ) / 10 );
-rPropMap.setProperty(PROP_GraphicCrop, aGraphCrop);
bool bHasCropValues = aGraphCrop.Left != 0 ||
aGraphCrop.Right !=0 || aGraphCrop.Top != 0 || aGraphCrop.Bottom != 0;
// Negative GraphicCrop values means "crop" here.
@@ -826,12 +825,17 @@ void FillProperties::pushToPropMap( ShapePropertyMap&
rPropMap,
if(bIsCustomShape && bHasCropValues && bNeedCrop)
{
+// Physically crop the image
+// In this case, don't set the
PROP_GraphicCrop because that
+// would lead to applying the crop twice after
roundtrip
xGraphic = lclCropGraphic(xGraphic,
CropQuotientsFromFillRect(aFillRect));
if
(rPropMap.supportsProperty(ShapeProperty::FillBitmapName))
rPropMap.setProperty(ShapeProperty::FillBitmapName, xGraphic);
else
rPropMap.setProperty(ShapeProperty::FillBitmap, xGraphic);
}
+else
+rPropMap.setProperty(PROP_GraphicCrop,
aGraphCrop);
}
}
}
diff --git a/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
b/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
new file mode 100644
index ..6db60d0e8c60
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
b/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
index bc48cc158975..2d5cca60eb27 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,20 @@ CPPUNIT_TEST_FIXTURE(Test, testSdtDuplicatedId)
assertXPath(pXmlDoc, "//w:sdt", 2);
}
+CPPUNIT_TEST_FIXTURE(Test, testImageCropping)
+{
+loadAndReload("crop-roundtrip.docx");
+
+// the image has no cropping after roundtrip, because it has been
physically cropped
+// NB: this test should be fixed when the core feature to show image
cropped when it
+// has the "GraphicCrop" is set is implemented
+auto aGraphicCropStruct = getProperty(getShape(1),
"GraphicCrop");
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Left);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Right);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Top);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Bottom);
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
[Libreoffice-commits] core.git: Branch 'libreoffice-7-4' - oox/source sw/qa
oox/source/drawingml/fillproperties.cxx |6 +-
sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx |binary
sw/qa/extras/ooxmlexport/ooxmlexport18.cxx| 15 +++
3 files changed, 20 insertions(+), 1 deletion(-)
New commits:
commit 96accaabebc2685a55323f939c432ce8e8c60f34
Author: Jan Holesovsky
AuthorDate: Thu Nov 24 11:22:49 2022 +0100
Commit: Xisco Fauli
CommitDate: Fri Nov 25 10:48:11 2022 +0100
tdf#152199: Don't crop twice
We have a "GraphicCrop" property that is supposed to roundtrip the
cropping in OOXML, but there is no core feature backing it (ie. the
image is not shown cropped when this is imported and set).
Instead, to show the image "cropped", we crop the image physically on
import (throw away pixels that are 'outside' of the cropped area).
But - the "GraphicCrop" is then saved on export, together with the image
already physically cropped, which leads to garbled DOCX on re-import.
Given that the core feature to show image cropped when the "GraphicCrop"
is set, let's avoid setting it when we physically crop the image.
Change-Id: Ia1090ea9c6d22e60c77d52bf65281f6588d07d4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143216
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
Signed-off-by: Xisco Fauli
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143251
diff --git a/oox/source/drawingml/fillproperties.cxx
b/oox/source/drawingml/fillproperties.cxx
index 3b540ba1de29..144c67fa5caf 100644
--- a/oox/source/drawingml/fillproperties.cxx
+++ b/oox/source/drawingml/fillproperties.cxx
@@ -853,7 +853,6 @@ void FillProperties::pushToPropMap( ShapePropertyMap&
rPropMap,
aGraphCrop.Right = static_cast< sal_Int32 >( (
static_cast< double >( aOriginalSize.Width ) * aFillRect.X2 ) / 10 );
if ( aFillRect.Y2 )
aGraphCrop.Bottom = static_cast< sal_Int32 >(
( static_cast< double >( aOriginalSize.Height ) * aFillRect.Y2 ) / 10 );
-rPropMap.setProperty(PROP_GraphicCrop, aGraphCrop);
bool bHasCropValues = aGraphCrop.Left != 0 ||
aGraphCrop.Right !=0 || aGraphCrop.Top != 0 || aGraphCrop.Bottom != 0;
// Negative GraphicCrop values means "crop" here.
@@ -861,12 +860,17 @@ void FillProperties::pushToPropMap( ShapePropertyMap&
rPropMap,
if(bIsCustomShape && bHasCropValues && bNeedCrop)
{
+// Physically crop the image
+// In this case, don't set the
PROP_GraphicCrop because that
+// would lead to applying the crop twice after
roundtrip
xGraphic = lclCropGraphic(xGraphic,
CropQuotientsFromFillRect(aFillRect));
if
(rPropMap.supportsProperty(ShapeProperty::FillBitmapName))
rPropMap.setProperty(ShapeProperty::FillBitmapName, xGraphic);
else
rPropMap.setProperty(ShapeProperty::FillBitmap, xGraphic);
}
+else
+rPropMap.setProperty(PROP_GraphicCrop,
aGraphCrop);
}
}
}
diff --git a/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
b/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
new file mode 100644
index ..6db60d0e8c60
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
b/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
index e1e515f99e57..dc9429c20cbe 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -101,6 +102,20 @@ CPPUNIT_TEST_FIXTURE(Test, testTdf150966_regularInset)
assertXPathAttrs(pXmlDoc, "//wps:bodyPr", { { "tIns", "179640" }, {
"bIns", "36" } });
}
+CPPUNIT_TEST_FIXTURE(Test, testImageCropping)
+{
+loadAndReload("crop-roundtrip.docx");
+
+// the image has no cropping after roundtrip, because it has been
physically cropped
+// NB: this test should be fixed when the core feature to show image
cropped when it
+// has the "GraphicCrop" is set is implemented
+auto aGraphicCropStruct = getProperty(getShape(1),
"GraphicCrop");
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Left);
+CPPUNIT_ASSERT_EQUAL(s
[Libreoffice-commits] core.git: oox/source sw/qa
oox/source/drawingml/fillproperties.cxx |6 +-
sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx |binary
sw/qa/extras/ooxmlexport/ooxmlexport18.cxx| 15 +++
3 files changed, 20 insertions(+), 1 deletion(-)
New commits:
commit ab080ab1ab3100d9702a745287566b78b8d59e54
Author: Jan Holesovsky
AuthorDate: Thu Nov 24 11:22:49 2022 +0100
Commit: Jan Holesovsky
CommitDate: Thu Nov 24 21:58:46 2022 +0100
tdf#152199: Don't crop twice
We have a "GraphicCrop" property that is supposed to roundtrip the
cropping in OOXML, but there is no core feature backing it (ie. the
image is not shown cropped when this is imported and set).
Instead, to show the image "cropped", we crop the image physically on
import (throw away pixels that are 'outside' of the cropped area).
But - the "GraphicCrop" is then saved on export, together with the image
already physically cropped, which leads to garbled DOCX on re-import.
Given that the core feature to show image cropped when the "GraphicCrop"
is set, let's avoid setting it when we physically crop the image.
Change-Id: Ia1090ea9c6d22e60c77d52bf65281f6588d07d4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143216
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
diff --git a/oox/source/drawingml/fillproperties.cxx
b/oox/source/drawingml/fillproperties.cxx
index 75da3836b6f5..329d5d3bb4b1 100644
--- a/oox/source/drawingml/fillproperties.cxx
+++ b/oox/source/drawingml/fillproperties.cxx
@@ -853,7 +853,6 @@ void FillProperties::pushToPropMap( ShapePropertyMap&
rPropMap,
aGraphCrop.Right = static_cast< sal_Int32 >( (
static_cast< double >( aOriginalSize.Width ) * aFillRect.X2 ) / 10 );
if ( aFillRect.Y2 )
aGraphCrop.Bottom = static_cast< sal_Int32 >(
( static_cast< double >( aOriginalSize.Height ) * aFillRect.Y2 ) / 10 );
-rPropMap.setProperty(PROP_GraphicCrop, aGraphCrop);
bool bHasCropValues = aGraphCrop.Left != 0 ||
aGraphCrop.Right !=0 || aGraphCrop.Top != 0 || aGraphCrop.Bottom != 0;
// Negative GraphicCrop values means "crop" here.
@@ -861,12 +860,17 @@ void FillProperties::pushToPropMap( ShapePropertyMap&
rPropMap,
if(bIsCustomShape && bHasCropValues && bNeedCrop)
{
+// Physically crop the image
+// In this case, don't set the
PROP_GraphicCrop because that
+// would lead to applying the crop twice after
roundtrip
xGraphic = lclCropGraphic(xGraphic,
CropQuotientsFromFillRect(aFillRect));
if
(rPropMap.supportsProperty(ShapeProperty::FillBitmapName))
rPropMap.setProperty(ShapeProperty::FillBitmapName, xGraphic);
else
rPropMap.setProperty(ShapeProperty::FillBitmap, xGraphic);
}
+else
+rPropMap.setProperty(PROP_GraphicCrop,
aGraphCrop);
}
}
}
diff --git a/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
b/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
new file mode 100644
index ..6db60d0e8c60
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/crop-roundtrip.docx
differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
b/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
index 71d28b313d2a..04c775fa8fcb 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -172,6 +173,20 @@ CPPUNIT_TEST_FIXTURE(Test, testSdtDuplicatedId)
assertXPath(pXmlDoc, "//w:sdt", 2);
}
+CPPUNIT_TEST_FIXTURE(Test, testImageCropping)
+{
+loadAndReload("crop-roundtrip.docx");
+
+// the image has no cropping after roundtrip, because it has been
physically cropped
+// NB: this test should be fixed when the core feature to show image
cropped when it
+// has the "GraphicCrop" is set is implemented
+auto aGraphicCropStruct = getProperty(getShape(1),
"GraphicCrop");
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Left);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Right);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Top);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(0), aGraphicCropStruct.Bottom);
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
[Libreoffice-commits] core.git: configure.ac
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit e50cffea75456551382445c28fdd4cabd9c2e81b
Author: Jan Holesovsky
AuthorDate: Wed Nov 9 12:23:25 2022 +0100
Commit: Jan Holesovsky
CommitDate: Wed Nov 9 13:17:52 2022 +0100
Clarify the cairo warning in ./configure
To know what to expect.
Change-Id: Ia660a1ebdbb76c04aa96934cabc16e1cbfc4cfd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142478
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
diff --git a/configure.ac b/configure.ac
index 0fa69d60a292..08c2ac634b71 100644
--- a/configure.ac
+++ b/configure.ac
@@ -11774,7 +11774,7 @@ GTK3_LIBS=""
ENABLE_GTKTILEDVIEWER=""
if test "$test_gtk3" = yes -a "x$enable_gtk3" = "xyes" -o "x$enable_gtk3_kde5"
= "xyes"; then
if test "$with_system_cairo" = no; then
-add_warning 'Non-system cairo combined with gtk3 is assumed to cause
trouble; proceed at your own risk.'
+add_warning 'Non-system cairo combined with gtk3 is known to cause
trouble (eg. broken image in the splashscreen). Use --with-system-cairo unless
you know what you are doing.'
fi
: ${with_system_cairo:=yes}
PKG_CHECK_MODULES(GTK3, gtk+-3.0 >= 3.20 gtk+-unix-print-3.0
gmodule-no-export-2.0 glib-2.0 >= 2.38 atk >= 2.28.1 cairo)
End-thread
Hi Amit, I'm sorry you feel that way. Either way, this mailing list is for technical discussions, so please let's end this thread now, before people start offending each other even more. If you reconsider your position, happy to review your patches of course. All the best, Kendy A píše v St 09. 11. 2022 v 15:57 +0530: > > Don't tell me where to contribute. I will decide that myself. > > My patches are there in linux kernel. I am happy contributing to > linux kernel. > > As long as MS Office is in existence, libreoffice will be considered > a failure. > > I didn't hate libreoffice earlier but now I hate libreoffice because > of egoist people like you. > > Amit > > > On Wed, Nov 9, 2022, 3:49 PM Tor Lillqvist wrote: > > Dear Amit, I suggest you contribute to Apache OpenOffice instead. > > They > > are a much more welcoming bunch, and you will share the hate of > > LibreOffice! They are eager to welcome new contributors. > > > > --tml
[Libreoffice-commits] core.git: Branch 'distro/collabora/co-22.05' - sc/source
sc/source/ui/view/gridwin.cxx | 61 +-
1 file changed, 2 insertions(+), 59 deletions(-)
New commits:
commit 657ddc1a8631418f39f587e448954ec47996cf75
Author: Jan Holesovsky
AuthorDate: Mon Oct 24 16:27:17 2022 +0200
Commit: Gülşah Köse
CommitDate: Tue Nov 8 16:04:45 2022 +0100
sc lok: Double-click should behave more like on desktop
When editing was introduced in Calc LibreOfficeKit, there were lots of
limitations. Particularly the thinking was that it would be good if a
double-click into any text (even if spanning over more cells)
actually started editing that text.
These days, the LOK behaves much more consistently, so it is better to
behave as the LibreOffice on desktop (or other tools, like gdocs) do:
If the cell:
* Is empty
-> single click places the cell cursor
-> double click places the cell cursor & shows the text caret
* Is empty, but covered by text bleeding from other cell
-> same as if it was empty
* Isn't empty
-> single click places the cell cursor
-> double click places the cell cursor & places the text caret
inside the text where the user clicked
+ this is actually different in gdocs - there the caret is
placed at the end of the text; in LO it is where the user has
double-clicked
Change-Id: Ib5884f887c98f803b06d8bed5057ec435be480ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141772
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Gülşah Köse
diff --git a/sc/source/ui/view/gridwin.cxx b/sc/source/ui/view/gridwin.cxx
index 32573c92b8a2..93522adc4bdb 100644
--- a/sc/source/ui/view/gridwin.cxx
+++ b/sc/source/ui/view/gridwin.cxx
@@ -1809,49 +1809,6 @@ void ScGridWindow::HandleMouseButtonDown( const
MouseEvent& rMEvt, MouseEventSta
if ( !nButtonDown || !bDouble ) // single (first) click is
always valid
nButtonDown = rMEvt.GetButtons(); // set nButtonDown first, so
StopMarking works
-// special handling of empty cells with tiled rendering
-if (bIsTiledRendering)
-{
-Point aPos(rMEvt.GetPosPixel());
-SCCOL nPosX, nNonEmptyX(0);
-SCROW nPosY;
-SCTAB nTab = mrViewData.GetTabNo();
-mrViewData.GetPosFromPixel(aPos.X(), aPos.Y(), eWhich, nPosX, nPosY);
-
-ScRefCellValue aCell(rDoc, ScAddress(nPosX, nPosY, nTab));
-bool bIsEmpty = aCell.isEmpty();
-bool bIsCoveredByText = bIsEmpty && IsCellCoveredByText(nPosX, nPosY,
nTab, nNonEmptyX);
-
-if (bIsCoveredByText)
-{
-// if there's any text flowing to this cell, activate the
-// editengine, so that the text actually gets the events
-if (bDouble)
-{
-ScViewFunc* pView = mrViewData.GetView();
-
-pView->SetCursor(nNonEmptyX, nPosY);
-SC_MOD()->SetInputMode(SC_INPUT_TABLE);
-
-bEditMode = mrViewData.HasEditView(eWhich);
-assert(bEditMode);
-
-// synthesize the 1st click
-EditView* pEditView = mrViewData.GetEditView(eWhich);
-MouseEvent aEditEvt(rMEvt.GetPosPixel(), 1,
MouseEventModifiers::SYNTHETIC, MOUSE_LEFT, 0);
-pEditView->MouseButtonDown(aEditEvt);
-pEditView->MouseButtonUp(aEditEvt);
-}
-}
-else if (bIsEmpty && bEditMode && bDouble)
-{
-// double-click in an empty cell: the entire cell is selected
-SetCellSelectionPixel(LOK_SETTEXTSELECTION_START, aPos.X(),
aPos.Y());
-SetCellSelectionPixel(LOK_SETTEXTSELECTION_END, aPos.X(),
aPos.Y());
-return;
-}
-}
-
if ( ( bEditMode && mrViewData.GetActivePart() == eWhich ) ||
!bFormulaMode )
GrabFocus();
@@ -2382,14 +2339,11 @@ void ScGridWindow::MouseButtonUp( const MouseEvent&
rMEvt )
mrViewData.GetPosFromPixel( aPos.X(), aPos.Y(), eWhich, nPosX, nPosY );
ScDPObject* pDPObj = rDoc.GetDPAtCursor( nPosX, nPosY, nTab );
-bool bInDataPilotTable = (pDPObj != nullptr);
-
// double click (only left button)
-// in the tiled rendering case, single click works this way too
bool bIsTiledRendering = comphelper::LibreOfficeKit::isActive();
bool bDouble = ( rMEvt.GetClicks() == 2 && rMEvt.IsLeft() );
-if ((bDouble || (bIsTiledRendering && !bInDataPilotTable))
+if ( bDouble
&& !bRefMode
&& (nMouseStatus == SC_GM_DBLDOWN || (bIsTiledRendering &&
nMouseStatus != SC_GM_URLDOWN))
&& !pScMod->IsRefDialogOpen())
@@ -2449,19 +2403,8 @@ void ScGridWindow::MouseButtonUp( const MouseEvent&
rMEvt )
[board-discuss] Resigning from the Membership and from the Board of Directors
Hi all, Over the last ten months in the Board of Directors, I have been trying to achieve two things: Get a *balanced* proposal how to hire and manage TDF in-house developers, and to contract Weblate developers to improve Weblate for our l10n community needs. The latter seemed simple - there was a huge support for improving Weblate inside the Board, we've got an offer from the Weblate people, and yet, there is no contract signed ten months later. I have high hopes that it will happen at some stage, but now it is becoming obvious that there is very little chance that the actual work will start until the end of the year. The former was a tough nut to crack obviously; there were many views how to do that, but that is fine - I am used to work with people who see things differently, always happy to present my ideas, and work towards a compromise. What I am much less happy about is when people start accusing me that I'm doing everything "because of commercial interests" - which is not true; all I want is a fun, successful Free Software / Open Source community that is equally pleasant for all the contributors: volunteer, commercial, and TDF in-house. It has come to the point when I am sick and tired of all the accusations and passive aggression against me and others. It has just become folklore in this community: "when you don't agree with somebody, accuse them that they do that because of commercial interests". In other words, TDF has moved from a meritocracy (where the doers decide) to some kind of "shouting-ocracy" (where the vigorous shouters decide). I was always trying to be calm even in heated debates (both public and those inside the Board). I worked with many of you since the 2003 [*] so I hope many contributors here can confirm I am a very patient and open-minded person. Unfortunately, the toxicity of the questioning of motivations of me and other long-time community members has exhausted my emotional energy, and I cannot stand that any more. I resign from the Membership (Board of Trustees), and consequently I also resign from the Board of Directors. I'll be still around contributing to the LibreOffice code (which I still love), and I'm still excited to talk code, l10n, documentation (ie. areas to which I've contributed over the years) with everyone, but I don't care about the TDF's governance and its politics any more. I hope that things will change for the better, and I'll be willing to become a Member again, but for the moment, I cannot see it happening. All the best, Kendy [*] I started contributing to the code as a volunteer, and I am extremely grateful that initially SUSE and later Collabora decided to sponsor me. But even with that, I've always been contributing on top of my paid time. In the code, my areas were eg. the KDE integration, 64bit porting, or interoperability. Outside of the code, I've worked with many of you when I've helped forming the UX team in LibreOffice, were translating to Czech, or when I've created the web-based LibreOffice help. I was one of the Founding Members of LibreOffice, and mentored a lot of newcomers who joined the freshly born project; and also many GSoC students later. -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[Libreoffice-commits] core.git: sc/source
sc/source/ui/view/gridwin.cxx | 61 +-
1 file changed, 2 insertions(+), 59 deletions(-)
New commits:
commit 142d3e15916afd1c38bcccf0d23cac292ea357fc
Author: Jan Holesovsky
AuthorDate: Mon Oct 24 16:27:17 2022 +0200
Commit: Jan Holesovsky
CommitDate: Thu Nov 3 21:52:40 2022 +0100
sc lok: Double-click should behave more like on desktop
When editing was introduced in Calc LibreOfficeKit, there were lots of
limitations. Particularly the thinking was that it would be good if a
double-click into any text (even if spanning over more cells)
actually started editing that text.
These days, the LOK behaves much more consistently, so it is better to
behave as the LibreOffice on desktop (or other tools, like gdocs) do:
If the cell:
* Is empty
-> single click places the cell cursor
-> double click places the cell cursor & shows the text caret
* Is empty, but covered by text bleeding from other cell
-> same as if it was empty
* Isn't empty
-> single click places the cell cursor
-> double click places the cell cursor & places the text caret
inside the text where the user clicked
+ this is actually different in gdocs - there the caret is
placed at the end of the text; in LO it is where the user has
double-clicked
Change-Id: Ib5884f887c98f803b06d8bed5057ec435be480ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142196
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
diff --git a/sc/source/ui/view/gridwin.cxx b/sc/source/ui/view/gridwin.cxx
index 69a1daf6f9ce..1ae16dd962aa 100644
--- a/sc/source/ui/view/gridwin.cxx
+++ b/sc/source/ui/view/gridwin.cxx
@@ -1833,49 +1833,6 @@ void ScGridWindow::HandleMouseButtonDown( const
MouseEvent& rMEvt, MouseEventSta
if ( !nButtonDown || !bDouble ) // single (first) click is
always valid
nButtonDown = rMEvt.GetButtons(); // set nButtonDown first, so
StopMarking works
-// special handling of empty cells with tiled rendering
-if (bIsTiledRendering)
-{
-Point aPos(rMEvt.GetPosPixel());
-SCCOL nPosX, nNonEmptyX(0);
-SCROW nPosY;
-SCTAB nTab = mrViewData.GetTabNo();
-mrViewData.GetPosFromPixel(aPos.X(), aPos.Y(), eWhich, nPosX, nPosY);
-
-ScRefCellValue aCell(rDoc, ScAddress(nPosX, nPosY, nTab));
-bool bIsEmpty = aCell.isEmpty();
-bool bIsCoveredByText = bIsEmpty && IsCellCoveredByText(nPosX, nPosY,
nTab, nNonEmptyX);
-
-if (bIsCoveredByText)
-{
-// if there's any text flowing to this cell, activate the
-// editengine, so that the text actually gets the events
-if (bDouble)
-{
-ScViewFunc* pView = mrViewData.GetView();
-
-pView->SetCursor(nNonEmptyX, nPosY);
-SC_MOD()->SetInputMode(SC_INPUT_TABLE);
-
-bEditMode = mrViewData.HasEditView(eWhich);
-assert(bEditMode);
-
-// synthesize the 1st click
-EditView* pEditView = mrViewData.GetEditView(eWhich);
-MouseEvent aEditEvt(rMEvt.GetPosPixel(), 1,
MouseEventModifiers::SYNTHETIC, MOUSE_LEFT, 0);
-pEditView->MouseButtonDown(aEditEvt);
-pEditView->MouseButtonUp(aEditEvt);
-}
-}
-else if (bIsEmpty && bEditMode && bDouble)
-{
-// double-click in an empty cell: the entire cell is selected
-SetCellSelectionPixel(LOK_SETTEXTSELECTION_START, aPos.X(),
aPos.Y());
-SetCellSelectionPixel(LOK_SETTEXTSELECTION_END, aPos.X(),
aPos.Y());
-return;
-}
-}
-
if ( ( bEditMode && mrViewData.GetActivePart() == eWhich ) ||
!bFormulaMode )
GrabFocus();
@@ -2406,14 +2363,11 @@ void ScGridWindow::MouseButtonUp( const MouseEvent&
rMEvt )
mrViewData.GetPosFromPixel( aPos.X(), aPos.Y(), eWhich, nPosX, nPosY );
ScDPObject* pDPObj = rDoc.GetDPAtCursor( nPosX, nPosY, nTab );
-bool bInDataPilotTable = (pDPObj != nullptr);
-
// double click (only left button)
-// in the tiled rendering case, single click works this way too
bool bIsTiledRendering = comphelper::LibreOfficeKit::isActive();
bool bDouble = ( rMEvt.GetClicks() == 2 && rMEvt.IsLeft() );
-if ((bDouble || (bIsTiledRendering && !bInDataPilotTable))
+if ( bDouble
&& !bRefMode
&& (nMouseStatus == SC_GM_DBLDOWN || (bIsTiledRendering &&
nMouseStatus != SC_GM_URLDOWN))
&& !pScMod->IsRefDialogOpen())
@@ -2473,19 +2427,8 @@ void ScGridWindow::MouseButtonUp( const MouseEvent&
rMEvt )
Re: [board-discuss] Board of Directors Meeting 2022-09-05
Hi Paolo, Paolo Vecchi píše v So 10. 09. 2022 v 15:45 +0200: > > I am happy to share the folder (read-only) to the general public > > too, > > but I'd like to have Paolo's OK before I do - Paolo, is it OK for > > you? > > I'm totally fine with sharing the folder to all so that they can see > how it changed over time. Thank you, it can be seen here: https://nextcloud.documentfoundation.org/s/zfoRygFbBgJZZcj > I've uploaded version 2.8 with some comments. > > I've accepted several changes even if don't satisfy me fully but a > decent compromise today is better than nothing at all. > > It took a very long time to get here so I hope that the long > discussions haven't put off potential candidates. > > I believe this version (2.8) should now be sent to our legal counsel > for verification and the result should be voted on. > > Would you agree? I've added answers to your comments as: TDF-In-House-Developers-Proposal-v2-8-Merged-answers.odt For many of them, it is just an "OK, accepted"; just few bits around the ESC are controversial or even not acceptable for me - but I've outlined those already in the call on Monday. Can you please have a look? Thank you in advance! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [NO DECISION] TDF to change composition of legal oversight group
Hi Paolo, No comment. We have a Board meeting later today, and I believe it is better to resolve things like this in a call or in person. All the best, Kendy Paolo Vecchi píše v Čt 15. 09. 2022 v 12:20 +0200: > Hi Jan, > > On 15/09/2022 11:41, Jan Holesovsky wrote: > > Hi Paolo, > > > > Paolo Vecchi píše v Čt 15. 09. 2022 v 11:27 +0200: > > > > > Andreas' email is polite > > I am sorry, but "It shows that there is no will of cooperation from > > five members of the board." does not sound polite to me. > > That comment might seems to be pushing a bit the boundaries of > politeness but it's probably reflecting the impression that the > inaction > by some members of the board sends out to the public. > > > I have a lot of will to cooperate with everyone, including people I > > don't agree with, so a statement like this is very offensive to me. > > I'm sure you would be due an apology if you wrote that you would > have > participated but urgent matters didn't allow you to vote for 3 days > and > what Andreas said hurt your feelings but have any of the directors > not > participating to the vote evaluated if they were going to hurt the > feelings of those that proposed the vote? > > The vote has been discussed internally, before re-running it due to > Caolan's departure from the board, good reasons to perform this > change > have been documented and "the conditions that brought to it are > persisting". > > So of course what happened hurts the feelings of the 2 directors, > doing > a lot of hard work in the legal group, to see that other directors > did > not comment, explicitly abstained or even voted against it maybe > providing legitimate reasons for doing so. > > > All the best, > > Kendy > > > Ciao > > Paolo > > -- > Paolo Vecchi - Member of the Board of Directors > The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE > Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts > Legal details: https://www.documentfoundation.org/imprint > -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [NO DECISION] TDF to change composition of legal oversight group
Hi Paolo, Paolo Vecchi píše v Čt 15. 09. 2022 v 11:27 +0200: > Andreas' email is polite I am sorry, but "It shows that there is no will of cooperation from five members of the board." does not sound polite to me. I have a lot of will to cooperate with everyone, including people I don't agree with, so a statement like this is very offensive to me. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Board of Directors Meeting 2022-09-05
Hi Andreas, Andreas Mantke píše v Pá 09. 09. 2022 v 16:50 +0200: > Thus it would be great, if you could make the current state of the > documents (maybe with the changes done) available for the interested > community. It is still all developing in the same folder as before, available for all the TDF members: https://nextcloud.documentfoundation.org/apps/files/?dir=/Developers It contains all the versions since 2.0, and most of them have change tracking turned on. I am happy to share the folder (read-only) to the general public too, but I'd like to have Paolo's OK before I do - Paolo, is it OK for you? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Board of Directors Meeting 2022-09-05
Hi Andreas, Andreas Mantke píše v Čt 08. 09. 2022 v 21:01 +0200: > > * Anything closer to be voted on? (Thorsten) > > * another round of editing document (Kendy) > > * closer to be voted on > > * it's in shared folder > > * another round of edits on his documents > > * Paolo made last edits on Friday, will look into it soon > > * glad to hear, re-added some comments to latest version (Paolo) > > * no massive rush right now, been in the making for a while > > (Thorsten) > > AI: add to agenda of next board call > > Folder with developers proposal (under Shared/Developers) > > Latest version 2.6 - Comments in version 2.5-With-Comments > > https://nextcloud.documentfoundation.org/f/960049 > > > looks like I learned another sort of management strategies: > > management by continuous postponement I am not sure what do you mean; we are working hard with Paolo on the document to minimize areas that are mutually unacceptable, and I am pleased to see that the amount of problematic points is decreasing with every version. If you compare the document in the current state with my or Paolo's first version, you will see the huge amount of work we have both put into this. I am also extremely pleased that we are both able to work on one shared ODT document together. As to the current state, I cannot speak for Paolo (so Paolo, please correct me if I'm wrong), but from my point of view it is now clear that: 1. We both agree TDF should hire developers. I've moved on from my "more development mentors instead of developers, please" position long ago; I think it was even documented on this ML. 2. We both agree that the Board has the ultimate deciding power. 3. We have accepted and/or removed many problematic parts (ranging from words to full paragraphs) all over the document. 4. We are still finding middle-ground for the role of ESC. (For example, the idea that TDF in-house developers wouldn't be bound by ESC rules and decisions the same way as volunteer and/or corporate contributors is not acceptable for me, and so far I am unfortunately failing to come up with formulation that is acceptable for Paolo.) 5. We are still finding middle-ground for some details around knowledge sharing/mentoring in areas where the in-house developers become experts. (But I think in this area, we are much closer to a conclusion, compared to 4.) I've spent many hours answering the comments in the 2.5-With-Comments today, and I'm finalizing the 2.7 that will be hopefully again one more step closer to being acceptable by both of us; but unfortunately it is too late to upload it now - hope to do it tomorrow early. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Agenda for TDF board meeting on Monday, August 8th at 1800 Berlin time (UTC+2)
Hi Stephan, all, Stephan Ficht píše v Pá 05. 08. 2022 v 11:11 +0200: > TDF board meeting with a public part, and followed by a private part > on Monday, August 08 at 1800 Berlin time at > https://jitsi.documentfoundation.org/TDFBoard I am sorry, most likely I cannot make it to the meeting on Monday. If I'm not around, the standard representation applies. > 3. Vote, Discuss: Merged developer proposal (tdf-board, Jan > Holesovsky, 10 mins) > > * should the merged proposal be ready > * have a last round of discussion > * if conclusive - vote & budget for it Unfortunately no progress on this since the last report from my side, so it is not ready for a vote yet. All the best, Kendy -- Jan Holešovský, Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[Libreoffice-qa] ESC meeting minutes: 2022-07-28
* Present: + Kendy, Heiko, Hossein, Caolán, Ilmari, Michael W., Cloph, Michael S., Xisco, Tomaž, Olivier, * Completed Action Items: + enable commit access for Hannah (Cloph) * Pending Action Items: * Release Engineering update (Cloph) + 7.4 status + 7.4 RC2 this week? + has been tagged yesterday + hard code freeze now + 2 additional reviews needed + builds to be available tomorrow evening on the mirrors + additional buildfix needed for aarch64 windows build https://gerrit.libreoffice.org/c/core/+/137568 + no need to re-spin + RC3 to be in 2 weeks (week 32) + 7.3 status: 7.3.6 rc1 in 3 weeks? + week 33 + Appstores + filed the tax forms for MS app store + finalizing the listing, eg. the pricing * Documentation (Olivier) + New Help + No news + Helpcontents2 + SourceForge Help page (R. Lima) + Updates in master password (Caolán) + Guides + Stalled - vacation time :-) + Bugzilla Documentation statistics 239(239) bugs open + Updates: BZ changes 1 week 1 month 3 months 12 months created 3(2) 33(-9) 96(-2) 331(1) commented 5(4) 60(-12) 291(-10) 1463(3) resolved 1(1) 16(-3) 43(0) 209(1) + top 10 contributors: Olivier Hallot made 23 changes in 1 month, and 463 changes in 1 year Seth Chaiklin made 20 changes in 1 month, and 330 changes in 1 year Kaganski, Mike made 12 changes in 1 month, and 96 changes in 1 year Rafael Lima made 11 changes in 1 month, and 313 changes in 1 year Adolfo Jayme Barrientos made 9 changes in 1 month, and 24 changes in 1 year Nabet, Julien made 9 changes in 1 month, and 89 changes in 1 year Alain Romedenne made 6 changes in 1 month, and 38 changes in 1 year Németh, László made 6 changes in 1 month, and 12 changes in 1 year Ezinne Nnamani made 6 changes in 1 month, and 6 changes in 1 year Timur made 6 changes in 1 month, and 28 changes in 1 year * UX Update (Heiko) + was on vacation & in the in-person meetings; not much to report + but people working on the new icon themes + looking forward to that + Bugzilla (topicUI) statistics 271(271) (topicUI) bugs open, 61(61) (needsUXEval) needs to be evaluated by the UXteam + Updates: BZ changes 1 week 1 month 3 months 12 months added 7(4) 15(7) 18(5) 44(6) commented 46(17) 144(39) 509(-20) 2237(-14) removed 0(0) 1(0) 3(-3) 29(0) resolved 4(1) 19(-2)63(-6) 324(1) + top 10 contributors: Heiko Tietze made 79 changes in 1 month, and 1543 changes in 1 year Timur made 31 changes in 1 month, and 75 changes in 1 year Rafael Lima made 23 changes in 1 month, and 95 changes in 1 year Roman Kuznetsov made 21 changes in 1 month, and 202 changes in 1 year Telesto made 18 changes in 1 month, and 183 changes in 1 year Bielefeld, Rainer made 13 changes in 1 month, and 19 changes in 1 year Hossein made 12 changes in 1 month, and 38 changes in 1 year m.a.riosv made 9 changes in 1 month, and 9 changes in 1 year Pierre Fortin made 8 changes in 1 month, and 8 changes in 1 year Aron Budea made 7 changes in 1 month, and 24 changes in 1 year + bug 150182 - Pivot Table Filter is inaccessible from main menu, and its label in context menu doesn't distinguish it from e.g. Standard Filter + bug 150040 - Feature Request (Writer): Delete parts of an image after cutting + bug 150005 - Default Cell Borders thickness not customizable using the toolbar buttons + bug 149984 - Add sortable counts to AutoFilter drop down + bug 149944 - Base: Dialog for User Administration couldn't be resized - too small when translated to German to show all buttons * Crash Testing (Caolan) + 113(+32) import failure, 73(+27) export failures - one issue likely fixed in next run - fairly stable, the most offensive fixed recently + 2 coverity issues - opaque what code triggers this + 7 ossfuzz issues - one crash left + CVE's were announced * Crash Reporting (Xisco) + symbols were missing in 7.3.5 + resolved, Cloph uploaded yesterday + not much info from the latest version yet due to that + https://crashreport.libreoffice.org/stats/version/7.2.7.2 + (-4) 512 516 479 484 410 396 382 314 268 167 0 + https://crashreport.libreoffice.org/stats/version/7.3.3.2 + (-66) 701 767 878 1041 1063 1438 1797 1583 1417 1055 555 0 + https://crashreport.libreoffice.org/stats/version/7.3.4.2 + (+23) 1695 1672 1581 1128 963 675 0
ESC meeting minutes: 2022-07-28
* Present: + Kendy, Heiko, Hossein, Caolán, Ilmari, Michael W., Cloph, Michael S., Xisco, Tomaž, Olivier, * Completed Action Items: + enable commit access for Hannah (Cloph) * Pending Action Items: * Release Engineering update (Cloph) + 7.4 status + 7.4 RC2 this week? + has been tagged yesterday + hard code freeze now + 2 additional reviews needed + builds to be available tomorrow evening on the mirrors + additional buildfix needed for aarch64 windows build https://gerrit.libreoffice.org/c/core/+/137568 + no need to re-spin + RC3 to be in 2 weeks (week 32) + 7.3 status: 7.3.6 rc1 in 3 weeks? + week 33 + Appstores + filed the tax forms for MS app store + finalizing the listing, eg. the pricing * Documentation (Olivier) + New Help + No news + Helpcontents2 + SourceForge Help page (R. Lima) + Updates in master password (Caolán) + Guides + Stalled - vacation time :-) + Bugzilla Documentation statistics 239(239) bugs open + Updates: BZ changes 1 week 1 month 3 months 12 months created 3(2) 33(-9) 96(-2) 331(1) commented 5(4) 60(-12) 291(-10) 1463(3) resolved 1(1) 16(-3) 43(0) 209(1) + top 10 contributors: Olivier Hallot made 23 changes in 1 month, and 463 changes in 1 year Seth Chaiklin made 20 changes in 1 month, and 330 changes in 1 year Kaganski, Mike made 12 changes in 1 month, and 96 changes in 1 year Rafael Lima made 11 changes in 1 month, and 313 changes in 1 year Adolfo Jayme Barrientos made 9 changes in 1 month, and 24 changes in 1 year Nabet, Julien made 9 changes in 1 month, and 89 changes in 1 year Alain Romedenne made 6 changes in 1 month, and 38 changes in 1 year Németh, László made 6 changes in 1 month, and 12 changes in 1 year Ezinne Nnamani made 6 changes in 1 month, and 6 changes in 1 year Timur made 6 changes in 1 month, and 28 changes in 1 year * UX Update (Heiko) + was on vacation & in the in-person meetings; not much to report + but people working on the new icon themes + looking forward to that + Bugzilla (topicUI) statistics 271(271) (topicUI) bugs open, 61(61) (needsUXEval) needs to be evaluated by the UXteam + Updates: BZ changes 1 week 1 month 3 months 12 months added 7(4) 15(7) 18(5) 44(6) commented 46(17) 144(39) 509(-20) 2237(-14) removed 0(0) 1(0) 3(-3) 29(0) resolved 4(1) 19(-2)63(-6) 324(1) + top 10 contributors: Heiko Tietze made 79 changes in 1 month, and 1543 changes in 1 year Timur made 31 changes in 1 month, and 75 changes in 1 year Rafael Lima made 23 changes in 1 month, and 95 changes in 1 year Roman Kuznetsov made 21 changes in 1 month, and 202 changes in 1 year Telesto made 18 changes in 1 month, and 183 changes in 1 year Bielefeld, Rainer made 13 changes in 1 month, and 19 changes in 1 year Hossein made 12 changes in 1 month, and 38 changes in 1 year m.a.riosv made 9 changes in 1 month, and 9 changes in 1 year Pierre Fortin made 8 changes in 1 month, and 8 changes in 1 year Aron Budea made 7 changes in 1 month, and 24 changes in 1 year + bug 150182 - Pivot Table Filter is inaccessible from main menu, and its label in context menu doesn't distinguish it from e.g. Standard Filter + bug 150040 - Feature Request (Writer): Delete parts of an image after cutting + bug 150005 - Default Cell Borders thickness not customizable using the toolbar buttons + bug 149984 - Add sortable counts to AutoFilter drop down + bug 149944 - Base: Dialog for User Administration couldn't be resized - too small when translated to German to show all buttons * Crash Testing (Caolan) + 113(+32) import failure, 73(+27) export failures - one issue likely fixed in next run - fairly stable, the most offensive fixed recently + 2 coverity issues - opaque what code triggers this + 7 ossfuzz issues - one crash left + CVE's were announced * Crash Reporting (Xisco) + symbols were missing in 7.3.5 + resolved, Cloph uploaded yesterday + not much info from the latest version yet due to that + https://crashreport.libreoffice.org/stats/version/7.2.7.2 + (-4) 512 516 479 484 410 396 382 314 268 167 0 + https://crashreport.libreoffice.org/stats/version/7.3.3.2 + (-66) 701 767 878 1041 1063 1438 1797 1583 1417 1055 555 0 + https://crashreport.libreoffice.org/stats/version/7.3.4.2 + (+23) 1695 1672 1581 1128 963 675 0
Re: [board-discuss] Another "merged" proposal of in-house developers
Hi Paolo, Paolo Vecchi píše v Po 27. 06. 2022 v 17:58 +0200: > The differences are not that many apart from those that I could not > accept as they impose limitations that have no place in an > employment > proposal. > > In the document v. 2.3 you just merged back the issues that will > cause > TDF to incur more costs and issues in finding the developers we need > so > we should not accept those changes- Unfortunately I am not sure which are those, and on the other hand, I hope there are still parts that are acceptable for you in the new form - where I've included eg. your paragraphs that explicitly say that the developers don't have to be senior and don't have to mentor from the day one, etc. Can you please check the 2.3 once again, and merge those bits that are acceptable for you, and I'll see how can I rephrase the rest, so that we can finalize this, please? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Another "merged" proposal of in-house developers
Hi Paolo, all, Paolo Vecchi píše v St 22. 06. 2022 v 16:49 +0200: > as finally many of the changes requested by other proposals are clear > I've integrated what makes sense to have on a > developers recruitment proposal and added a few items clarifying > some aspect in version 2.2 (in ODF format) of this "merged" proposal > that you'll find here together with the other proposal: > > https://nextcloud.documentfoundation.org/f/960049 Thank you very much for that! I've once again rebased the changes on top of yours, but I see we are getting much closer; so in the TDF-In-House-Developers-Proposal-v2-3-Merged.odt I've accepted your changes where we both agree, to avoid confusion in change tracking, hope that's fine. Also it is good to see that we both agree that BoD has the ultimate deciding power; I think now it is mostly about finding the balance between the ESC and team, to make the conditions equal for all developers - internal, volunteer, or commercial. For those who don't have access to the TDF Nextcloud, here is a direct link: https://nextcloud.documentfoundation.org/s/pJLYLiH4m4HcjSN For those interested, I have also provided a change-tracked version of your document as TDF-In-House-Developers-Proposal-v2-2-Merged-Change-tracked.odt I am sorry I didn't find time yet to go through your below points one by one, happy to do that in a follow-up mail if needed. All the best, Kendy > What changed: > I've adapted a few sentences/words to get closer to the other > proposal where possible and eliminated some sentences/words > that might not add much to the context. > I've also reinstated the app store area as now is not controversial > anymore. > There is a specific paragraph stating that in-house developers are > not bound by ESC decisions. > > Overall the original logic is still there but showing a lower number > of differences to the other proposal. > > > What is still different: > The developers do not need to be senior or already capable of > mentoring, training them is part of our goals so we should do that > > The focus is clearly on the development side with mentoring to be > done when the developers are ready and willing > > There is less focus on the ESC handling the task and more on staff > dealing with it as developers are going to be part of TDF's staff so > they shouldn't be told what to do by non employees of TDF or the > Board. > > > What is not there: > The section related to "Targeted Developers" as it's a construct that > imposes limitations on what TDF's staff can do. We will employ in- > house developers that will work for the best interest of TDF and it's > wider community which initially will surely focus on specific areas, > the "Focus Areas", but over the years could cover other areas if they > like it and it's necessary. > > I believe that a candidate reading that an organisation is looking > for "targeted developers" might already feel the limitation of the > role and the lack of opportunities for personal growth so we might > prefer to welcome in-house developers that won't feel that > limitations as full members of TDF's staff. > > ESC deciding and having a final word on "overlaps in the development > of the LibreOffice code" is too broad as it might imply also > development related to projects, features or bug fixes on which a > third party might have interests expressed through the ESC which at > present has no CoI Policy. Limitations imposed on TDF's staff that > satisfy the interests/needs of third parties, or in some cases both > TDF and third parties, should be part of a separate agreement, not a > recruitment proposal. > > Other similar limitations, including non competition or development > of alternative implementation to (eg.) "Collabora Online, mdds, or > cppunit" have not been included in this version as they should be > covered by separate agreements which are independent to TDF's staff > recruitment. > > Contracts with subcontractors, trainers and specialists do not belong > in a recruitment proposal. Additional support or training will be > taken in consideration once we have evaluated the candidates and when > our mentors will inform us of what is necessary. > > Development contracts present in the other proposal will follow the > due tendering process. > > > I hope that the rationale for not including certain areas, terms and > limitations is clear to all in this "merged" proposal and that we can > proceed in finding great candidates to join our team as soon as > possible. > > Ciao > > Paolo > -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Work On Update LOOL (was Re: LOOL is about to be archived)
Hi Andreas, Andreas Mantke píše v So 25. 06. 2022 v 00:05 +0200: > FYI: I wrote a short blog post about my work. And for those who like > visuals, I added two ones. > > https://amantke.de/2022/06/25/work-on-revival-of-libreoffice-online/ Thank you for sharing that! Seeing the pictures, you have not only applied the security patches, but actually you took the entire Collabora Online and rebranded it as LibreOffice Online. You could have saved a lot of work, it was enough to configure Collabora Online with: ./configure --with-app-name="LibreOffice Online" \ --with-vendor="The Document Foundation" \ --with-info-url="https://www.libreoffice.org"; Now the question is - does TDF want to be in a business of rebranding other well behaving open source projects? And - when you find out that COOL / LOOL is just the editing bit, in other words, it does nothing without a file sync & sharing solution, will you rebrand eg. Nextcloud or ownCloud to "LibreOffice Cloud" next? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Collabora Productivity from AppStore - bug reports
Hi Alex, Adolfo, all, Thank you for the pointers to the bugreports! More inline: Alexander Thurgood píše v St 15. 06. 2022 v 10:26 +0200: > It is neither a question of overblowing or "paranoia", (thanks for > the > gratuitous comment by the way, in tdf#147130), but I raised the issue > as > to where bugs for Collabora should be reported when it was first > released via the AppStore and was told, multiple times, and no less > by > Michael Meeks himself, to report them in the LO BZ. Regardless of my hat & the issue at hand, I'd support using the LibreOffice bugzilla even for the downstream reports, because ultimately, the code will end up in the LibreOffice repository either way. The reason is that we (TDF hat) would like to have all the patches up- streamed, even the packaging related ones (under the distro- config/...). Piling the down-stream patches in their own bug reporting systems will only lead to problems long-term. To avoid the feel that the bugzilla is misused, I think it might be useful to create a categories for such bugs (where we don't have them yet) - so that the volunteers can decide if they want to spend their time on triaging such bug reports or not. But ultimately - the categorization is up to the QA team to decide. Xisco - what is your take please? > Seemingly, and without any other form of policy discussion, that has > now > changed. > > Where is the due process in that decision ? In general, when it seems that an existing code-related policy does not fit, the best way is to bring it to the ESC so that the pro's and con's can be properly discussed from the technical point of view. In case you think a decision is needed, it would be great to have you both joining the meeting on Thursday, so that we can talk this through. Either way - thank you so much Alex and Adolfo for your contributions, much appreciate that! & hope this is all just a misunderstanding. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Collabora Productivity from AppStore - bug reports
Hi Alex, Alexander Thurgood píše v Út 14. 06. 2022 v 09:52 +0200: > I have reported a number of bugs against Collabora Productivity in > the LibreOffice bugzilla over several years (basically since the > product was first released via the AppStore). > > I see now that my reports are being closed as NOTOURBUG, and being > told that I should report them to Collabora. I have no idea what is going on, can you please point me to some bugs where this is happening? Thank you in advance! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v Čt 09. 06. 2022 v 20:48 +0200: > this confirms that TDF has payed a part of the Android and Online > development from donation money. Interestingly, I don't recall any of the Collabora Productivity clients (even proprietary companies) ever complaining that the code Collabora develops for them end up in the open, as Free Software, and may be reused later to build new stuff on top of that, and that it may help other clients too. The donation money were used to develop Android editing. The fact that a small part of that work was later re-used for other developments is irrelevant, this his how Open Source and Free Software works. > If I remember correctly I attended a presentation from Michael M. > about > a LibreOffice online pre alpha version at the conference in Paris > 2011. The prototype from 2011 was using a different approach (remote desktop in a browser) and no code from that approach was used in online.git. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Simon, Simon Phipps píše v Pá 03. 06. 2022 v 09:59 +0100: > On Fri, Jun 3, 2022 at 7:51 AM Ilmari Lauhakangas < > ilmari.lauhakan...@libreoffice.org> wrote: > > Tendering and in-house development are not interchangeable, but > > they are > > interlinked. Keep in mind that the in-house devs would participate > > in > > running tenders. > > Another valuable role for an in-house developer would be to manage a > more long-term relationship with specialist subcontractors, for > example a company with expertise in accessibility development. With a > longer-term expert subcontractor, TDF could then actually develop new > capabilities rather than simply fix bugs and stand still like AOO. By > adding to our list of approaches a managed but non-employee longer- > term relationship with outside firms that is not limited to a single > task, TDF would be able to both benefit from the flexibility of > tendering and also gain the benefit of long-term staffing. Thank you very much, I've added this paragraph as a new Focus area, and removed your comment that touched this area. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Michael, Thank you for the feedback! I've updated the document accordingly, see below: Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +: > > Please don't get me wrong - I believe the appstores is an important > > discussion, just don't want to block the hiring on that; as I think > > it > > is orthogonal to that. > > I used to agree here. > > In light of the recent BoD decision that TDF will publish LO in the > app > stores [1] however, I think it is fair to reconsider this, and > consider > development needed to keep LO in line with app store requirements as > a > potential target area for TDF-internal developers, unless that's > already > covered otherwise. [...] > In that regard, the "App stores management" section in Paolo's > updated > proposal (v2.1) looks reasonable to me at first sight. Makes sense, I've removed the deletion, the "App stores management" is back. > > Ah - it is the extension of the rationale how the development > > itself > > fits the TDF mission, ie. doesn't make that much sense without the > > previous paragraph that starts "Why is it important to major on > > mentoring". > > > > So how about: "Development per se is not part of TDF mission, but > > it is > > expected that while a mentor is unable to actively contribute to > > public > > and professional education for whatever reason (eg. absence of > > volunteers) that they will be researching and increasing their > > experience by contributing to new ways to advance the free software > > and > > standards in their particular Target Areas." > > > > Does it make more sense this way? > > I'm not sure. It's still a bit unclear to me what "researching and > increasing their experience by contributing to new ways to advance > the > free software and standards in their particular Target Areas" means > in > practice, s.a. questions in my previous emails. I see - so this is to make sure the work of the developers fits the charitable mission of TDF. > I have the impression that my personal understanding/perspective of > the > job of a targeted developer is a bit different from the one outlined > in > your proposal, and more in line with Paolo's when there are no > mentees > in the developer's target areas. > That would seem reasonable to me: > > * If there are mentees in the target area, mentoring is the primary > focus (as outlined in your proposal). > * However, if there are no mentees, it's the primary focus to do > development in the target area. Thank you, I've added this as clarification. > Quoting from my previous email: > > > (I think it definitely makes sense to get deeper into the topic and > > cooperate with other organizations and free software projects. > > I still think that the main focus should be to achieve practical > > improvements in LO. Depending on the target area, I can think of > > more or less way that this would naturally involve contributing to > > other free software projects etc, but - given limited resource - I > > personally wouldn't necessarily see contributing to other projects > > or doing research as a main goal by itself, at least not in the > > beginning.) > > After all, it seems to be a matter of setting priorities how TDF > money > is spent, and one can decide one way or the other. > I can't judge how well each option fits with the "Development per se > is > not part of TDF mission" you mention, but to me, doing "development > per > se" doesn't seem to be less in line with the TDF mission than > spending > money on tenders, as was mentioned elsewhere in one of the threads > already. I think, in the past, there used to be long discussions whether TDF can or cannot have developers; so my hope that framing that in a way that fits the mission by default can help here. For the moment, I've added the "Developers per se..." there, but I don't insist, can be further tweaked in whatever way needed, I think. > > Indeed, I should clarify this; I think changing "Overlaps or > > prioritisations that find ..." to "Technical decisions that > > find..." > > could do? > > Yes, sounds good to me; thanks for the clarification. Applied. > > The hope is that there will be many applicants, and that we'll have > > the > > possibility to choose two. But if there is only one good > > candidate, I > > think we should not start another round of interviews until we > > evaluate > > the experience - because the process is expensive & time consuming. > > Sounds reasonable. > If it helps finding a consensus (minimize differences between the 2 > proposals at hand), I wonder whether it would make sense to rephrase > this, so that it becomes clear that having 2 would be preferred (and > just employing one if only one suitable candidate shows up is the > fallback), but for me personally, this explanation is enough and it > doesn't seem to make any difference in practice. OK, I've changed the default to 2, fallback to 1; and added a note for the Board to decide when no suitable ca
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v St 08. 06. 2022 v 19:53 +0200: > > Interestingly I cannot remember TDF ever tendering for LibreOffice > > Online work, can you please point me to the details? > TDF tendered in 2014/2015 the work for the Android editing, which was > explained to the board also as important for LOOL. Thus this project > was > payed from the LibreOffice donation money. The biggest part of this > work > (according to the prize) was done by Collabora productivity. > > [But I may be wrong - as said, I have nothing to do with TDF > > tending > > process, so maybe I've missed something?] > > > I made a research in an archive and found out that the document with > the > offer from Collabora was created by Jan Holesovsky with LibreOffice > 4.2 > on Oct., 6 2014. Sure, if we are talking the Android editing, then of course, I know what you are talking about. The work consisted of 478 commits, 265 of them were clearly marked as "android". The remaining 213 commits may still have been Android-only (and the author just forgot to mark them that way), or may have improved (the pre-existing, funded by CloudOn, Smoose and others) LibreOfficeKit with functionality needed for the Android work (I'd need to check commit by commit to tell you the exact number, so the 213 is the upper bound - it could be less). Anybody can check the reports, Collabora has published them previously: https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M1.pdf https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M2.pdf LibreOfficeKit was indeed important for what has started as LibreOffice Online thanks to the seed investment from IceWarp, but was just a part of what was necessary for the LibreOffice Online development. The completely missing bits, not existing previously & not paid by TDF, were the server and the JavaScript renderer of the tiles. To put the 213 commits to perspective, the server and JS bits were 12489 commits at the time of the Online repository move to GitHub. It is hard to count the commits done to LibreOfficeKit (ie. to LibreOffice core) before and after the TDF Android editing tender; but I suppose there were thousands, and they are still part of LibreOffice, of course. None of the server & JS commits were paid by TDF, it was all funded by IceWarp, Collabora itself & many others, and the price that TDF has paid for the 213 commits was marginal compared to the other work that made the Online happen. Please don't get me wrong though - I am really grateful for that, every cent counts, and especially counted the 8 years ago; for people at Collabora, those were hard (but exciting) times with very unpredictable future. And for the avoidance of doubt - all these 213 commits were needed for the Android work, none of them was done speculatively for a potential Online use later. More details here: https://collaboraonline.github.io/post/faq/#mobile-story All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [DECISION] TDF to publish LibreOffice in app stores
Hello, Caolán McNamara píše v St 08. 06. 2022 v 15:45 +0100: > On Wed, 2022-06-08 at 11:44 +0200, Florian Effenberger wrote: > > happy to update the vote template if the board is fine with that. > > > > All board members are on this list, so we can gather some feedback. > > Yeah, I'm content to see that information presented by default. Works for me too. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v Ne 05. 06. 2022 v 19:12 +0200: > If I remember correctly TDF has paid a big part of work on the basics > of > LOOL. And maybe some former / current board member recognize which > company was paid for that work from donation money. Interestingly I cannot remember TDF ever tendering for LibreOffice Online work, can you please point me to the details? [But I may be wrong - as said, I have nothing to do with TDF tending process, so maybe I've missed something?] All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v Čt 02. 06. 2022 v 18:34 +0200: > But seriously: you behave in a way which is unworthy for a leader of > an > OSS project. The TDF community consists not only from TDF members. > And > you denigrate all participants which are not TDF member. This damages > the whole LibreOffice/TDF community. I'm afraid this is a misunderstanding. I meant to point out that TDF has the members, the Board and elections for a reason, particularly when we are talking strategic projects affecting the TDF future. But after re-reading, I appreciate the paragraph might have sounded arrogantly. If it offended you, please accept my apology. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v St 01. 06. 2022 v 17:23 +0200: > Am 01.06.22 um 11:11 schrieb Jan Holesovsky: > > > > The difference is that once you hire a developer / developers, the > > development becomes a mandatory expense - TDF has to pay their wage > > every month. > > It seemed you try to create the impression that a contract of an > in-house-developer is always for livelong and thus a big mandatory > expense for a very long time. If you have a look at the history of TDF staff, you will see that only very few people have ever left it. I am very pleased that we have people working for TDF even for around 10 years, and most of the people stay for lng periods - which is great for continuity of course. > But I think you as the general manager of > a commercial company should know better (?). Unfortunately you are very confused about my role in Collabora it seems. My role is "People Development Manager" - which is a nice sounding title for a mentor. I have no company shares, and no executive role there. > Because a > commercial company has to calculate in unforeseeable problems and > realize a profit, the price for a tender is much higher. On the other hand, the commercial company has to assume there are other competing companies in the process, so every bid is (and has to be) risky and as cheap as possible. I am not directly involved, but I have heard that Collabora were actually losing money on some tenders, so TDF got a much better deal than it would do with internal developers. And it is not Collabora's fault, it is one of the reasons why "tendering" exists as a tool in general. > Over all I think the above answer shows that the role of a general > manager of a commercial company, which has some interest in TDF > tendering development, has a huge CoI with the TDF role(s). I am not a general manager, I have no personal interest in the tenders and I have no shares from the tenders. I have no CoI in the process of drafting the proposal. I have large experience in development and in mentoring, so I have the experience and skills needed for drafting the proposal. > Thus I'd > expect that this CoI should be solved asap and the appropriate > measures > taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal concerns
Hi Paolo, Paolo Vecchi píše v Út 31. 05. 2022 v 16:30 +0200: > That is not a merged proposal is simply another proposal and what > you > are doing is only generating confusion. Does that mean that you have no interest in trying to find a middle ground, and that we should decide for one or the other via a Board vote? If that is a misunderstanding, and you are actually interested in finding a solution that fits all, please point out concrete sentences in the Merged proposal you have problem with (like Michael W. has done), I am more than happy to explain, rephrase, or amend. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v Út 31. 05. 2022 v 19:49 +0200: > I'd be curious to know what would be (from the point of TDF's mission > / > statutes) the difference between working on the source code by in- > house > developers and by tendering and paying a commercial company for doing > this work? > > I only could see the difference that in one case TDF has full control > and has not to pay for the benefit of a commercial company. And thus > in > the first case could get reach more targets / tickets done than in > the > latter case from my point of view. The difference is that once you hire a developer / developers, the development becomes a mandatory expense - TDF has to pay their wage every month. Also when TDF switches targets, it has to pay for the time the developers have to spend learning the new area. On the other hand, the tendering is (and always has been) only budgeted from the excess, as the last thing after all the other costs (staff, marketing, infrastructure, etc. etc.) are covered - which gives TDF much more freedom in the planning: it can decide not to tender at all, if all the other costs give no room for that (and avoid hard decisions where to cut - infrastructure? conference? or even jobs?). And obviously, for tendering, TDF should choose projects that fit the mission, no question about that. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Michael, Michael Weghorn píše v So 28. 05. 2022 v 21:21 +: > I think having Paolo's original proposal and this one in a form > that's > easy to compare is very helpful. Thank you! > After reading the discussion on the mailing list, I was surprised > that > the overall direction still seems very similar to the one in Paolo's > unmodified proposal. Indeed - I'm trying to find the middle ground... > Removal of section "App stores management": As mentioned earlier, I > agree that it makes sense to separate the app store topic from the > current proposal of hiring developers, and focus on areas that are > currently not receiving enough attention otherwise. Please don't get me wrong - I believe the appstores is an important discussion, just don't want to block the hiring on that; as I think it is orthogonal to that. > Section "The solution: Hire a Targeted Developer": This sounds > mostly > good to me and if I understand correctly, also mostly fits with what > I > wrote earlier in the discussion. [1] > With the goal of improving areas that are neglected, having those > developers take responsibility for specific "oversight/target areas" > (by > either improving them themselves or by mentoring others) looks like > the > right approach to me, and it IMHO makes sense to focus on mentoring > others in case capable people interested in working on those areas > show > up. This way, TDF developers can potentially cover more areas over > time, > as work is shared. Perfect. > The following passage in that section is a bit unclear to me: > > > It is also expected that while the Targeted Developer is unable to > > actively contribute to public and professional education for > > whatever > > reason (eg. absence of volunteers) that they will be researching > > and > > increasing their experience by contributing to new ways to advance > > the > > free software and standards in their particular Target Areas. > > Can you clarify what that means in practice? Ah - it is the extension of the rationale how the development itself fits the TDF mission, ie. doesn't make that much sense without the previous paragraph that starts "Why is it important to major on mentoring". So how about: "Development per se is not part of TDF mission, but it is expected that while a mentor is unable to actively contribute to public and professional education for whatever reason (eg. absence of volunteers) that they will be researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas." Does it make more sense this way? > Section "Selecting Target Areas": This sounds reasonable to me > (applying > a similar process to the tendering one and have ESC suggest, but BoD > ultimately decide on target areas). Great. > Section "Project management" has this: > > > The Targeted Developer will have the same rules, rights and > > conditions > > as any other volunteer or corporate contributor to the code under > > TDF > > umbrella. Overlaps or prioritisations that find no clear conclusion > > between the Targeted Developer and the ESC will be decided by an > > ESC > > vote, as is standardized for any overlaps in the development of the > > LibreOffice code, and applicable to all volunteer and corporate > > developers. For avoidance of doubt, by no means the Targeted > > Developer > > or TDF leadership by tasking the Targeted Developer can overrule > > code-related decisions as decided by the ESC. > > I completely agree to the first sentence. > > However, the part that ESC has the ultimate decision in case of > overlap > or prioritisation replaces one in Paolo's proposal where BoD would > have > the ultimate decision there. > > I think it would be in line with the previous section "Selecting > Target > Areas" if BoD would have the final say when it comes to > prioritisation > of target areas/tasks for the developer(s) (which I *thought* was > what > Paolo's proposal meant to say). > > In case of different opinions on a more technical level I'd > completely > agree that ESC should be the committee that would have the final > say, > just as is the case for any other contributor. (The last sentence > seems > to fit well with this.) > > As I understand it, your reply to Paolo [2] seems to be in line with > this, but can you please clarify this? Indeed, I should clarify this; I think changing "Overlaps or prioritisations that find ..." to "Technical decisions that find..." could do? > Section "Bootstrapping": > The initial proposal suggests to employ 2 developers, while the > modified > one suggests to "start with hiring a single Targeted Developer > initially, with the option to expand this to two if multiple > suitable > candidates present at the interview stage". > What's the practical difference of the initial proposal of planning > to > hire two developers (and then only employing one, if only one > suitable > candidate s
Re: [board-discuss] In-house developers proposal v 2.1
Hi all, Paolo Vecchi píše v Po 30. 05. 2022 v 13:44 +0200: > After having read the other proposal I have integrated some minor > changes into v 2.1 that you can find here: > > https://nextcloud.documentfoundation.org/s/sFtCk9wiMWbt2pB > > Some of the changes implemented: > - added that TDF has increased its contributions also thanks to > improved > QA triage, UI and unit tests development > - moved the "app stores management" section under Focus Areas and > removed the long rationale behind the proposed focus area as it > should > be by now clear to all. It might be seen as controversial but it is > a > natural evolution to have the apps managed directly by TDF > - removed the paragraph stating that tenders are a negligible part > of > commercial contributors income > - added that in-house developers should participate to events to > present > their achievements For the ease of review, here is the above document in editable form, with the changes visible as tracked changes: https://nextcloud.documentfoundation.org/s/YNZyoL7Q39bMiCD I've also rebased the Merged proposal on top of this; it is great to see the amount of differences decreased, please see it here: https://nextcloud.documentfoundation.org/s/ggx9zJnN9yZSKc6 In case you want to edit it, you can do so directly in the shared folder: https://nextcloud.documentfoundation.org/f/960049 If you are not a TDF Member, happy to incorporate your changes for you, please send them as a reply to this ML. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Merged proposal concerns
Hi Paolo, Paolo Vecchi píše v Po 30. 05. 2022 v 13:44 +0200: > While TDF is committed > to working with members of the commercial ecosystem in a mutually > beneficial relationship it should be made clear that third parties > and > suppliers (commercial contributors) should not limit what a > charitable > organisation can do as that is against our statutes and the > principles > TDF was created with. Can you please explain what concrete limitations do you mean? I'd be very pleased to see how the Merged proposal can be improved to address those. > The ESC provides valuable contributions but it is well represented > by > commercial contributors and other external organisations which > should > not directly influence TDF's employees. I am a bit confused - are you concerned about the Board the same way? If it contains commercial contributors the same way as ESC does, should it not influence TDF staff either? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi píše v Pá 27. 05. 2022 v 10:58 +0200: > Hiring-another-mentor-controlled-by-ESC-v1.0.odt is probably a more > indicated name for that new proposal. Hiring: yes. another-mentor: no; the proposal clearly says the primary role is development. + The secondary mentoring / sharing the knowledge sub-role is in line with the TDF mission, and only 'kicks in' when a volunteer in the area appears. + Rationale: when there are volunteers to work on the area, it is not an abandoned area any more, so it is better to use the donation money to bring the volunteers up to speed, and start focusing on the next Target Area. controlled-by-ESC: no; the proposal clearly says the Developer is managed by TDF, and the Target Areas are ultimately decided by the Board. + The role of ESC is important another way - it is necessary to avoid situation that the TDF in-house developer is "more equal" than the other developers; and the ESC is the only way how to make that happen. + Rationale: In the StarDivision times, we have already been in a situation when some developers were privileged, and it was hindering contribution both from volunteers and corporates. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Merged proposal for in-house developers at TDF
Hi all, Paolo Vecchi píše v St 25. 05. 2022 v 16:03 +0200: > Could you please at least rename the file so that people don't get > confused? Good idea, Paolo, thank you. The new version that merges the proposals is in: https://nextcloud.documentfoundation.org/f/960049 as TDF-In-House-Developers-Proposal-v2.1.odt All my changes are change-tracked, so it should make the review easy. I've also removed some bits that are controversial, and OTOH not blocking the hiring. Hope this fits the community needs? - comments much appreciated! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Merged proposal for in-house developers at TDF
Hi all, Paolo Vecchi píše v St 25. 05. 2022 v 16:03 +0200: > Could you please at least rename the file so that people don't get > confused? Good idea, Paolo, thank you. The new version that merges the proposals is in: https://nextcloud.documentfoundation.org/f/960049 as TDF-In-House-Developers-Proposal-v2.1.odt All my changes are change-tracked, so it should make the review easy. I've also removed some bits that are controversial, and OTOH not blocking the hiring. Hope this fits the community needs? - comments much appreciated! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Proposal for in-house developers at TDF
Hello, Jan Holesovsky píše v St 25. 05. 2022 v 14:18 +0200: > To me it seems like those two proposals can be merged together to > create something good for TDF, if there is a will for that. And > there is from my side. And to show I mean it, I've converted the document to an editable version. Please check it here: https://nextcloud.documentfoundation.org/f/960049 Would be great if anybody independent can confirm it is 100% same as the original PDF from here: https://nextcloud.documentfoundation.org/s/sfJeNq7H9GS8YPe The document I've shared is editable for any TDF member and the change tracking is turned on there, please feel free to fix stuff in case you find anything wrong. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi píše v St 25. 05. 2022 v 13:41 +0200: > Michael Meeks made a completely different proposal to employ a > mentor. That is not my reading of the proposal. Also what I like about the proposal is that it addresses my questions I had wrt. the tasking and management; where your proposal was mostly a placeholder in those areas. To me it seems like those two proposals can be merged together to create something good for TDF, if there is a will for that. And there is from my side. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi píše v St 25. 05. 2022 v 12:13 +0200: > I've been waiting for Kendy to propose improvements for the past 3 > months but I'm yet to receive some. I see - I was waiting for the Board Working group being set up, as was proposed by Emiliano, and as seemed to me as the agreed way forward. I've volunteered for that group, but unfortunately you haven't set it up yet :-( > I guess that if Kendy hasn't proposed improvements in 3 months he's > probably satisfied of the progress so why do you keep pushing him? For the moment I'm happy enough with the Michael's proposal. As I've expressed previously - I'd prefer a proposal that is more mentoring-focused, and less development-focused myself, so from that point of view, even the Michael's proposal doesn't make me 100% happy, but I can live with that. That one is public - so what should be the next steps? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Hiring Targeted Developers ...
Hi Ilmari, Ilmari Lauhakangas píše v Po 23. 05. 2022 v 20:08 +0300: > > * Hire a Targeted Developer, with primary focus on mentoring > > If mentoring is put in the center, it seriously limits the pool of > applicants. Most devs who could apply will simply skip it. We know > this > from the experience in 2017-2021 and comments that C++ devs made > when > the mentoring position was advertised. I am afraid it is not clear from your message - can you please clarify if you are dismissing the proposal as a whole, or only the name of the role? Would a "Hire a Targeted Developer" work for you? Thank you in advance! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi píše v Čt 12. 05. 2022 v 14:29 +0200: > I have received no additional constructive feedback from the board > since > the last published version so I assume that the proposal will be > promptly approved as a new strategic project and the team will be > kindly > asked to prepare the job descriptions shortly after. I remember there was a Board working group to be set up to finalize the proposal, for which I volunteered, to be able to further my feedback there. Unfortunately I am not aware of the working group being setup yet, did I miss that, please? If the Board working group is not going to be set up, I still have some feedback I'd like to share. Should I send it here instead? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] ratify board communication best practices document
Hello, Thorsten Behrens píše v Út 12. 04. 2022 v 18:44 +0200: > having discussed this and incorporated your feedback, calling for a > vote, to: > > * ratify attached best practices as current board communication > guidelines > (verbatim copy from > https://nextcloud.documentfoundation.org/f/900757 as of 2022-04-12 > 1600 UTC) > > Vote runs the usual 72 hours, please answer with +1/-1/abstain to > this > email. +1, thank you! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] approval of preliminary budget for 2022
Hi Andreas, Andreas Mantke píše v Pá 08. 04. 2022 v 17:38 +0200: > there is no such document, which collects all answers. I see, so all this was a "you have to believe me because I say so" from the very start. > E.g. I'd expect you wouldn't find it usual, if an employee (e.g. from > Collabora) would have the power to decide on his own about his salary > and the employer had to pay this amount of money. I have never heard > about such behavior e.g. in European country. This is a completely different topic of course, and has nothing to do with your accusations. But if you wish - trade unions are designed to do what you outline above, and usual eg. in European countries. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] approval of preliminary budget for 2022
Hi Andreas, Andreas Mantke píše v Čt 07. 04. 2022 v 16:56 +0200: > > Applying the above, the CoI'd deputy is not CoI'd any more when > > representing the non-CoI'd director, correct? > > No, because the reprenting deputy has the CoI in his person and could > not drop that. I see, thank you! Is this all collected somewhere at one place so that I can read it myself, and don't have to ask you bit by bit? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] approval of preliminary budget for 2022
Hi Andreas, Andreas Mantke píše v St 06. 04. 2022 v 18:11 +0200: > > Suppose you were in the Board with me as a deputy, I was missing in > > a > > meeting, and you were to represent me. > > > > Are you suddenly becoming a Collabora employee or contractor or > > affiliate in any other way? Or what is the base for the CoI in > > such a > > case? > > in such case the representing deputy steps in for the member and thus > he > replaces the member. If the member has a CoI, this couldn't be solved > by > a representation. > > And to add: the deputy member votes for the represented member (as if > the member do it himself). This is very interesting. So assume that a CoI'd deputy represents a director with no CoI. Applying the above, the CoI'd deputy is not CoI'd any more when representing the non-CoI'd director, correct? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] approval of preliminary budget for 2022
Hi Andreas, Andreas Mantke píše v St 06. 04. 2022 v 17:05 +0200: > b) It doesn't help, if a deputy board member tries to jump in for a > board member, because it represents the board member (with all > consequences including CoI). If the member is not able to vote (e.g. > because of CoI), there is no representation possible. I don't agree with your line of thinking. Suppose you were in the Board with me as a deputy, I was missing in a meeting, and you were to represent me. Are you suddenly becoming a Collabora employee or contractor or affiliate in any other way? Or what is the base for the CoI in such a case? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Translation as part of the attic policy
Hi Sophie, sophi píše v Po 28. 03. 2022 v 21:55 +0200: > Would that mean that each time a l10n team resign for whatever > reason > (UK currently in my mind and heart), it will be atticized and need > at > least 3 contributors who use something else than Weblate to > demonstrate > their contributions to be accepted again in the LO community? >From my point of view, you don't have to worry at all: 1) 'The “attic” is a special area [...] not being actively developed, *can* be stored.' (emphasis mine) => it is up to the l10n community to propose to ESC and Board to atticize something, not that it would go there automatically. If it fits you better not to atticize (eg. there is no risk when incomplete translations are used for production, etc.), I don't think anything forces you to put the particular language to the attic. 2) 'A sufficient number of developers [2] have committed changes', where the [2] says: '1 for small, 3 for medium, and 6 developers for a large project' => if the l10n community decide to atticize something, best if they define the size they'd like to target for the de-atticization. To me, 'small' sounds reasonable for one language. Hope this helps? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Andreas, Andreas Mantke píše v Čt 24. 03. 2022 v 21:24 +0100: > > • Any repositories inside it will be made “read only”, so no “push” > > or > >“pull request” mechanisms will be available: this allows changes > > to > >the code to be shared as it was the last time it was > > “atticisized”; > > I'm curious why there is not only push function is disabled but also > pull function. Does this mean that there is no 'git clone' available > too? It is "pull request" as a term known originally from GitHub, not "pull", so "git clone" is supposed to be available; it would make no sense without that of course. GH explains "pull request" as: "Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch." All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
Jan Holesovsky píše v Čt 24. 03. 2022 v 20:07 +0100: > > calling for an email VOTE on the below final version of the Attic > > Proposal. The vote runs for 72 hours, starting now. > > Thank you for this effort, +1 from me. Oops, meant to +1 from this email address :-) [Sorry about that, I've mis-configured after a reinstall...] All the best, Kendy -- Jan Holešovský, Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Thorsten & Emiliano, all, Thorsten Behrens píše v Čt 24. 03. 2022 v 00:20 +0100: > calling for an email VOTE on the below final version of the Attic > Proposal. The vote runs for 72 hours, starting now. Thank you for this effort, +1 from me. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Age
Hi Paolo, Paolo Vecchi píše v Út 15. 03. 2022 v 12:56 +0100: > Then you have to tell me how you can look so young as I thought you > were > in your early 40. Apparently sports make me look younger, phew :-) And happy to share details about my past & present work, contributions and merits with anybody who is interested in person; a public mailing list is not the right place. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi Paolo, Paolo Vecchi píše v Po 14. 03. 2022 v 20:59 +0100: > It's true that through the 80s and 90s software development was > different but I can assure you that there were levels of complexity > that > aren't that different from today's systems and the tolerance for > errors > were probably a lot narrower. You really don't have to assure me. I started programming 35 years ago, I was there in the 80's and 90's, so I can compare with the present. > Maybe a small number of passionate and capable developers will be > able > to fix the CVEs and bring LOOL to a state where it could work well > with > the features left since the fork for those that don't need new fancy > features. The most important "new fancy features" are in the area of making the editing more fluent, optimized & pleasant, do you really think there are people who don't need them? > The point is that we don't know until we open the repository and let > people know that is available with all the relevant warnings. It is git, anybody can clone it & work on it if they want. If there were passionate and capable developers interested in this, they'd be bombarding the development mailing list with their patches the last >12 months; passionate and capable developers always find their way to get their code integrated one way or the other. But I'm not aware of any such patches. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi Paolo, Paolo Vecchi píše v Po 14. 03. 2022 v 17:07 +0100: > I have to agree with you that the process seems to be too cumbersome > and > it would very likely lead to the end of the project, so may as well > delete it, or to forks that will never come back. Interestingly when I've read the de-atticization part of the attic proposal, I had the feeling it goes well with your proposal that when a commercial entity wants to contribute a project, they have to go through extra scrutiny? What has changed, please? > > As plenty of time has passed by since LOOL has been forked I would > even > propose to just re-open the repository and let the community decide > if > they are actually interested in contributing to it. With my developer hat on (ie. not Board, not Collabora), I'd like to point out that you should consider the implications of potential or real security issues. How do you want to force the community to fix those? [I mean, who will be the actual people actually fixing those?] What if the re-opened repo gets a CVE? > We may discover that the community is actually interested in > contributing to a LOOL which is unlikely to reach features parity > with > other similar products but that is good enough for some use cases > where > basic features and a lightweight component is needed. Still with my developer hat on, I think you underestimate the complexity of the Online editing problem; the programming was just completely different 25 years ago (I think you said you used to be a developer then?). The problems that the Online has to sort out are complex; like extremely complex; like nobody-25-years-ago-could-imagine-how-much complex: Lots of asynchronous communication, performance implications (on many levels - in C++, in C++/JS combination, in JS, on the network), limitations of JavaScript, limitations of various browsers, and more. And solving these problems is painful, there are no good tools to debug the C++ / JavaScript combination, developers who love C++ hate JS & the other way around, etc. In other words, from the development point of view, there is no "basic features and a lightweight component" possible for the approach that COOL / LOOL is using. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [VOTE] Approve version 1.3.2 of the CoI policy
Hi Florian, all, Florian Effenberger píše v Pá 04. 03. 2022 v 13:30 +0100: > as discussed in https://listarchives.tdf.io/i/nUXiQDLatIR_Od6g63A08xU > 3 > and in the last board call, the following VOTE is proposed on the > recently published draft update to the CoI policy [1], to modify our > Rules of Procedure [2] - such that we reference version 1.3.2 of the > CoI > policy: +1 All the best, Kendy -- Jan Holešovský, Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Representation statement
Hi all, I, Jan Holešovský, elected member of the Board of Directors of The Document Foundation, hereby and until further notice, nominate the following deputies to represent me during board calls and meetings, in the order set forth below: 1. Gabriel Masei 2. Gábor Kelemen 3. Ayhan Yalçınsoy All the best, Kendy -- Jan Holešovský, Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] [DISCUSS] Proposed update for the CoI Policy: version 1.3.2
Hi Thorsten, all, Thorsten Behrens píše v Út 15. 02. 2022 v 19:17 +0100: > there's another update to the board CoI policy now in draft status, > I've uploaded it with enabled change tracking here: > > https://wiki.documentfoundation.org/images/e/e5/BoD_Conflict_of_Inte > rest_Policy_ver1_3_2_draft_2022-02-15.pdf > > Modifications are in sections 5.1 and 6.3. The changes were discussed > in the legal group, and drafted by Mike. Both changes are fine for me - the 5.1 sounds like a good clarification, and the 6.3 like a good cleanup: IANAL, but I was advised by a lawyer once that "intention" is worthless in contracts, because "intention" is nearly impossible to prove anyway. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v St 16. 02. 2022 v 15:04 +0100: > Is the "plan" a bit clearer for you now? Thank you, sounds much more positive this way. I'd still call it more an "outline" than a "plan", but I can see potential for the development mentoring in that too, so I can imagine we can agree something great for TDF together as the Board. > I'll find the time to collate together the feedback received by many > that help in completing the plan. The devil is always in the detail, but I'm all ears & patient too, please do take your time - I'm really looking forward to the plan. Again - thank you! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v St 16. 02. 2022 v 11:16 +0100: > It would be great if members of the board of directors, with their > TDF > hat on, would explain clearly why they seem to be opposed to > employing > in-house developers. I have never said I am opposed (and never said I'm supportive) to employing in-house developers, because I don't have enough information to make an informed decision yet. I have said two things: * I'd prefer hiring development mentors, rather than developers, because I am convinced that that is the best way how to scale as an organization responsible for the source code, and I see less potential problems with that * I am unhappy how the proposal to hire developers was and is being pushed, with lots of wishful thinking, and on the other hand without outlining potential problems, without proper discussion of the pro's & con's of this or other solutions, and without outlining details of tasking and management of the developers. In other words, my view is that the "let's first hire 2 developers, and then see" approach is irresponsible, and we should have a plan first. That is why I am so grateful to those who have constructively contributed to the debate, and particularly to those who have added their thoughts as answers or responses to my questions! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v Út 15. 02. 2022 v 17:09 +0100: > > And to conclude: the easiest way to convince me (and likely others) > > on > > the board that a proposal is a good idea - is to make your case > > properly with a well-researched writeup. > > Could you please forward to me the well researched write-up used to > employ the new mentor so that I can use that as a template? The difference is that we already have a mentor (actually several mentors in several areas), while you suggest a strategic decision - which in my view deserves research, consideration from multiple views, listening to others & consensus. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Andreas, Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100: > but maybe it would be great, if you could stop to pick on someone. > > It seemed your only intention on this topic is to control (with your > non-TDF-hat on) everything. > > That is not a cooperative behavior. I've told it in the public part of the Board meeting on Friday, and will repeat it again: I am very sad that this whole discussion started framed as (let me paraphrase) "TDF will hire 2 developers, it is all done deal, there are no problems" [in concrete words "Funds are available for at least 2 developers allowing us to start employing them straight away; Next steps: create and publish the job offers for developers and on-board them ASAP"]. This is extremely unhelpful, as it totally dismisses views of others. There was no full agreement of this in the Board, no plan, no prioritization against other budget items and no consideration if this is the best way how to improve the situation - so please don't be surprised it lead to a challenging discussion. I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and others (I'm sure I forgot some, sorry about that) for their patience & helpful input, and I do hope we will move to a more constructive, concrete debate. In my world [regardless of the hat], a constructive debate is much easier over a document collecting: * the problem statement & the need * the pros & cons of various solutions * the proposal & conclusion That with change tracking (redlining) turned on & possibility to comment - so that it is possible to finalize it to a form that is acceptable for all involved: in other words, to form a consensus. So - I am really looking forward to such a document! Actually I'd be happy to start it myself, if that helped the situation; and would ask people to volunteer to work with me on that - but not sure it is a good idea just now. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Ilmari, Thank you for your answers, lots of great stuff! Just two notes: Ilmari Lauhakangas píše v So 12. 02. 2022 v 23:30 +0200: > > * How to make sure they don't compete with other open source > > projects, > >or the ecosystem companies? > > Trust the more experienced staff members to know this distinction > when > it comes to areas of focus. I fear it shouldn't be about trust only :-) - so I'm looking forward to the Paolo's promised document, I hope it will cover it some way too. > > * How to avoid growing a group-think in the internal developers > >group that there is no need for the ecosystem companies, or even > >for the community as a whole? [As explained elsewhere; as much > > as > >it sounds strange - TDF is a subset of the community, not the > > other > >way around.] > > By regular brainwashing sessions conducted by me (I am well-known for > my > free advertising of the ecosystem companies before and after my > hiring > at TDF). Love this one! :-D - thank you! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v Pá 11. 02. 2022 v 16:11 +0100: > As I started the proposal I'm very happy to work with Sophie and > Hossein > to complement the proposal with the useful feedback we received in > this > thread. Perfect, I am looking forward to an ODT that we can then collectively redline as the Board, to form a proposal based on consensus! As to working with Sophie & Hossein - are you about to politely ask them to work on that as volunteers (as I've asked Michael W. - Michael, once again thank you for your input & answers!), or are you about to ask your fellow Board members & Florian to dedicate some of their work time (ie. donation money) to work on the proposal? Thank you! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Italo, Italo Vignoli píše v Čt 10. 02. 2022 v 18:28 +0100: > I would have applauded a reaction to the message that has opened > this > thread which was integrating the proposal with some additional > thoughts > and suggestions, to specify which could be the areas where a > developer > hired by TDF could work for the common benefit of the project. I see, thank you for the explanation! I have expressed elsewhere in this thread that I am a proponent of hiring more development mentors rather than generic developers; so it is hard for me to get excited about this proposal. Also I forgot to answer Heiko elsewhere that his idea of graphics designer / website developer in one person sounds reasonably positive to me. Having said that, maybe we can get a bit more constructive even in this discussion about hypothetical possibility of hiring generic developers; so what about this: Michael, please - would you be willing to further your (and Sophie's) idea in form of a document that can be discussed as a whole, particularly how the details together fit the TDF mission? I myself would be interested in the following questions; do you think you can cover them some way, please? * How to frame the hiring process - where developers should have a say in it, without being accused of CoI? * How to make it quick, so that the potential hires are still available once TDF decides for this or that candidate? * How to get the developers up-to-speed or mentor them once they are hired? * Also how to task them, how to day-to-day manage them, and how to make sure they are progressing at a reasonable pace? * What to do if they get stuck, and there is nobody in the community who can help them? * How to detect they are not performing, and just consume the donors' money? * How to make sure they don't compete with other open source projects, or the ecosystem companies? * How to make sure they are not misused by (any, not only ecosystem) companies to fix bugs for them or for their customers? [Particularly companies disguised by @gmail or so addresses in bugzilla.] * On the other hand - how to make it possible to cherry-pick fixes or features into the release branches of ecosystem companies without the risk of being accused of misusing the previous point? * Should there be a mechanism for the ecosystem companies to flag a bug "this is what I'm working on for a customer - please don't touch"? * With my pet idea of development mentors rather than generic developers in mind - should they be mentoring too, and if yes, how to prioritize vs. the actual development? * How to avoid growing a group-think in the internal developers group that there is no need for the ecosystem companies, or even for the community as a whole? [As explained elsewhere; as much as it sounds strange - TDF is a subset of the community, not the other way around.] * How to avoid TDF internal developers to feel (or worse, to be) "more equal" than the rest of the community - particularly when there is no 1/3 rule for them, direct access to release engineering and admins (their colleagues), etc.? I am sure this list is not exhaustive, and suppose others will contribute, but hope it is a start. Thank you in advance! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Italo, Italo Vignoli píše v Čt 10. 02. 2022 v 16:31 +0100: > Yes, but it looks like the discussion is blocked one step before > reaching a consensus on this very simple point. If the discussion > stays > as such, I have to say that I don't feel I am represented - as a TDF > Member - by any member of the just elected board of directors (of > course, those who have expressed their opinions). This is very sad to hear :-( I am afraid this is a product of the unilateral & vigorous presentation of hiring developers as the only way forward, regardless of what the ecosystem companies have to say. > > Of course, in case the main intention were for TDF to provide more > > business-like services (like an LTS version or creating an > > impression of > > "donate a certain amount of money and your pet bug will be fixed"), > > I > > see very well how that might interfere significantly with the > > business > > model of ecosystem companies. > > Totally agree. But I don't see the issue, as ESC and BoD members > could > easily stop any project before it starts, when there is a potential > risk > of conflict. AFAIK, major development activities are scrutinized by > both > bodies, as they are ranked in order of importance, suggested, > approved > and transformed to tenders, or not considered for tendering. If assurances like these were part of the proposal, I am sure it would be much easier to discuss - at least for me personally. Thank you for pointing this out! And also Michael (W.) - thank you for your great summary! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Andreas, Andreas Mantke píše v St 09. 02. 2022 v 19:58 +0100: > once I read this sentences the first time, I thought I was in a > different film in 2010. But maybe I didn't understand the situation > in OOo project at that time. I may be wrong, it is a long time ago, but from what I remember, the problem was not the domination per se [though please don't understand me as supporting domination ;-)], but the unwillingness to communicate & seek consensus how to improve the situation for contributors. [This is also why I insist that "community" means the contributors - the situation was perfectly fine for the users; they were getting their builds for free & were happy.] At that time: * There was the CWS system that was forcing contributors to go through a complicated process even for the simplest fixes + unless you have found a friendly internal engineer who was kind enough to include your patch into their CWS + not to mention that the access to CWS was restricted for the outside for a long time in the first place * CVS was a disaster for version control + and I've created a working, usable git import + yet Mercurial was favored, even though not ready for the OOo size + so the conversion was postponed and OOo was converted to Subversion as a temporary measure + then 2 years later converted to Mercurial - with a terrible penalty for the non-internal contributors, because Mercurial had to download 500MB of metadata for each branch [which might be OK'ish these days - but this was 11 years ago and more] + only to be converted to Subversion again [at Apache] + and then finally to git * the localization went through the .sdf files + I was not involved in this, so I have only vague memories it was a terrible pain for the l10n community * the build system was a disaster by itself due to build.pl & dmake + and worse, the company had a different, internal one - so no interest in improving it for the contributors + but at least Bjoern has invented the gbuild while being an internal engineer, regardless of the internal pushback - he's a hero; and I have fond memories of other heroes who helped to make the contributing easier - still - the general approach of the company was to make the contribution hard. * I'm sure there's more; but luckily I forgot :-) So if you see any sign of an ecosystem company trying to make contributing harder (like the above), please do shout - contributing must be as easy as possible for everybody who wants to contribute! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Italo, Awesome, thank you so much for the summary! All the best, Kendy Italo Vignoli píše v Čt 10. 02. 2022 v 15:27 +0100: > On 2/10/22 14:56, Jan Holesovsky wrote: > > > Comes to my mind - as you deal with the donors daily, and > > particularly > > ask them why do they want to stop their recurring donations (in > > case > > they do), I wonder if there is an aggregated data available > > somewhere? > > The majority of recurring donations is stopped immediately after the > first donation by the donor, when he gets the receipt and realizes > that > he has triggered a recurring donation instead of a one off. > > Then there is a number of donors who ask to stop the recurring > donation. > Some of them provide a reason, which in some cases is that he wanted > to > donate once and not on a recurring basis, in some cases lack of > money, > and in some other because they don't use the software anymore (no bug > or > other technical reason provided). > > A small number of donors block donations because the software > doesn't > fit their needs or is too difficult to use (again, without providing > any > technical reason or a bug). > > You should always consider the fact that only a very small number of > users is capable of spotting bugs, as for them the software always > works > as intended. It took me several years to get a marginal understanding > of > bugs, and I have been working in technology environments since 1982. > The > majority of users is technically dumb, including people who are > supposed > to be competent, and this is just a fact. > > > Also, in case it is a concrete problem that stops them donating any > > longer, please do you have an opportunity to file bugzilla tickets > > for > > such cases? > > Since 2013, not a single user has related stopping donations with > bugs, > while some donors have related their donation to solving bugs. > > Best regards, Italo > -- > Italo Vignoli - it...@vignoli.org > mobile/signal +39.348.5653829 > GPG Key ID - 0xAAB8D5C0 > DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0 > > -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Stephan, Stephan Ficht píše v Čt 10. 02. 2022 v 14:28 +0100: > Yeah, on the one hand it's satisfaction, and from my POV dealing > with > donors nearly every day, on the other hand, and in many cases, it's > even > an incentive, a support, and an expectation to improve what the wide > community will provide and share in the future. Thank you very much for that! Comes to my mind - as you deal with the donors daily, and particularly ask them why do they want to stop their recurring donations (in case they do), I wonder if there is an aggregated data available somewhere? Also, in case it is a concrete problem that stops them donating any longer, please do you have an opportunity to file bugzilla tickets for such cases? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Stephan,
Stephan Ficht píše v Čt 10. 02. 2022 v 12:30 +0100:
> wrt the subject line and reading through this thread comes in my
> mind:
>
> "contributors of code" is subset of "contributors of anything" is
> subset
> of "community" is subset of TDF to fulfill its written objectives.
Thank you! Unfortunately it is not as easy, when you look at that as
"sets".
"contributors of code" is definitely a subset of "contributors of
anything". "Contributors of anything" could be a subset of "community"
(though I argue "contributors of anything" equals to "community" - but
that is an unimportant detail here).
But the "community" is not a subset of "TDF" - there are many
contributors ("community" by the above definition) who are not TDF
trustees.
So from the sets point of view, "TDF" is a subset of "community" too.
[Of course, that is assuming the Membership committee does not allow
non-contributors to became TDF trustees (but I believe that's the case
:-) ) - because then the "TDF" and "community" would only have an
intersection.]
> So, everyone and everything being an important piece in the mosaic
> for
> the big picture for a FLOSS office suite, called LibreOffice.
Definitely, I agree with you, and I believe listening to others &
seeking for consensus is key.
All the best,
Kendy
--
To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Regis, Regis Perdreau píše v Čt 10. 02. 2022 v 11:21 +0100: > Some parts of LibreOffice are not covered by the ecosystem... > Although we sometimes have customers who ask for improvements : If you talk about customers - it sounds like there is a company willing to pay to fix those. With my Collabora hat on, I'd love somebody from our company to talk to those customers to see what we can offer them. But with my TDF hat on - why should TDF, paid by donations from real, living people, use those donations to employ developers to fix stuff for enterprises? > May be those topics below are not fashionable but they contribute to > give some credibility to LibreOffice > > - VBA compatibility > - Basic bugs > - Base enhancement > - Python support > - Math equation > - Slide transition > - documents signature support (CNG api) > - All most annoying bugs... I didn't check how many of these were proposed for tendering - but I think some of these were. Can you please add the missing ones as proposals, so that it is possible to rate them & see which of them are in line with the TDF goals & TDF can tender them? Thank you very much! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Lothar, Lothar K. Becker píše v Čt 10. 02. 2022 v 11:12 +0100: > It was one of my first and foremost task as chair - and let me add it > was hard time consuming work - that everybody was heard and could > speak, it is simply not true, that contributors wasn't heard. I am sorry, I didn't mean to offend you. I've seen it myself in the public parts of the calls I were attending how hard a job it must have been for you given the conditions, and I am sure you *yourself* made everything to listen very carefully - thank you for that! And the same way - I want thank everyone who were carefully listening & considering, instead of just pushing their agenda. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v St 09. 02. 2022 v 19:56 +0100: > He asked himself quite a few interesting questions: > "Without sharing too much, there are some moral questions popping up > for > me. Who owns the community? Who owns ownCloud itself? And what > matters > more, short term money or long term responsibility and growth? Is > ownCloud just another company or do we also have to answer to the > hundreds of volunteers who contribute and make it what it is today?" > > Shouldn't we all ask ourselves the same questions? Awesome - so now you finally understand how hard a decision it was for us (Free Software lovers & contributors for decades) to move the LOOL development to GitHub - because it was the result of asking & pondering the same questions. Thank you for that! Particularly: * TDF does not own the community, TDF is an organization designed to make the community (let me repeat, "community" = "group of contributors") strong & flourishing. * TDF does not own LibreOffice itself; it owns the brand, but the code, translations, etc. is owned by the particular contributors (ie. by the community) - to the level of lines of code, strings of translations, icons painted, test cases provided, etc. * Long term responsibility & growth matter more - and when the LOOL's (sub-)community didn't grow under TDF, it was time to move on. The decisions shouldn't be about donation money. And regarding the last one: "Is TDF just another foundation or do we also have to answer to the hundreds of volunteers who contribute and make it what it is today?" is for us, the new board, to improve - because from what I can see, TDF was not listening to the contributors the last 2 years too much. Let's improve it together! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v St 09. 02. 2022 v 15:09 +0100: > The community and our valuable members of the ecosystem have been > asking us to invest more in development It is important to understand that "community" means "contributors"; as opposed to "users". "Users" are not part of the "community", until they start contributing; via code, QA, translations, marketing under the TDF umbrella, etc. With that in mind - can you please point us to those requests? Thank you! All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Daniel, Daniel A. Rodriguez píše v Út 08. 02. 2022 v 19:31 -0300: > I think Andreas hits the nail on the head when he mentions that in > other > projects no company dominates the project or the community. The contrary is true: Most of the successful open source projects have a major, dominating company behind them - have a look at Nextcloud (Nextcloud GmbH), ownCloud (ownCloud GmbH), MariaDB (MariaDB Corporation Ag), ... and I can continue on and on. In LibreOffice, there is no dominating company. Many like to paint Collabora as one, but it is not the case due to how the founding members (and I was one of them) have designed the TDF (with the 1/3 rule in the bodies and other means to protect from the project domination) and due to how the German charity laws work. Also, such thinking is very offensive to eg. Allotropia - who is doing a great job undermining any kind of potential domination by excellent engineering; have a look at their impressive WASM prototype. But if you want to see an open source project with no company behind them, have a look at Apache OpenOffice. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi all, Paolo Vecchi píše v Po 07. 02. 2022 v 19:16 +0100: > Enable TDF to contribute more code to LibreOffice with in-house > developers to address our donors specific needs My candidacy statement was much more focused on the community growth; so I'd like to propose a different vision: TDF should be a pleasant place for contributors to feel welcome. TDF should focus on growing the community, mentoring, and welcoming newcomers. I don't think that paying in-house developers is in line with this vision; if we talk about TDF employees or contractors, we need more mentors - because that is the only way how to scale: "Give a person a fish, and you feed them for a day. Teach a person to fish, and you feed them for a lifetime". This is what TDF should be doing in my view - teaching how to fish, not fishing itself. All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Re: Acceptance of role in the Board of Directors
Dear Marina, all, I, Jan Holešovský, elected director of the board of The Document Foundation, hereby accept this position within the Stiftung bürgerlichen Rechts. My term will start February 18, 2022. Signed: Jan Holešovský Ich, Jan Holešovský, gewähltes Mitglied des Vorstands der The Document Foundation, nehme mein Amt innerhalb der Stiftung bürgerlichen Rechts an. Meine Amtszeit beginnt am 18. Februar 2022. Unterzeichnet: Jan Holešovský -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[Libreoffice-commits] core.git: include/vcl
include/vcl/mtfxmldump.hxx | 17 +
1 file changed, 17 insertions(+)
New commits:
commit 9067b827f013caafc61ef3d0d63305572a320ee2
Author: Jan Holesovsky
AuthorDate: Thu Jan 6 11:55:57 2022 +0100
Commit: Miklos Vajna
CommitDate: Thu Jan 6 16:52:59 2022 +0100
Add a comment how to use MetafileXmlDump in the tests
Change-Id: I5088874be3fbf2ac114f5e5d0cd9571a3caf48dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128040
Reviewed-by: Miklos Vajna
Tested-by: Jenkins
diff --git a/include/vcl/mtfxmldump.hxx b/include/vcl/mtfxmldump.hxx
index edfcaff55e4d..3425bccb710f 100644
--- a/include/vcl/mtfxmldump.hxx
+++ b/include/vcl/mtfxmldump.hxx
@@ -24,6 +24,23 @@ class SvStream;
enum class MetaActionType;
+/**
+ * Class that is used for testing of the decomposition into shapes. Used like
+ * this:
+ *
+ * std::shared_ptr xMetaFile = xDocShRef->GetPreviewMetaFile();
+ * MetafileXmlDump dumper;
+ * xmlDocUniquePtr pXmlDoc = XmlTestTools::dumpAndParse(dumper, *xMetaFile);
+ * CPPUNIT_ASSERT(pXmlDoc);
+ *
+ * assertXPath(pXmlDoc, "/metafile/push[1]/push[1]/textarray[1]", "x",
"2093");
+ *
+ * To see the dump to be able to create the assertXPath() call, use:
+ *
+ * xMetaFile->dumpAsXml();
+ *
+ * and check the output in /tmp/metafile.xml
+ */
class VCL_DLLPUBLIC MetafileXmlDump final
{
o3tl::enumarray maFilter;
Re: [board-discuss] Draft text: an "attic" proposal
Hi Marco, Thank you for your questions! There has been a lot of positive changes regarding the Online in the last year; like that the CODE docker images have no limits of users or documents any more; that the documentation is freely available to anyone at https://sdk.collaboraonline.com/ ; that a support channel for CODE has been set up: https://forum.collaboraonline.com/ and that we (Collabora) have started actively supporting the LibreOffice Technology brand in Collabora Online: https://people.collabora.com/~kendy/tdf/collabora-online-about.jpg https://people.collabora.com/~kendy/tdf/nextcloud-office-about.jpg and on our webpages: https://www.collaboraoffice.com/community-lot/ Regarding your concerns - please read inline: Marco Marinello píše v Po 20. 12. 2021 v 20:34 +0100: > I have already said this many times but I want to repeat it: it has > to be clear (and hopefully stated by legal contracts) to the > companies working in the LibreOffice ecosystem that they cannot wake > up one day and bring their development outside the LibreOffice > project. They cannot stay with one foot inside the ecosystem, > contributing to it, and with the other one bringing their development > effort outside. This is something the next board should focus on. Given that we are doing FLOSS (Free / Libre / Open Source Software) here, I wonder how would you like to frame such a legal contract, given that the "right to fork" is one of the basic Free Software freedoms? And what if it was not a company, but another group (do you remember IceWeasel?) >From my point of view, rather than legal contracts, a much better strategy is to listen to what the ecosystem companies or other contributors are telling you; work with them, instead of against them; treat them as partners, not as enemies. If you do that, there is no reason for anybody to leave the community, move the code away, or fork. In the Online case, we (as Collabora) were trying extremely hard not to have to move the development outside of TDF infrastructure, and we have done many steps to fulfill asks of various people. Unfortunately - they were demanding more and more; and at some stage they wanted just too much: to dismiss the agreement we had with TDF that LibreOffice Online will be a source-only project, for *everyone* to build their branded versions on, ie. it won't be a binary product that people can download under LibreOffice name from TDF pages. This agreement was in place to ensure that the economics work correctly, and all ecosystem companies (not only Collabora) can build their Online's on top of the shared code. > Getting to this specific situation, Jan 'Kendy' Holešovský, in the > last Q+A session for the next BoD, stated that “it was really hard > for us [Collabora] to get contributors and volunteers under the TDF > umbrella… and we tried hard […] now that we’re on GitHub we get > several commits from random people just because it’s on GitHub” [1]. > Kendy didn’t bring any data supporting this thesis but – for the sake > of the argument – assume he’s true. Sure - I was unprepared for the question, it was ad-hoc, so everything I've said there was without the possibility to have the numbers at hand in advance :-) Let me add the details now: d0edfeabbdc969a9a66cf90976a63c2f4403a6d3 was the last commit that happened on the TDF infrastructure. It covers work from 2015-03-03 to 2020-09-30. The amount of people who have contributed during those 5 years and 7 months was 85: $ git log d0edfeabbdc969a9a66cf90976a63c2f4403a6d3 | grep '^Author:' | sed 's/^Author: //' | sed 's/ <.*//' | sort | uniq | wc -l 85 In the rest of the period, so from 2020-10-01 to now, the amount of people who have contributed in the 1 year and 2 months was 75 (155 if I include the translations - but that wouldn't be correct): $ git log --invert-grep --grep=Weblate d0edfeabbdc969a9a66cf90976a63c2f4403a6d3.. | grep '^Author:' | sed 's/^Author: //' | sed 's/ <.*//' | sort | uniq | wc -l 75 Do you see the 5 years vs. 1 year proportion? > Shouldn’t this have been a concern for the whole foundation, and not > only for Collabora? It’s the foundation scope to bring new developers > in. Definitely it should be a concern - and I've stressed this several times on other occasions that the main reason why I am standing for the Board is that I want to make TDF more welcoming (to get new contributors) & friendly (to keep the existing ones). And by contributors, I mean not only developers, but also translators, designers, documentation authors, QA and other people actually enhancing the project. > If GitHub can magically attract developers, also TDF, from my point > of view, should move there. There are many pro's and con's; eg. we were criticized after the move that GitHub is proprietary software & infrastructure. Also I think gerrit works better for a C++ project rather than the system of PR's known from Github. But if you think even TDF should consider the opt
[board-discuss] Candidacy to the BoD elections: Jan "Kendy" Holešovský
Dear Members, I would like to stand for elections to the Board of Directors of The Document Foundation (again). I am Jan Holešovský, known as "Kendy" to many, 44 years old, married, father of two girls, living in the Czech Republic. I work for Collabora as an Engineering Manager, but still love to be close to the code whenever possible. In the LibreOffice community, I used to serve in the Board of Directors as a member and a deputy, but have a gap of one term. While not in the Board, I was attending many of the public parts of the Board meetings, not to lose contact. Otherwise I am a developer contributing to the LibreOffice codebase, member of the Engineering Steering Committee and member of the Developer Certification group. An important part of my involvement in LibreOffice is mentoring. I often help the team members with their code, or review patches in gerrit. That's it about me - if you need to know more, please do ask! Full name: Jan Holešovský Email: ke...@collabora.com Corporate affiliation: Collabora (Less than) 75 words candidacy statement: "As a long-time contributor to LibreOffice, I would like to serve in the Board to help make decisions that support contributors in their work and that lead to having more people involved in the project. I want to offer my experience from cross-team work and from the past years in the Board, because LibreOffice is an important part of my life." All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[Libreoffice-commits] core.git: Branch 'libreoffice-7-2' - filter/source
filter/source/config/fragments/types/writer_T602_Document.xcu |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit da66ff3d83e5e975383615081eeffd3fa2f668f9
Author: Jan Holesovsky
AuthorDate: Thu Oct 7 15:12:18 2021 +0200
Commit: Xisco Fauli
CommitDate: Thu Oct 14 20:48:19 2021 +0200
T602 is an obsolete format, don't assume .txt files are T602
Without this, when the user tries to open a 0-bytes .txt file, they are
asked for a Save As operation after they hit the Save button.
When we remove the 'txt' from the T602 detection, it rather asks if the
user wants to use ODT or Plain text (and lose formatting).
Change-Id: Ic48fa61064a9ed78c64d56bc8864f0e12528e072
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123216
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
(cherry picked from commit d602c433a08c6df28198ceb61b95f5c6d85d1a87)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123525
Reviewed-by: Xisco Fauli
diff --git a/filter/source/config/fragments/types/writer_T602_Document.xcu
b/filter/source/config/fragments/types/writer_T602_Document.xcu
index c34f823da4ca..e9b3df39cf33 100644
--- a/filter/source/config/fragments/types/writer_T602_Document.xcu
+++ b/filter/source/config/fragments/types/writer_T602_Document.xcu
@@ -18,7 +18,7 @@
com.sun.star.comp.Writer.T602ImportFilter
-602 txt
+602
application/x-t602
true
T602Document
[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.4' - filter/source
filter/source/config/fragments/types/writer_T602_Document.xcu |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 4feba9d025f1f97ea80854bc340ee0867eef8fff
Author: Jan Holesovsky
AuthorDate: Thu Oct 7 15:12:18 2021 +0200
Commit: Miklos Vajna
CommitDate: Thu Oct 14 15:00:09 2021 +0200
T602 is an obsolete format, don't assume .txt files are T602
Without this, when the user tries to open a 0-bytes .txt file, they are
asked for a Save As operation after they hit the Save button.
When we remove the 'txt' from the T602 detection, it rather asks if the
user wants to use ODT or Plain text (and lose formatting).
Change-Id: Ic48fa61064a9ed78c64d56bc8864f0e12528e072
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123216
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
(cherry picked from commit d602c433a08c6df28198ceb61b95f5c6d85d1a87)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123401
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Miklos Vajna
diff --git a/filter/source/config/fragments/types/writer_T602_Document.xcu
b/filter/source/config/fragments/types/writer_T602_Document.xcu
index c34f823da4ca..e9b3df39cf33 100644
--- a/filter/source/config/fragments/types/writer_T602_Document.xcu
+++ b/filter/source/config/fragments/types/writer_T602_Document.xcu
@@ -18,7 +18,7 @@
com.sun.star.comp.Writer.T602ImportFilter
-602 txt
+602
application/x-t602
true
T602Document
[Libreoffice-commits] core.git: Branch 'distro/collabora/co-2021' - filter/source
filter/source/config/fragments/types/writer_T602_Document.xcu |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit bc714f2401d0f912c6cc38abc0bc21f36202b1c6
Author: Jan Holesovsky
AuthorDate: Thu Oct 7 15:12:18 2021 +0200
Commit: Miklos Vajna
CommitDate: Thu Oct 14 14:59:52 2021 +0200
T602 is an obsolete format, don't assume .txt files are T602
Without this, when the user tries to open a 0-bytes .txt file, they are
asked for a Save As operation after they hit the Save button.
When we remove the 'txt' from the T602 detection, it rather asks if the
user wants to use ODT or Plain text (and lose formatting).
Change-Id: Ic48fa61064a9ed78c64d56bc8864f0e12528e072
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123216
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
(cherry picked from commit d602c433a08c6df28198ceb61b95f5c6d85d1a87)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123402
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Miklos Vajna
diff --git a/filter/source/config/fragments/types/writer_T602_Document.xcu
b/filter/source/config/fragments/types/writer_T602_Document.xcu
index c34f823da4ca..e9b3df39cf33 100644
--- a/filter/source/config/fragments/types/writer_T602_Document.xcu
+++ b/filter/source/config/fragments/types/writer_T602_Document.xcu
@@ -18,7 +18,7 @@
com.sun.star.comp.Writer.T602ImportFilter
-602 txt
+602
application/x-t602
true
T602Document
[Libreoffice-commits] core.git: external/libcmis
external/libcmis/UnpackedTarball_libcmis.mk |1 + external/libcmis/libcmis-boost-string.patch | 11 +++ 2 files changed, 12 insertions(+) New commits: commit c6564fb00a59224b223f4bbd8e58612ab3e40b0f Author: Jan Holesovsky AuthorDate: Thu Sep 2 14:54:22 2021 +0200 Commit: Jan Holesovsky CommitDate: Mon Sep 6 18:41:46 2021 +0200 Fix build with system boost Change-Id: I86ffabd30535b594a40d786f7c4602a5a54a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121513 Tested-by: Jenkins Reviewed-by: Jan Holesovsky diff --git a/external/libcmis/UnpackedTarball_libcmis.mk b/external/libcmis/UnpackedTarball_libcmis.mk index 8398853e4511..f48201d319d0 100644 --- a/external/libcmis/UnpackedTarball_libcmis.mk +++ b/external/libcmis/UnpackedTarball_libcmis.mk @@ -19,6 +19,7 @@ $(eval $(call gb_UnpackedTarball_add_patches,libcmis, \ external/libcmis/libcmis_onedrive.patch \ external/libcmis/libcmis_oauth_pw_as_refreshtoken.patch.1 \ external/libcmis/libcmis_gdrive.patch.1 \ + external/libcmis/libcmis-boost-string.patch \ )) # vim: set noet sw=4 ts=4: diff --git a/external/libcmis/libcmis-boost-string.patch b/external/libcmis/libcmis-boost-string.patch new file mode 100644 index ..247d38a19759 --- /dev/null +++ b/external/libcmis/libcmis-boost-string.patch @@ -0,0 +1,11 @@ +--- a/src/libcmis/oauth2-handler.cxx b/src/libcmis/oauth2-handler.cxx +@@ -26,6 +26,8 @@ + * instead of those above. + */ + ++#include ++ + #include "oauth2-handler.hxx" + + #include
[Libreoffice-commits] core.git: Branch 'feature/themesupport2' - 504 commits - accessibility/inc accessibility/source avmedia/source basctl/source basegfx/CppunitTest_basegfx.mk basegfx/source basegfx
Rebased ref, commits from common ancestor:
commit 6546856703cf1cec4493e8c357fa89fa7f53f8ca
Author: Jan Holesovsky
AuthorDate: Fri Apr 2 00:21:34 2021 +0200
Commit: Tomaž Vajngerl
CommitDate: Thu Jul 1 09:53:47 2021 +0900
Unit test (with the content disabled so far) for the theming.
Change-Id: Ie9e003df38e1bc766fb5323936138d3e0e664321
diff --git a/sw/qa/extras/ooxmlexport/data/themeOrange.docx
b/sw/qa/extras/ooxmlexport/data/themeOrange.docx
new file mode 100644
index ..e350c2676d41
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/themeOrange.docx
differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
b/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
index bafe3b511730..f29b156d171e 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
@@ -587,6 +587,12 @@ DECLARE_OOXMLEXPORT_EXPORTONLY_TEST(Test_ShadowDirection,
"tdf142361ShadowDirect
"rotWithShape", "0");
}
+DECLARE_OOXMLEXPORT_TEST(testThemeOrange, "themeOrange.docx")
+{
+// Assert that the theme color of the 1st paragraph is "accent1"
+//CPPUNIT_ASSERT_EQUAL(getProperty(getParagraph(1),
"CharColorTheme"), static_cast(4));
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
commit f02d56dca274961ad9ecc6b1eaeb2acc4dea25b3
Author: Tomaž Vajngerl
AuthorDate: Wed Sep 23 13:38:38 2015 +0200
Commit: Tomaž Vajngerl
CommitDate: Thu Jul 1 09:53:30 2021 +0900
adjust the conversion from theme color type to the color set index
Change-Id: I8c54c8935de8acc3e2b302e10327aa2488f9ac85
diff --git a/writerfilter/source/dmapper/TDefTableHandler.cxx
b/writerfilter/source/dmapper/TDefTableHandler.cxx
index 42ab0d61bd83..4bc8faf7e3d5 100644
--- a/writerfilter/source/dmapper/TDefTableHandler.cxx
+++ b/writerfilter/source/dmapper/TDefTableHandler.cxx
@@ -298,15 +298,15 @@ sal_Int16
TDefTableHandler::getThemeColorTypeIndex(sal_Int32 nType)
case NS_ooxml::LN_Value_St_ThemeColor_followedHyperlink:
return 11;
case NS_ooxml::LN_Value_St_ThemeColor_none:
-return 12;
+return -1;
case NS_ooxml::LN_Value_St_ThemeColor_background1:
-return 13;
+return 0;
case NS_ooxml::LN_Value_St_ThemeColor_text1:
-return 14;
+return 1;
case NS_ooxml::LN_Value_St_ThemeColor_background2:
-return 15;
+return 2;
case NS_ooxml::LN_Value_St_ThemeColor_text2:
-return 16;
+return 3;
default:
break;
}
commit d480eea0e754d0849ff59b391bd37abf043d47cc
Author: Tomaž Vajngerl
AuthorDate: Wed Sep 23 13:37:43 2015 +0200
Commit: Tomaž Vajngerl
CommitDate: Thu Jul 1 09:53:29 2021 +0900
convert tint value from ooxml to the value we support
Change-Id: I5a79ca434be16f9dccc5aa6118a7efbf4544f0b1
diff --git a/writerfilter/source/dmapper/DomainMapper.cxx
b/writerfilter/source/dmapper/DomainMapper.cxx
index a28e3dae2838..8ba4881c4e13 100644
--- a/writerfilter/source/dmapper/DomainMapper.cxx
+++ b/writerfilter/source/dmapper/DomainMapper.cxx
@@ -999,7 +999,7 @@ void DomainMapper::lcl_attribute(Id nName, Value & val)
case NS_ooxml::LN_CT_Color_themeTint:
if (m_pImpl->GetTopContext())
{
-
m_pImpl->GetTopContext()->Insert(PROP_CHAR_COLOR_TINT_OR_SHADE,
uno::makeAny(sal_Int16(nIntValue * 1 / 256)));
+
m_pImpl->GetTopContext()->Insert(PROP_CHAR_COLOR_TINT_OR_SHADE,
uno::makeAny(sal_Int16((256 - nIntValue) * 1 / 256)));
}
m_pImpl->appendGrabBag(m_pImpl->m_aSubInteropGrabBag, "themeTint",
OUString::number(nIntValue, 16));
break;
commit 4e553ab0e53feb30e17048da065921ad9cb78054
Author: Tomaž Vajngerl
AuthorDate: Wed Sep 23 13:35:56 2015 +0200
Commit: Tomaž Vajngerl
CommitDate: Thu Jul 1 09:53:29 2021 +0900
check that the color index is valid
Change-Id: Id5c7c83f50e1611af12f3b25e6c9a335a8353ba0
diff --git a/sw/source/uibase/sidebar/ThemePanel.cxx
b/sw/source/uibase/sidebar/ThemePanel.cxx
index 9117f20a7013..ce42983879ce 100644
--- a/sw/source/uibase/sidebar/ThemePanel.cxx
+++ b/sw/source/uibase/sidebar/ThemePanel.cxx
@@ -232,9 +232,9 @@ void changeFont(SwFormat* pFormat, SwDocStyleSheet const *
pStyle, FontSet const
void changeColor(SwTextFormatColl* pCollection, svx::ColorSet const&
rColorSet, StyleRedefinition* /*pRedefinition*/)
{
SvxColorItem aColorItem(pCollection->GetColor());
-if (aColorItem.GetThemeIndex() >= 0)
+sal_Int16 nIndex = aColorItem.GetThemeIndex();
+if (nIndex >= 0 && nIndex < 12)
{
-sal_Int16 nIndex = aColorItem.GetThemeIndex();
[Libreoffice-commits] core.git: Branch 'feature/themesupport2' - 9 commits - editeng/source include/editeng offapi/com svx/sdi svx/source sw/qa sw/source writerfilter/source
Rebased ref, commits from common ancestor:
commit 18da302474cc58314649a3bc6700651ed2d44c15
Author: Jan Holesovsky
AuthorDate: Fri Apr 2 00:21:34 2021 +0200
Commit: Tomaž Vajngerl
CommitDate: Thu Jun 17 13:15:19 2021 +0900
Unit test (with the content disabled so far) for the theming.
Change-Id: Ie9e003df38e1bc766fb5323936138d3e0e664321
diff --git a/sw/qa/extras/ooxmlexport/data/themeOrange.docx
b/sw/qa/extras/ooxmlexport/data/themeOrange.docx
new file mode 100644
index ..e350c2676d41
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/themeOrange.docx
differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
b/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
index b550e62ef6a2..7af07caa58d8 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
@@ -518,6 +518,12 @@ DECLARE_OOXMLEXPORT_EXPORTONLY_TEST(Test_ShadowDirection,
"tdf142361ShadowDirect
"rotWithShape", "0");
}
+DECLARE_OOXMLEXPORT_TEST(testThemeOrange, "themeOrange.docx")
+{
+// Assert that the theme color of the 1st paragraph is "accent1"
+//CPPUNIT_ASSERT_EQUAL(getProperty(getParagraph(1),
"CharColorTheme"), static_cast(4));
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
commit afcbc832cae0cd825e5c69748f8a7df2516bb689
Author: Tomaž Vajngerl
AuthorDate: Thu Sep 24 12:32:14 2015 +0200
Commit: Tomaž Vajngerl
CommitDate: Thu Jun 17 13:15:19 2021 +0900
Improve preview of theme color sets - add color set name
Change-Id: I1f7b3668ba9dfbab1da283741e99754de2d6be47
diff --git a/sw/source/uibase/sidebar/ThemePanel.cxx
b/sw/source/uibase/sidebar/ThemePanel.cxx
index 09a7665950c9..d41db8ffd659 100644
--- a/sw/source/uibase/sidebar/ThemePanel.cxx
+++ b/sw/source/uibase/sidebar/ThemePanel.cxx
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -371,17 +372,39 @@ BitmapEx GenerateColorPreview(const svx::ColorSet&
rColorSet)
{
ScopedVclPtrInstance
pVirtualDev(*Application::GetDefaultDevice());
float fScaleFactor = pVirtualDev->GetDPIScaleFactor();
-tools::Long BORDER = 2 * fScaleFactor;
-tools::Long SIZE = 12 * fScaleFactor;
+long BORDER = 3 * fScaleFactor;
+long SIZE = 14 * fScaleFactor;
+long LABEL_HEIGHT = 16 * fScaleFactor;
+long LABEL_TEXT_HEIGHT = 14 * fScaleFactor;
-Size aSize(BORDER * 7 + SIZE * 6, BORDER * 3 + SIZE * 2);
+Size aSize(BORDER * 7 + SIZE * 6 + BORDER * 2, BORDER * 3 + SIZE * 2 +
LABEL_HEIGHT);
pVirtualDev->SetOutputSizePixel(aSize);
+
pVirtualDev->SetBackground(Wallpaper(Application::GetSettings().GetStyleSettings().GetFaceColor()));
+pVirtualDev->Erase();
tools::Long x = BORDER;
-tools::Long y1 = BORDER;
+tools::Long y1 = BORDER + LABEL_HEIGHT;
tools::Long y2 = y1 + SIZE + BORDER;
pVirtualDev->SetLineColor(COL_LIGHTGRAY);
+pVirtualDev->SetFillColor(COL_LIGHTGRAY);
+tools::Rectangle aNameRect(Point(0, 0), Size(aSize.Width(), LABEL_HEIGHT));
+pVirtualDev->DrawRect(aNameRect);
+
+vcl::Font aFont;
+OUString aName = rColorSet.getName();
+aFont.SetFontHeight(LABEL_TEXT_HEIGHT);
+pVirtualDev->SetFont(aFont);
+
+Size aTextSize(pVirtualDev->GetTextWidth(aName),
pVirtualDev->GetTextHeight());
+
+Point aPoint((aNameRect.GetWidth() / 2.0) - (aTextSize.Width() / 2.0),
+ (aNameRect.GetHeight() / 2.0) - (aTextSize.Height() / 2.0));
+
+pVirtualDev->DrawText(aPoint, aName);
+
+pVirtualDev->SetLineColor(COL_LIGHTGRAY);
+pVirtualDev->SetFillColor();
for (sal_uInt32 i = 0; i < 12; i += 2)
{
@@ -392,6 +415,8 @@ BitmapEx GenerateColorPreview(const svx::ColorSet&
rColorSet)
pVirtualDev->DrawRect(tools::Rectangle(x, y2, x + SIZE, y2 + SIZE));
x += SIZE + BORDER;
+if (i == 2 || i == 8)
+x += BORDER;
}
return pVirtualDev->GetBitmapEx(Point(), aSize);
@@ -419,6 +444,7 @@ ThemePanel::ThemePanel(weld::Widget* pParent)
{
mxValueSetColors->SetColCount(2);
mxValueSetColors->SetLineCount(3);
+
mxValueSetColors->SetColor(Application::GetSettings().GetStyleSettings().GetFaceColor());
mxApplyButton->connect_clicked(LINK(this, ThemePanel, ClickHdl));
mxListBoxFonts->connect_row_activated(LINK(this, ThemePanel,
DoubleClickHdl));
commit bc94559bc118da7957799f36cf721cc2e7335eb7
Author: Tomaž Vajngerl
AuthorDate: Thu Sep 24 12:30:10 2015 +0200
Commit: Tomaž Vajngerl
CommitDate: Thu Jun 17 13:15:19 2021 +0900
StylePresets: set bacground color for ValueSet
Change-Id: Ifbaab139235dbe2fdcebf278bce2c91c2b744aa6
diff --git a/sw/source/uibase/sidebar/StylePresetsPanel.cxx
b/sw/source/uibase/sidebar/StylePresetsPanel.cxx
index 79b1b93ed34c..981f26b3e839 1
[Libreoffice-commits] core.git: Branch 'feature/themesupport2' - 2834 commits - accessibility/inc accessibility/README.md accessibility/source android/.gitignore android/README.md android/source anima
Rebased ref, commits from common ancestor:
commit 42fafd1cb63a63714d6f088201b06c7d5c10e0e1
Author: Jan Holesovsky
AuthorDate: Fri Apr 2 00:21:34 2021 +0200
Commit: Tomaž Vajngerl
CommitDate: Wed Jun 16 23:05:18 2021 +0900
Unit test (with the content disabled so far) for the theming.
Change-Id: Ie9e003df38e1bc766fb5323936138d3e0e664321
diff --git a/sw/qa/extras/ooxmlexport/data/themeOrange.docx
b/sw/qa/extras/ooxmlexport/data/themeOrange.docx
new file mode 100644
index ..e350c2676d41
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/themeOrange.docx
differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
b/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
index b550e62ef6a2..7af07caa58d8 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport16.cxx
@@ -518,6 +518,12 @@ DECLARE_OOXMLEXPORT_EXPORTONLY_TEST(Test_ShadowDirection,
"tdf142361ShadowDirect
"rotWithShape", "0");
}
+DECLARE_OOXMLEXPORT_TEST(testThemeOrange, "themeOrange.docx")
+{
+// Assert that the theme color of the 1st paragraph is "accent1"
+//CPPUNIT_ASSERT_EQUAL(getProperty(getParagraph(1),
"CharColorTheme"), static_cast(4));
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
commit 421e722049c937e24d8b4740e14de4e172845c16
Author: Tomaž Vajngerl
AuthorDate: Thu Sep 24 12:32:14 2015 +0200
Commit: Tomaž Vajngerl
CommitDate: Wed Jun 16 23:05:17 2021 +0900
Improve preview of theme color sets - add color set name
Change-Id: I1f7b3668ba9dfbab1da283741e99754de2d6be47
diff --git a/sw/source/uibase/sidebar/ThemePanel.cxx
b/sw/source/uibase/sidebar/ThemePanel.cxx
index 09a7665950c9..d41db8ffd659 100644
--- a/sw/source/uibase/sidebar/ThemePanel.cxx
+++ b/sw/source/uibase/sidebar/ThemePanel.cxx
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -371,17 +372,39 @@ BitmapEx GenerateColorPreview(const svx::ColorSet&
rColorSet)
{
ScopedVclPtrInstance
pVirtualDev(*Application::GetDefaultDevice());
float fScaleFactor = pVirtualDev->GetDPIScaleFactor();
-tools::Long BORDER = 2 * fScaleFactor;
-tools::Long SIZE = 12 * fScaleFactor;
+long BORDER = 3 * fScaleFactor;
+long SIZE = 14 * fScaleFactor;
+long LABEL_HEIGHT = 16 * fScaleFactor;
+long LABEL_TEXT_HEIGHT = 14 * fScaleFactor;
-Size aSize(BORDER * 7 + SIZE * 6, BORDER * 3 + SIZE * 2);
+Size aSize(BORDER * 7 + SIZE * 6 + BORDER * 2, BORDER * 3 + SIZE * 2 +
LABEL_HEIGHT);
pVirtualDev->SetOutputSizePixel(aSize);
+
pVirtualDev->SetBackground(Wallpaper(Application::GetSettings().GetStyleSettings().GetFaceColor()));
+pVirtualDev->Erase();
tools::Long x = BORDER;
-tools::Long y1 = BORDER;
+tools::Long y1 = BORDER + LABEL_HEIGHT;
tools::Long y2 = y1 + SIZE + BORDER;
pVirtualDev->SetLineColor(COL_LIGHTGRAY);
+pVirtualDev->SetFillColor(COL_LIGHTGRAY);
+tools::Rectangle aNameRect(Point(0, 0), Size(aSize.Width(), LABEL_HEIGHT));
+pVirtualDev->DrawRect(aNameRect);
+
+vcl::Font aFont;
+OUString aName = rColorSet.getName();
+aFont.SetFontHeight(LABEL_TEXT_HEIGHT);
+pVirtualDev->SetFont(aFont);
+
+Size aTextSize(pVirtualDev->GetTextWidth(aName),
pVirtualDev->GetTextHeight());
+
+Point aPoint((aNameRect.GetWidth() / 2.0) - (aTextSize.Width() / 2.0),
+ (aNameRect.GetHeight() / 2.0) - (aTextSize.Height() / 2.0));
+
+pVirtualDev->DrawText(aPoint, aName);
+
+pVirtualDev->SetLineColor(COL_LIGHTGRAY);
+pVirtualDev->SetFillColor();
for (sal_uInt32 i = 0; i < 12; i += 2)
{
@@ -392,6 +415,8 @@ BitmapEx GenerateColorPreview(const svx::ColorSet&
rColorSet)
pVirtualDev->DrawRect(tools::Rectangle(x, y2, x + SIZE, y2 + SIZE));
x += SIZE + BORDER;
+if (i == 2 || i == 8)
+x += BORDER;
}
return pVirtualDev->GetBitmapEx(Point(), aSize);
@@ -419,6 +444,7 @@ ThemePanel::ThemePanel(weld::Widget* pParent)
{
mxValueSetColors->SetColCount(2);
mxValueSetColors->SetLineCount(3);
+
mxValueSetColors->SetColor(Application::GetSettings().GetStyleSettings().GetFaceColor());
mxApplyButton->connect_clicked(LINK(this, ThemePanel, ClickHdl));
mxListBoxFonts->connect_row_activated(LINK(this, ThemePanel,
DoubleClickHdl));
commit 8d02d87a4d04b46607844c427db414b769355381
Author: Tomaž Vajngerl
AuthorDate: Thu Sep 24 12:30:10 2015 +0200
Commit: Tomaž Vajngerl
CommitDate: Wed Jun 16 23:05:16 2021 +0900
StylePresets: set bacground color for ValueSet
Change-Id: Ifbaab139235dbe2fdcebf278bce2c91c2b744aa6
diff --git a/sw/source/uibase/sidebar/StylePresetsPanel.cxx
b/sw/source/uibase/sidebar/StylePresetsPanel.cxx
index 79b1b93ed34c..981f26b3e839 1
[Libreoffice-commits] core.git: sc/source
sc/source/ui/app/inputhdl.cxx |5 +++--
sc/source/ui/unoobj/docuno.cxx |5 +
2 files changed, 8 insertions(+), 2 deletions(-)
New commits:
commit 0dc9da5df470b9c345e78dbe9553d81b9e4a7435
Author: Jan Holesovsky
AuthorDate: Wed Mar 24 15:39:05 2021 +0100
Commit: Jan Holesovsky
CommitDate: Thu Apr 29 17:53:57 2021 +0200
lok: Disable the "AutoInput" again.
This partially reverts "lok: sc - suppress LOK editengine events for the
calc input bar."
The feature itself is very problematic in Online:
1) causes unwanted jumps to other cells,
2) causes the selection blinking in the cell when typing, and
3) it is very annoying in the form that in which it is implemented
in LibreOffice anyway, compared to other office suites.
Let's disable it, and enable again when we address the above issues.
This (partially) reverts commit 91319ad56887f932b2da334db560d5d0a79a0280.
Change-Id: I2234455c29069f74d13896474f3499035935931b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113047
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Jan Holesovsky
(cherry picked from commit 65990058f041c3f1d280a69d411eb4ceacf5a721)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113112
Tested-by: Jenkins
diff --git a/sc/source/ui/app/inputhdl.cxx b/sc/source/ui/app/inputhdl.cxx
index 3abf07641963..bca87cd88aaa 100644
--- a/sc/source/ui/app/inputhdl.cxx
+++ b/sc/source/ui/app/inputhdl.cxx
@@ -801,7 +801,6 @@ ScInputHandler::ScInputHandler()
if (comphelper::LibreOfficeKit::isActive())
{
ScInputHandler::bOptLoaded = true;// Evaluate App options
-ScInputHandler::bAutoComplete = true; // Is set in KeyInput
}
}
@@ -2707,7 +2706,9 @@ void ScInputHandler::UpdateFormulaMode()
if (pInputWin)
pInputWin->SetFormulaMode(true);
-if ( bAutoComplete )
+// in LOK, we always need to perform the GetFormulaData() call so
+// that the formula insertion works
+if (bAutoComplete || comphelper::LibreOfficeKit::isActive())
GetFormulaData();
UpdateParenthesis();
diff --git a/sc/source/ui/unoobj/docuno.cxx b/sc/source/ui/unoobj/docuno.cxx
index 371cb395e139..1729c2ca1cdb 100644
--- a/sc/source/ui/unoobj/docuno.cxx
+++ b/sc/source/ui/unoobj/docuno.cxx
@@ -1179,6 +1179,11 @@ void ScModelObj::initializeForTiledRendering(const
css::uno::SequenceGetAppOptions() );
+aAppOptions.SetAutoComplete(false);
+SC_MOD()->SetAppOptions(aAppOptions);
+
for (const beans::PropertyValue& rValue : rArguments)
{
if (rValue.Name == ".uno:SpellOnline" && rValue.Value.has())
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'distro/collabora/co-2021' - sw/source
sw/source/core/doc/docredln.cxx | 16
1 file changed, 12 insertions(+), 4 deletions(-)
New commits:
commit dc401a7b0ae419a8f8bb433850046281c61bca74
Author: Jan Holesovsky
AuthorDate: Tue Nov 24 15:34:55 2020 +0100
Commit: Andras Timar
CommitDate: Thu Apr 8 00:04:02 2021 +0200
lok: Don't even iterate through the redlines when they are disabled.
It is not necessary, when we are not issuing any output anyway.
Change-Id: Id952549befb1bef04a2dd9237d286922939eaae2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106509
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Miklos Vajna
(cherry picked from commit 8f44a939ad09d0365607ae8960e2abfe77e3fe72)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106517
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
diff --git a/sw/source/core/doc/docredln.cxx b/sw/source/core/doc/docredln.cxx
index a41348027471..354aa058d9ed 100644
--- a/sw/source/core/doc/docredln.cxx
+++ b/sw/source/core/doc/docredln.cxx
@@ -341,14 +341,22 @@ void lcl_LOKInvalidateStartEndFrames(SwShellCursor&
rCursor)
FRM_CNTNT, &rCursor.GetEndPos());
}
+bool lcl_LOKRedlineNotificationEnabled()
+{
+static bool bDisableRedlineComments = getenv("DISABLE_REDLINE") != nullptr;
+if (comphelper::LibreOfficeKit::isActive() && !bDisableRedlineComments)
+return true;
+
+return false;
+}
+
} // anonymous namespace
/// Emits LOK notification about one addition / removal of a redline item.
void SwRedlineTable::LOKRedlineNotification(RedlineNotification nType,
SwRangeRedline* pRedline)
{
// Disable since usability is very low beyond some small number of changes.
-static bool bDisableRedlineComments = getenv("DISABLE_REDLINE") != nullptr;
-if (!comphelper::LibreOfficeKit::isActive() || bDisableRedlineComments)
+if (!lcl_LOKRedlineNotificationEnabled())
return;
boost::property_tree::ptree aRedline;
@@ -1038,7 +1046,7 @@ SwRangeRedline::~SwRangeRedline()
void MaybeNotifyRedlineModification(SwRangeRedline& rRedline, SwDoc& rDoc)
{
-if (!comphelper::LibreOfficeKit::isActive())
+if (!lcl_LOKRedlineNotificationEnabled())
return;
const SwRedlineTable& rRedTable =
rDoc.getIDocumentRedlineAccess().GetRedlineTable();
@@ -1054,7 +1062,7 @@ void MaybeNotifyRedlineModification(SwRangeRedline&
rRedline, SwDoc& rDoc)
void SwRangeRedline::MaybeNotifyRedlinePositionModification(tools::Long nTop)
{
-if (!comphelper::LibreOfficeKit::isActive())
+if (!lcl_LOKRedlineNotificationEnabled())
return;
if(!m_oLOKLastNodeTop || *m_oLOKLastNodeTop != nTop)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'feature/themesupport2'
New branch 'feature/themesupport2' available with the following commits: commit fafb9498ee7a83c77b45e161f4b1372a2d25cb0f Author: Jan Holesovsky Date: Fri Apr 2 00:21:34 2021 +0200 Unit test (with the content disabled so far) for the theming. Change-Id: Ie9e003df38e1bc766fb5323936138d3e0e664321 commit ea7755fcc195d48959c2ab1341031cd63fd8157d Author: Tomaž Vajngerl Date: Thu Sep 24 12:32:14 2015 +0200 Improve preview of theme color sets - add color set name Change-Id: I1f7b3668ba9dfbab1da283741e99754de2d6be47 commit 5b562d0f69153aa3e8b4657985b607ea7b3f1d6e Author: Tomaž Vajngerl Date: Thu Sep 24 12:30:10 2015 +0200 StylePresets: set bacground color for ValueSet Change-Id: Ifbaab139235dbe2fdcebf278bce2c91c2b744aa6 commit 90a50a8098b958f5439ce67c823240427c348142 Author: Tomaž Vajngerl Date: Wed Sep 23 13:38:38 2015 +0200 adjust the conversion from theme color type to the color set index Change-Id: I8c54c8935de8acc3e2b302e10327aa2488f9ac85 commit 8d9ded86502cb72a9990ee340d47674825ac7bc7 Author: Tomaž Vajngerl Date: Wed Sep 23 13:37:43 2015 +0200 convert tint value from ooxml to the value we support Change-Id: I5a79ca434be16f9dccc5aa6118a7efbf4544f0b1 commit f26ebb15e0a5d582363de86c36614811d75b406c Author: Tomaž Vajngerl Date: Wed Sep 23 13:35:56 2015 +0200 check that the color index is valid Change-Id: Id5c7c83f50e1611af12f3b25e6c9a335a8353ba0 commit 6a2bd264bc5b9560788a9c10b81a80ab4ac20ef9 Author: Tomaž Vajngerl Date: Wed Sep 23 13:33:59 2015 +0200 swap text and background colors in colorsets Change-Id: I1e1da85d6c58e3ed5ab4c44c2ab0ae7c3b080251 commit ecd52b7ae86890afed422f498bd272466069533d Author: Tomaž Vajngerl Date: Sun Sep 20 19:27:09 2015 +0200 Support reading back theme color from an ooxml document ooxml supports theme colors and tint/shade value that additionally changed the theme color. Read back which theme color + tint/shade value was applied in the resulting color and add this attributes as properties to be used by writer. In sidebar theme panel the changing the theme colors now doesn't takes this into account and changes the colors correctly. Change-Id: I6703e86b1fc6b2ba07f3023ec48e619aec961ff1 commit 91f29d5b2585dbe51e2bc44a32a52bdbe5378477 Author: Tomaž Vajngerl Date: Sun Sep 20 19:20:59 2015 +0200 Theme color and tint/shade attribute for SvxColorItem To support theme colors the SvxColorItem must be extended with an optional attribute theme index to define the index to which theme color current color belongs and an optional tint/shade attribute define how much the color ha been additionally tinted or shaded. Change-Id: I87b7788ead25f956eeec835ba80df5e913790697 ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.4' - sc/source
sc/source/ui/app/inputhdl.cxx |5 +++--
sc/source/ui/unoobj/docuno.cxx |5 +
2 files changed, 8 insertions(+), 2 deletions(-)
New commits:
commit 65990058f041c3f1d280a69d411eb4ceacf5a721
Author: Jan Holesovsky
AuthorDate: Wed Mar 24 15:39:05 2021 +0100
Commit: Jan Holesovsky
CommitDate: Thu Mar 25 15:51:48 2021 +0100
lok: Disable the "AutoInput" again.
This partially reverts "lok: sc - suppress LOK editengine events for the
calc input bar."
The feature itself is very problematic in Online:
1) causes unwanted jumps to other cells,
2) causes the selection blinking in the cell when typing, and
3) it is very annoying in the form that in which it is implemented
in LibreOffice anyway, compared to other office suites.
Let's disable it, and enable again when we address the above issues.
This (partially) reverts commit 91319ad56887f932b2da334db560d5d0a79a0280.
Change-Id: I2234455c29069f74d13896474f3499035935931b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113047
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Jan Holesovsky
diff --git a/sc/source/ui/app/inputhdl.cxx b/sc/source/ui/app/inputhdl.cxx
index 7e0bb9272970..954af2a304cd 100644
--- a/sc/source/ui/app/inputhdl.cxx
+++ b/sc/source/ui/app/inputhdl.cxx
@@ -806,7 +806,6 @@ ScInputHandler::ScInputHandler()
if (comphelper::LibreOfficeKit::isActive())
{
ScInputHandler::bOptLoaded = true;// Evaluate App options
-ScInputHandler::bAutoComplete = true; // Is set in KeyInput
}
}
@@ -2680,7 +2679,9 @@ void ScInputHandler::UpdateFormulaMode()
if (pInputWin)
pInputWin->SetFormulaMode(true);
-if ( bAutoComplete )
+// in LOK, we always need to perform the GetFormulaData() call so
+// that the formula insertion works
+if (bAutoComplete || comphelper::LibreOfficeKit::isActive())
GetFormulaData();
UpdateParenthesis();
diff --git a/sc/source/ui/unoobj/docuno.cxx b/sc/source/ui/unoobj/docuno.cxx
index 0e74d7dd5cda..9d2539a25bcd 100644
--- a/sc/source/ui/unoobj/docuno.cxx
+++ b/sc/source/ui/unoobj/docuno.cxx
@@ -1177,6 +1177,11 @@ void ScModelObj::initializeForTiledRendering(const
css::uno::SequenceGetAppOptions() );
+aAppOptions.SetAutoComplete(false);
+SC_MOD()->SetAppOptions(aAppOptions);
+
for (const beans::PropertyValue& rValue : rArguments)
{
if (rValue.Name == ".uno:SpellOnline" && rValue.Value.has())
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.2' - sw/source
sw/source/core/doc/docredln.cxx | 16
1 file changed, 12 insertions(+), 4 deletions(-)
New commits:
commit 8e996d7aa41d29b46964c656f4f959316e5ad265
Author: Jan Holesovsky
AuthorDate: Tue Nov 24 15:34:55 2020 +0100
Commit: Miklos Vajna
CommitDate: Thu Nov 26 13:50:32 2020 +0100
lok: Don't even iterate through the redlines when they are disabled.
It is not necessary, when we are not issuing any output anyway.
Change-Id: Id952549befb1bef04a2dd9237d286922939eaae2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106509
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Miklos Vajna
(cherry picked from commit 8f44a939ad09d0365607ae8960e2abfe77e3fe72)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106516
diff --git a/sw/source/core/doc/docredln.cxx b/sw/source/core/doc/docredln.cxx
index a3fabfaf514d..174437ea4156 100644
--- a/sw/source/core/doc/docredln.cxx
+++ b/sw/source/core/doc/docredln.cxx
@@ -355,14 +355,22 @@ void lcl_LOKInvalidateStartEndFrames(SwShellCursor&
rCursor)
FRM_CNTNT, &rCursor.GetEndPos());
}
+bool lcl_LOKRedlineNotificationEnabled()
+{
+static bool bDisableRedlineComments = getenv("DISABLE_REDLINE") != nullptr;
+if (comphelper::LibreOfficeKit::isActive() && !bDisableRedlineComments)
+return true;
+
+return false;
+}
+
} // anonymous namespace
/// Emits LOK notification about one addition / removal of a redline item.
void SwRedlineTable::LOKRedlineNotification(RedlineNotification nType,
SwRangeRedline* pRedline)
{
// Disable since usability is very low beyond some small number of changes.
-static bool bDisableRedlineComments = getenv("DISABLE_REDLINE") != nullptr;
-if (!comphelper::LibreOfficeKit::isActive() || bDisableRedlineComments)
+if (!lcl_LOKRedlineNotificationEnabled())
return;
boost::property_tree::ptree aRedline;
@@ -1091,7 +1099,7 @@ SwRangeRedline::~SwRangeRedline()
void MaybeNotifyRedlineModification(SwRangeRedline* pRedline, SwDoc* pDoc)
{
-if (!comphelper::LibreOfficeKit::isActive())
+if (!lcl_LOKRedlineNotificationEnabled())
return;
const SwRedlineTable& rRedTable =
pDoc->getIDocumentRedlineAccess().GetRedlineTable();
@@ -1107,7 +1115,7 @@ void MaybeNotifyRedlineModification(SwRangeRedline*
pRedline, SwDoc* pDoc)
void SwRangeRedline::MaybeNotifyRedlinePositionModification(long nTop)
{
-if (!comphelper::LibreOfficeKit::isActive())
+if (!lcl_LOKRedlineNotificationEnabled())
return;
if(!m_oLOKLastNodeTop || *m_oLOKLastNodeTop != nTop)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: sw/source
sw/source/core/doc/docredln.cxx | 16
1 file changed, 12 insertions(+), 4 deletions(-)
New commits:
commit 56e7c74b2994ead8b1f376b65549ad8a623018cd
Author: Jan Holesovsky
AuthorDate: Tue Nov 24 15:34:55 2020 +0100
Commit: Jan Holesovsky
CommitDate: Wed Nov 25 11:02:35 2020 +0100
lok: Don't even iterate through the redlines when they are disabled.
It is not necessary, when we are not issuing any output anyway.
Change-Id: Id952549befb1bef04a2dd9237d286922939eaae2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106509
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Miklos Vajna
(cherry picked from commit 8f44a939ad09d0365607ae8960e2abfe77e3fe72)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106517
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky
diff --git a/sw/source/core/doc/docredln.cxx b/sw/source/core/doc/docredln.cxx
index ab57f1bb6b50..8a0f8d4b3597 100644
--- a/sw/source/core/doc/docredln.cxx
+++ b/sw/source/core/doc/docredln.cxx
@@ -341,14 +341,22 @@ void lcl_LOKInvalidateStartEndFrames(SwShellCursor&
rCursor)
FRM_CNTNT, &rCursor.GetEndPos());
}
+bool lcl_LOKRedlineNotificationEnabled()
+{
+static bool bDisableRedlineComments = getenv("DISABLE_REDLINE") != nullptr;
+if (comphelper::LibreOfficeKit::isActive() && !bDisableRedlineComments)
+return true;
+
+return false;
+}
+
} // anonymous namespace
/// Emits LOK notification about one addition / removal of a redline item.
void SwRedlineTable::LOKRedlineNotification(RedlineNotification nType,
SwRangeRedline* pRedline)
{
// Disable since usability is very low beyond some small number of changes.
-static bool bDisableRedlineComments = getenv("DISABLE_REDLINE") != nullptr;
-if (!comphelper::LibreOfficeKit::isActive() || bDisableRedlineComments)
+if (!lcl_LOKRedlineNotificationEnabled())
return;
boost::property_tree::ptree aRedline;
@@ -1044,7 +1052,7 @@ SwRangeRedline::~SwRangeRedline()
void MaybeNotifyRedlineModification(SwRangeRedline& rRedline, SwDoc& rDoc)
{
-if (!comphelper::LibreOfficeKit::isActive())
+if (!lcl_LOKRedlineNotificationEnabled())
return;
const SwRedlineTable& rRedTable =
rDoc.getIDocumentRedlineAccess().GetRedlineTable();
@@ -1060,7 +1068,7 @@ void MaybeNotifyRedlineModification(SwRangeRedline&
rRedline, SwDoc& rDoc)
void SwRangeRedline::MaybeNotifyRedlinePositionModification(tools::Long nTop)
{
-if (!comphelper::LibreOfficeKit::isActive())
+if (!lcl_LOKRedlineNotificationEnabled())
return;
if(!m_oLOKLastNodeTop || *m_oLOKLastNodeTop != nTop)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.4' - sw/source
sw/source/core/doc/docredln.cxx | 16
1 file changed, 12 insertions(+), 4 deletions(-)
New commits:
commit 8f44a939ad09d0365607ae8960e2abfe77e3fe72
Author: Jan Holesovsky
AuthorDate: Tue Nov 24 15:34:55 2020 +0100
Commit: Miklos Vajna
CommitDate: Tue Nov 24 16:40:01 2020 +0100
lok: Don't even iterate through the redlines when they are disabled.
It is not necessary, when we are not issuing any output anyway.
Change-Id: Id952549befb1bef04a2dd9237d286922939eaae2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106509
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Miklos Vajna
diff --git a/sw/source/core/doc/docredln.cxx b/sw/source/core/doc/docredln.cxx
index b3a1e6d6337b..3987957d920a 100644
--- a/sw/source/core/doc/docredln.cxx
+++ b/sw/source/core/doc/docredln.cxx
@@ -339,14 +339,22 @@ void lcl_LOKInvalidateStartEndFrames(SwShellCursor&
rCursor)
FRM_CNTNT, &rCursor.GetEndPos());
}
+bool lcl_LOKRedlineNotificationEnabled()
+{
+static bool bDisableRedlineComments = getenv("DISABLE_REDLINE") != nullptr;
+if (comphelper::LibreOfficeKit::isActive() && !bDisableRedlineComments)
+return true;
+
+return false;
+}
+
} // anonymous namespace
/// Emits LOK notification about one addition / removal of a redline item.
void SwRedlineTable::LOKRedlineNotification(RedlineNotification nType,
SwRangeRedline* pRedline)
{
// Disable since usability is very low beyond some small number of changes.
-static bool bDisableRedlineComments = getenv("DISABLE_REDLINE") != nullptr;
-if (!comphelper::LibreOfficeKit::isActive() || bDisableRedlineComments)
+if (!lcl_LOKRedlineNotificationEnabled())
return;
boost::property_tree::ptree aRedline;
@@ -1031,7 +1039,7 @@ SwRangeRedline::~SwRangeRedline()
void MaybeNotifyRedlineModification(SwRangeRedline* pRedline, SwDoc* pDoc)
{
-if (!comphelper::LibreOfficeKit::isActive())
+if (!lcl_LOKRedlineNotificationEnabled())
return;
const SwRedlineTable& rRedTable =
pDoc->getIDocumentRedlineAccess().GetRedlineTable();
@@ -1047,7 +1055,7 @@ void MaybeNotifyRedlineModification(SwRangeRedline*
pRedline, SwDoc* pDoc)
void SwRangeRedline::MaybeNotifyRedlinePositionModification(long nTop)
{
-if (!comphelper::LibreOfficeKit::isActive())
+if (!lcl_LOKRedlineNotificationEnabled())
return;
if(!m_oLOKLastNodeTop || *m_oLOKLastNodeTop != nTop)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.4' - chart2/source desktop/source
chart2/source/controller/sidebar/ChartElementsPanel.cxx | 20 +---
desktop/source/lib/init.cxx | 10 +++-
2 files changed, 21 insertions(+), 9 deletions(-)
New commits:
commit c5bd74c0ace401812be416a295c71a6604f8240d
Author: Jan Holesovsky
AuthorDate: Fri Oct 16 14:34:43 2020 +0200
Commit: Jan Holesovsky
CommitDate: Wed Nov 18 19:52:08 2020 +0100
lok: Make the chart (sub)title work even from the mobile-wizard.
Change-Id: Ic6346a403639e283ade47429f581f91e7a468f63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104436
Tested-by: Andras Timar
Reviewed-by: Andras Timar
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105617
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Jan Holesovsky
diff --git a/chart2/source/controller/sidebar/ChartElementsPanel.cxx
b/chart2/source/controller/sidebar/ChartElementsPanel.cxx
index 68175acd46d2..a4771b76ee0c 100644
--- a/chart2/source/controller/sidebar/ChartElementsPanel.cxx
+++ b/chart2/source/controller/sidebar/ChartElementsPanel.cxx
@@ -427,19 +427,23 @@ void ChartElementsPanel::updateData()
bool hasTitle = isTitleVisisble(mxModel, TitleHelper::MAIN_TITLE);
mpCBTitle->Check(hasTitle);
-if (!mpEditTitle->HasFocus())
-{
-
mpEditTitle->SetText(TitleHelper::getCompleteString(TitleHelper::getTitle(TitleHelper::MAIN_TITLE,
mxModel)));
+
+OUString title = mpEditTitle->GetText();
+OUString newTitle =
TitleHelper::getCompleteString(TitleHelper::getTitle(TitleHelper::MAIN_TITLE,
mxModel));
+if (title != newTitle)
+mpEditTitle->SetText(newTitle);
+if (mpEditTitle->IsEnabled() != hasTitle)
mpEditTitle->Enable(hasTitle);
-}
bool hasSubtitle = isTitleVisisble(mxModel, TitleHelper::SUB_TITLE);
mpCBSubtitle->Check(hasSubtitle);
-if (!mpEditSubtitle->HasFocus())
-{
-
mpEditSubtitle->SetText(TitleHelper::getCompleteString(TitleHelper::getTitle(TitleHelper::SUB_TITLE,
mxModel)));
+
+OUString subtitle = mpEditSubtitle->GetText();
+OUString newSubtitle =
TitleHelper::getCompleteString(TitleHelper::getTitle(TitleHelper::SUB_TITLE,
mxModel));
+if (subtitle != newSubtitle)
+mpEditSubtitle->SetText(newSubtitle);
+if (mpEditSubtitle->IsEnabled() != hasSubtitle)
mpEditSubtitle->Enable(hasSubtitle);
-}
mpCBXAxisTitle->Check(isTitleVisisble(mxModel, TitleHelper::X_AXIS_TITLE));
mpCBYAxisTitle->Check(isTitleVisisble(mxModel, TitleHelper::Y_AXIS_TITLE));
diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index f527656333b6..b37c85ffbc63 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -3724,6 +3724,7 @@ static void doc_sendDialogEvent(LibreOfficeKitDocument*
/*pThis*/, unsigned long
{
static const OUString sClickAction("CLICK");
static const OUString sSelectAction("SELECT");
+static const OUString sSetAction("SET");
static const OUString sClearAction("CLEAR");
static const OUString sTypeAction("TYPE");
static const OUString sUpAction("UP");
@@ -3749,6 +3750,7 @@ static void doc_sendDialogEvent(LibreOfficeKitDocument*
/*pThis*/, unsigned long
if (!bIsWeldedDialog)
{
+OUString sControlType = aMap["type"];
OUString sAction((aMap.find("cmd") != aMap.end())?
aMap["cmd"]: "");
WindowUIObject aUIObject(pWindow);
std::unique_ptr
pUIWindow(aUIObject.get_visible_child(aMap["id"]));
@@ -3774,9 +3776,15 @@ static void doc_sendDialogEvent(LibreOfficeKitDocument*
/*pThis*/, unsigned long
{
aMap["TEXT"] = aMap["data"];
-pUIWindow->execute(sClearAction, aMap);
+pUIWindow->execute(sClearAction, aMap); // FIXME -
change the "CLEAR"&"TYPE" to "SET" and test thoroughly; the "TYPE" really types
a character by character
pUIWindow->execute(sTypeAction, aMap);
}
+else if (sControlType == "edit" && sAction == "change") //
FIXME - shouldn't "edit" issue "set" instead of "change"?
+{
+aMap["TEXT"] = aMap["data"];
+
+pUIWindow->execute(sSetAction, aMap);
+}
else if (sAction == "value")
{
aMap["VALUE"] = aMap["data"];
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.4' - desktop/source
desktop/source/lib/init.cxx | 50 ++--
1 file changed, 21 insertions(+), 29 deletions(-)
New commits:
commit cd475b517abcace4ed79bfd129e4487d60513b30
Author: Jan Holesovsky
AuthorDate: Thu Oct 15 18:05:35 2020 +0200
Commit: Muhammet Kara
CommitDate: Mon Nov 16 01:11:08 2020 +0100
lok: Simplify the check for command in sendDialogEvent.
Change-Id: I1d2c967b68113d2528b80e91c32170f749ed9335
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104434
Tested-by: Andras Timar
Reviewed-by: Andras Timar
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105615
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Muhammet Kara
diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index 210ce2d84d34..f527656333b6 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -3749,43 +3749,35 @@ static void doc_sendDialogEvent(LibreOfficeKitDocument*
/*pThis*/, unsigned long
if (!bIsWeldedDialog)
{
+OUString sAction((aMap.find("cmd") != aMap.end())?
aMap["cmd"]: "");
WindowUIObject aUIObject(pWindow);
std::unique_ptr
pUIWindow(aUIObject.get_visible_child(aMap["id"]));
if (pUIWindow) {
bool bIsClickAction = false;
-if (aMap.find("cmd") != aMap.end()) {
-if (aMap["cmd"] == "selected")
-{
-aMap["POS"] = aMap["data"];
-aMap["TEXT"] = aMap["data"];
+if (sAction == "selected")
+{
+aMap["POS"] = aMap["data"];
+aMap["TEXT"] = aMap["data"];
-pUIWindow->execute(sSelectAction, aMap);
-}
-else if (aMap["cmd"] == "plus")
-{
-pUIWindow->execute(sUpAction, aMap);
-}
-else if (aMap["cmd"] == "minus")
-{
-pUIWindow->execute(sDownAction, aMap);
-}
-else if (aMap["cmd"] == "set")
-{
-aMap["TEXT"] = aMap["data"];
+pUIWindow->execute(sSelectAction, aMap);
+}
+else if (sAction == "plus")
+{
+pUIWindow->execute(sUpAction, aMap);
+}
+else if (sAction == "minus")
+{
+pUIWindow->execute(sDownAction, aMap);
+}
+else if (sAction == "set")
+{
+aMap["TEXT"] = aMap["data"];
-pUIWindow->execute(sClearAction, aMap);
-pUIWindow->execute(sTypeAction, aMap);
-}
-else if (aMap["cmd"] == "value")
-{
-aMap["VALUE"] = aMap["data"];
-pUIWindow->execute(sValue, aMap);
-}
-else
-bIsClickAction = true;
+pUIWindow->execute(sClearAction, aMap);
+pUIWindow->execute(sTypeAction, aMap);
}
-else if (aMap["cmd"] == "value")
+else if (sAction == "value")
{
aMap["VALUE"] = aMap["data"];
pUIWindow->execute(sValue, aMap);
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: sw/qa vcl/source
sw/qa/uitest/writer_tests3/customizeDialog.py |2 +-
vcl/source/uitest/uiobject.cxx| 13 -
2 files changed, 13 insertions(+), 2 deletions(-)
New commits:
commit 706aff509857a79cbd93a76410e63931747369f5
Author: Jan Holesovsky
AuthorDate: Fri Oct 16 14:27:27 2020 +0200
Commit: Andras Timar
CommitDate: Sun Nov 15 15:41:56 2020 +0100
uitest: Rename the "SET" to "TYPE" for Edit boxes + implement the real
"SET".
To be consistent with the other controls: "TYPE" actually enters the
characters one by one, while "SET" sets it as a whole.
Change-Id: I967dc270b1d92fe76107732a511cc3e70d3d65c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104435
Tested-by: Andras Timar
Reviewed-by: Andras Timar
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105739
Tested-by: Jenkins
diff --git a/sw/qa/uitest/writer_tests3/customizeDialog.py
b/sw/qa/uitest/writer_tests3/customizeDialog.py
index 5b6ab664346a..52adae2b0ee1 100644
--- a/sw/qa/uitest/writer_tests3/customizeDialog.py
+++ b/sw/qa/uitest/writer_tests3/customizeDialog.py
@@ -35,7 +35,7 @@ class ConfigureDialog(UITestCase):
initialEntryCount = get_state_as_dict(xfunc)["Children"]
self.assertTrue(initialEntryCount != 0)
-xSearch.executeAction("SET", mkPropertyValues({"TEXT":"format"}))
+xSearch.executeAction("TYPE", mkPropertyValues({"TEXT":"format"}))
# Wait for the search/filter op to be completed
timeout = time.time() + 1
diff --git a/vcl/source/uitest/uiobject.cxx b/vcl/source/uitest/uiobject.cxx
index 32d8d2417f0f..90322d500611 100644
--- a/vcl/source/uitest/uiobject.cxx
+++ b/vcl/source/uitest/uiobject.cxx
@@ -720,7 +720,7 @@ void EditUIObject::execute(const OUString& rAction,
const StringMap& rParameters)
{
bool bHandled = true;
-if (rAction == "SET")
+if (rAction == "TYPE")
{
if (rParameters.find("TEXT") != rParameters.end())
{
@@ -743,6 +743,17 @@ void EditUIObject::execute(const OUString& rAction,
bHandled = false;
}
}
+else if (rAction == "SET")
+{
+auto it = rParameters.find("TEXT");
+if (it != rParameters.end())
+{
+mxEdit->SetText(it->second);
+mxEdit->Modify();
+}
+else
+bHandled = false;
+}
else if (rAction == "SELECT")
{
if (rParameters.find("FROM") != rParameters.end() &&
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.4' - uitest/writer_tests vcl/source
uitest/writer_tests/customizeDialog.py |2 +-
vcl/source/uitest/uiobject.cxx | 13 -
2 files changed, 13 insertions(+), 2 deletions(-)
New commits:
commit fc5aeeb8d9d44808d18880f6812075830bb5d11c
Author: Jan Holesovsky
AuthorDate: Fri Oct 16 14:27:27 2020 +0200
Commit: Andras Timar
CommitDate: Sun Nov 15 15:42:17 2020 +0100
uitest: Rename the "SET" to "TYPE" for Edit boxes + implement the real
"SET".
To be consistent with the other controls: "TYPE" actually enters the
characters one by one, while "SET" sets it as a whole.
Also I believe Modify() should be called, not UpdateData()...
Change-Id: I967dc270b1d92fe76107732a511cc3e70d3d65c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104435
Tested-by: Andras Timar
Reviewed-by: Andras Timar
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105616
Tested-by: Jenkins CollaboraOffice
diff --git a/uitest/writer_tests/customizeDialog.py
b/uitest/writer_tests/customizeDialog.py
index 9d2311eb46a6..5812c51e098e 100644
--- a/uitest/writer_tests/customizeDialog.py
+++ b/uitest/writer_tests/customizeDialog.py
@@ -36,7 +36,7 @@ class ConfigureDialog(UITestCase):
initialEntryCount = get_state_as_dict(xfunc)["Children"]
self.assertTrue(initialEntryCount is not 0)
-xSearch.executeAction("SET", mkPropertyValues({"TEXT":"format"}))
+xSearch.executeAction("TYPE", mkPropertyValues({"TEXT":"format"}))
# Wait for the search/filter op to be completed
time.sleep(1)
diff --git a/vcl/source/uitest/uiobject.cxx b/vcl/source/uitest/uiobject.cxx
index 3d6242697066..818a4513b7f6 100644
--- a/vcl/source/uitest/uiobject.cxx
+++ b/vcl/source/uitest/uiobject.cxx
@@ -710,7 +710,7 @@ void EditUIObject::execute(const OUString& rAction,
const StringMap& rParameters)
{
bool bHandled = true;
-if (rAction == "SET")
+if (rAction == "TYPE")
{
if (rParameters.find("TEXT") != rParameters.end())
{
@@ -733,6 +733,17 @@ void EditUIObject::execute(const OUString& rAction,
bHandled = false;
}
}
+else if (rAction == "SET")
+{
+auto it = rParameters.find("TEXT");
+if (it != rParameters.end())
+{
+mxEdit->SetText(it->second);
+mxEdit->Modify();
+}
+else
+bHandled = false;
+}
else if (rAction == "SELECT")
{
if (rParameters.find("FROM") != rParameters.end() &&
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
