Re: New options "Hide" and "With condition" in the bookmark dialog unclear

[Michael Weghorn]

On 26/11/2019 13.08, Heiko Tietze wrote:
> That's quite vague. I suggest to make it experimental until we have a 
> documentation. Should work for your customer anyway. Patch is here 
> https://gerrit.libreoffice.org/#/c/83509/

I was told that the WollMux extension uses the functionality via UNO
API, which will be unaffected by hiding the UI elements anyway
For some more background, s.a. tdf#101856 ("MAILMERGE Add conditional to
expand / collapse bookmarks").

Therefore, hiding the UI parts until the polishing has actually happened
sounds like a good idea, IMHO.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Building skia with clang(-cl)

[Michael Weghorn]

On 08/06/2020 15.16, Rene Engelhard wrote:
> (I consider the existence of gen a problem, too, maybe I should just
> make -gtk3 a non-optional part.
> 
> But still then afaik the desktop detector will still use "gen" on e.g.
> fluxbox or so, didn't actually check lately?)

IIRC, Caolán mentioned that on IRC yesterday already:
Unless explicitly specified otherwise (like setting SAL_USE_VCLPLUGIN
env variable), "gen" is the last choice, so won't be used if another VCL
plugin is present and can be loaded, s. [1].

[1]
https://git.libreoffice.org/core/+/4c4b3218b8595a9809ffade0cfd064f3d9335dff/vcl/source/app/salplug.cxx#228
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 6.4.4.4 libssl error

[Michael Weghorn]

On 09/06/2020 08.18, Chetan Aru wrote:
> Thanks for pointing it out.
> How do I get my build of 6.4.4.2 to ignore these errors then? I can
> build with VS17 as well as VS19.
> Is there any flag that I need to setup during build?

I can't tell what the exact circumstances were that made it work for
"some people" while it broke for others (and am not building on Windows
myself usually).
Anyway, is there any specific reason to not just apply the patch that
fixes the issue (or build a branch that already has it)?

> 
> On Tue, 9 Jun 2020 at 11:35 AM, Michael Weghorn  <mailto:m.wegh...@posteo.de>> wrote:
> 
> On 09/06/2020 06.48, Chetan Aru wrote:
> > I am trying to build the LibreOffice 6.4.4.4 tag on Windows machine
> > (Virtual Machine). I have installed cygwin 64-bit and doing 64-bit
> > build. I am getting the following errors. Can someone please help?
> Seems
> > that having this patch (
> https://gerrit.libreoffice.org/c/core/+/95559)
> > helps, but how is it that 6.4.4.4 was built on Windows machine
> without this?
> 
> The commit message of the commit you're pointing to says:
> 
> "For other people these failures are silently ignored, but they
> show up in their python3 build.log. But my msbuild version
> 15.9.21+g9802d43bc3 from VS2017 fails hard on these errors."
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
> 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Building skia with clang(-cl)

[Michael Weghorn]

On 09/06/2020 08.32, Rene Engelhard wrote:
> Hi,
> 
> Am 09.06.20 um 08:18 schrieb Michael Weghorn:
>> On 08/06/2020 15.16, Rene Engelhard wrote:
>>> (I consider the existence of gen a problem, too, maybe I should just
>>> make -gtk3 a non-optional part.
>>>
>>> But still then afaik the desktop detector will still use "gen" on e.g.
>>> fluxbox or so, didn't actually check lately?)
>> IIRC, Caolán mentioned that on IRC yesterday already:
>> Unless explicitly specified otherwise (like setting SAL_USE_VCLPLUGIN
>> env variable), "gen" is the last choice, so won't be used if another VCL
>> plugin is present and can be loaded, s. [1].
> 
> And as I also said yesterday on IRC it is possible to install LO in
> Debian without gtk3 or qt5/kf5 present.
> 
> That also can be deliberate (some random WM which doesn't "need" gtk3,
> KDE people who do not want gtk3 stuff on their system, ..), or
> accidentially (apt install libreoffice doesn't "force" gtk3 on people.
> If you choose -gnome you get -gtk3 recommended and thus installed, as
> does the installer for "desktop" installs)
> 
> Yes, I know people advocate on ignoring those dependencies and just ship
> it in -core or so and let the loading mechanism figure it out. I think
> this is bad (packages should express their library linkage in dependencies.)

Yes, you mentioned that indeed; I was just referring to the part of the
email I quoted where you were mentioning what would happen if -gtk3 was
made non-optional in Debian. (So this was not really news, more of a
"for the records" comment, since probably not everybody on the mailing
list also reads all IRC messages).

(And I personally agree that VCL plugin packages in Debian should
actually depend on the libraries they need to be usable.)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 6.4.4.4 libssl error

[Michael Weghorn]

On 09/06/2020 08.40, Chetan Aru wrote:
> I have been asked to produce a build from any of the tags 6.4.3.x or later.
> So looks like my best bet is wait for 6.4.5.x or figure out a way to get
> around the build error.

In case you really don't have the option to add that commit for some
reason or wait until 6.4.5 has been tagged, the build log of the Jenkins
build of the parent commit (i.e. which doesn't contain the fix) might
help to see what's the relevant difference in your setup (since this one
worked while yours fails):

https://ci.libreoffice.org/job/gerrit_windows/65734/consoleFull
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 6.4.4.4 libssl error

[Michael Weghorn]

On 09/06/2020 06.48, Chetan Aru wrote:
> I am trying to build the LibreOffice 6.4.4.4 tag on Windows machine
> (Virtual Machine). I have installed cygwin 64-bit and doing 64-bit
> build. I am getting the following errors. Can someone please help? Seems
> that having this patch ( https://gerrit.libreoffice.org/c/core/+/95559)
> helps, but how is it that 6.4.4.4 was built on Windows machine without this?

The commit message of the commit you're pointing to says:

"For other people these failures are silently ignored, but they
show up in their python3 build.log. But my msbuild version
15.9.21+g9802d43bc3 from VS2017 fails hard on these errors."
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 6.4.4.4 libssl error

[Michael Weghorn]

On 12/06/2020 05.28, Chetan Aru wrote:
> I went with the 6.4.5.1 tag and it got past this error.
> But now I am facing the error with unit test failure for
> test testShapeTextAlignment in sw/qa/uibase/shells/shells.cxx  
> This commit takes care of the error, I have requested that to be cherry
> picked into 6.4 and 6.4.5. But no one has responded, can someone please
> help?
> https://gerrit.libreoffice.org/c/core/+/88427/3  


Cherry-picks for libreoffice-6-4 and libreoffice-6-4-5 now awaiting
review here:

https://gerrit.libreoffice.org/c/core/+/96234
https://gerrit.libreoffice.org/c/core/+/96331
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Fwd: Suggestion

[Michael Weghorn]

Hi,

Heiko wrote an answer to your email in May already, but it went to the
mailing list only, so in case you weren't subscribed, you probably just
didn't get it.

You can also read it here:
https://lists.freedesktop.org/archives/libreoffice/2019-May/082756.html

Michael

On 24/06/2019 03.20, Ricardo Ruff wrote:
> dear Sirs,
> 
> Awaiting your comments
> 
> Regards,
> 
> Ricardo Ruff F.
> 
>> Inicio del mensaje reenviado:
>>
>> *De: *Ricardo Ruff mailto:rr...@zayex.cl>>
>> *Asunto: **Suggestion*
>> *Fecha: *14 de mayo de 2019, 16:00:25 CLT
>> *Para: *libreoffice@lists.freedesktop.org
>> 
>>
>> Dear Sirs,
>>
>> I am a user of Libre Office since searching in the Web a software of
>> open source that not depend of the big Companies that manage the world
>> with their closed source softwares. I congratulate you in keeping
>> Libre Office adding constant improvements.  
>>
>> As I am a user of MAC computers for many years, I am writing you only
>> to suggest if you can study the possibility of change something in
>> your Spreadsheet. I would like use the Libre Office spreadsheet, but I
>> use normally a spreadsheet of MAC whose name is Numbers. This
>> spreadsheet has the advantage of other spreadsheets because you can
>> open a file which have a lot of sheets with their own names, and each
>> of them with many tables, each one with also its proper name. 
>>
>> In the normal spreadsheets of Excel and all of others you can not have
>> this advantage, that helps a lot to work. If you want I can send you a
>> file and you can study this possibility.
>>
>> Await your comments.
>>
>> Regards,
>>
>> Ricardo Ruff F.
>> Phone: 56 2 2243 2093
>> Cel: 9 4042 2153
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
> 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

gtk3 include handling - Improving IDE support

[Michael Weghorn]

Hi,

one issue with the existing Qt Creator integration for LibreOffice,
provided by the 'qtcreator-ide-integration' make target, is that gtk3
includes cannot be found in Qt Creator (leading to incorrect
code-completion, error detection, ...).

As far as I understand, the following is basically what happens (with
steps 1 and 2 being part of the "normal" build process, steps 3 and 4
specific to building the IDE integration):

1) 'configure.ac': the gtk3-related compiler flags are determined using
'PKG_CHECK_MODULES' and exported as 'GTK3_CFLAGS'.

2) 'vcl/Library_vclplug_gtk3.mk': 'gb_Library_add_cxxflags' is called to
set the flags, using the 'GTK3_CFLAGS' variable set in step 1

3) 'gbuildtojson' writes the JSON file
'workdir/GbuildToJson/Library/libvclplug_gtk3lo.so', based on the
information set among others in step 2

4) 'bin/gbuild-to-ide' reads that JSON file and generates IDE-specific
config files (e.g. '.pro' files in the case of Qt Creator)


Looking at the JSON file generated in step 3, one can see that the
'-isystem' compiler flags end up in the 'CXXFLAGS' section, while only
the 'INCLUDE' section is taken into account for includes when generating
the '.pro' file for Qt Creator in step 4, thus eventually causing the
problem that included files are not found by Qt Creator.


2 potential approaches to improve this came to my mind:


1) make sure the include-related compiler flags actually end up in the
'INCLUDE' section in the generated JSON file

As far as I can see, 'gb_Library_set_include' is the way to set the
'-I'/'-isystem' compiler flags in gbuild, and that approach is used for
pretty much all other libraries.
https://gerrit.libreoffice.org/#/c/65207 demonstrates this approach.


2) adapt gbuild-to-ide to detect include-related compiler flags even if
set via 'gb_Library_add_cxxflags'

https://gerrit.libreoffice.org/#/c/65206 demonstrates a way to do this
for Qt Creator.


To me, approach 1 seems cleaner, but since I'm far from being a gbuild
expert, I'm unable to assess all the implications and would be very
thankful for any opinions on this, either here or in the corresponding
gerrit changes.

Regards,
Michael


PS: Another approach might be to have the IDE use *all* compiler flags,
but at least for qtcreator, that would at least require splitting up the
project into more '.pro' files (one per library/executable, if not even
further). Currently, one '.pro' file is generated per top-level directory.

PPS: While I just encountered this for 'vclplug_gtk3' so far, the same
might be the case for other targets.



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: new contributor

[Michael Weghorn]

Hi,

welcome and thanks for your interest in contributing to LibreOffice!

> where i can see the beginner level bugs to get hold of libreoffice environment

Those are called "Easy Hacks". The wiki page
https://wiki.documentfoundation.org/Development/EasyHacks contains more
information on those (and links at the end that will get you to a list
of existing Easy Hacks).

On 15/12/2018 15.43, jayaraj s wrote:
> I am interested in contributing to libreoffice.
> 
> As i read in get involved page
> 
> I am accepting that all of my past&future contribution to
> Libreoffice may be licensed under the MPLv2/LGPLv3+ dual license.
> 
> where i can see the beginner level bugs to get hold of libreoffice
> environment
> 
> 
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
> 



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: gtk3 include handling - Improving IDE support

[Michael Weghorn]

On 17/12/2018 09.14, Stephan Bergmann wrote:

> Indeed, for better or worse, e.g. all the *_CFLAGS in
> RepositoryExternal.mk are passed into gb_LinkTarget_set_include, not
> gb_LinkTarget_set_cxxflags.  Feel free to go with this approach, I'd say
> in vcl/Library_vclplug_gtk3.mk, I'd say.

Thanks for the quick reply! I'll go with the updated
https://gerrit.libreoffice.org/#/c/65207 then.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Libre Office Installation Error

[Michael Weghorn]

Hi,

On 24/12/2018 10.53, Komal Bharadiya wrote:
> After all this I tried cloning the repository directly from
> github(libreoffice/core repository):
> In this, after successful execution of ./autogen.sh, make command
> gives errors:
> ***
> This is what I get on terminal-
> komal@komal-Vostro-15-3568:~/core-master$ /usr/bin/make
> /bin/sh: 1: .: Can't open /home/komal/core-master/sources.ver
> Makefile:250: *** Error while retrieving $lo_sources_ver from
> /home/komal/core-master/sources.ver.  Stop.
> 

A quick look at 'Makefile.in' suggests that this message occurs when you
haven't cloned from git and the mentioned file does not exist.

Did you download as an archive from github rather than using 'git clone'?

As Mike already mentioned in the other thread, please try to get the
sources using one of the "official ways". [1] also mentions a way to
start by downloading an official tarball, should 'git clone' not work.
Please try using that one and the steps described there rather than
using some tarball from github.

[1] https://www.libreoffice.org/about-us/source-code/



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Jenkins_Callgrind broken after: Drop extra define ENABLE_GTKSINK

[Michael Weghorn]

Hi Luke,

this happens when both gtk3 and gstreamer-0.10 are enabled for the build.

When this popped up, some people asked the question whether gstreamer
0.10 is still relevant after all (in which case this needs to be fixed,
which should be quite straight-forward), or gstreamer-0.10 can be
dropped completely (which also will make the problem go away), s.a.
comment in the Gerrit change [1].

This will be discussed in the ESC call to start in a few minutes and
fixed then.

Michael

[1] https://gerrit.libreoffice.org/#/c/73270/

On 06/06/2019 15.43, Luke Benes wrote:
> Michael,
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=34bbf192a7753205bb64d14e4eec4ce303317396
> 
> broke Jenkins_Callgrind 
> https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1559555453.4509
> 
> https://ci.libreoffice.org/computer/vm139/builds
> 
> with this error:
> avmedia/source/gstreamer/gstplayer.hxx:33:14: fatal error: gtk/gtk.h: No such 
> file or directory
> 
> 
> Does Jenkins_Callgrind need to be upgraded?
> 
> -Luke
> 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Jenkins_Callgrind broken after: Drop extra define ENABLE_GTKSINK

[Michael Weghorn]

On 06/06/2019 15.58, Michael Weghorn wrote:
> This will be discussed in the ESC call to start in a few minutes and
> fixed then.

Since ESC decision is to drop gstreamer-0.10,
https://gerrit.libreoffice.org/#/c/73608/
("distro-config: Drop '--enable-gstreamer-0-10' everywhere") should
quickly fix the build issue for all affected Jenkins jobs and I'll
remove the gstreamer-0.10 code after all in a subsequent step.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: avmedia/Library_avmediagst.mk avmedia/source vcl/qt5

[Michael Weghorn]

On 10/06/2019 14.19, Jan-Marek Glogowski wrote:
> The only halfway sane way I could come up with would be to move an abstract
> interface of the gstreamer sink loading into VCL, and just use symbol lookup 
> in
> there, so no gstreamer linkage for VCL. avmedia already depends on VCL. I 
> don't
> think we support any other avmedia backend then gstreamer on Linux, so that
> should be fine. At the point of avmedia usage, all required libraries are
> already loaded by the VCL plugin and avmedia.
> 
> The whole backend depending code just uses one gstreamer symbol:
> gst_element_factory_make.

For the record, Jan-Marek has implemented this in commit [1] ("Don't
link avmediagst with gtk3 and qt5").

Regards,
  Michael


[1]
https://gerrit.libreoffice.org/plugins/gitiles/core/+/a6201725d760cbce832d4de029b418bb7334df6a%5E!
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LO Viewer for Android: daily builds missing

[Michael Weghorn]

Hi Terry,

On 12/04/2020 17.04, Terrence Enger wrote:
> I notice that daily builds are no longer available at 
> .
> Is this intentional?

from IRC #libreoffice-dev just now:

[13:35]  michaelweghorn: FYI: not intentional that the
android tinderbox is not at least trying to build. the machine had a
hard lockup/required serial recovery access to reboot, but is stuck at
boot/looks like it is another case of storage starting to fail...
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Fwd: Rivan's license statement

[Michael Weghorn]

Forwarding to dev mailing list, since I had forgotten that one in my
initial reply...


 Forwarded Message 
Subject: Re: Rivan's license statement
Date: Mon, 27 Apr 2020 07:14:24 +0200
From: Michael Weghorn 
To: Muhammad Rivan 

Hi,

On 27/04/2020 01.54, Muhammad Rivan wrote:
> To the extent possible under law, I waive all copyright and related or
> neighboring rights to my past & future contributions to LibreOffice:
> https://creativecommons.org/licenses/by/4.0/

in case you want to contribute to LibreOffice code, please use the text
as mentioned in the wiki [1], in particular cling to those licenses.


[1]
https://wiki.documentfoundation.org/Development/GetInvolved#License_statement
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Update Android min NDK version to 23.x?

[Michael Weghorn]

For the Android build, configure.ac currently checks for a minimum NDK 
version of 16.x and the Jenkins builds use 20.1.5948944 (s. 
distro-configs/Jenkins/android_common.conf ).


In the context of adding support for newer NDKs, I would like to update 
the minimum version to 23.x to avoid the complexity that would be needed 
to support older versions in parallel.


Updating to NDK 23 would among others allow using lld for linking 
liblo-native-code.so, which significantly reduces the time for linking 
in debug builds (~40s -> ~10s for me for an x86 build) and also fixes an 
error I get for 64-bit-ARM debug builds (for which I had a local 
workaround so far, s. https://gerrit.libreoffice.org/c/core/+/130947 ).


AFAICT, this should have no impact on runtime requirements/supported 
devices, since NDK 23 still supports API 16 (Android 4.1).



Suggested changes in Gerrit:
https://gerrit.libreoffice.org/c/core/+/146118
https://gerrit.libreoffice.org/c/core/+/146119

(Changes further up the relation chain are for supporting NDK 24 and 25 
as well.)


In addition to the above changes, installing the corresponding NDK for 
all Android builders is needed, don't know about additional custom 
config for android builders beyond above-mentioned 
distro-configs/Jenkins/android_common.conf )



Clang version for NDK 23.2.8568313 which is the one that I used for 
testing and that https://gerrit.libreoffice.org/c/core/+/146118 would 
currently switch the Jenkins builds to):



$ 
~/Android/Sdk/ndk/23.2.8568313/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
 --version
Android (8481493, based on r416183c2) clang version 12.0.9 
(https://android.googlesource.com/toolchain/llvm-project 
c935d99d7cf2016289302412d708641d52d2f7ee)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: 
/home/michi/Android/Sdk/ndk/23.2.8568313/toolchains/llvm/prebuilt/linux-x86_64/bin


Are there any thoughts/concerns on that?
(I plan to bring up that topic in tomorrow's ESC call as well.)

Re: does the CLI option --cat (text to stdout) work?

[Michael Weghorn]

On 27/01/2023 01.00, Jono wrote:

LibreOffice-still.basic-x86_64.AppImage --version
LibreOffice 7.0.5.2 64390860c6cd0aca4beafafcfd84613dd9dfb63a


This LibreOffice version is outdated.


LibreOffice-still.basic-x86_64.AppImage --help

reports:

--cat   Dump text content of the following files to console
(implies --headless). Cannot be used with --convert-to.


but the following produces no output:

./LibreOffice-still.basic-x86_64.AppImage --cat test.odt

Does this feature work?


For a "test.odt" that contains the text "Test 123", this gives the 
expected result for me for both, a current development version and the 
Debian-provided LibreOffice 7.4.4:


$ libreoffice --cat /tmp/test.odt
Test 123

If it doesn't work with an up to date LibreOffice version, please report 
a bug in our Bugzilla issue tracker (and attach the test.odt you're using):

https://bugs.documentfoundation.org/

Since you're using an AppImage version of LibreOffice, I'd also suggest 
to first check whether it works when using the version from the official 
LibreOffice download page [1] instead.


[1] https://www.libreoffice.org/download/download-libreoffice/

Re: ESC budget ranking vote

[Michael Weghorn]

On 22/06/2023 20.47, Ilmari Lauhakangas wrote:
Per the decision in the ESC budget review meeting today, below is the 
ranking of budget items to be submitted to TDF board of directors.


Non-conflicted ESC members: please give your approval of the ranking by 
replying to this mail.


+ Cleanup & further improve ODF conformance (2021)
+ Convert Impress slideshow to drawinglayer primitives (2021)
+ Writer tables: support cell margins (next to cell padding) (2021)
+ Font subsetter for font embedding (2022)
+ XLSX Aggressive Competitors tracker: gridlines for 3d line charts (2022)
+ Look-ahead styleref field for Writer (2022)
+ Normalized spell checking (2022)
+ Remove/Replace usages of XOR-Paint (2022)
+ ODT export nondeterminism (2022)
+ Bitmaps in vcl: Merge RGB and A layer into one (2022)
+ Allow inline graphics, formulas in impress (and draw), open equation 
with inline formulas from PPT, PPS, PPTX, PPSX (ranked 1 in Feb 2023)

+ Make Firebird implementation production-ready (ranked 3 in Feb 2023)
+ SVG rendering improvements (ranked 4 in Feb 2023)
+ Rotated Writer TextFrames (ranked 9 in Feb 2023)
+ XLSX Aggressive Competitors tracker: support math equations in Calc 
shapes (ranked 12 in Feb 2023)

+ Slideshow: rendering content on top of videos (ranked 19 in Feb 2023)
+ Missing ODF Features: Attribute svg:d of  some of the 
possible commands are missing (ranked 30 in Feb 2023)
+ Missing ODF Features: The attribute draw:text-rotate-angle is 
interpreted, but there exists no user interface to change it. (ranked 33 
in Feb 2023)
+ Missing ODF Feature:  missing completely (ranked 
33 in Feb 2023)
+ Missing ODF Features: Draw:shadow-offset-x/y only partially 
implemented (ranked 38 in Feb 2023)
+ Replace remaining Carbon functions with non-Carbon functions (macOS) 
(ranked 38 in Feb 2023)

+ Tests for drawinglayer and basegfx (ranked 41 in Feb 2023)


+1

Best regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Re: LO Viewer for Android: failures in make install

[Michael Weghorn]

Hi Terry,

On 08/02/2023 20.05, Terrence Enger wrote:

I am trying to follow the instructions at
"Development/BuildingForAndroid"
;.
The step `make install` failed with messages (lines rewrapped).

 * Where:

 Build file
 '/home/terry/lo_hacking/git/android/android/source/build.gradle'
 line: 3

 * What went wrong:
 A problem occurred evaluating root project 'source'.
 Could not read script
 '/home/terry/lo_hacking/git/android/android/source/liboSettings.gradle'
 as it does not exist.

and

 Task failed with an exception.
 ---
 * What went wrong:
 A problem occurred configuring root project 'source'.
 compileSdkVersion is not specified. Please add it to build.gradle

Christian Lohmaier has written

that a toplevel make will create the file.  I had just done a toplevel
make, but after another one, 'make install` failed similarly.

In build.gradle, line 3 is

 apply from: 'liboSettings.gradle'


The mentioned 'liboSettings.gradle' should actually be generated during 
the top-level make, so that sounds like that one isn't doing what it 
should in your case.



I am building on debian-sid, and my autogen.input, minus comments, is

 --enable-option-checking=fatal
 --with-vendor=Terrence Enger
 --with-external-tar=/home/terry/lo_hacking/git/src
 --build=x86_64-pc-linux-gnu
 --host=i686-linux-android
 --with-android-sdk=/home/terry/Android/Sdk
 --with-android-ndk=/home/terry/Android/Sdk/ndk/25.2.9519653
 --with-android-api-level=21
 --enable-dbgutil
 --with-theme=colibre
 --disable-zxing

and I have set envvar ANDROID_HOME=/home/terry/Android/Sdk


This is using NDK 25.2.9519653. From what commit are your trying to 
build? Does the top-level make succeed for you?


In my experience, building with NDK 25 required changes, s. 
https://gerrit.libreoffice.org/c/core/+/146135 (and change further down 
in the relation chain).


If you haven't applied these changes yet, I'd suggest to either do that 
or build with an older NDK until these changes have been merged to 
master (currently waiting for the new NDK to become availabe on Jenkins 
builders).


FYI, my autogen.input on Debian testing for master as of commit 
b2bd60b8c1937502857e12b0eea42323fd2353c8 currently looks like this:


--build=x86_64-unknown-linux-gnu
--with-android-ndk=/home/michi/Android/Sdk/ndk/20.0.5594570/
--with-android-sdk=/home/michi/Android/Sdk
--with-distro=LibreOfficeAndroidX86
--enable-sal-log
--with-external-tar=/home/michi/development/libreoffice-external
--enable-ccache
--enable-dbgutil
--with-jdk-home=/usr/lib/jvm/java-17-openjdk-amd64/

Re: Update Android min NDK version to 23.x?

[Michael Weghorn]

On 25/01/2023 14.14, Michael Weghorn wrote:
For the Android build, configure.ac currently checks for a minimum NDK 
version of 16.x and the Jenkins builds use 20.1.5948944 (s. 
distro-configs/Jenkins/android_common.conf ).


In the context of adding support for newer NDKs, I would like to update 
the minimum version to 23.x to avoid the complexity that would be needed 
to support older versions in parallel.


Updating to NDK 23 would among others allow using lld for linking 
liblo-native-code.so, which significantly reduces the time for linking 
in debug builds (~40s -> ~10s for me for an x86 build) and also fixes an 
error I get for 64-bit-ARM debug builds (for which I had a local 
workaround so far, s. https://gerrit.libreoffice.org/c/core/+/130947 ).


AFAICT, this should have no impact on runtime requirements/supported 
devices, since NDK 23 still supports API 16 (Android 4.1).



Suggested changes in Gerrit:
https://gerrit.libreoffice.org/c/core/+/146118
https://gerrit.libreoffice.org/c/core/+/146119

(Changes further up the relation chain are for supporting NDK 24 and 25 
as well.)


In addition to the above changes, installing the corresponding NDK for 
all Android builders is needed, don't know about additional custom 
config for android builders beyond above-mentioned 
distro-configs/Jenkins/android_common.conf )


As discussed in the ESC call on 2023-01-26 [1], Jenkins builders have 
been switched to NDK 25 now (thanks, Cloph!) and I have merged the 
pending Gerrit changes and updated the documentation on Android baseline 
in README.md.



[1] 
https://lists.freedesktop.org/archives/libreoffice/2023-January/089878.html

.gitreview added to dictionaries git submodule

[Michael Weghorn]

https://gerrit.libreoffice.org/c/dictionaries/+/138340
("Add .gitreview used by git-review tool")
added a .gitreview to the dictionaries git repo.

As Eike pointed out in the Gerrit change, this means that people who 
already have a local .gitreview in the submodule need to (re)move that 
before updating the submodule:



Note this when checking out on an existing tree with  ./g pull -r  where 
.gitreview exists already results in

  error: The following untracked working tree files would be overwritten by 
checkout:
  .gitreview
  Please move or remove them before you switch branches.
  Aborting
  fatal: Unable to checkout 'bcf7f049315dee2001cc2f7c7eabfbcb0b8ef21a' in 
submodule path 'dictionaries'

Please announce on the dev list, the usual generated by gitreview content is 
identical, but in case someone did modifications the file should be moved out 
of the way, otherwise must be deleted.


Sorry for any inconvenience this may have caused.

Re: UI/accessibility dev advice needed on change 150546

[Michael Weghorn]

On 27/04/2023 07.19, Lionel Élie Mamane wrote:

I'm reviewing https://gerrit.libreoffice.org/150546
by Nirnay. It adds a .ui file, and a "make" outputs warning like

WARNING: 'GtkLabel' 'browselabel' does not specify what it labels within 
'GtkFrame' 'frame1'

The other preexisting .ui files also generate a bunch of them, but
they are silenced in a .suppr file...

What is our policy on this? Should/can Nirnay just silence them, too,
by adding them to the .suppr file? I guess not. Please tell Nirnay
what he should do in respect of this; I'd rather not commit as is
with the warning (nor simply suppressing them) unless a
UI/accessibility knowledgeable persons signs off on it
(the rest of the change is nearly ready to merge, and should be
  completely ready within an hour so.)


For the record:
Solved now thanks to the input from Samuel Thibault in the Gerrit change
( https://gerrit.libreoffice.org/c/core/+/150546 )


OpenPGP_signature
Description: OpenPGP digital signature

Re: Welcome Michael Weghorn, new Developer at TDF

[Michael Weghorn]

Thanks for the warm welcome in my new role as part of the TDF team and 
the great time in the LibreOffice project so far and all the help I have 
received from many of you over all these years!


I'm really looking forward to continue working together with all of you 
to further improve LibreOffice.


OpenPGP_signature
Description: OpenPGP digital signature

Re: LibreOffice Build failed on Debian-x86-32bit inside Module VCL

[Michael Weghorn]

On 2023-07-12 21:04, Andreas Mantke wrote:

I compiled LibreOffice on a Netbook with Debian-x86-32bit for a while
successful. I did this with success from the source repo some weeks ago
(before version 7.6 was tagged).

[...]

But yet I got a break inside the VCL module
Here is the output from my current build process:

[...]
error: no declaration matches ‘void AtkListener::handleChildAdded(const
com::sun::star::uno::Reference&,
const
com::sun::star::uno::Reference&,
sal_Int32)’
   164 | void AtkListener::handleChildAdded(
   |  ^~~
[...]


This sounds like the issue fixed by
https://git.libreoffice.org/core/commit/469fc646ec782f42e42947f480d5931b97e686ab
("gtk3 a11y: Use sal_Int32 consistently to fix i386 build").

Can you try again with current git master (or apply that commit)?


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Help] Exception occurred, When debugging LibreOffice by VS Code on ubuntu (gnome desktop) . can't debug by vscode nomally.

[Michael Weghorn]

On 2023-07-21 03:24, Kevin Suo wrote:
Could someone on the list take look at the error Zhao Xiao has 
encountered when he is debugging in VS Code. He is a newcomer and is 
preparing to contribute on CJK bug fixing.


I don't know much about Snap or LibreOffice development with VS Code, so 
maybe others can provide better input, but at least some thoughts below.


于 2023年7月18日 GMT+08:00 下午12:07:26, "赵 晓东" 
 写到:


[ENV]
OS: Ubuntu 22.04.2 LTS
LibreOffice: 7.5.5.1
VS Code: 1.80.1

[Compile Command]
./autogen.sh --enable-debug --disable-ldap
make

[GDB Debug is OK]
make debug
run --writer

[When running libreoffice on VS Code terminal, exception occurred]
it@it-hp-desktop02:~/dev/libreoffice_dev/libreoffice-7.5.5.1$
./instdir/program/soffice

/home/it/dev/libreoffice_dev/libreoffice-7.5.5.1/instdir/program/soffice.bin: 
symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: 
undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE


The path here ( 
/snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0 ) suggests 
that this is somehow related to a library installed via snap.
Do you know how that was installed and why it is being used when 
debugging from VS Code? Is there e.g. some LD_LIBRARY_PATH set in the VS 
Code (project) settings?
Did you install VS Code via Snap? If so, does the issue also occur when 
installing otherwise?


Since you mention that debugging with plain GDB works: Does starting 
LibreOffice from outside VS Code and then attaching to the running 
process work for debugging (at least as an alternative/workaround until 
figuring out how to address the actual issue)?


OpenPGP_signature
Description: OpenPGP digital signature

Re: GSoC ideas wiki page gardening

[Michael Weghorn]

On 24/01/2022 18.40, Ilmari Lauhakangas wrote:

These ideas are missing mentors:
https://wiki.documentfoundation.org/Development/GSoC/Ideas#Improve_UX_for_deaf_people 


There was a discussion on that "Improve UX for deaf people" topic in 
2020, thread starting at [1]. Reading the last email [2], it sounds to 
me like there was a consensus that a separate application using the 
existing a11y APIs would be the best way forward.


At a quick glance, [3] looks like an actual application has been 
developed for Linux in the meantime (and something similar should be 
possible for Windows using MSAA).


However, that's my impression from only a quick glance at the project in 
GitLab and a machine-translation from its Spanish README.


Does anybody know more about that or whether there are any specific 
issues that would still need work on LO side (or whether the suggested 
GSoC suggestion has become obsolete in the meanwhile)?


Michael


[1] 
https://lists.freedesktop.org/archives/libreoffice/2020-March/084694.html
[2] 
https://lists.freedesktop.org/archives/libreoffice/2020-March/084761.html

[3] https://gitlab.com/LabIS-UFRJ/LIBRASOffice/at-spi2-librasoffice

Re: Libreoffice build error[for android]

[Michael Weghorn]

Hi,

On 03/03/2022 16.08, di liu wrote:
the build environment is linux(centos 7) which installed in vmware (my 
host system is macOS) this is my autogen.input content 
--with-distro=LibreOfficeAndroid 
--with-android-sdk=/home/disco/Documents/dev_env/android_sdk 
--with-android-ndk=/home/disco/Documents/dev_env/android_sdk/ndk/20.1.5948944 
--with-ant-home=/home/disco/Documents/dev_env/apache-ant-1.10.12 


I tried a build with an equivalent autogen.input on Debian testing:

--with-distro=LibreOfficeAndroid
--with-android-sdk=/home/michi/Android/Sdk
--with-android-ndk=/home/michi/Android/Sdk/ndk/20.1.5948944
--with-external-tar=/home/michi/development/libreoffice-external

which worked fine with master (as of commit 
0a774bae7d402a6880760b1226a6741604e23f5a).



everything is ok when execute: ./autogen.sh But when I execute: make the 
error is happened:


[...]
Linking

/home/disco/Documents/res/libreoffice/android/obj/local/armeabi-v7a/liblo-native-code.so

/home/disco/Documents/res/libreoffice/instdir/program/libuno_cppuhelpergcc3.a(shlib.o):shlib.cxx:function
cppuhelper::detail::loadSharedLibComponentFactory(rtl::OUString
const&, rtl::OUString const&, rtl::OUString const&, rtl::OUString
const&, rtl::OUString const&,
com::sun::star::uno::Reference
const&, std::__ndk1::function const&)>*,
com::sun::star::uno::Reference*):
error: undefined reference to 'lo_get_constructor_map'

/home/disco/Documents/res/libreoffice/instdir/program/libuno_cppuhelpergcc3.a(shlib.o):shlib.cxx:function
cppuhelper::detail::loadSharedLibComponentFactory(rtl::OUString
const&, rtl::OUString const&, rtl::OUString const&, rtl::OUString
const&, rtl::OUString const&,
com::sun::star::uno::Reference
const&, std::__ndk1::function const&)>*,
com::sun::star::uno::Reference*):
error: undefined reference to 'lo_get_factory_map'
[...] >
Could you give me some suggestions


If you have current git master without any local changes and 'make 
distclean' and trying again doesn't work, you could try using a 
different version of the Android NDK, or use LLD as linker instead of 
ld.gold by applying the demo patch at 
https://gerrit.libreoffice.org/c/core/+/130947 and switching to a newer 
NDK; a build here worked with that Gerrit change in place and an 
autogen.input containing this:


--with-distro=LibreOfficeAndroid
--with-android-ndk=/home/michi/Android/Sdk/ndk/22.1.7171670/
--with-android-sdk=/home/michi/Android/Sdk
--with-external-tar=/home/michi/development/libreoffice-external

(At least my experience in the past was that it was a bit tricky to find 
a combination of Android NDK and linker that would work depending on 
architecture and whether this was a release or debug build. But the 
problems I encountered back then were more "fundamental" than the 
"undefined reference" issue you're encountering. Maybe all of the issues 
I had two years ago or so are fixed in newer versions of the toolchain, 
but so far I just stayed with what was working back then...)

Re: Libreoffice build error[for android]

[Michael Weghorn]

On 04/03/2022 10.42, di liu wrote:

Thank you for your reply.
 > If you have current git master without any local changes and 'make
 > distclean' and trying again doesn't work

I just modified one file which named "Makefile.fetch" location in root 
dir of libreoffice,But i think this change has nothing to do with this error

below is my change's content
"

ifneq (,$(WGET))
define fetch_Download__wget_command
&& bash -c '$(WGET) --no-check-certificate--progress=dot:mega -Q 0 -P 
"." -l 0 -nd -nH -N --no-use-server-timestamps $1/$2 2>&1 | tee -a 
$(fetch_LOGFILE) && [ $$PIPESTATUS -eq 0 ]'

endef

"
I have added he green color option which used solve certification problem
but I still want to have try with "make distclean"


It's not really clear to me what "he green color option" refers to, but 
if that refers to the change of adding the '--no-check-certificate' 
option for wget, that should actually be unrelated.



I have a another problem:
I have search the undefined method "lo_get_custom_widget_func" and find 
this method is defined dynamic . It's was defined by native-code.py I 
don't know why we're doing this and how it's work
.Could you give me a simple explanation or provide me some documents to 
make it's clear ?


Good point.

I don't know details about this either, but I think the idea is to strip 
down what C++ code to build/include for the mobile apps to reduce the 
size of the library to what's actually needed there.


At last I wonder if I can do that execute "native-code.py" and put the 
result to a new  cpp file and add it to makefile when I still have the 
link error ?


Looking at android/source/Makefile, this is the command used to generate 
the file:


./solenv/bin/native-code.py -j -g core -g writer -g calc -g draw -g 
edit > android/source/native-code.cxx


I have pasted what the output/file looks like for me here:
http://paste.debian.net/1232969/

In case that differs from yours, tracking down what happens inside 
native-code.py might provide insights what's going wrong.

Re: Libreoffice build error[for android]

[Michael Weghorn]

On 04/03/2022 12.37, Michael Weghorn wrote:
It's not really clear to me what "he green color option" refers to, but 
if that refers to the change of adding the '--no-check-certificate' 
option for wget, that should actually be unrelated.


OK, had I enabled HTML rendering for the email, it would have been clear 
that the '--no-check-certificate' option was actually meant, sorry for 
the noise...

Re: libreoffice-7.3.2 compile in arm system

[Michael Weghorn]

On 18/03/2022 05.50, gcxyw1314 wrote:

dear all：
https://paste.debian.net/1234705/


By now, that says:

> Entry not found
> The requested entry isn't in our database. That usually means it
> expired or has been deleted by the author.

Can you paste again, and set the expiration time to 90 days or "never"?

Does the same happen with current git master?

Re: 回复：libreoffice-7.3.2 compile in arm system

[Michael Weghorn]

On 22/03/2022 05.57, gcxyw1314 wrote:

The packages I compiled on the centos7.7 arm system are as follows:
When I install it, it says it is missing libXinerama.so.1
But I have installed
libXinerama-1.1.3-2.1.el7.aarch64

-> Finished Dependency Resolution
Error: Package: lodevbasis7.0-core-7.0.6.2-2.aarch64 
(/lodevbasis7.0-core-7.0.6.2-2.aarch64)
    Requires: libXinerama.so.1
  You could try using --skip-broken to work around the problem
https://paste.debian.net/1235204/


Did you install the package "libXinerama"?

https://centos.pkgs.org/7/centos-aarch64/libXinerama-1.1.3-2.1.el7.aarch64.rpm.html

Re: Mentions of bugs in the dev guide

[Michael Weghorn]

On 20/03/2022 12.22, Ilmari Lauhakangas wrote:
The dev guide references some known issues (without bug numbers). I 
appreciate any help in figuring out if they are still relevant.


https://wiki.documentfoundation.org/Documentation/DevGuide/LibreOffice_Basic#Date_Field 

Dropdown is currently not working by program, but you can set it with 
the Control Properties in the IDE.


That still seems to be the case, I've submitted tdf#148129 with a sample 
macro.

Re: Hi (Formats supported by LibreOffice).

[Michael Weghorn]

On 23/03/2022 06.23, Amit Amit wrote:
I was thinking that why does LibreOffice support document formats other 
than that of Microsoft Office?


You might be interested in Italo's FOSDEM talk:
https://fosdem.org/2022/schedule/event/lotech_odfbetterthanooxml/

Re: 回复：回复：libreoffice-7.3.2 compile in arm system

[Michael Weghorn]

On 25/03/2022 08.12, gcxyw1314 wrote:

help ,

Is it something to do with the version

[...]
发件人：Christian Lohmaier 
[...]

When building packages using the epm method, the dependency gets added
by instsetoo_native/inc_openoffice/unix/find-requires-x11.sh - and it
looks like it should also add the ()(64bit) marker to the dependency
when PLATFORMID is linux_aarch64 and not only for linux_x86_64

check with rpm -q --provides libXinerama-1.1.3-2.1.el7.aarch64 whether
it provides "libXinerama.so.1()(64bit)"



If I understand correctly, Christian's suggestion was to apply the 
following change if the output to the `rpm -q --provides 
libXinerama-1.1.3-2.1.el7.aarch64` command shows that the package 
provides "libXinerama.so.1()(64bit)":


https://gerrit.libreoffice.org/c/core/+/132094

Can you check whether it works if you rebuild with that change applied?

Re: 回复：回复：回复：libreoffice-7.3.2 compile in arm system

[Michael Weghorn]

Do I correctly understand the discussion so far that there are 2 
different issues that you are encountering on aarch64? (This thread 
jumps back and forth between the two a bit):


1) building LibreOffice 7.3 fails on aarch64
2) building LibreOffice 7.0 works, but installation of RPM packages fails

On 25/03/2022 10.41, gcxyw1314 wrote:


[root@1 rpm2]# `rpm -q --provides
 ^CbXinerama-1.1.3-2.1.el7.aarch64 

[root@1 rpm2]# rpm -q --provides libXinerama-1.1.3-2.1.el7.aarch64
libXinerama = 1.1.3-2.1.el7
libXinerama(aarch-64) = 1.1.3-2.1.el7
libXinerama.so.1()(64bit)


Thanks, that shows that the package actually provides
"libXinerama.so.1()(64bit)" on aarch64 and change
https://gerrit.libreoffice.org/c/core/+/132094 is needed.

This should solve issue 2).
Can you confirm that the installation works if you apply the above 
change before doing your 7.0 build?



When I built versions 7.3 and 7.1, I kept reporting

/home/logsaas/libreoffice-7-1/workdir/CxxObject/xmloff/source/core/xmlimp. o: 
In function `SvXMLImport::SetAutoStyles(SvXMLStylesContext*)':

xmlimp. cxx:(.text+0x8b90): undefined reference to `non-virtual thunk to 
cppu::WeakImplHelper::acquire()'


Now we're at issue 1). Some questions to try to narrow the issue down:

Can you please try whether the same happens with the current git master 
branch instead of 7.3 (run "make distclean" first after switching 
branches), and if so, submit a more detailed error output to 
paste.debian.net, with the expiration date set to "never"?


What does your autogen.input look like? Or if you're not using that, 
what options are you passing to `./autogen.sh`?


This is on CentOS 7.7, aarch64 architecture, right?
Can you share the file `config.log` from your build directory?


But I am 
https://bug-attachments.documentfoundation.org/attachment.cgi?id=172646 No 
modification method was found above, so I compiled on 7.06 and didn't encounter 
this error,


Where does that patch come from? Is there a related Bugzilla issue it is 
attached to?

Re: 回复：回复：回复：libreoffice-7.3.2 compile in arm system

[Michael Weghorn]

On 25/03/2022 11.20, gcxyw1314 wrote:


I have rebuilt it based on 7.06 and it can be installed normally.

e rebuilt it based on 7.06 and it can be installed normally.


Is that with the change mentioned earlier applied, i.e. an answer to one 
question in the email I sent just now:


On 25/03/2022 11.37, Michael Weghorn wrote:

Thanks, that shows that the package actually provides
"libXinerama.so.1()(64bit)" on aarch64 and change
https://gerrit.libreoffice.org/c/core/+/132094 is needed.

This should solve issue 2).
Can you confirm that the installation works if you apply the above change before doing your 7.0 build? 

Re: 回复：回复：回复：回复：libreoffice-7.3.2 compile in arm system

[Michael Weghorn]

On 25/03/2022 11.50, gcxyw1314 wrote:
  rebuilt it based on 7.06 
Modifying find-requires-x11.sh can be installed successfully


Thanks for testing, I've merged the change to master now:
https://git.libreoffice.org/core/+/d6ea4b8ffce91d7956cea0267c95ca69e208db24%5E%21
("Depend on 64-bit packages for aarch64 as well")

Backport for 7.3 pending here:
https://gerrit.libreoffice.org/c/core/+/132044


but building LibreOffice 7.3 和7.1 fails on aarch64 following：
https://paste.debian.net/1235553/


To narrow that issue down, please answer the remaining questions in my 
email of 11:37 today.


Also, did the patch you mention change anything (or was the error just 
the same before)?

Re: 回复：回复：回复：回复：回复：libreoffice-7.3.2 compile in arm system

[Michael Weghorn]

On 25/03/2022 12.34, gcxyw1314 wrote:

Are you talking about question 2?


I mean these questions:


Some questions to try to narrow the issue down:

Can you please try whether the same happens with the current git master branch instead of 7.3 (run 
"make distclean" first after switching branches), and if so, submit a more detailed error 
output to paste.debian.net, with the expiration date set to "never"?

What does your autogen.input look like? Or if you're not using that, what 
options are you passing to `./autogen.sh`?

This is on CentOS 7.7, aarch64 architecture, right?
Can you share the file `config.log` from your build directory?


But I am 
https://bug-attachments.documentfoundation.org/attachment.cgi?id=172646 No 
modification method was found above, so I compiled on 7.06 and didn't encounter 
this error,


Where does that patch come from? Is there a related Bugzilla issue it is 
attached to?



and:

Also, did the patch you mention change anything (or was the error just the same before)? 


OpenPGP_signature
Description: OpenPGP digital signature

Re: Headless mail merge

[Michael Weghorn]

On 06/04/2022 12.47, Marco Marinello wrote:

what's the easiest way to perform a mail-merge with libreoffice by
passing arguments from an automated script? Should I use UNO?

Do you have any reference?


A rather complex example is the WollMux extension [1], in particular the 
"core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge/" directory 
[2]. Class "OOoBasedMailMerge" [3] might be a good starting point.



[1] https://github.com/WollMux/WollMux

[2] 
https://github.com/WollMux/WollMux/tree/WollMux_18.2/core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge


[3] 
https://github.com/WollMux/WollMux/blob/WollMux_18.2/core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge/print/OOoBasedMailMerge.java

Re: ESC meeting minutes: 2022-05-26

[Michael Weghorn]

On 31/05/2022 12.01, Colomban Wendling wrote:
* Only on-screen elements of the document are exposed to ATs.  This is 
on purpose probably for performance (not sure if we have any numbers to 
base it on?) so elements are lazy-loaded and destroyed, but it has 
non-trivial impact on various AT features.  There are some things 
supposed to help mitigate the issues (like flows-from and flows-to 
relationships), but they present their own sets of issues (like some 
elements from there not having proper parent/child relationships, etc.).


tdf#35652 [1] ("ACC: AT-SPI accessible tree omits objects which are not 
visible on the screen.") sounds like a related bug report here.



* Some relations are missing, like for annotations and footnotes.


There's e.g. tdf#96481 ("Connect annotations to the paragraphs they 
describe").


Also there is a lack of semantics for change tracking leading to messy output 
from ATs.


There's e.g. tdf#96487 ("Expose tracked changes to ATs via accessible 
objects and attributes").


I have added links to those tickets to the wiki page [2] as well.

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=35652
[2] 
https://wiki.documentfoundation.org/Development/Under-loved_areas#Document_Level_Accessibility

Re: ESC meeting minutes: 2022-05-26

[Michael Weghorn]

On 31/05/2022 12.36, Caolán McNamara wrote:

If the overview is there are a thousand little things and not a small
set of large scale specific projects then that's still a useful
overview. We could still sweep them into some general themes.


Indeed. Thanks for adding the subtopics that came up during the 
discussion on the wiki page.



(I have also *heard* that Base seems to be most problematic in
general, but haven't had much to do with it myself yet.)


I wonder if it's the initial base screen (I think I might have replaced
some custom widgets there with more standard ones which might have
improved matters) or the "design view" rows/columns screen which is a
custom widget, but one I think that does at least have an a11y
implementation. In general custom widgets lead to forgotten a11y, like
the extensions dialog.

How about math? I see a bug 140659 for math still open linked to the
meta bug, which says "formula editor not operable with screenreaders",
but then the commentary seems maybe less bleak


Does anyone (affected users?) have any further insights/experiences with 
either Base or Math and could say where the main a11y problems are or 
whether it's mostly working fine by now?


(For Math, might makes sense to retest that after a11y has been restored 
for the elements panel after d79c527c2a599c7821d27cf03b95cb79e2abe685 
("Use IconView in SmElementsControl"), which mentions that as a TODO in 
the commit message and Mike already has a WIP change for that.)



Depends of what is being read out of course, missing labels for .ui
widgetry are super trivial to fix[1]. Something not read out from a
document can range from some small missing piece to some difficult
total lack of a11y.


Indeed, and I've seen various root causes when looking at different 
issues, so it's really hard to say where the problems are without taking 
a closer look into the single issues.



The a11y meta bug tdf#101912 [1] currently lists ~200 specific
issues. (I also have a ranked list from Richard, CCed, a blind user
who uses the NVDA screen reader on Windows.)


If Richard is ok with sharing that here it could help get a general
feel on what's lacking.


Read-only link to Richard's ranked list:
https://www.dropbox.com/s/2m5cr0m8gzz027n/NvdaAndLoAccessibilityBugSummary.xlsx?dl=0

(no need to sign in, just click the "Download" button on the top left, 
and switch to the "Summary" table to see the actual list)


Since the main focus is using LO with NVDA on Windows, the basis for the 
list were:


1) all LO Bugzilla issues set as directly blocking one of tdf#60251 
(Windows a11y meta bug), tdf#101912 (general a11y meta bug) or 
tdf#103440 (sidebar a11y meta bug):

https://bugs.documentfoundation.org/buglist.cgi?f1=blocked&list_id=1464413&o1=anywordssubstr&query_format=advanced&resolution=---&v1=60251%20101912%20103440
i.e. e.g. Linux- or macOS-specific issues or PDF a11y bugs are not 
covered, since those have their own meta bugs underneath tdf#101912.


2) a list of issues related to LO/AOO from the NVDA issue tracker on Github

Since various issues have been reported for both, LO and NVDA, Richard
also matched the corresponding bug reports with each other (entries that 
have both a "LO Bug ID" and an "NVDA Bug ID").


The underlying data from the two issue trackers is mostly from one year 
ago, so newer issues don't show up unless they were blocking work on 
existing ones.


(If of any practical value for upcoming steps, the list could be updated 
or turned into a different form as needed.)

Re: [libreoffice-accessibility] Re: ESC meeting minutes: 2022-05-26

[Michael Weghorn]

On 31/05/2022 16.24, Christophe Strobbe wrote:
I don't have a comprehensive overview of LibreOffice UI accessibility either, unfortunately. However, if you are looking for ways to prioritise issues, one way may be based on the accessibility requirements in the ETSI standard EN 301 549, which defines the requirements that software, documents and a number of other IT products will need to fulfil in the EU starting June 2025. If you want the biggest bang for your buck, my recommendations are the following: 
(1) With regard to the UI, focus on Windows-based accessibility issues first, since that is where (a) the majority of people with disabilities are and (b) the version that is most likely to get audited if accessibility audits get done. (As a Linux user, I would also like GTK-related to get fixed, but I am not representative of the market.) With regard to applications, I would focus on Writer before Impress or Calc. (I don't know how often Base and Draw are used in professional contexts, if at all.)


Thanks, Christophe, that's really helpful.

I generally agree with the priorities.
(FWIW, looking at, comparing and working a bit on the a11y 
implementations of all of Windows/gtk3/qt has proven to be very useful 
to me to get a deeper overall understanding, though.)


One other aspect that came to my mind:

For Windows, we currently support IAccessible2, but not UIA.
That's fine for NVDA, but I have heard/read at times that other screen 
readers/AT rely more on UIA. (But I haven't done any further research so 
far.)
Does anybody know more about this and whether it would actually be 
necessary to implement native UIA support in LO for those AT to properly 
interact with LO?
(Or is it more about having proper plugins/app modules/scripts for LO 
for the single AT, since e.g. NVDA and JAWS appear to rely heavily on 
those to properly support specific apps?)

Re: [libreoffice-accessibility] Re: ESC meeting minutes: 2022-05-26 [IAccessible2 support in JAWS]

[Michael Weghorn]

Hi Christophe,

On 07/06/2022 12.14, Christophe Strobbe wrote:

After some online searching, it seems that JAWS at least used to support 
IAccessible2, originally mainly for IBM Lotus Symphony.
According to a tweet by Marco Zehe from December last year, JAWS handles 
Chromium and Edge via IAccessible2. (See 
https://twitter.com/MarcoInEnglish/status/1471523578805997570 )


That sounds promising, JAWS was what I vaguely had in mind about having 
been mentioned of presumably not supporting IAccessible2 (well) in the past.



Twitter is not an ideal source, but I couldn't find any documentation related 
to IAccessible2 on Freedom Scientific's website. They do have documentation on 
to use script access to UIAutomation: 
https://support.freedomscientific.com/support/jawsdocumentation/UIAScriptAPI 
but nothing similar for IAccessible2.
This calls for some LibreOffice testing with JAWS; I hope to do some of that 
next weekend.


Thanks a lot, that's much appreciated!

Best regards,
Michael

Re: [libreoffice-accessibility] Re: ESC meeting minutes: 2022-05-26 [IAccessible2 support in JAWS]

[Michael Weghorn]

Hi Marco,

On 08/06/2022 13.09, Marco Zehe wrote:

JAWS does support IAccessible2, but only if it needs to, like in Firefox, and 
some parts of Chromium-based browsers. However, with the UI Automation 
implementation for the latter becoming stronger, there might be a time when 
JAWS moves to UIA for web content support in Chromium browsers. But you never 
know what plans Vispero actually has for which version of JAWS, ZoomText, and 
Fusion. All I notice is that, with Windows 11 having an even stronger UIA 
implementation than 10, more things are being done through that interface 
rather than traditional MSAA or IAccessible2 channels where possible. And as 
has been said elsewhere, UIA properties and events are even very accessible 
from within the JAWS scripting language, which makes this even more compelling 
because the end user experience can be customized further. As IAccessible2 is 
an extension of MSAA, and MSAA is largely deprecated by Microsoft, it will 
probably never get the same treatment.


thanks a lot for that valuable input.

I have added a new sub-section for adding UIA support to the wiki page ( 
https://wiki.documentfoundation.org/Development/Under-loved_areas#UIA_support_on_Windows 
), mostly based on the above and more information from your other email 
about announcing slide content in Impress presentation mode ( 
https://listarchives.libreoffice.org/global/accessibility/msg01007.html ).


A probably rather crazy thought I once had was whether it would be a 
good idea to try to get rid of our custom a11y bridge on Windows in the 
long run after all, e.g. by switching to Gtk or Qt there as well (at 
least as one option). But that would certainly have to make sense not 
only from the a11y perspective but the UI as a whole and would probably 
be rather contentious.


(I have close to zero knowledge about Windows-specific bits in LO 
besides winaccessibility, so don't know whether there would be any value 
in even spending any time in looking into this any further at some point 
in time. And as of now, neither the gtk4 nor the qt5/qt6 VCL plugins in 
LO have proper a11y anyway, and the Gtk 4 library presumably doesn't 
have any a11y implementation for Windows yet either, even though the new 
a11y architecture [1] in Gtk 4 should allow for one to be added at some 
stage.)


Michael

[1] https://blog.gtk.org/2020/10/21/accessibility-in-gtk-4/

Re: [libreoffice-accessibility] Re: ESC meeting minutes: 2022-05-26 [IAccessible2 support in JAWS]

[Michael Weghorn]

Hi Marco, all,

On 09/06/2022 09.39, Marco Zehe wrote:

AFAIK, QT exposes accessibility information to UIA on Windows. They switched 
over from an MSAA implementation to UIA some time in the QT5 time frame: 
https://www.qt.io/blog/2018/02/20/qt-5-11-brings-new-accessibility-backend-windows.


Indeed, that was what I had come across as well. (I had linked the 
corresponding Qt commit in the wiki article about adding UIA support.)



So, using QT widgets in the VCL certainly would help with that, UIA 
implementation bugs in the Windows QT layer not withstanding of course. So, 
there are advantages of using QT on Windows where appropriate, but that also 
entails the danger of inheriting QT UIA bugs.


Very true. While looking a bit into a11y of the Qt-based LO VCL plugins 
on Linux, I also came across some issues that need fixing for the AT-SPI 
integration in the Qt library rather than in LO.



I don't know anything about GTK4, so cannot make any qualified statement.


At a quick glance, everything underneath Gtk 4's "gtk/a11y" directory in 
git ( https://gitlab.gnome.org/GNOME/gtk/-/tree/main/gtk/a11y ) still 
looks AT-SPI only, though that might change at some point.



The original advantages of IAccessible2 and GTK3 was that they were made to be 
very closely related to one another in terms of concepts. But with GTK4 and 
other frameworks becoming more prominent, this has only been in a maintained 
state for years, not really further developed, except for adding necessary 
missing pieces for new HTML widgets or markup. UIA, on the other hand, has 
turned out to be much more flexible especially with the latest enhancements 
published by Microsoft. Custom property sets etc., which allows for various 
annotations in MS Word, Excel etc. NVDA has a pull request for implementation 
of some of these newest UIA technologies into their support for MS Office here: 
https://github.com/nvaccess/nvda/pull/13387

So, in the long run, it is probably safest to indeed invest in switching to an UIA implementation. 
Note, however, that you may still need to do some work yourselves for the document specific stuff for Writer, Calc, and Impress specifically, since probably not everything is available in the QT libraries that you need.


As I understand it from what I have seen so far, the concept for current 
LO a11y is also largely based on the same concepts as 
IAccessible2/AT-SPI, and Qt a11y API is also largely based on the same.


IIUC, what current platform-specific a11y integrations in LO (gtk3, 
qt5/qt6, winaccessibility) do is mostly provide a wrapper around/bridge 
between LO a11y API and the platform-specific API (ATK for gtk3 which is 
bridged to AT-SPI by ATK, Qt for qt5/qt6 which is then bridged to AT-SPI 
by the Qt library for the Linux case, MSAA/IAccessible2 for 
winaccessibility).


Most of the LO UI and document-specific a11y is implemented in a 
platform-independent way (VCL toolkit for the UI) and the mapping to the 
platform-specific implementations happens in a thin layer.


In my understanding, that would remain unchanged in case of using either 
Gtk or Qt on Windows as well. As far as a11y is concerned, this would 
essentially mean dropping the MSAA/IAccessible2 bridge contained in the 
"winaccessibility" directory and reusing the code that is also used for 
Linux (and leave the mapping to UIA to Gtk/Qt).


Should that turn out to be a reasonable approach (which I don't know!), 
my expectation would be that this would essentially give us the same set 
of features with UIA that we currently have with IAccessible2.


I suppose that supporting new UIA concepts/features in addition would 
probably require more fundamental changes than "just" adding a new 
wrapper/bridge for UIA around existing LO a11y interfaces (either a 
custom one, or using Gtk/Qt).
But I'm not an expert and have only little experience with a11y so far 
and not looked into UIA any closer, so all of the above would need 
deeper knowledge/further investigation for a more reliable statement.



Unless there are resources to work on UIA specifically, I tend to think 
it would make sense to focus on improving the existing 
IAccessible2-based implementation ("winaccessibility") (and fixing 
issues that are not platform-specific) for now if that's (still) 
sufficiently supported by AT in practice, and reconsider what to do 
about UIA at some later point in time (at which there might also be news 
on the state of gtk4 and qt5/qt6 a11y).


Happy to hear what others think about this.

Michael

Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 27/04/2022 09.34, di liu wrote:

forget the crash video add it
crash_video.mp4 



The video appears to be inaccessible unless access has specifically been 
granted in Google Drive.


di liu mailto:disco@gmail.com>> 于2022年4月27 
日周三 15:23写道：

There has  a crash error when i use libreoffice in android which is
compiled from the source code.

*The development information:*
the libreoffice branch is *master*(update when a write this mail)
*phone information:*
android sdk : *29(android 10)*
brand*:**HUAWEI HMI-AL100*
ram*:6G*
screen*:2244x1080*


Does that device have a 64-bit ARM processor?


*The triggering scenario for this error：*
This error appears more frequently  when load xlsx file(load other
file also happen).
when l load xlsx file and zoom in the document then slide up and
down quickly (the video in the accessorias) the app will be crashed
suddenly.


i.e. the crash is not 100% reproducible? Can you give a rough estimation 
of how often it happens? (like "almost always", "about every third 
time",...)?
It might also help to share a sample doc (e.g. attaching one to a bug 
report on Bugzilla) if it happens more often with specific files.



the full error log is below

[...]
*What i have try:*
I think the key point log is
org.free.dike.ldoffice E/LibreOffice/androidinst: SalAbort:
'Unspecified application error'
so i searched this message in the source code and finally found it's
in this method: "vcl/source/app/salplug.cxx -> void SalAbort( const
OUString& rErrorText, bool bDumpCore )"
And i search the method 'SalAbort'  to found out the possible invoke
chains.But when i reached method "void
Desktop::Exception(ExceptionCategory nCategory)" in
"desktop/source/app/app.cxx" which i think is most possibly invoke
point trigger this crash. But unfortunately i have not found who
invoke this method. I want to use gdb to debug but when i try to
compile a new so which contain needed symbols and debug info i meet
a link error again(clang++ error:unable to execute command Killed)
which i think cause by low memory of my computer,But i can't change
it...


Finding a working combination of NDK version and linker that work for a 
specific architecture and debug configuration can be a bit tricky.


What does your autogen.input look like? (Or what options are you passing 
to ./autogen.sh manually?)


For a 64-bit ARM debug build, using LLD with NDK 22.1.7171670 worked for 
me in the past, by applying this change on top of master:

https://gerrit.libreoffice.org/c/core/+/130947

and then using an autogen.input containing this:

--build=x86_64-unknown-linux-gnu
--with-android-ndk=/home/michi/Android/Sdk/ndk/21.0.6113669
--with-android-sdk=/home/michi/Android/Sdk
--with-distro=LibreOfficeAndroidAarch64
--enable-sal-log
--with-external-tar=/home/michi/development/libreoffice-external
--enable-ccache
--enable-ld=lld
--enable-dbgutil
--with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/

(Maybe requiring newer NDK versions and switching to LLD for all 
architectures might work by now, but that would need some more testing. 
At least this didn't work for all architectures with older NDK versions 
~2 years ago.)



So could you give me some suggestions how to solve this error


In addition to the above, you could try whether it crashes the same way 
with a daily build provided by TDF, available here, to see whether it's 
in some way related to your build setup:

https://dev-builds.libreoffice.org/daily/master/current.html

Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 27/04/2022 17.27, Michael Weghorn wrote:
For a 64-bit ARM debug build, using LLD with NDK 22.1.7171670 worked for 
me in the past, by applying this change on top of master:

https://gerrit.libreoffice.org/c/core/+/130947

and then using an autogen.input containing this:

--build=x86_64-unknown-linux-gnu
--with-android-ndk=/home/michi/Android/Sdk/ndk/21.0.6113669
--with-android-sdk=/home/michi/Android/Sdk
--with-distro=LibreOfficeAndroidAarch64
--enable-sal-log
--with-external-tar=/home/michi/development/libreoffice-external
--enable-ccache
--enable-ld=lld
--enable-dbgutil
--with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/


... which is obviously using NDK 21.0.6113669, not 22.1.7171670 (which 
is mentioned in the Gerrit patch, but that was for another discussion...).

Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 28/04/2022 05.04, di liu wrote:

Thank you for your response ^_^

The video appears to be inaccessible unless access has specifically been
granted in Google Drive.

I am sorry, have made it

  Does that device have a 64-bit ARM processor?

Yeah ,my device abi is arm64-v8a,And the so is compiled for armeabi-v7a

i.e. the crash is not 100% reproducible? Can you give a rough estimation
of how often it happens? (like "almost always", "about every third
time",...)?

almost always

  It might also help to share a sample doc (e.g. attaching one to a bug

report on Bugzilla) if it happens more often with specific files.
see the accessories


Thanks for sharing the video and a sample file. With those, I can 
reproduce a crash.


Is that file confidential or can it be shared publicly (attached to a 
Bugzilla ticket)? (I can't read most of the text in it. :-))



What does your autogen.input look like? (Or what options are you passing
to ./autogen.sh manually?)

passing nothing to ./autogen.sh
the autogen.input containing this:
--with-distro=LibreOfficeAndroid
--with-android-sdk=/home/disco/Documents/dev_env/android_sdk
--with-android-ndk=/home/disco/Documents/dev_env/android_sdk/ndk/20.1.5948944
--with-ant-home=/home/disco/Documents/dev_env/apache-ant-1.10.12
--enable-debug
--enable-symbols="vcl/source/app/"

For a 64-bit ARM debug build, using LLD with NDK 22.1.7171670 worked for
me in the past, by applying this change on top of master:
https://gerrit.libreoffice.org/c/core/+/130947


and then using an autogen.input containing this:

--build=x86_64-unknown-linux-gnu
--with-android-ndk=/home/michi/Android/Sdk/ndk/21.0.6113669
--with-android-sdk=/home/michi/Android/Sdk
--with-distro=LibreOfficeAndroidAarch64
--enable-sal-log
--with-external-tar=/home/michi/development/libreoffice-external
--enable-ccache
--enable-ld=lld
--enable-dbgutil
--with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/

If i want to build debug version so must build a 64-bit ?


I suppose, in theory, 32-bit should also work. My practical experience 
with the Android toolchain was that several things that should work in 
theory didn't work in reality, and trying a different architecture, NDK 
version, or linker could give better results.


Trying an x86 or x86_64 AVD might also be worth trying.
A dbgutil build works fine for me on a Debian testing machine with 16 GB 
of RAM and an autogen.input containing


--build=x86_64-unknown-linux-gnu
--with-android-ndk=/home/michi/Android/Sdk/ndk/20.0.5594570/
--with-android-sdk=/home/michi/Android/Sdk
--with-distro=LibreOfficeAndroidX86
--enable-sal-log
--enable-ccache
--enable-dbgutil
--with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/

so with your config that uses --enable-debug and restricts for what 
modules symbols are enabled, even less should be needed.



Addition:
Yesterday i use "bugreport" command on my device and found below logs:

04-27 15:53:50.551 10316  3015  3287 W libc    : malloc(2292954)
failed: returning null pointer
04-27 15:53:50.552  1000  2433  6251 I chatty  : uid=1000(system)
Binder:2433_6 expire 4 lines
04-27 15:53:50.553 10316  3015  3287 E LibreOffice/androidinst:
SalAbort: 'Unspecified application error'


There have a log "malloc(2292954) failed: returning null pointer" before 
the error 'Unspecified application error' (both of them come from my 
app(pid=10316))
So i wonder if it is possible that the crash was happened in java ? 
Because i found every time i slide the screen it's will trigger the 
render redraw which will trigger allocate a direct buffer


From what I have seen so far, the problem is that the app/system is 
running out of memory, caused by a memory leak on the C++ side.


Can you try whether the demo patch at 
https://gerrit.libreoffice.org/c/core/+/133581 makes the crash go away 
for you as well?


At least with the experimental editing mode disabled, this worked here.
I haven't tried with experimental mode enabled yet, which was running 
out of memory earlier without the patch in place, and was showing 
another out-of-memory-related error in the ADB log ouput with an x86 
debug build.


(The patch is obviously not meant to be merged as is, just a demo where 
the problem is.)


PS: Adding dev list back to the conversation.

Re: SalAbort:Unspecified application error

[Michael Weghorn]

Is that file confidential or can it be shared publicly (attached to a
Bugzilla ticket)? (I can't read most of the text in it. :-))


 The file is not confidential and can be shared publicly (haha，The text in it 
is chiness)


Great, thanks.


On 29/04/2022 12.07, di liu wrote:

Ok, I will make a try (recompile the source code will spend me
hours... )


Unfortunately it's also crash with same error when i swipe up and down 
more times.


Does "more times" here mean that it takes longer now than previously 
until the problem shows up? Or is it pretty much unchanged for you?


Is that with experimental mode enabled or disabled in the app settings?

I suppose the memory leak maybe exit in this method 
"desktop/source/lib/init.cxx -> doc_paintTile".Because every time i 
swipe the screen the java code will call this method to paint tile where 
crash was happened


Yes, that's most likely.
The one from https://gerrit.libreoffice.org/c/core/+/133581 is also 
called further down in the stack from there and was clearly showing up 
in the memory profile.


The app was working fine with the sample file in non-editing mode  for 
me with that hack in place in a quick test.

But it's well possible that there are more leaks elsewhere.

Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 29/04/2022 12.54, Michael Weghorn wrote:

    Is that file confidential or can it be shared publicly (attached to a
    Bugzilla ticket)? (I can't read most of the text in it. :-))


 The file is not confidential and can be shared publicly (haha，The 
text in it is chiness)


Great, thanks.


I've now created a Bugzilla ticket for the initial issue that I could 
reproduce and have a pending fix for that in Gerrit:

https://bugs.documentfoundation.org/show_bug.cgi?id=148851
https://gerrit.libreoffice.org/c/core/+/133581

With that in place, I didn't see any more crashes or unexpected memory 
usage increase when testing more with your sample doc and experimental 
mode *disabled*.


I can still reproduce a crash due to running out of memory with 
experimental mode *enabled*, though.


I have created a separate ticket in Bugzilla for that one and added some 
more information, also mentioning a potential workaround:

https://bugs.documentfoundation.org/show_bug.cgi?id=148854

I suggest to continue discussion about that particular issue in Bugzilla 
(e.g. I'd be interested whether your crash also disappears when you do 
that change locally).



 My compile machine only has 4GB RAM so that i must restrict the symbols but even so the 
memory is also not enough(because of that link error "clang++ error:unable to 
execute command Killed")


4 GB are actually not much. I have no further ideas what you could 
do/try to do a build with debug symbols in that setup, other than having 
lots of swap, which will probably be very slow.

Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 30/04/2022 06.14, di liu wrote:
I am so sorry,I made a mistake (I made some local changes but did not 
restore the code completely which interferes the test result.)

After my initial test(on the same devices) the crash disappeared.
I will continue to test this issue on different devices and scenarios to 
make sure it be fixed completely


Great, thanks for the update.


  Yeah,thank you so much for all you do.


Thank you for your valuable input. :-)


OpenPGP_signature
Description: OpenPGP digital signature

Re: trigger MapMode ScaleX change in writer

[Michael Weghorn]

On 25/05/2022 15.42, Mark Hung wrote:

You're right. GetScaleX() changes as soon as I zoom the document in or out.
I have just neglected that there is another precondition: OutputDevice 
must be a printer (bPrt ==true)
I'm still trying to figure out how to have a OutputDevice use a 
different scale value.
I'm using a Linux VM so I don't know if a physical printer can make a 
difference.


In case you need a CUPS printer, CUPS-PDF (e.g. provided by the 
printer-driver-cups-pdf package in Debian) might help.


From an application perspective, that should behave like a "real printer".

You can also set up a dummy printer with any PPD file of a real HW 
printer by setting "FileDevice Yes" in /etc/cups/cups-files.conf, 
restarting cups and then using e.g. this command


sudo lpadmin -p dummyprinter -v file:/tmp/tofile-dummyprinter -P 
 -E

Re: ESC meeting minutes: 2022-05-26

[Michael Weghorn]

On 26/05/2022 16.41, Miklos Vajna wrote:

* Completed Action Items:
[...]
     + under-loved areas wiki page (Miklos):
   https://wiki.documentfoundation.org/Development/Under-loved_areas

[...]

* Under-loved areas of the codebase (Michael M)
     + concern that we can't execute quickly on this
     + seems to me the ESC should be recommending areas that are un-loved
   in the code, and ranking them by which are not going to get loved 
soon.

     + brainstorming next-week instead ? (Cloph)
    + lots of people on holiday
     + how do we feel about a wiki page to collect this stuff ? (Caolan)
    + sounds good (Michael)
    + endangered species kind of list (Caolan)
   + would allow non-ESC members but experts in their own field 
to have their say
AI:    + will create a wiki page for this before sending the minutes 
(Miklos)

     + is it an indication - we're going to drop the feature ? (Olivier)
    + concerned re: Math & Base - perhaps Draw
    + no - the opposite (Miklos)
   + we know it is useful - we want to put more resource into it.
   + help the board identify where the best places to invest are 
(Michael)

     + also useful for oversight (Caolan)
    + to indicate where resources can go if they are available.
     + in docs team - paying attention to base module (Olivier)
    + lots of open issues there - happy to hear we can continue to file
  bugs on base as we document it.


Adding my input here, since I wasn't in the meeting and will be mostly 
offline during the next week:


Does it make sense to add the topics already mentioned on board-discuss 
in the discussion around TDF-internal developers?


Without digging deeper in the mail archive, these come to my mind:

From [1]:

* RTL/CTL: meta bug tdf#43808
* CJK: meta bug tdf#83066
* a11y: meta bug tdf#101912, and "accessibility" keyword

and

* Base, with meta bug tdf#120062 and some more additional information in 
[2], [3], [4], [5], [6]


I'm a bit hesitant to add all of those with my own name next to them, 
because I can't be of much help when it comes to those, except for a11y 
maybe.



[1] 
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00277.html
[2] 
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00365.html
[3] 
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00368.html
[4] 
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00370.html
[5] 
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00377.html
[6] 
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00394.html

Re: ESC meeting minutes: 2022-05-26

[Michael Weghorn]

On 29/05/2022 20.40, Caolán McNamara wrote:

On Sun, 2022-05-29 at 07:35 +, Michael Weghorn wrote:

Does it make sense to add the topics already mentioned on board-
discuss in the discussion around TDF-internal developers?
...
* RTL/CTL: meta bug tdf#43808
* CJK: meta bug tdf#83066
* a11y: meta bug tdf#101912, and "accessibility" keyword
* Base, with meta bug tdf#120062 and some more additional information
in [2], [3], [4], [5], [6]

I'm a bit hesitant to add all of those with my own name next to them,
because I can't be of much help when it comes to those, except for
a11y maybe.


Yeah, IMO it does. I think what we want is a level higher than the very
detailed meta-bug level but a level a step more detailed than say, "RTL
needs work" to see what are the stalled areas.


Ah, I see. IIUC, this is then about more specific topics than I was 
assuming previously, and reminds me a bit of the "Tenders for budget" 
collection [1].


Not having been in the call, my previous assumption was more something 
like a mixture of the two levels you mention above, like:
"RTL needs work. If somebody starts working on it, looking at the 
corresponding meta bug might be a good starting point when trying to get 
an overview, besides potential input from people that have experience in 
the area. But while working on bugs from the meta bug, the developer 
will presumably identify other things that need work, and come up with 
their own agenda/suggestion on how to continue to drive the (rather 
high-level) area forward."



For base I've added in the two main issues of hsqldb to firebird
replacement and migration, and the java-based report generator. I've
mostly copy and pasted Alex's thoughts in there. (@alex feel free to
add in other big ticket failings)


Thanks!


[1] https://wiki.documentfoundation.org/Development/Budget2022


OpenPGP_signature
Description: OpenPGP digital signature

Re: ESC meeting minutes: 2022-05-26

[Michael Weghorn]

On 30/05/2022 11.08, Caolán McNamara wrote:

For a11y I don't know what is seen as the major problems, is there some
fundamentally missing pieces (like in the past not having direct
windows IAccessible2 support and needing a java access bridge). Or are
the fundamentals ok and its a matter of a general malaise. Is the
general widgetry ok, but particular components have poor document level
a11y. Or is there an endless amount of fairly easy entry level problems
that there isn't enough people to take care of.


I don't have a comprehensive overview at this point.
At least from the little experience I have by now, I *tend to think* 
it's mostly the latter, at least as far as root causes for the major 
problems are concerned.
(I have also *heard* that Base seems to be most problematic in general, 
but haven't had much to do with it myself yet.)


From what I have seen so far while looking at some a11y issues 
affecting Windows and Linux (gtk3 and qt5/qt6 VCL plugins), the 
fundamentals look fine, and it seems to be mostly that various smaller 
issues in LO a11y code of the single components and the platform 
integrations (and sometimes in other projects, like the NVDA screen 
reader or the Qt library) cause a lack of a11y in the UI (lack of 
usability with accessibility technology, like screen readers, e.g. 
because not everything is announced) and documents (like a11y-related 
attributes not being properly set in docs, in particular when exported 
to other formats like OOXML, PDF, (X)HTML).


The a11y meta bug tdf#101912 [1] currently lists ~200 specific issues. 
(I also have a ranked list from Richard, CCed, a blind user who uses the 
NVDA screen reader on Windows.)
Working on some issues requires some level of understanding/experience 
with AT (accessibility technologies, like a screen reader), others (like 
doc export to other formats) shouldn't.


I don't know about the situation on macOS.

IIUC, the gtk4 VCL plugin currently doesn't have an a11y implementation 
yet, and there has been a change of how a11y is handled at least within 
the Gtk library itself. [1]
@Caolán: Is that correct? And is it something you are planning to look 
into at some point or something that should be covered otherwise?



I've added the accessibility mailing list; maybe others have further 
insights to add here.



[1] https://blog.gtk.org/2020/10/21/accessibility-in-gtk-4/
[2] 
https://wiki.documentfoundation.org/Development/Budget2022#Fix_accessibility_issues


OpenPGP_signature
Description: OpenPGP digital signature

Re: high contrast accessibility application guidelines?

[Michael Weghorn]

[Adding the accessibility mailing list, somebody on that list might have 
more insights]


On 10/10/2022 22.02, Caolán McNamara wrote:

Is there a set of guidelines as to the intent of high contrast within
documents?


Not sure I grasp the context of this question (s. below), but from a 
quick search: WCAG has a criterion 1.4.3 about contrast for (primarily 
web) documents:

https://www.w3.org/WAI/WCAG21/quickref/?tags=contrast#contrast-minimum

The "Understanding Success Criterion 1.4.3: Contrast (Minimum)" page has 
some more details on the intent, etc.:

https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html


As far as I can see in impress/draw/shapes we ignore/force-highcontrast
text color, line color and fill colors, and there's a certain logic to
that. And in general in documents we use a high contrast text selection
mode. >
On the other hand in writer we do show the real text color and fill
color in the normal document content, but do the opposite for shapes
and for the content of frames. If we use the insert, table UI, then we
have forced colors in the preview of what the table will look like, but
the final inserted table then doesn't have forced colors.


Is that with any explicit high-contrast settings either in the desktop 
environment or OS (like a specific theme) or LibreOffice explicitly applied?


In a quick test of mine *without* having taken any explicit settings, it 
behaved like this for me (LO master as of 
221d76260096b9e6b4c4479b1b89c95af8b05774, gtk3 with Adwaita theme and 
kf5 with Breeze theme):


Impress:

1) With the font color in character settings set to "Automatic" (the 
default), font color seems to be chosen automatically to provide 
contrast to the slide background ("Slide properties" -> "Background" -> 
"Color"), e.g. changing slide background from white to black makes the 
text be shown in white.


2) Character highlighting color doesn't seem to be taken into account, 
though. (Setting black highlighting color for text in a new presentation 
results in black text on black background.)


3) If any explicit color is set in the character settings, that one is 
used, regardless of the background, nothing is forced then (i.e. if 
slide background is set to black and font color is explicitly set to 
black, text is unreadable).


Other than Impress, in Writer, "Automatic" text color seems to take into 
account the character highlighting color and page background. (Changing 
the character highlighting color or page background to black results in 
white text, and character background takes precedence over page 
background, which seems reasonable.) Explicitly setting font color to 
black in addition results in black text on black on black background, 
nothing is automatically adapted.


In a quick test on Windows 10 (with an older LO master as of  commit 
349e3af0c5dd5ed495ed61aab526f63c16f0e215), enabling "Use high contrast" 
in the Windows settings results in unreadable text in Impress in a new 
presentation (both, font and background use the same dark color).


OpenPGP_signature
Description: OpenPGP digital signature

Re: Unsubscribe from the Mailing List

[Michael Weghorn]

On 03/12/2021 17.50, İrem Akyol wrote:
I'm so sorry to say this and thank you so much everyone for being on the 
mailing list. However, due to my busyness, I cannot keep up with the 
mail flow. May I ask how to unsubscribe from the mailing list, please?


You can unsubscribe here:
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [VS Code] [vscode-cpptools plugin] Intellisense - Dim Inactive Regions: Where does vscode-cpptools get the values for variables used in "#IF" e.g. "GTK_CHECK_VERSION"?

[Michael Weghorn]

On 11/12/2021 15.40, Christian Ohrfandl wrote:
I have the problem that vscode-cpptools "dim inactive regions" option 
dims the region in the statement

`#if GTK_CHECK_VERSION(4,0,0)`
and additionally Intellisense also does not work in that region.

When changing the statement to
`#if GTK_CHECK_VERSION(3,0,0)`
the respective region is not dimmed anymore and also IntelliSense works 
again.


However when running the application, the following code
`cout << gtk_get_major_version() << "." << gtk_get_minor_version() << 
"." << gtk_get_micro_version() << endl;`

returns `4.5.0`
Therefore, I know for a fact that at compile time level my application 
uses GTK 4.5.0.


What specific source file are you editing?

Are you building both the gtk3 and gtk4 VCL plugins? (gtk3 is enabled by 
default. You can check e.g. whether you have a file 
'instdir/program/libvclplug_gtk3lo.so' after the build, in addition to 
'instdir/program/libvclplug_gtk4lo.so')


Most of the files in 'vcl/unx/gtk3' are used for both, the gtk3 and the 
gtk4 VCL plugin. (s. how the .cxx files in 'vcl/unx/gtk4/' include the 
ones from the 'vcl/unx/gtk3 directory'; 'vcl/Library_vclplug_gtk3.mk' 
and 'vcl/Library_vclplug_gtk4.mk' are the corresponding Makefiles where 
you can see the compiler flags used).


So where does the vscode-cpptools know the GTK version from and 
therefore is able to judge `GTK_CHECK_VERSION(4,0,0)`?


I don't have much experience with VS Code myself, but I'd suppose it 
uses the macro from the corresponding Gtk 3 header (e.g. 
'/usr/include/gtk-3.0/gtk/gtkversion.h' on my Debian testing system).


I also looked into my project's `.vscode` folder into the 
`c_cpp_properties.json` file and added the GTK4 library install dir 
`"/usr/local/include/gtk-4.0"` as follows:

```
{
     "configurations": [
     {
     "name": "Linux",
     "includePath": [
     "${default}",
     "/usr/local/include/gtk-4.0",
     "/usr/include/gtk-3.0",
     "/usr/include/glib-2.0",
     "/usr/lib/x86_64-linux-gnu/glib-2.0/include",
     "/usr/include/pango-1.0"
     ],
     "defines": [],
     "cStandard": "c17",
     "intelliSenseMode": "linux-clang-x64"
     }
     ],
     "version": 4
}


What happens if you drop the Gtk 3 include path "/usr/include/gtk-3.0" 
in addition?
Alternatively, if you don't need the gtk3 VCL plugin, you could also try 
adding '--disable-gtk3' to your 'autogen.input'.

Re: VCL selection

[Michael Weghorn]

On 2024-03-06 21:00, Gwyn Ciesla wrote:
Fedora is looking at changing the default VCL plugin used for 
the interface for various desktop environments, specifically gtk4 for 
GNOME and kf6 for KDE. I'm able to choose the plugin by settting 
SAL_USE_VCL_PLUGIN, but when I have several installed and remove gtk3 it 
defaults to X11, so I'm not sure how it makes that choice.


Julien's email contains a code pointer.

To explicitly mention it here: For KDE Plasma 6, the kf6 VCL plugin is 
already selected by default.


(see commit

commit 06dbdb0f5b618ce01a79f07dc78e8049c419cc5f
Author: Michael Weghorn 
Date:   Thu Jun 22 08:56:36 2023 +0200

Use kf6 VCL plugin by default on Plasma 6
)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: VCL selection

[Michael Weghorn]

On 2024-03-07 09:33, Caolán McNamara wrote:

On Wed, 2024-03-06 at 21:58 +, Gwyn Ciesla wrote:

Interesting. Would you recommend waiting to set gtk4 as default, or
would doing so spur correction of extant issues?


I don't really know. I'm not actively working on it anymore. IMO the
a11y issues are more of an upstream gtk issue in the sense of a lack of
a route to complete a11y integration, Michael Weghorn has far more of a
grasp of the current state of that.


For gtk4 a11y, as Caolán mentioned, this currently lacks upstream Gtk 
API to implement what's needed, see for example the discussion in these 
Gtk issues:


https://gitlab.gnome.org/GNOME/gtk/-/issues/6272
https://gitlab.gnome.org/GNOME/gtk/-/issues/6204
https://gitlab.gnome.org/GNOME/gtk/-/issues/6269
https://gitlab.gnome.org/GNOME/gtk/-/issues/6197

The latter mentions a potential approach (in my perspective this would 
feel more like a workaround ) to implement the low-level platform a11y 
API (AT-SPI) directly in LO for things like the document content instead 
of using (non-existing) Gtk API, but there are open questions for that 
approach also.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Java a11y test not executed

[Michael Weghorn]

On 2024-01-18 19:41, Hossein Nourikhah wrote:

This can be seen in:
https://gerrit.libreoffice.org/c/core/+/162263

Unfortunately, the test fails for me.


On what system does that fail for you?

Interestingly, running `make JunitTest_sw_complex` succeeds for me on 
Debian testing with your above-mentioned change in place.



And the test is actually run, since it fails as expected for me when I 
add an additional assert for the opposite:


diff --git 
a/sw/qa/complex/indeterminateState/CheckIndeterminateState.java 
b/sw/qa/complex/indeterminateState/CheckIndeterminateState.java

index 347552d36f92..b95bc7f40c55 100644
--- a/sw/qa/complex/indeterminateState/CheckIndeterminateState.java
+++ b/sw/qa/complex/indeterminateState/CheckIndeterminateState.java
@@ -80,6 +80,7 @@ public class CheckIndeterminateState {
 long oSet = oContext.getAccessibleStateSet();

 assertTrue("The 'INDETERMINATE' state is not set.", (oSet & 
AccessibleStateType.INDETERMINATE) != 0);
+assertTrue("The 'INDETERMINATE' state is set.", (oSet & 
AccessibleStateType.INDETERMINATE) == 0);

 }

 @Before public void setUpDocument() throws 
com.sun.star.uno.Exception {




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: New tests: GTK3 platform accessibility

[Michael Weghorn]

On 2023-08-03 16:58, Colomban Wendling wrote:
OK… that's already quite a lot.  As CI passes on that changes (well, the 
relevant ones passed, the pending ones are irrelevant for this change), 
what about merging it and seeing if that number goes down?


Sounds like a good way forward to me. I've merged
https://gerrit.libreoffice.org/c/core/+/155310 .


OpenPGP_signature
Description: OpenPGP digital signature

Re: New tests: GTK3 platform accessibility

[Michael Weghorn]

On 2023-08-01 19:30, Colomban Wendling wrote:
Platform accessibility (a11y) conformance tests for the GTK3 VCL [1] 
have been merged a couple days ago.  This is a set of tests validating 
that the a11y exposed to the platform on Linux using the GTK3 VCL is 
coherent with the internal representation in LO.  This can catch (and 
already had caught) issues in the VCL layer not correctly transmitting 
data over -- and even more [2].  You can read a bit more on the 
technical side of things on the wiki page [3].

[...]
[3] 
https://wiki.documentfoundation.org/Development/Accessibility_Unit_Tests#Platform_accessibility_tests


Thanks again, that's really great to have!

To mention it: Platform a11y tests are one of 3 ways that the a11y test 
framework written by Colomban provides to write Cppunit tests (or 
convert Java ones to C++). The other 2 are also described on the 
above-mentioned wiki page.


OpenPGP_signature
Description: OpenPGP digital signature

Re: New tests: GTK3 platform accessibility

[Michael Weghorn]

On 2023-08-24 13:38, Stephan Bergmann wrote:
When I --enable-atspi-tests (which passes configure) on my local Fedora 
38 Linux machine, CppunitTest_vcl_gtk3_a11y fails the



    assert(m_pAtspiApp);


in Atspi2TestBase::setUp 
(vcl/qa/cppunit/a11y/atspi2/atspi2testbase.hxx), apparently because



    Atspi::Accessible desktop(atspi_get_desktop(desktopId));


in Atspi2TestBase::getApp 
(vcl/qa/cppunit/a11y/atspi2/atspi2testbase.hxx) produces


** (cppunittester:1641471): WARNING **: 12:56:34.251: AT-SPI: Could 
not obtain desktop path or name



(cppunittester:1641471): dbind-WARNING **: 12:56:34.251: Couldn't get 
application list: Could not activate remote peer: unit failed.


(cppunittester:1641471): GLib-GObject-CRITICAL **: 12:56:34.251: 
g_object_unref: assertion 'G_IS_OBJECT (object)' failed


on stderr but returns an empty Atspi::Accessible with no children to 
iterate over.


Is there perhaps anything I would need to additionally install or to 
enable to make this work?  Or does it just not work on Wayland?


In my test, it failed differently on Wayland, and forcing the X11 Gdk 
backend makes that work:

https://gerrit.libreoffice.org/c/core/+/156086

Does that fix your case as well?
Otherwise: Does the test work when run in an X11 session instead?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: New tests: GTK3 platform accessibility

[Michael Weghorn]

On 2023-08-28 19:54, Stephan Bergmann wrote:

Otherwise: Does the test work when run in an X11 session instead?


no; guess I need to install some piece of software that is missing from 
my machine


I can reproduce in a GNOME session in a Fedora 38 VM.

It seems to be related to GNOME and dbus-broker being used by default on 
Fedora, together with the gtk3 a11y test suite using xvfb and dbus-launch.


It works just fine for me with the same VM in an SSH or OpenBox session 
instead of the GNOME one.


The error can also be triggered with a simple sample program instead 
(based on what the gtk3 a11y test does):



// to build:
// g++ -g $(pkg-config --cflags atspi-2) -o atspi-sample-app 
atspi-sample-app.cxx $(pkg-config --libs atspi-2)


#include 
#include 

#include 

int main()
{
const int nDesktops = atspi_get_desktop_count();
for (int desktopId = 0; desktopId < nDesktops; desktopId++)
{
AtspiAccessible* pAcc = atspi_get_desktop(desktopId);
GError* pError = nullptr;
gint nChildCount = atspi_accessible_get_child_count(pAcc, &pError);
std::cout << "pAcc: " << pAcc << ", childCount: " << 
nChildCount << ", error: " << pError

  << std::endl;
assert(nChildCount >= 0);
}
};


When running that app as follows, it fails the same way in the Fedora 38 
GNOME session:



$ xvfb-run dbus-launch --exit-with-session ./atspi-sample-app

(process:4584): dbind-WARNING **: 12:01:39.097: Couldn't get application list: 
Could not activate remote peer: unit failed.

(process:4584): GLib-GObject-CRITICAL **: 12:01:39.097: g_object_unref: 
assertion 'G_IS_OBJECT (object)' failed

(process:4584): dbind-WARNING **: 12:01:39.099: AT-SPI: Error in GetItems, 
sender=org.freedesktop.DBus, error=Could not activate remote peer: unit failed.
pAcc: 0xd0d500, childCount: -1, error: 0
atspi-sample-app: atspi-sample-app.cxx:19: int main(): Assertion `nChildCount 
>= 0' failed.
/usr/bin/xvfb-run: line 181:  4584 Aborted  



Running the same with dbus-run-session (hopefully doesn't affect the 
relevant behavior and) gives additional output:



$ xvfb-run dbus-run-session ./atspi-sample-app
dbus-daemon[4713]: [session uid=1000 pid=4713] Activating service name='org.a11y.Bus' requested by 
':1.0' (uid=1000 pid=4714 comm="./atspi-sample-app" label="kernel")
dbus-daemon[4713]: [session uid=1000 pid=4713] Successfully activated service 
'org.a11y.Bus'
Policy to allow eavesdropping in /usr/share/defaults/at-spi2/accessibility.conf 
+15: Eavesdropping is deprecated and ignored
Policy to allow eavesdropping in /usr/share/defaults/at-spi2/accessibility.conf 
+17: Eavesdropping is deprecated and ignored
dbus-daemon[4713]: [session uid=1000 pid=4713] Activating service name='org.freedesktop.systemd1' 
requested by ':1.2' (uid=1000 pid=4722 comm="/usr/bin/dbus-broker-launch 
--config-file=/usr/sha" label="kernel")
dbus-daemon[4713]: [session uid=1000 pid=4713] Activated service 
'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with 
status 1
dbus-daemon[4713]: [session uid=1000 pid=4713] Activating service name='org.freedesktop.systemd1' 
requested by ':1.2' (uid=1000 pid=4722 comm="/usr/bin/dbus-broker-launch 
--config-file=/usr/sha" label="kernel")
dbus-daemon[4713]: [session uid=1000 pid=4713] Activated service 
'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with 
status 1

(process:4714): dbind-WARNING **: 12:03:53.467: Couldn't get application list: 
Could not activate remote peer: unit failed.

(process:4714): GLib-GObject-CRITICAL **: 12:03:53.467: g_object_unref: 
assertion 'G_IS_OBJECT (object)' failed
dbus-daemon[4713]: [session uid=1000 pid=4713] Activating service name='org.freedesktop.systemd1' 
requested by ':1.2' (uid=1000 pid=4722 comm="/usr/bin/dbus-broker-launch 
--config-file=/usr/sha" label="kernel")
dbus-daemon[4713]: [session uid=1000 pid=4713] Activated service 
'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with 
status 1

(process:4714): dbind-WARNING **: 12:03:53.469: AT-SPI: Error in GetItems, 
sender=org.freedesktop.DBus, error=Could not activate remote peer: unit failed.
pAcc: 0x15fa500, childCount: -1, error: 0
atspi-sample-app: atspi-sample-app.cxx:19: int main(): Assertion `nChildCount 
>= 0' failed.


This shows that there is an attempt to start a dbus session using 
dbus-broker-launch. This seems surprising at first, since 
dbus-run-session (and dbus-launch) use dbus-daemon in $PATH by default.


But then, there's an at-spi-bus-launcher involved for running a separate 
bus for AT-SPI/a11y, and the README [1] mentions that that is a separate 
instance of dbus-daemon or dbus-broker. From a first look into the 
source code [2], it looks like it prefers dbus-broker-launch when built 
with the corresponding option and running under systemd, but that 
apparently fails at that stage.



I currently can't come with any idea how to fix/avoid that on our end, 
suggestions we

Re: Error Compiling LibreOffice Core on Debian 12 - x64

[Michael Weghorn]

On 2024-03-24 00:17, Andreas Mantke wrote:

I try to compile LibreOffice core on Debian 12 -x64 but the process
ended with an error.

Here the messages in the shell at the end of the build process:

[MOD] unoxml
/builddir/core/filter/source/graphicfilter/icgm/cgmtypes.hxx:108:
warning: type ‘LineType’ violates the C++ One Definition Rule [-Wodr]
   108 | enum LineType   { LT_SOLID = 1, LT_DASH = 2, LT_DOT =
3, LT_DASHDOT = 4, LT_DASHDOTDOT = 5, // Standard
   |
/builddir/core/vcl/inc/regband.hxx:47: note: an enum with different
value name is defined in another translation unit
    47 | enum class LineType { Ascending, Descending };
   |
/builddir/core/filter/source/graphicfilter/icgm/cgmtypes.hxx:108: note:
name ‘LT_SOLID’ differs from name ‘Ascending’ defined in another
translation unit
   108 | enum LineType   { LT_SOLID = 1, LT_DASH = 2, LT_DOT =
3, LT_DASHDOT = 4, LT_DASHDOTDOT = 5, // Standard
   |
/builddir/core/vcl/inc/regband.hxx:47: note: mismatching definition
    47 | enum class LineType { Ascending, Descending };
   |
g++: fatal error: Getötet signal terminated program lto1
compilation terminated.
lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[1]: *** [/builddir/core/Library_merged.mk:11:
/builddir/core/instdir/program/libmergedlo.so] Fehler 1
make: *** [Makefile:290: build] Fehler 2


I tried in parallel with a build on openSUSE 15.5 -x64 and the build of
LibreOffice  core was successful.

Any hints about a workaround or fix?


Renaming one of the enums could be one approach, e.g. the one defined in 
vcl/inc/regband.hxx to something like "RegionBandLineType".  (Just a 
first thought when skimming over the file, I don't otherwise know the 
involved code.)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

Hi Biswadeep,

On 2024-03-24 14:24, Biswadeep Purkayastha wrote:
Hello, I am Biswadeep Purkayastha, a contributor to OpenPrinting. I am 
reaching out to the community with a request for assistance in 
integrating CPDB (Common Print Dialog Backends) support into the current 
LibreOffice print dialog. CPDB has evolved a lot since the last time an 
attempt was made at providing CPDB support around 6 years ago and so has 
LibreOffice. So I am willing to adapt the older 
code(https://gerrit.libreoffice.org/#/c/40565 
) to align with the current 
LibreOffice and CPDB versions(https://github.com/OpenPrinting/cpdb-libs 
).


That sounds great.

Do I understand correctly that the idea is that the new CPDB-based 
approach would remain optional (for now at least), i.e. replace the 
previous CPDB implementation and co-exist with the existing code 
directly using CUPS/PPD API, rather than making it mandatory to use the 
new approach unconditionally once it's implemented?


To accomplish this task 
effectively, I am seeking guidance and support from LibreOffice 
developers who can provide insights into the current codebase and help 
me achieve this integration. Additionally, having a mentor from the 
LibreOffice community would greatly facilitate the process, allowing for 
smoother integration and ensuring adherence to best practices. If anyone 
in the community is willing to assist or mentor me through this 
endeavor, I would greatly appreciate your support. Please feel free to 
reach out to me via email.


I'm generally willing to support/mentor this project from the 
LibreOffice side.


Our wiki has some general documentation on how to get started with 
LibreOffice development:

https://wiki.documentfoundation.org/Development

Please feel free to ask any questions you might have either on the 
regular channels (like IRC and this mailing list) or directly.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

On 2024-03-26 18:26, Till Kamppeter wrote:
This is no problem to keep it optional, so that the packager/admin/user 
can choose, at least at build time, perhaps even at run time.


Great.

But note that PPD files and classic CUPS drivers are deprecated. CUPS 
3.x, getting completeky released near the end of this year will not 
support PPD files and addable driver filters any more, but exclusively 
support driverless IPP printers. For legacy (non-driverless) we have 
introduced the concept of Printer Applications, software emulations of 
driverless IPP printers.


This requires changes on the print dialog:

- List IPP print destinations, independent whether there is a CUPS queue 
for them or not (if not, CUPS would create a temporary queue)
- Obtain printer capabilities and options via IPP, do not try to 
download the PPD file via CUPS or even try to directly access it in the 
file system.


This can be principally obtained by using the current CUPS APIs (the 
"Dest" ones, already available in libcups2 for several years). Also all 
PPD-related APIs will go away in libcups3.


The CPDB backend for CUPS is already completely updated to the new CUPS 
3.x realm and can actually be built with libcups3. This means with a 
CPDB-supporting print dialog we can smoothly transition from CUPS 2.x to 
CUPS 3.x without loss of functionality and without loss of access to any 
of the available print destinations.


Also the CPDB backend for CUPS is maintained by OpenPrinting, the 
maintainer of CUPS and is updated along with any future change on CUPS. 
So CPDB-supporting print dialogs will keep working in case of such a 
change, so the maintainers of the print dialogs do not have to keep pace 
with that.


So the CPDB option for the LibreOffice dialog will work with CUPS 3.x 
and future versions, the CUPS/PPD option requires updating by the 
maintainers of the LibreOffice dialog.


Thanks for the detailed description. Since printing is a critical 
feature for many users and the current CUPS/PPD API implementation has 
been used successfully for quite a long time now, I wouldn't feel 
comfortable unconditionally replacing it with the CPDB-based approach at 
this point in time. (So I'm glad that isn't the goal for the GSoc project.)


Of course, switching the default to the CPDB-based implementation and 
ultimately dropping the custom CUPS/PPD API implementation are things 
that can be considered at some point in the future, once the CPDB-based 
implementation has proven to be able to cover all relevant use cases and 
all relevant distros provide the libraries and printer applications,


(I remember that the CUPS PPD API has been deprecated for a long time, 
and the IPP-based API would have provided the necessary means to make 
everything work in theory. But at least in pre-printer-application 
times, the practical problem I saw years ago was that - even then new - 
printers weren't offering all of their functionality as IPP attributes, 
so still using the deprecated API was the only way to not lose that 
functionality. IIUC, printer applications are meant to bridge that gap now.)


So I am inviting you as GSoC mentor officially. To get access to all 
resources I do an invitation to the GSoC dashboard. Please watch out for 
an e-mail from Google and follow the instructions in it. If you do not 
feel comfortable to use these facilities, please tell me and I will do 
the official part.


Thanks! I've followed those instructions, am happy to co-mentor.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

On 2024-03-27 11:27, Till Kamppeter wrote:
Michael, Biswadeep will take care of the CPDB interface, but the 
CUPS/PPD interface also needs attention, as if it is not done correctly, 
it will cease to work if CUPS 3.x is used (also if the CUPS Snap or any 
other containerized form of CUPS is used).


For CUPS 3.x support, my initial thought was that requiring the 
CPDB-based implementation for that could be a way forward, while leaving 
LO's internal CUPS/PPD implementation basically unchanged and around for 
compatibility reasons (for CUPS 2.x setups only) as long as necessary.


The CPDB implementation would then be optional for CUPS 2.x, but 
required for CUPS 3.x.


If the CPDB approach will cover everything that the current CUPS/PPD 
implementation does (does it?), that could avoid the need to spend extra 
effort on LibreOffice's CUPS/PPD implementation.


So the CUPS interface (I intentionally do not call it CUPS/PPD 
interface) following has to be assured:


1. The correct CUPS APIs have to be used (cupsEnumDests(), ...), to list 
both classic, permanent CUPS queues with PPD file and IPP print 
destinations for which CUPS creates a queue on-demand. The GTK print 
dialog (GTK version 4.x) uses these APIs, to have an example.


2. Also for obtaining the options only these new "Dests" APIs of CUPS 
have to be used, no old PPD-downloading APIs, and especially no direct 
access to PPD files. The "Dests" APIs for options automatically take 
care what the best is for obtaining the options (including providing all 
PPD options if the queue is a classic CUPS queue), and they continue to 
be available in libcups3. Take the GTK (4.x) print dialog as example for 
use of these APIs.


3. Generally take care to use only libcups API functions which are also 
available in libcups3. Also make the code build with both libcups2 and 
libcups3 (see the projects libcupsfilters (2.x) and libpappl (1.4.x 
branch) as example repos which can be compiled with the user's choice of 
libcups2 or libcups3.


Thanks for explaining what would be needed.

From a first glance at the GTK 4.x code, I'm a bit surprised by it 
being referenced as an example of how to implement things properly.


While I see it has a CPDB implementation (initially added in [1]), its 
own CUPS print backend implementation (e.g. in [2] and [3]) seems to be 
full of uses of deprecated API, including direct use of PPDs.

[2] even has this comment at the top:

/* Cups 1.6 deprecates ppdFindAttr(), ppdFindCustomOption(),
 * ppdFirstCustomParam(), and ppdNextCustomParam() among others.
 * The replacement is to use the Job Ticket API, but that requires
 * a larger refactoring of this backend.
 */

Is there another CUPS-based implementation (besides the CPDB-based 
backend) or am I missing anything else here?



The "Dests" APIs for options automatically take care what the best is
for obtaining the options (including providing all PPD options if the queue is
a classic CUPS queue), (...)


Does that include cases like [4]? And if so, what would be the 
requirements for that to work (as it didn't work in the past)?


In general, my opinion is that for LibreOffice's existing CUPS/PPD 
implementation, we should be very careful not to risk to break existing 
(legacy) setups.


To me, the potential approach outlined above (envision to fully move to 
CPDB-approach in the longer run, leave existing CUPS/PPD implementation 
basically unchanged and around as long as needed so things work "as they 
always did" for legacy setups) seemed to match well with that idea, but 
I'm certainly not as knowledgeable about how this all works as you are, 
so would appreciate to hear your (and anyone else's) opinion on that.



You are now officially registered as mentor and you can see the 
submitted proposals now. Please mark at Biswadeep's proposal that you 
are interested in mentoring. Also have a look into Biswadeep's proposal 
itself.


Thanks, I've done that right after registering. The proposal looks good 
to me.


You will do the LibreOffice side of the mentoring, Gaurav Guleria and me 
will do the CPDB side.


That sounds great, thank you!


[1] 
https://gitlab.gnome.org/GNOME/gtk/-/commit/41b60bbd6ceb36dfc22e625d2b3c65bd45f15c76
[2] 
https://gitlab.gnome.org/GNOME/gtk/-/blob/b1eed1c153f7553c353dc77ae2b0154bdcedc8a0/modules/printbackends/gtkprintbackendcups.c
[3] 
https://gitlab.gnome.org/GNOME/gtk/-/blob/b1eed1c153f7553c353dc77ae2b0154bdcedc8a0/modules/printbackends/gtkprintercups.c

[4] https://github.com/apple/cups/issues/4969


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

On 2024-03-27 15:26, Till Kamppeter wrote:
Also, if we would clean up and update the current CUPS/PPD interface, 
some distros will not go CPDB and users complain when CUPS has another 
significant change or if a clod printing service with their CPDB backend 
shows up.


Are you aware of any specific reasons why distros would prefer direct 
use of CUPS API over CPDB other than the usual packaging efforts needed 
for any new library?


This ways distros have to go CPDB at a certain point of time. They can 
opt to switch over early, for a smooth transition to CUPS 3.x.


Yes, distro packagers should generally be able to judge best when it's 
the right time to switch.


GTK has no alternative CUPS-based backend. Only its original one and 
alternative is CPDB with CPDB's CUPS backend. This alternative is 
required for CUPS 3.x.


I did not actually check the GTK dialog's CUPS backend code. I only 
observed that the GTK dialog is the only one not only showing the 
permanent CUPS queues but also the IPP print destinations for which CUPS 
creates a temporary queue on demand. I did not look into how the options 
and choices are obtained.


Then it seems that they just plugged the problem "IPP destinations 
without permanent CUPS queue do not get listed" by using cupsEnumDests() 
but left all the rest untouched. This satisfies all needs for users of 
CUPS 2.x but will fail with PPD-less CUPS 3.x, requiring the use of CPDB 
for CUPS 3.x here, too.


Even better if the approach other projects take seems to be the same one 
as we're discussing for LibreOffice now. This should also provide a more 
uniform user experience (same printers + options show up regardless of 
the application/toolkit,...).


This means also that the only example known to me, which uses the 
"Dests" API of CUPS correctly is the CUPS backend of CPDB, even more 
important to driver forward that CPDB gets used everywhere.


Thanks for the hint, I'll keep that in mind.

Modern (driverless) printers seem to have a job-password IPP attribute. 
Print dialogs (and for them CPDB) should add support for that.


On old printers Printer Applications (PAPPL, pappl-retrofit) should 
support generatring a job-password IPP attribute (from typical PPD file 
options) and report it.


CUPS should pass on this attributes for print queues which support this 
kind of secured printing.


So we should post feature requests for all these components.

This would also improve the UI of print dialogs when you can type the 
PIN as a 4-digit number instead of selecting the digits with 4 dropdowns.


There's the existing [1], but I don't know whether that would still be 
the right place to report such things these days.



OK, let us keep it for now and make sure uses/packagers/admins using 
CUPS 3.x use CPDB. The CUPS/PPD interface could be automatically skipped 
at build time if there is no libcups2 present, as the CPDB part could be 
skipped if there is no cpdb-libs present. If both got built, one could 
have a choice in the settings (not in the print dialog itself, to avoid 
clutter) which one actually to use.



(...)


I think we can go this way, see above. Important is that libcups2 with 
its PPD APIs is not required to build LibreOffice with print functionality.


That sounds reasonable and shouldn't be a problem in general, but will 
of course need a closer look into the code to see whether CUPS-related 
code is already fairly local or currently spread all over the place 
right now, requiring some more refactoring or reconsideration.


We already have various `--enable-`/`--disable-` 
configure flags (some with autodetection if not passed explicitly) for 
various features. Adding additional ones for those cases should be fine 
and fairly straightforward.


(Details on how to configure things at build and run time can also be 
discussed later.)



Michael


[1] https://bugs.linuxfoundation.org/show_bug.cgi?id=1393


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

On 2024-03-27 17:40, Till Kamppeter wrote:

On 27/03/2024 16:22, Michael Weghorn wrote:


Are you aware of any specific reasons why distros would prefer direct 
use of CUPS API over CPDB other than the usual packaging efforts 
needed for any new library?




No.

It could only happen that some distros are perhaps not aware of CPDB and 
therefore try to go the way of directly talking with CUPs.


Good, then I currently see no blocker for requiring CPDB for CUPS 3.x 
support. Distros will then become aware once they're packaging any 
software depending on CPDB at latest.


OK. If CPDB is used it must be taken care that we nowhere talk with CUPS 
directly, as otherwise non-CUPS CPDB backends (cloud printing services) 
will not work.


Yes, that makes sense. (For the CPDB case, we won't want to use CUPS 
directly anymore, as CPDB API should be providing everything that's 
needed, as you mentioned earlier.)


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

On 2024-03-27 19:33, Till Kamppeter wrote:


Would be good to tell them that for CUPS 3.x use of CPDB is required.

For CUPS 2.x the direct CUPS interface can be used and CPDB also works 
with CUPS 2.x (CPDB works with any CUPS).


Once CPDB support has been implemented, that can be added to the release 
notes.

These are maintained on a wiki page.

For the next Libreoffice release LibreOffice 24.8:
https://wiki.documentfoundation.org/ReleaseNotes/24.8

@Biswadeep: As you're implementing the feature, could you please keep in 
mind to add this to the release notes once it's been integrated?


(Depending on when it gets merged, this would likely be either for 
LibreOffice 24.8 or 25.2).


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Eager to contribute to GSoC 2024

[Michael Weghorn]

On 2024-03-27 12:12, Ritobroto Mukherjee wrote:
I am submitting my formal application for GSoC in this email, and an 
attached document with further details.


Please note that (from what I know at least), the formal application 
needs to be submitted via the GSoC website, so I'd recommend to check 
and resubmit there.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

On 2024-03-28 11:23, Biswadeep Purkayastha wrote:

 >@Biswadeep: As you're implementing the feature, could you please keep in
 >mind to add this to the release notes once it's been integrated?

 >(Depending on when it gets merged, this would likely be either for
 >LibreOffice 24.8 or 25.2).

Sure, I'll keep it in mind.


Great, thanks!


OpenPGP_signature.asc
Description: OpenPGP digital signature

android: Bump minSdkVersion to 21 (Android 5.0)

[Michael Weghorn]

Android NDK 26 dropped support for Android API levels lower than 21 
(Android 5). [1] [2]


To ease maintenance, I would like to do the same for our Android build.
According to [2] and [3], more than 99% of Android devices have an 
Android version of at least 5.0 by now.


If there are any concerns about this, please raise them before or during 
the ESC call this Thursday. Otherwise, I plan to merge the corresponding 
Gerrit change. [4]


(No changes on Jenkins side are required, but this will unify the API 
level that the 32- and 64-bit Android builds use, since 64-bit builds 
already require API level 21 anyway, and 32-bit builds on Jenkins 
currently use API level 19.)



[1] https://github.com/android/ndk/issues/1751
[2] https://developer.android.com/ndk/downloads/revision_history
[3] https://apilevels.com/
[4] https://gerrit.libreoffice.org/c/core/+/160334


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Outreachy Dec 2023 - Implement Qt/KDE Frameworks theming using native Qt widgets

[Michael Weghorn]

Hi Omkar, all,

On 2023-12-06 18:47, Omkar Acharekar wrote:
        My Name is Omkar Acharekar. I am excited to share with you that 
I will be working this next months on "Implement Qt/KDE Frameworks 
theming using native Qt widgets (Weld interface)" project as part of the 
Outreachy internship, under mentorship of Michael Weghorn and Heiko Tietze.


welcome again, it's great to have you! :-)

      The project aim is to refine the UI of Qt/KDE Frameworks by making 
use of native Qt widgets through the Weld interface. (...)


For reference, these are the Outreachy pages of accepted interns and 
Omkar's project:


https://www.outreachy.org/alums/2023-12/
https://www.outreachy.org/outreachy-december-2023-internship-round/communities/libreoffice/#implement-qtkde-framework-theming-using-native-qt-

The project is based on an earlier idea from Jan-Marek for a GSoC project:
https://wiki.documentfoundation.org/Development/GSoC/Ideas_without_a_mentor#Implement_qt5_/_kf5_theming_using_native_Qt_widgets_(Weld_interface)

For anyone interested, I'm copying parts of 2 emails I sent to Omkar 
earlier with some more thoughts on the project. If anyone has any 
further thoughts, please don't hesitate to add them.


Michael


On 2023-11-23 18:58, Michael Weghorn wrote:


Some notes and code pointers in addition to what the project description 
mentions:

## Qt

Did you work with Qt or any other UI toolkit before? If you didn't, I'd 
recommend to experiment a bit with Qt to get an impression/some experience with 
the toolkit outside of the LibreOffice context. (What a native Qt application 
looks like, how the widgets work,...)

Qt widgets doc:
https://doc.qt.io/qt-6/qtwidgets-index.html
Tutorial:
https://doc.qt.io/qt-6/widgets-tutorial.html


## VCL plugins

To support good integration for different platforms/desktop environments, LibreOffice 
uses a concept of so-called "VCL plugins", in particular on Linux.

vcl/README.md has some more information.

In order to choose what VCL plugin to use, the SAL_USE_VCLPLUGIN environment 
variable can be used.

E.g. if you start LibreOffice with

SAL_USE_VCLPLUGIN=gtk3 ./instdir/program/soffice.bin --writer

, the "gtk3" VCL plugin will be used, and likewise for the other plugins 
(gen/gtk3/gtk4/kf5/kf6/qt5/qt6).

For the project, the Qt-based VCL plugins are relevant (qt5, qt6, kf5/kf6).

They share most of the code. Relevant directories:
vcl/inc/qt{5,6}
vcl/qt{5,6}
vcl/unx/kf{5,6}

To enable building of these VCL plugins, use the corresponding autogen.sh 
switch, e.g. `--enable-kf5`
(see also `./autogen.sh --help` output)

## Weld (API)

The weld API is an abstraction layer used in LibreOffice to support different 
UI toolkits.

* include/vcl/weld.hxx is the central header file with declarations for the 
weld API.
* Implementing this API using native Qt widgets is basically the task of the 
Outreachy project.
* weld::Widget is the basic widget and more complex widget types derive from 
that.
* class weld::Builder is responsible for creating the different widgets, e.g. 
`weld::Builder::weld_message_dialog` creates a message dialog, 
`weld::Builder::weld::button` creates a button,...
* weld::Builder and weld::Widget have purely virtual methods, the actual 
implementation is in different subclasses that use a specific widget 
toolkit/library.
* vcl/inc/unx/gtk/gtkinst.hxx and vcl/unx/gtk3/gtkinst.cxx are a good starting 
point to see how this is done for the Gtk implementation that uses native Gtk 
widgets.
* `SalInstanceBuilder` is the implementation using LibreOffice's own VCL 
toolkit, currently also used by the Qt-based VCL plugins.
(vcl/inc/salvtables.hxx and  vcl/source/app/salvtables.cxx are good starting 
points.)
* There's also a `JSInstanceBuilder` (vcl/inc/jsdialog/jsdialogbuilder.hxx) 
used for Collabora Online [1], which can give some more ideas on what a 
specific implementation can look like.

## User interface definitions

LO's user interface is mostly defined in .ui files that can be opened and 
edited in Glade ( https://glade.gnome.org/ ).
Potentially helpful:
https://wiki.documentfoundation.org/Development/Create_new_dialog_in_Impress

The .ui file format that LO uses is the one that Gtk applications also use 
themselves.

Looking at the .ui files of a few sample dialogs (both, in glade and at the 
"plain" XML file) and experimenting with them a bit (e.g. change some 
properties, insert an additional widget) can be useful to get an understanding of how 
this works.

Basically, the .ui files (or elements therein) are processed by the 
weld::Builder mentioned above to create the corresponding widgets.

A simple example is the dialog that shows when you try to close LO with a 
document open that has unmodified changes:

UI file: sfx2/uiconfig/ui/querysavedialog.ui
C++ code: sfx2/source/doc/QuerySaveDocument.cxx

(`git grep ` is usually helpful to find the corresponding C++ sou

Re: android: Bump minSdkVersion to 21 (Android 5.0)

[Michael Weghorn]

On 2023-12-05 11:18, Michael Weghorn wrote:
Android NDK 26 dropped support for Android API levels lower than 21 
(...)


To ease maintenance, I would like to do the same for our Android build.
(...)

If there are any concerns about this, please raise them before or during 
the ESC call this Thursday. Otherwise, I plan to merge the corresponding 
Gerrit change. [4]


(..)
[4] https://gerrit.libreoffice.org/c/core/+/160334


Change merged now, since there were no concerns:

commit c2fc2c8c7c63ca4e43bca6e8c9b82c50418422d2
Author: Michael Weghorn 
Date:   Tue Dec 5 09:57:22 2023 +0100

android: Bump minSdkVersion to 21 (Android 5.0)



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Resurrecting --enable-online-update-mar

[Michael Weghorn]

On 2023-12-15 13:53, Stephan Bergmann wrote:

- Online Update".  (For non-GTK VCL backends, there's still a bug that 
the "Automatic Update" section on that options page is mixed into the 
traditional --enable-online-update options at the top of the page, 
instead of down at the bottom; fixing of 
cui/uiconfig/ui/optonlineupdatepage.ui welcome...)


See
https://gerrit.libreoffice.org/c/core/+/160830
"Fix placement for --enable-online-update-mar UI"


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Commit 70ef230 causes GTK4 build to fail

[Michael Weghorn]

On 2023-12-22 08:21, Etna - wrote:

Hi, building on Linux (Debian 12) breaks with the following error:

[LNK] Library/libvclplug_gtk4lo.so
ld.lld: error: undefined symbol: lo_accessible_new(_GdkDisplay*, 
_GtkAccessible*, 
com::sun::star::uno::Reference const&)

referenced by gtkaccessibleregistry.cxx
              
/home/etna/Tmpdir/libreoffice/build/workdir/CxxObject/vcl/unx/gtk4/gtkaccessibleregistry.o:(GtkAccessibleRegistry::getLOAccessible(com::sun::star::uno::Reference,
  _GdkDisplay*, _GtkAccessible*))
clang-15: error: linker command failed with exit code 1 (use -v to see 
invocation)
make[1]: *** 
[/home/etna/Tmpdir/libreoffice/vcl/Library_vclplug_gtk4.mk:20: 
/home/etna/Tmpdir/libreoffice/build/instdir/program/libvclplug_gtk4lo.so] Error 1

make[1]: *** Waiting for unfinished jobs

I was able to get the build to succeed by rolling back commit 70ef230 ( 
https://github.com/LibreOffice/core/commit/70ef230aae4f961c8197cc11a7ff5feaf1d96c20 )


What could be the cause here? And can this commit can be reverted?


The newly introduced code uses code requiring Gtk 4.9, but Debian 12 
only has Gtk 4.8.


Does
https://gerrit.libreoffice.org/c/core/+/161144
make the build work again for you?



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: ESC meeting minutes: 2023-12-21

[Michael Weghorn]

On 2023-12-21 16:51, Colomban Wendling wrote:

Le 21/12/2023 à 16:27, Stephan Bergmann a écrit :

[…]
  14 CppunitTest_test_a11y    gerrit_windows

That doesn't look too good…

 From a couple failing jobs, I see a weird error that barely seem related:


[_RUN_] SelfTestIncorrectDialog::TestBody
warn:sfx.appl:16560:16772:sfx2/source/appl/app.cxx:147: No DDE-Service 
possible. Error: 16399

warn:unotools.misc:16560:16772:unotools/source/misc/mediadescriptor.cxx:372: url: 
'private:factory/swriter' com.sun.star.ucb.ContentCreationException message: "No 
Content Provider available for URL: private:factory/swriter at 
C:/cygwin/home/tdf/lode/jenkins/workspace/gerrit_windows/ucbhelper/source/client/content.cxx:205"
 eError: (com.sun.star.ucb.ContentCreationError) NO_CONTENT_PROVIDER


Any idea of what that can be?


I think that that warning should be unrelated to the failing test. At 
least I see a similar warning locally when just running Writer from a 
local master build on Linux.


Or has this been solved already somehow?  Though, it seems flaky, at 
least from https://gerrit.libreoffice.org/c/core/+/160450 in which it 
looks like a mere re-trigger "fixed" it.


Unfortunately, I don't see anything useful in the backtrace (where the 
SIGABRT might come from). (It might be an actual issue somewhere in LO 
source code not even directly related to a11y.)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Commit 70ef230 causes GTK4 build to fail

[Michael Weghorn]

On 2023-12-22 08:48, Michael Weghorn wrote:

Does
https://gerrit.libreoffice.org/c/core/+/161144
make the build work again for you?


I've merged that change to master now, so hopefully a `git pull` makes 
things work again. (Feedback appreciated.)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Commit 70ef230 causes GTK4 build to fail

[Michael Weghorn]

On 2023-12-22 14:47, Jean-Baptiste Faure wrote:
I've merged that change to master now, so hopefully a `git pull` makes 
things work again. (Feedback appreciated.)


That worked for me, now I can build the master with GTK4 enabled.
Thank you.


Great, thank you for the feedback.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: New tests: GTK3 platform accessibility

[Michael Weghorn]

On 2023-09-12 10:49, Colomban Wendling wrote:

All that is a bit confusing to me, but let me try ton understand:
- On a system using dbus-broker, when logged in under GNOME, test fails?
- On *the same system*, but logging-in through SSH works!??


Yes, that's what I've observed in a Fedora 38 VM.

That's worrying, as it suggests the running environment has too much 
influence on the test run, which is not good.


However, IIUC you suggest it might be a dbus/dbus-borken conflict 
somehow?


That's what it looked like to me during first analysis.

What might be happening is that at-spi-bus-launcher detects a systemd 
environment that makes it think running dbus-broker should work, but 
something about the systemd/D-Bus environment in the virtual X session 
provided by xfvb-run and dbus-launch doesn't match what's expected/required.


See also this comment in the at-spi-bus-launcher source code [1]:

  /* This detects whether we are running under systemd. We only try to
   * use dbus-broker if we are running under systemd because D-Bus
   * service activation won't work otherwise.
   */

The following sample program, based on the at-spi-bus-launcher-code, 
could explain why the SSH case works: The "systemd, use dbus-broker" 
case is triggered for me on Debian testing in a KDE Plasma X11 session 
(and probably the same way for a Fedora 38 GNOME session), but not in an 
SSH session ("no systemd, don't use dbus-broker").



---

// build: g++ -o test test.cxx -lsystemd

#include 
#include 
#include 

int main()
{

// s. 
https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/e7310f8a57cf9d9744f68059fad451cb3acd116a/bus/at-spi-bus-launcher.c#L453-460

char* unit;
if (sd_pid_get_user_unit (getpid (), &unit) >= 0)
std::cout << "systemd, use dbus-broker" << std::endl;
else
std::cout << "no systemd, don't use dbus-broker" << std::endl;
}

---

What if we try `dbus-broker-launch` (assuming it's compatible) 
instead of `dbus-launch` if the former is available? 
Would that help?



As Stephan mentioned already, it's not compatible as a drop-in-replacement.

Maybe this more complicated way mentioned in the Github discussion I 
mentioned earlier could work:


Question [2]:

"What is the recommended way to run a nested dbus session, if not by 
using dbus-run-session? I mostly use it to run debug instances of GNOME 
Shell, as well as the for the CI pipeline when running inside Docker."

Answer (next comment):

"We don't have a recommended way to do that. If that functionality is
needed, it should be straightforward to achieve by just invoking your
private instance of `dbus-broker-launch`. Socket-activation for the
listener-socket is mandatory, though. So I would imagine creating
`dbus-broker@.socket` and `dbus-broker@.service` as systemd template
units, which take a path as template-argument where to place the socket.
It should then be as simple as `systemctl start
dbus-broker@foobar.service` to get it up and running.

If, however, you intend to integrate it into a test-suite, I would
rather expect the test-suite to create the listener manually and pass it
through `execve(2)` to `dbus-broker-launch`."

I don't have any system to test this with yet, and it might take some 
time before I can have a F38 VM up and running with a LO build setup, 
but I'll try and see to this soon if it's a concern.


I'm on vacation this week, but could give this another try in my Fedora 
VM sometime afterwards. Or, if you're also attending LibreOffice 
conference next week in person, we could also take a look at it together 
then for example.



[1] 
https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/e7310f8a57cf9d9744f68059fad451cb3acd116a/bus/at-spi-bus-launcher.c#L453-460

[2] https://github.com/bus1/dbus-broker/issues/145#issuecomment-437874214


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: New tests: GTK3 platform accessibility

[Michael Weghorn]

On 2023-09-14 11:05, Colomban Wendling wrote:
I'm on vacation this week, but could give this another try in my 
Fedora VM sometime afterwards. Or, if you're also attending 
LibreOffice conference next week in person, we could also take a look 
at it together then for example.


I'll be there, we can indeed try and pull some hairs together on this 
then :)


Great! :)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: New tests: GTK3 platform accessibility

[Michael Weghorn]

On 2023-09-13 23:56, Michael Weghorn wrote:
Or, if you're also attending LibreOffice 
conference next week in person, we could also take a look at it together 
then for example.


Colomban and I analyzed this a bit further yesterday, without coming up 
with an actual solution yet.


We noticed that at-spi2-core itself is using a similar approach to run 
its CI tests, which also fails when run in a Fedora 38 GNOME session.


Colomban found this existing issue about running tests using dbus-broker 
on which I've commented now, hoping to get input from upstream:

https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/49


OpenPGP_signature.asc
Description: OpenPGP digital signature

Request for tarball upload (IAccessible2)

[Michael Weghorn]

Could someone please upload the following tarball to
dev-www.libreoffice.org?

https://nextcloud.documentfoundation.org/s/tpKW89gmd5zLzNH/download/IAccessible2-1.3+git20231013.3d8c7f0.tar.gz

(needed for https://gerrit.libreoffice.org/c/core/+/158427
"tdf#135586 a11y: Make IAccessible2 an external and update it";
tarball generated from current IAccessible2 git master as described in 
the commit message)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Request for tarball upload (IAccessible2)

[Michael Weghorn]

On 2023-10-25 17:44, Stephan Bergmann wrote:

On 10/25/23 16:40, Michael Weghorn wrote:

Could someone please upload the following tarball to
dev-www.libreoffice.org?

https://nextcloud.documentfoundation.org/s/tpKW89gmd5zLzNH/download/IAccessible2-1.3+git20231013.3d8c7f0.tar.gz


done,


Thanks a lot, Stephan!


$ sha256sum IAccessible2-1.3+git20231013.3d8c7f0.tar.gz
0e279003f5199f80031c6dcd08f79d6f65a0505139160e7df0d09b226bff4023  
IAccessible2-1.3+git20231013.3d8c7f0.tar.gz


That's the correct checksum.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Which GUI toolkit should I learn so that I can "Hack the UI"

[Michael Weghorn]

On 2024-05-03 19:15, Printf Debugging wrote:
**Opinions invited**: I want to work on the UI, beyond small issues, 
like creating custom widgets, notebookbar, tabbed UI etc. I feel that I 
need to know a GUI toolkit well, like gtk or qt for that. So some days 
ago, I started playing around with GTK. My question is that which 
toolkit will be more useful? I picked GTK because we use .ui files for 
the UI, and being good at GTK will somehow help when working on LO UI, 
but again I don't know, that's just an idea.


Starting with GTK generally sounds reasonable to me.
Concepts are usually very similar in other toolkits (like Qt), so 
learning GTK will also help understanding those better.


In any case, I recommend explicitly testing the non-GTK case when doing 
UI changes (with SAL_USE_VCLPLUGIN=gen and qt5/qt6/kf5/kf6 on Linux or 
by testing on a different platform).


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: GSoC project to add CPDB support to the LibreOffice print dialog

[Michael Weghorn]

On 2024-05-06 19:22, Biswadeep Purkayastha wrote:> I am Biswadeep 
Purkayastha, a GSoC 2024 contributor to OpenPrinting. In
the upcoming months I'll be working on getting CPDB support into the 
LibreOffice print dialogs. I had previously reached out to the community 
asking for a mentor to help me from the LibreOffice side and I am happy 
to announce that Michael Weghorn will be mentoring me from the 
LibreOffice side on this project. I look forward to working on this 
project with my mentors and being a part of the open-source community.


Thanks for the update and welcome again!
I'm looking forward to working together and hope you'll have a great 
GSoC experience!


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

On 15/02/2021 12.26, Michael Weghorn wrote:
In order to directly match an actual kit, one could try to retrieve the 
UUID for a valid kit from the settings in the Qt Creator profile and use 
that one when generating the *.pro.user files, but that's not ideal 
either in my opinion (e.g. one would have to "guess" what kit is the 
right one, rely on a specific Qt Creator profile path,...).


I just recently read about *.pro.shared files [1] which are actually 
meant to share project settings. Those might actually be a better way to 
handle all of this.

I'll probably take a closer look at some point in time.


From commit e827cb144ee9886134a946c7a3b316f9eeb83168 ("qtcreator: 
Create *.pro.shared files instead of *.pro.user") on, *.pro.shared files 
will be generated.
If you still don't want to use the autogenerated and autoselected kit 
with build/run settings, this will at least make sure you don't have to 
configure your custom settings every time, since the *.pro.user file 
holding the settings is no longer overwritten every time that

'make qtcreator-ide-integration' is run.


And for the contents of lo.pro, I still get "." as the first
subdirectory. I have to
manually change it to "../core".


As mentioned in my previous email, I can take a quick look whether I can 
see anything obvious if you upload your generated files somewhere or 
send them by email and tell me the paths used in your case (and whether 
you use a separate build dir).


I've seen a similar error message to yours when testing with a separate 
build dir that is not on the same "hierarchy level" in the file system 
as the source dir (srcdir: ~/development/git/libreoffice, builddir: 
~/temp/lobuild):


~/development/git/libreoffice/lo.pro:-1: error: Could not find .pro 
file for subdirectory "../../development/git/libreoffice/UnoControls" in 
"~/development/git/libreoffice/../../development/git/libreoffice/UnoControls".


Pending Gerrit change [1] ("qtcreator: Create *.pro and *.pro.shared 
files in builddir, not srcdir") (and its ancestors) should fix cases 
where builddir != srcdir, hopefully fixing your problem as well (for 
which I don't know the details, so can't explicitly test that).


I'll update the wiki entry [2] later, once everything has been merged.


[1] https://gerrit.libreoffice.org/c/core/+/111553
[2] https://wiki.documentfoundation.org/Development/IDE#Qt_Creator
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

Hi Hossein,

On 25/02/2021 18.10, Hossein Noorikhah wrote:

Now I am using the latest LibreOffice master build which uses .pro.shared files.
Everything works just fine, except that 'Replacement for "Desktop"' Qt kit,
which does not cause harm to the build process. If this is unavoidable at this
point, I am ok with it.


I currently don't see a good way to avoid this while still having proper 
run and build configurations, since this is how Qt Creator's handling of 
kits works: If no existing kit is set, it creates such a new 
"Replacement" kit to take over settings, s. Qt Creator's source code: 
https://codereview.qt-project.org/gitweb?p=qt-creator/qt-creator.git;a=blob_plain;f=src/plugins/projectexplorer/project.cpp;hb=caaad2107db4f6c1150d40d8d6c01eb6b21bede1 
- method 'Project::createTargetFromMap'.



I see these build configurations:

 01-Global Build
 02-Global tests -- quick tests (unitcheck)
 03-Global tests -- slow tests (unitcheck, slowcheck, screenshot)
 04-Global tests -- integration tests (unitcheck, slowcheck, screenshot,
 subsequentcheck)
 05-Global tests -- performance tests (perfcheck)
 06-Global tests -- tests (check)
 07-Global build -- nocheck
 08-Global build -- build-l10n-only
 09-Global build -- build-non-l10n-only
 10-Global build -- clean
 11-Global build -- clean-build
 12-Global build -- clean-host

with the run settings as expected, having the correct executable and path in
place.


Great.

I try to update the wiki entry "Development/IDE" according to your changes, and
I appreciate your help in adding any relevant information.


Thanks! Please just go ahead, I think you'll probably best know what 
information is helpful for someone who starts "from scratch". :-)

I'll be happy to review that in the end.

However, let's first try to identify the other remaining issue in your 
setup, I'll reply to your other email in a moment.


Regards,
Michael
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

Hi Hossein,

On 26/02/2021 07.46, Hossein Noorikhah wrote:

Not all sources are included in the project. Look at vcl/source/window/menu.cxx
https://opengrok.libreoffice.org/xref/core/vcl/source/window/menu.cxx

I can not find this file in vcl.pro or any other .pro file. Is it intentional?


That should be present, and it is in my case:

$ grep 'source/window/menu.cxx' -- vcl/vcl.pro
/home/michi/development/git/libreoffice/vcl/source/window/menu.cxx \

The above is the output with the pending changes in Gerrit in place 
already (so that absolute paths are used), but I see the entry (with 
path relative to the vcl/ directory) in the files I had uploaded earlier 
as well [1]:


$ tar xf qtc_autogenerated.tar.gz
$ grep 'source/window/menu.cxx' vcl/vcl.pro
source/window/menu.cxx \

This is on Debian testing and I've checked that on Windows as well.
Can you share your autogen.input (if present) and share your vcl.pro via 
pastebin (or send by email)?


Regards,
Michael


[1] https://nextcloud.documentfoundation.org/s/cXTdxJPw83cfTd3


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

On 26/02/2021 08.53, Michael Weghorn wrote:

This is on Debian testing and I've checked that on Windows as well.
Can you share your autogen.input (if present) and share your vcl.pro via 
pastebin (or send by email)?


Now that the Jenkins CI builds have finished, I have merged the pending 
patches. It may be worth trying again with current master first, in case 
any of the changes might already have fixed the issue for your setup...

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

On 26/02/2021 10.33, Hossein Noorikhah wrote:

I am using the latest Ubuntu LTS.
There is no autogen.input here, I usually run ./autogen.sh without any
parameters, but I have this in autogen.lastrun:

./autogen.sh --with-distro=LibreOfficeLinux

Although I think the last run of autogen.sh was without any parameters.


If run without any parameters, './autogen.sh' will use the params set in 
'autogen.input', and if that's not present, those from 
'autogen.lastrun', so that's OK.


My current autogen.input contains these params:

--enable-ccache
--enable-dbgutil
--enable-werror
--enable-gtk3-kde5
--enable-qt5
--enable-kf5
--without-doxygen
--with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/
--enable-python=fully-internal
--with-valgrind
--enable-split-debug
--enable-ld=gold
--enable-gdb-index
--enable-online-update

Not sure whether it's related to the qtcreator issue we're discussing, 
but in case you should want to debug LO, you'll probably want 
'--enable-debug' or '--enable-dbgutil'.




The vcl.pro file is also attached. Look at these results:

hossein@linux:~/Projects/libreoffice/core/vcl$ find -iname "*.cxx"|wc
 830 830   26203
hossein@linux:~/Projects/libreoffice/core/vcl$ find -iname "*.hxx"|wc
 388 388   10798
hossein@linux:~/Projects/libreoffice/core/vcl$ wc vcl.pro
   816  1631 56830 vcl.pro
hossein@linux:~/Projects/libreoffice/core/vcl$ grep .cxx vcl.pro | wc
 202 405   15719
hossein@linux:~/Projects/libreoffice/core/vcl$ grep .hxx vcl.pro | wc
 294 589   20919

A lot of files are missing in the vcl.pro


qtcreator-ide-integration (and the other IDE integrations as well) uses 
information from gbuild (the LO build system).
Does 'workdir/GbuildToJson/Library/libvcllo.so' have an entry 
'source/window/menu'?


You can check e.g. by using

grep -E --color 'source/window/menu( |$)' 
workdir/GbuildToJson/Library/libvcllo.so

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

On 26/02/2021 10.06, Hossein Noorikhah wrote:

I am using the latest git master, and here is the result of the command. The
same error is shown when I set the paths and run "gbuild-to-ide" manually.

-
hossein@linux:~/Projects/libreoffice/core$ make qtcreator-ide-integration
make -j 8 -rs -f
/home/hossein/Projects/libreoffice/core/Makefile.gbuild gbuildtojson
cd /home/hossein/Projects/libreoffice/core &&
/home/hossein/Projects/libreoffice/core/bin/gbuild-to-ide --ide
qtcreator --make make
ERROR : creating pro file=/home/hossein/Projects/libreoffice/core/core/core.pro
[Errno 2] No such file or directory:
'/home/hossein/Projects/libreoffice/core/core/core.pro'
Traceback (most recent call last):
   File "/home/hossein/Projects/libreoffice/core/bin/gbuild-to-ide",
line 1773, in emit
 with open(qt_pro_file, mode) as fpro:
FileNotFoundError: [Errno 2] No such file or directory:
'/home/hossein/Projects/libreoffice/core/core/core.pro'




ERROR : creating pro.shared
file=/home/hossein/Projects/libreoffice/core/core/core.pro.shared
[Errno 2] No such file or directory:
'/home/hossein/Projects/libreoffice/core/core/core.pro.shared'
Traceback (most recent call last):
   File "/home/hossein/Projects/libreoffice/core/bin/gbuild-to-ide",
line 1787, in emit
 with open(qt_pro_shared_file, mode) as fproshared:
FileNotFoundError: [Errno 2] No such file or directory:
'/home/hossein/Projects/libreoffice/core/core/core.pro.shared'


It's weird that it tries to create a 'core/core.pro' and 
'core/core.pro.shared', I don't have any such files here.


Is it correct that directory 
'/home/hossein/Projects/libreoffice/core/core/' does not exist? (which 
would explain the error messages when trying to create the files, but 
not why this is attempted at all...).




Please note that I have cloned LibreOffice core in the ~/Projects/libreoffice
folder, and then built it.

sudo apt-get build-dep libreoffice
cd ~/Projects/libreoffice
git clone git://anongit.freedesktop.org/libreoffice/core
cd core
./autogen.sh
make


I'll try that here to see how it behaves for me when I take those steps, 
then run 'make qtcreator-ide-integration'.


Can you possibly send me your 'workdir/GbuildToJson/' so I can see 
whether there's anything obviously weird in there?

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

On 26/02/2021 11.32, Michael Weghorn wrote:

Please note that I have cloned LibreOffice core in the 
~/Projects/libreoffice

folder, and then built it.

sudo apt-get build-dep libreoffice
cd ~/Projects/libreoffice
git clone git://anongit.freedesktop.org/libreoffice/core
cd core
./autogen.sh
make


I'll try that here to see how it behaves for me when I take those steps, 
then run 'make qtcreator-ide-integration'.


Can you possibly send me your 'workdir/GbuildToJson/' so I can see 
whether there's anything obviously weird in there?


I can't reproduce by using exactly those steps, i.e.

   mkdir -p ~/Projects/libreoffice
   cd ~/Projects/libreoffice/
   git clone git://anongit.freedesktop.org/libreoffice/core
   cd core/
   ./autogen.sh
   make
   make qtcreator-ide-integration
   grep -E --color 'source/window/menu( |$)' 
workdir/GbuildToJson/Library/libvcllo.so


worked fine for me, but I can reproduce with the 
'--with-distro=LibreOfficeLinux' param you mentioned in your other 
email, i.e. running this afterwards:


   git clean -dxf
   ./autogen.sh --with-distro=LibreOfficeLinux
   make
   make qtcreator-ide-integration

I get the


$ make qtcreator-ide-integration
make -j 64 -rs -f 
/home/michael.weghorn/Projects/libreoffice/core/Makefile.gbuild gbuildtojson
cd /home/michael.weghorn/Projects/libreoffice/core &&  
/home/michael.weghorn/Projects/libreoffice/core/bin/gbuild-to-ide --ide qtcreator 
--make make
ERROR : creating pro 
file=/home/michael.weghorn/Projects/libreoffice/core/core/core.pro
[Errno 2] No such file or directory: 
'/home/michael.weghorn/Projects/libreoffice/core/core/core.pro'
Traceback (most recent call last):
  File "/home/michael.weghorn/Projects/libreoffice/core/bin/gbuild-to-ide", 
line 1773, in emit
with open(qt_pro_file, mode) as fpro:
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/michael.weghorn/Projects/libreoffice/core/core/core.pro'




ERROR : creating pro.shared 
file=/home/michael.weghorn/Projects/libreoffice/core/core/core.pro.shared
[Errno 2] No such file or directory: 
'/home/michael.weghorn/Projects/libreoffice/core/core/core.pro.shared'
Traceback (most recent call last):
  File "/home/michael.weghorn/Projects/libreoffice/core/bin/gbuild-to-ide", 
line 1787, in emit
with open(qt_pro_shared_file, mode) as fproshared:
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/michael.weghorn/Projects/libreoffice/core/core/core.pro.shared'




Successfully created the project files.


as well and


$ grep -E --color 'source/window/menu( |$)' 
workdir/GbuildToJson/Library/libvcllo.so
grep: workdir/GbuildToJson/Library/libvcllo.so: No such file or 
directory


and

grep -r source/window/menu workdir/GbuildToJson/

does not show any hit at all, so it seems that gbuild does not generate 
the relevant information when the '--with-distro=LibreOfficeLinux' param 
is used (and all the qtcreator-related issues are probably just a 
consequence of this).


You could check the single params set in 
'distro-configs/LibreOfficeLinux.conf' to see which one is the 
"problematic" one. At a quick glance, '--enable-mergelibs' looks like it 
might be related.


In a previous email, you had mentioned:


I had issues with other IDE integration outputs which need separate discussions.


I'm wondering whether those might all have the same root cause.

In any case, can you try again using e.g. the build params I had 
mentioned earlier or those recommended in the wiki for development to 
see whether that works for you as well?

It's probably best to run 'git clean -dxf' first for a fresh start.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

On 26/02/2021 13.05, Hossein Noorikhah wrote:

workdir/GbuildToJson/Library/libvcllo.so is blank. But VS Code
project has all the .cxx and .h files.


Looking at 'vs-code-template.code-workspace', it seems to just include 
the whole source tree as a directory, so I suspect that there's no 
problem since simply all header and source files in there will be included:



...
"folders": [
{
"name": "srcdir",
"path": "/home/michi/development/git/libreoffice"
},


It's weird that it tries to create a 'core/core.pro' and
'core/core.pro.shared', I don't have any such files here.
Is it correct that directory
'/home/hossein/Projects/libreoffice/core/core/' does not exist?


No, I don't have any directory named core/core.

I'm going to remove the whole source directory and try building again.


See my other mail from just now, this should hopefully work with 
different autogen options.


Regards,
Michael
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

Hi,

On 26/02/2021 16.02, Hossein Noorikhah wrote:

On Fri, Feb 26, 2021 at 3:46 PM Michael Weghorn  wrote:



On 26/02/2021 13.05, Hossein Noorikhah wrote:

workdir/GbuildToJson/Library/libvcllo.so is blank. But VS Code
project has all the .cxx and .h files.


Looking at 'vs-code-template.code-workspace', it seems to just include
the whole source tree as a directory, so I suspect that there's no
problem since simply all header and source files in there will be included:


So, why not do the same for the Qt Creator? It can cause no harm, since
the build system is separate. Finding source files, adding them to a single
lo.pro file, and that's all. What do you think about such an approach?
Maybe other useful file types can also be included.

$ find -iname "*.cxx" -o -iname "*.hxx"|wc
   21243   21243  901070


Different modules can be built with different parameters (like defines, 
include paths, compiler/linker flags), s.a. the .pro files. Mixing all 
of them together and setting all of them for all source files wouldn't 
really be "correct" in a strict sense. If I remember correctly, even 
with the current approach, the flags for all libraries/executables in 
one subdirectory are already "merged together". As long as there are no 
conflicting options, this should be no problem in practice, though, and 
*might* be no problem when doing everything it similarly in the 
top-level lo.pro either.


While those parameters in the .pro files are not relevant for the actual 
build (since Qt Creator just calls 'make' anyway and that one does not 
rely on what is set in the .pro files), Qt Creator uses the information 
from the .pro files for its Clang Code Model, which provides e.g. 
autocompletion, code navigation, displaying compiler warnings and errors.


So I *guess* (but haven't tried) that just adding all the sources and 
headers to lo.pro wouldn't give you a nice setup with the 
'--enable-mergelibs' autogen option set either, since the code model 
wouldn't work properly due to missing parameters (assuming that they are 
not properly propagated to workdir/GbuildToJson, as it seems).



Conceptually, it would probably be "most correct" from a build system 
perspective to have a separate .pro file for each library/executable 
(e.g. to generate a single .pro file for each of the 
'workdir/GbuildToJson/Library/libvclplug_*' files instead of merging 
them into 'vcl/vcl.pro').



However, I'd say it makes sense to be pragmatic, so IMHO, it's a 
question of what the practical advantages/disadvantages of changing the 
current approach would be.
Since the current approach is working fine for me (and it has been like 
that since I've been using it; I'm not the original author of 
qtcreator-ide-integration), I didn't see a real "need" to further 
evaluate changing the way of how this aspect is handled so far.
If there are practical advantages of changing that (to either just have 
a single top-level .pro file or further split the current ones), I see 
no reason not to do so.


Two more thoughts on the current handling came to my mind:

1) You can also just build a single module by e.g. right-clicking on the 
"vcl" directory in Qt Creator and selecting "build vcl".). It's also 
possible to just load e.g. vcl.pro as a project instead of the whole 
lo.pro. I've never really used that myself, since loading the full 
project is reasonably fast and I build from command line most times 
anyway, but it might be something to keep in mind when evaluating what 
pros/cons different approaches have.


2) With the current approach, you just see those source files in the 
project view that are actually compiled (e.g. don't see Windows-specific 
files when building on Linux). That can be seen as either an advantage 
or a disadvantage.



Regards,
Michael
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice