RE: Debugging on Visual Studio (Windows)

[Kaganski Mike]

On 19.07.2024 11:14, Miklos Vajna wrote:
> On Thu, Jul 18, 2024 at 07:30:53PM -0700, Kira Tubo  
> wrote:
>> 2. In Cygwin: make vs-ide-integration
>> 3. In Visual Studio, open LibreOffice.sln
>> 4. Add breakpoints to a .cxx file
>
> To be clear, this is for the IDE integration, debugging doesn't need
> that, it would be for tab completion while editing code, etc.
>
> If you just want to debug, you can simply open the file in question and
> put breakpoints there, no need for any kind of projects.

Just to clarify: while VS IDE integration is not required, it doesn't hurt, and 
can't be a reason of any failure like discussed here.

>> 5. In Cygwin: instdir/program/soffice.exe
>> 6. In Visual Studio, Debug > Attach to Process > soffice.bin (at this
>> point, it asked me to run VS with admin privileges)
>
> I don't recall I had to have admin privileges to debug a normal
> soffice.bin process, but otherwise yes, that's how you do it, yes.

The admin privileges request is most suspicious. I would blame it for 
everything, e.g. I could suspect that there is a problem that admin process 
working with other environment variables could simply be unable to find the 
symbols.

There must not be an admin request. It needs clarification, if you use 
different users to run VS, and run LO.

>> 7. F5 to start debugging
>
> Not sure you need this step, possibly once you attach the debugger to
> the process, it'll wait for your breakpoint to be hit, so you don't have
> to start anything.

Of course, attaching to a running process doesn't need F5 until a breakpoint 
hit, or otherwise paused; when in pause, F5 would resume (and F10 would step 
over).


--
Best regards,
Mike Kaganski

От: LibreOffice  от имени Miklos 
Vajna 
Отправлено: 19 июля 2024 г. 9:14
Кому: Kira Tubo 
Копия: libreoffice@lists.freedesktop.org 
Тема: Re: Debugging on Visual Studio (Windows)

Hi Kira,

On Thu, Jul 18, 2024 at 07:30:53PM -0700, Kira Tubo  wrote:
> I'm having difficulty debugging using Visual Studio on Windows. Not sure if
> I am doing something wrong or I'm missing some things that need to be
> installed.
>
>1. I have --enable-dbgutil set up in my autogen.input file

Good, at this point you should have debug symbols.

>2. In Cygwin: make vs-ide-integration
>3. In Visual Studio, open LibreOffice.sln
>4. Add breakpoints to a .cxx file

To be clear, this is for the IDE integration, debugging doesn't need
that, it would be for tab completion while editing code, etc.

If you just want to debug, you can simply open the file in question and
put breakpoints there, no need for any kind of projects.

>5. In Cygwin: instdir/program/soffice.exe
>6. In Visual Studio, Debug > Attach to Process > soffice.bin (at this
>point, it asked me to run VS with admin privileges)

I don't recall I had to have admin privileges to debug a normal
soffice.bin process, but otherwise yes, that's how you do it, yes.

>7. F5 to start debugging

Not sure you need this step, possibly once you attach the debugger to
the process, it'll wait for your breakpoint to be hit, so you don't have
to start anything.

Regards,

Miklos

Re: build error : 'f__faststorefence': is not a member of 'GrGLInterface::Functions'

[Kaganski Mike]

On 2020-02-01 8:58, himajin10 wrote:
> I'm getting the following error. how should I fix this error?(and why 
> doesn't Jenkis fail?)
> 
> C:/build/workdir/UnpackedTarball/skia/src/gpu/gl/GrGLGpu.cpp(3771): 
> error C2039: 'f__faststorefence': is not a member of 
> 'GrGLInterface::Functions'
> C:\build\workdir\UnpackedTarball\skia\include/gp/gl/GrGLInterface.h(74): 
> note: see declaration of 'GrGLInterface::Functions'

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

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: o3tl::make_unsigned

[Kaganski Mike]

On 2020-01-30 17:25, Luboš Luňák wrote:
> On Thursday 30 of January 2020, Kaganski Mike wrote:
>> Can the hypothetical make_signed function return a signed integer when
>> there's a bigger integer type exist,
> 
>   Yes.
> 
>> and a struct with overloaded
>> operator<=> when there's not, and that overloaded operator<=> would
>> check if contained unsigned value is greater than max value of its
>> signed argument, and return "contained unsigned is greater than passed
>> signed" in that case, otherwise fallback to "convert unsigned to signed
>> and compare normally" strategy? This would comply with the scope of the
>> function (which, as I understand it, to only be used in preparation to
>> comparison), always return mathematically correct result of comparison,
>> and allow all smaller types comparison to still be without overhead?
>> (But for 64-bit unsigned types, of course, it will introduce the
>> overhead. Will it be significant, though?)
> 
>   Not worth it. That'd be like doing error checking for every memory
> allocation - we also bother only with those few cases where it realistically
> can go wrong.
> 

I disagree with this approach. Not checking memory allocation result is 
a strategy with specific and easily controlled results of failed 
expectation. I am sure that it will segfault, not proceeding with wrong 
operation - and that's enough for me. Not checking in the discussed case 
is just a sure way to difficult-to-find bugs - and yes, I see the "this 
will not happen in my time" argument.

I share the "unsigned types are harmful" idea, but I see the logic in 
Stephan's solution which may have correct scope of application without 
any overhead; and there is no strictly correct scope of application for 
"make_signed" on 64-bit integers without additional checking. The 
"number is non-negative" has a natural application; "number no greater 
than std::numeric_limits::max()" is absolutely artificial.

IMO the "let's change make_unsigned with make_signed" only makes sense 
if it is *correct* solution, even if it implies overhead.

My take on this is https://gerrit.libreoffice.org/c/core/+/87762. I can 
see why it might be considered wrong and rejected (e.g., because 
overhead it brings is unacceptable; or because asserting on valid range 
is considered correct...) - but at least this would not (unless I made a 
programming error) give wrong results, not "I believe I will never meet 
values outside of this range".

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: o3tl::make_unsigned

[Kaganski Mike]

On 2020-01-30 15:30, Stephan Bergmann wrote:
> On 30/01/2020 12:56, Luboš Luňák wrote:
>> On Thursday 30 of January 2020, Stephan Bergmann wrote:
>>> On 29/01/2020 17:14, Luboš Luňák wrote:
    Exactly my point. It's just that you seem to find it guaranteed that
 people won't mess up range checks and only likely there won't be
 titanically huge files/allocations/containers, and I see it the 
 other way
 around. So far I've definitely seen more often somebody get >=0 wrong
 than I've seen 8 exabytes of anything.
>>>
>>> My point is that, for e1 of signed type S1 (where U1 is the unsigned
>>> counterpart) and e2 of unsigned type U2 (where S2 is the signed
>>> counterpart),
>>>
>>>     e1 < 0 || U1(e1) < e2  // (*)
>>>
>>> is guaranteed to work for all types S1 and U2 and all values of e1 and
>>> e2, while
>>>
>>>     e1 < S2(e2)
>>>
>>> is not.  My point has nothing to do with people writing broken code, or
>>> how to prevent them from doing so.
>>>
>>> It is just that for the task "compare a signed e1 against an unsigned
>>> e2", (*) is the tool I at least reach for (naturally; without much of a
>>> second thought, actually).  And it has in fact been used all over the LO
>>> code base,
>>
>>   This contradicts your original mail, where you stated that what is used
>> is "if (sal_uInt32(e1) < e2) ...    // (B)" (i.e. without the <0 
>> check). And
> 
> Maybe it is unclear, but my original mail was talking about a "correct" 
> comparison
> 
>    e1 < e2
> 
> (i.e., where it is known that e1 >= 0, but where compilers might 
> nevertheless emit a signed-vs.-unsigned warning).

Can the hypothetical make_signed function return a signed integer when 
there's a bigger integer type exist, and a struct with overloaded 
operator<=> when there's not, and that overloaded operator<=> would 
check if contained unsigned value is greater than max value of its 
signed argument, and return "contained unsigned is greater than passed 
signed" in that case, otherwise fallback to "convert unsigned to signed 
and compare normally" strategy? This would comply with the scope of the 
function (which, as I understand it, to only be used in preparation to 
comparison), always return mathematically correct result of comparison, 
and allow all smaller types comparison to still be without overhead? 
(But for 64-bit unsigned types, of course, it will introduce the 
overhead. Will it be significant, though?)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gsoc 2020

[Kaganski Mike]

Hi!

On 2020-01-26 20:18, Ilmari Lauhakangas wrote:
> You could try
> --with-jdk-home=/cygdrive/c/Program Files/Java/jdk-13.0.1

In cygwin, I usually use forward-slash paths, which are perfectly-valid 
cygwin paths, like

--with-jdk-home=C:/Program Files/Java/jdk-13.0.1

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Duplicate .uno commands

[Kaganski Mike]

On 2020-01-05 17:22, Kaganski Mike wrote:
> On 2020-01-05 2:38, Maxim Monastirsky wrote:
>> The separate .uno:BulletsAndNumberingDialog command predates the
>> handling of .uno:OutlineBullet in Writer. The latter was introduced
>> only in 2013 as part of the sidebar feature work (commit
>> d02f75a8c36705924ddd6a5921fe3012fafce812, "Resolves: #i121420# merge
>> sidebar feature"). I believe the intent there was to have a single
>> command to dispatch from the sidebar's bullets/numbering popups, across
>> different modules, not to introduce any new behavior beyond
>> .uno:BulletsAndNumberingDialog.
> 
> Thank you; so I assume that hiding .uno:BulletsAndNumberingDialog and
> replacing its uses with .uno:OutlineBullet is OK.

For the record: done with 
https://git.libreoffice.org/core/+/d1133d71a6109d1999121fd6a91573d12dc4852b.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Duplicate .uno commands

[Kaganski Mike]

Hi Maxim,

On 2020-01-05 2:38, Maxim Monastirsky wrote:
> The separate .uno:BulletsAndNumberingDialog command predates the
> handling of .uno:OutlineBullet in Writer. The latter was introduced
> only in 2013 as part of the sidebar feature work (commit
> d02f75a8c36705924ddd6a5921fe3012fafce812, "Resolves: #i121420# merge
> sidebar feature"). I believe the intent there was to have a single
> command to dispatch from the sidebar's bullets/numbering popups, across
> different modules, not to introduce any new behavior beyond
> .uno:BulletsAndNumberingDialog.

Thank you; so I assume that hiding .uno:BulletsAndNumberingDialog and 
replacing its uses with .uno:OutlineBullet is OK.

>> and is there an
>> existing mechanism to hide some .uno commands from the customization
>> UI?
> 
> Yes. Each sdi slot has 3 attributes which should be set to FALSE :
> AccelConfig, MenuConfig, ToolBoxConfig. As a result, the given command
> won't be reported to the customization dialog via the
> XDispatchInformationProvider interface. See the actual implementation
> in SfxBaseController::getConfigurableDispatchInformation and
> SfxAppDispatchProvider::getConfigurableDispatchInformation.

Thank you very much - now I see why I rejected my initial assumption of 
this: as you may see in the links to the SDIs in the starting message 
(duplicated below), the .uno:OutlineBullet slot does have the 
AccelConfig and MenuConfig both set to FALSE; yet the slot is visible on 
both menu and keyboard customization tabs. Looking at the places that 
use the constants, I see that they all harvest whatever has at least one 
of the flags set. So obviously a bug here :-)

https://opengrok.libreoffice.org/xref/core/sw/sdi/swriter.sdi?r=7efae60f#452
https://opengrok.libreoffice.org/xref/core/svx/sdi/svx.sdi?r=ef6e2b50#5897

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Duplicate .uno commands

[Kaganski Mike]

Hi Miklos,

Thanks for your comments!

On 2020-01-03 11:28, Miklos Vajna wrote:
>> The problem with this, besides duplication itself (including e.g.
>> drawing icons), is that both of them appear in customization dialog, and
>> that's confusing.
> 
> You can avoid duplicated icons via icon-themes/.../links.txt.

My point about duplication and icons was duplicated effort for creating 
them - which has already happened, as seen in this case; not how 
technically to make two commands to point to the same icon (which is 
easy - once you *know* that they are duplicates).

> 
>> Having two elements in customization dialog with same
>> name, but different operation, as often happening, is already bad enough
>> (user has to experiment to find the one that is needed; that was handled
>> partially in tdf#108458); but having two totally identical elements is
>> too much IMO. Users would struggle to find the difference; and anyway
>> assume they just didn't find the scenario where they act differently.
> 
> Can't we label the deprecated one as "... (deprecated)"?

Do you mean changing label of one? I'd say it's not ideal: the idea 
behind deprecation will not be obvious; in the presence of many 
non-duplicating commands with identical names, these two would still 
raise questions like "is this one deprecated because it's a duplicate of 
*that other one*, or *of another unknown*, or because of other reason?", 
which would still not address the problem. I hoped there's an existing 
way to mark a command as "hidden from Customization dialog" :-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Duplicate .uno commands

[Kaganski Mike]

Hi!

In tdf#129549 [1], two .uno commands were identified as duplicating: 
.uno:BulletsAndNumberingDialog and .uno:OutlineBullet. First of them is 
Writer-specific [2]; second is not [3].

In Writer, both of them are routed to SwTextShell::ExecEnterNum, and 
handled identically (in the same switch case), opening the bullets and 
numbering dialog.

They have identical UI names ("Bullets and Numbering"); similar (but not 
identical) icons (see [4] for screenshot of them side by side using 
Colibre icon set); and they both are used in Writer's UI: 
.uno:BulletsAndNumberingDialog in main menu [5], .uno:OutlineBullet in 
context menu [6].

The problem with this, besides duplication itself (including e.g. 
drawing icons), is that both of them appear in customization dialog, and 
that's confusing. Having two elements in customization dialog with same 
name, but different operation, as often happening, is already bad enough 
(user has to experiment to find the one that is needed; that was handled 
partially in tdf#108458); but having two totally identical elements is 
too much IMO. Users would struggle to find the difference; and anyway 
assume they just didn't find the scenario where they act differently.

The question is: how to handle this? I suppose that one of them 
(.uno:BulletsAndNumberingDialog) should be deprecated and hidden from 
the customization UI, and its uses replaced with the other. I suppose we 
can't drop it completely for compatibility reasons (might it be used in 
user code?).

So is there something I miss about these two commands behaving 
identically? Might there be a reason to keep it as is? and is there an 
existing mechanism to hide some .uno commands from the customization UI?

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=129549
[2] 
https://opengrok.libreoffice.org/xref/core/sw/sdi/swriter.sdi?r=7efae60f#452
[3] 
https://opengrok.libreoffice.org/xref/core/svx/sdi/svx.sdi?r=ef6e2b50#5897
[4] https://i.imgur.com/tTAMjDb.png
[5] 
https://opengrok.libreoffice.org/search?project=core&full=%22uno%3ABulletsAndNumberingDialog%22
[6] 
https://opengrok.libreoffice.org/search?project=core&full=%22uno%3AOutlineBullet%22
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Print dialog window too big with 6.4.0~rc1

[Kaganski Mike]

On 2019-12-31 16:32, Paul Menzel wrote:
> LibreOffice 6.4.0.1 40(Build:1) seems to have redesigned the print 
> dialog. The window is too big now, causing the buttons in the bottom not 
> to be seen on a laptop with 1366x768 resolution and GNOME Shell, which 
> does not allow you to move the window outside the screen. If the window 
> is supposed to stay that big, a scrollbar needs to be added so all parts 
> of the dialog can be seen.

Please see tdf#127782. In general, any bug reporting should be done 
there in the bug tracker. Thanks!

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=127782

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Failing UI tests on Winx64 build

[Kaganski Mike]

Hi Stepas Toliautas,

On 2019-12-30 0:32, Stepas Toliautas wrote:
> 
> However, we're not out of the woods yet, since a single new error of
> presumably the same type (access violation at shutdown) cropped up
> in impress_demo uitest suite -- at /backgrounds.ImpressBackgrounds/,
> in /test_background_dialog/ . Test log is at
> http://paste.debian.net/1123087/ . It might well have been there
> before, just the tests didn't get that far before now.
> 
> 
> A few more from another test run are shown below. Note that these (and 
> the last one) come and go, and are NOT reproduced by directly running 
> separate test files. Could it be that concurrent testing (-j 8) of 
> different modules is somehow at fault here?

I hope you had built LO (`make`) after pulling before running `make 
uitest.uicheck`?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Benchmark results on mdds::multi_type_vector

[Kaganski Mike]

Hi Kohei,

On 2019-12-14 1:38, Kohei Yoshida wrote:
> Alright, since now one person is raising objection on hastily 
> integrating this piece, I should hold on to integrating this piece for 
> now, and let the discussion continue.

If I understand correctly, there was no objections on integrating this 
work into LibreOffice; it sounded more like stating the obvious that the 
we can speculate as long as we want, but only actual usage will show the 
real picture - and that implies that the integration is really needed.

Personally I would love seeing it integrated; and I have high hopes on 
the improvements this offers. My understanding of the typical usage 
patterns of Calc makes me feel that the benefits will vastly outweigh 
possible corner-case slow-down.

Given that there was no further discussion on this topic (AFAICT), do 
you have plans to go on and integrate in in the near future please?

Thank you for your great work!

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Failing UI tests on Winx64 build

[Kaganski Mike]

Hi,

On 2019-12-26 22:59, Stepas Toliautas wrote:
> I happened to launch some "live" UI tests on my Windows 10 x64 machine 
> and noticed that some of them keep failing -- all with the same exit 
> status 3221225477 (0xC005, access violation) and, supposedly, right 
> at the end of testing, because I don't see any assert or warning 
> messages in output logs (or don't know where to look).

Hopefully these should be fixed with

https://git.libreoffice.org/core/+/3ebf6a090b227c0097ff8668fe023e7bdbdadc5d

and

https://git.libreoffice.org/core/+/8cce131dcc1803ac95f3079098be767662fcca09

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Avoid "JRE required" msg upon extension installation

[Kaganski Mike]

Hi Alexis,

On 2019-12-25 3:23, Alexis de Lattre wrote:
> I developed a LibreOffice Extension that contains a Python macro (and 
> the required Python libs):
> 
> https://github.com/akretion/factur-x-libreoffice-extension  file 
> "factur-x_macro.oxt" (source code in "extension/" subdir)
> 
> But, when I add this extension to LibreOffice on a PC without Java 
> installed, I get this error message:
> 
> << LibreOffice requires a Java runtime environment (JRE) to perform this 
> task. However, use of a JRE has been disabled. Do you want to enable the 
> use of a JRE now?  >>
> 
> If I answer "No", the extension will still work fine (because the 
> extension doesn't need Java at all, it only contains a Python macro). So 
> this message is wrong.
> 
> Could I change something in my macro to avoid this message ? My 
> extension targets users without IT background and they could be scared 
> by that wrong message.
> 
> Thanks in advance for your help,
> 

You can't change anything in the extension to avoid this. This is 
tdf#120363 [1], and is fixed in LibreOffice 6.2.

There are other cases when similar warnings appear; see e.g. [2] which 
is about warning in script organizer dialog, fixed in 6.3.1. If you come 
across such problems in current releases, please file a bug and CC me. 
Thanks.

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=120363
[2] https://bugs.documentfoundation.org/show_bug.cgi?id=126643

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [libreoffice-design] Minutes from the UX/design meeting 2019-DEC-12

[Kaganski Mike]

Dear Paul,

12 дек. 2019 г. 17:30 пользователь paul hofseth  написал:

Sirs,

please do not waste scarce coding resources on thoroughly trivial
matters like colours and signage, but rather on making the programs more
practical to use -  such as for instance having the choice of typeface
as a sdeparate item, not hidden inside the multiple format choices.
Risking ostracism fro monotounous suggestions, I repeat my wish for
sequential views of single pages with as little jumbling as possible of
text and illsustrations when proofreading long documents

Please do not waste scarce coding resources on thoroughly trivial
matters like telling others what to do, but rather on making the programs more
practical to use!

Why do I write this rather harsh statement? Not in the hope that you would 
start doing what I wrote, but to show you one important aspect that you seem to 
overlook. What would you do if you actually be denied of a way to contribute by 
expressing your opinions and wishes, and demanded to do something entirely 
different for the project? For most, such requirement would not mean they 
started contributing differently; that would mean they stopped contributing at 
all. Most people here contribute for one of two reasons: either being paid for 
the work by their employers/customers, or doing things they *can* for own 
enjoyment. Not everyone here likes or is able to do what you'd want them to do 
to fix your pet bug; and your expectation that if you deny someone of doing 
what *you* consider "trivial" would free the resources for a different task, 
are just plain wrong: instead of improving the areas you are interested in, we 
would simply loose those who love and able to contribute in areas *others* are 
interested in, nothing else.

By the way, I actually deem the importance of *your* contriburion (expressing 
your opinion about LibreOffice and its future, feeling for it, and proposing 
something) wery high. So please don't take the initial statement seriously, but 
just as a way to illustrate my point.

Best regards,

Mike Kaganski

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

Re: chart2.check fails in testAxisTitlePositionDOCX

[Kaganski Mike]

On 11.12.2019 1:32, Luke Benes wrote:
> I bisected this regression to
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=d10db7846602c16701dde019f12f61fd536e9ae4
> 
>  tdf#128133 WIN don't exit after link-output filter

I would assume this not to be a regression from that commit, but rather 
a regression from DPI-dependent unit tests added in the time span 
between an unintended disabled inclusion of the DPI-aware manifest in 
commit 7f791f431c79c6d0a156c4a2726a0dfc5ff40cc1, and this one fixing that.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Accessing code for Calc functions

[Kaganski Mike]

Hi Steve,

On 26.11.2019 17:15, Steve Fanning wrote:
> I am currently working as a member of the Documentation Team, updating 
> Chapter 18 of the Calc Guide (Description of Functions). From time to 
> time during this task, I would benefit from viewing the code that 
> implements individual functions but have not been able to find that 
> code. Could somebody give me some hints please?

E.g., given the function CHITEST [1]:

1. I git grep for the function's name:
 https://opengrok.libreoffice.org/search?project=core&full=CHITEST
2. I see opcode, like "{ "CHITEST" , SC_OPCODE_CHI_TEST },", and grep 
for the opcode:
 
https://opengrok.libreoffice.org/search?project=core&full=SC_OPCODE_CHI_TEST
3. I see "ocChiTest = SC_OPCODE_CHI_TEST," in opcode.hxx, and grep gain 
for it:
 https://opengrok.libreoffice.org/search?project=core&full=ocChiTest
4. In an interprN.cxx, I see "case ocChiTest :", and go there to see the 
name of function called when that opcode arrives:
 
https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/interpr4.cxx?r=0ef5c475#4392
5. So I see the function name is ScChiTest:
 
https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/interpr3.cxx?r=f853ec31#2797

This is possibly too long, but that's from the PoV of not knowing where 
to look initially. Of course, you could also try shortcut searching for 
ScFoo when looking for FOO function... (not always helpful). Anyway, 
this shows the relevant pieces.

> It would also help if I could view the code for the Function Wizard.

For any dialog, you look into its English UI, and grep for the strings 
in it (choose specific enough):
 
https://opengrok.libreoffice.org/search?project=core&full=%22Function+result%22

Find the .ui file, and then grep for its name in .cxx files - you will 
find the constructor creating the dialog or one of its tabs:
 
https://opengrok.libreoffice.org/search?project=core&full=%22formuladialog.ui%22

So likely you need to look in formula/source/ui/dlg/formula.cxx

That's how I do that. HTH.

[1] 
https://help.libreoffice.org/latest/en-US/text/scalc/01/04060181.html?DbPAR=CALC#bm_id3154260

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About replacing some "C-Array" into std::array

[Kaganski Mike]

On 22.11.2019 18:31, julien2412 wrote:
> Taking a look at cppcheck report, I noticed this kind of reports:
> vcl/source/treelist/transfer.cxx
> 132   useStlAlgorithm 398 style   Consider using std::fill algorithm 
> instead of
> a raw loop
> 
> To use std::fill, we'd need to convert the C array into std::array.

I don't see why is the conversion required specifically for using STL. A 
pointer inside the array is a perfect iterator, that STL can use. (No 
objections against conversion where it has benefits :-))

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Fwd: [comment] uitest for bug tdf#126685

[Kaganski Mike]

On 20.11.2019 21:58, Crhonek Zdenek wrote:
> Probably I found the reason - document is opened with macro warning and 
> test stuck here. I don't know why it worked on my computer and on gerrit 
> bots, but now I can reproduce it.  Unfortunately I cannot reproduce the 
> bug after copy of sheets to the new file and deleting of macros didn't 
> help (LO still raise warning).

You could try setting MacroSecurityLevel to 0 in a specifically crafted 
registrymodifications.xcu to use in the test (like the one used for 
setting locale to en-US; see qadevOOo/qa/registrymodifications.xcu, 
which is used in smoketest/CppunitTest_smoketest.mk, 
solenv/gbuild/JunitTest.mk, and - solenv/gbuild/UITest.mk). I don't know 
is making the modification right in that file is OK, or if a dedicated 
one needed.

(I couldn't find macros in the file actually.)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

C++ initialization talk wideo

[Kaganski Mike]

Hi All, Stephan, Noel,

possibly https://youtu.be/2jJumNzcp6Y would have something interesting 
for you regarding different initialization syntaxes in C++.
Personally for me it was really unexpected that using "=default" in 
method definition is different for inline (inside class definition) and 
outside of the class... well - that is to be expected, right? That's C++ 
after all.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Review for "improve import/export of line styles"

[Kaganski Mike]

On 02.09.2019 9:20, Németh László wrote:
>> And technical question: What do I need to do locally in Git, so
>> that the
>> information, that the no longer needed file
>> "lo_preset_dashes.odt" has
>> to be deleted, is included in my commit?
> 
> 
> If you deleted the file accidentally,
> 
> git checkout sw/qa/extras/ooxmlexport/data/lo_preset_dashes.odt
> 
> and
> 
> git rm sw/qa/extras/ooxmlexport/data/lo_preset_dashes.odt
> 
> and add deletion to the actual commit:
> 
> git commit --amend

If you have already deleted the file, there's no need to restore it then 
git rm. Just add its current (deleted) state to the index using

   git add path/to/removed/file

and proceed as usual (actually, using git commit -a --amend (when 
appropriate) also picks the removal correctly).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Crash test update

[Kaganski Mike]

On 27.04.2019 18:33, Caolán McNamara wrote:
> On Sat, 2019-04-27 at 00:33 +, Crashtest VM wrote:
>> New crashtest update available at
>> http://dev-builds.libreoffice.org/crashtest/0b56eb2c10ab4ca027f1a37e04519366b3cd7433/
> 
> 
> soffice.bin --headless --convert-to xlsx ooo83250-1.ods
> semi-reliably assert with null pDim at xepivotxml.cxx:504
> I presume this started with b082998401e37e6c7534906601bc481423a6ded0
> tdf#113908: Implement exporting pivot tables' groups fields to XSLX

I'm sorry it took too long; https://gerrit.libreoffice.org/77110 
addresses this.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: sw_uiwriter hangs in testDateFormFieldCurrentDateInvalidation

[Kaganski Mike]

On 14.07.2019 22:23, Jan-Marek Glogowski wrote:
> 
> If you want to debug Windows AnyInput handling, feel free
> to contact me on IRC (or even mail), if you have questions.

I have tried putting some tracing breakpoints to 
WinSalInstance::AnyInput, and I can say that at least when the process 
is already hung (emitting all those "ProcessEventsToIdle: 100500" 
warnings), the function isn't called at all.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

sw_uiwriter hangs in testDateFormFieldCurrentDateInvalidation

[Kaganski Mike]

Hi!

I see sw_uiwriter hanging locally in 
testDateFormFieldCurrentDateInvalidation (added in commit 
d0ff1090762ac61ce08f54bc76685232699d98a0), never returning from 
Scheduler::ProcessEventsToIdle. Killing the test after some time 
produces multiple lines in console:

> warn:vcl.schedule:5488:13820:vcl/source/app/svapp.cxx:470: 
> ProcessEventsToIdle: 1000
> warn:vcl.schedule:5488:13820:vcl/source/app/svapp.cxx:470: 
> ProcessEventsToIdle: 2000
> ...
> warn:vcl.schedule:5488:13820:vcl/source/app/svapp.cxx:470: 
> ProcessEventsToIdle: 845000

I believe that's the reason for massive number of aborted Windows 
jenkins builds that lately affect our CI (just the last few are builds 
#34586, #34587, #34588, #34589, #34590, #34591).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Reveal code, old macros convert them to LO

[Kaganski Mike]

Hi!

On 04.07.2019 20:08, Uwe Brauer wrote:
> 
> 
>  From time to time the question pops up whether LO could support
> Wordperfects reveal code. Sometimes it is stated that this feature could
> be implemented by a macro/extension.
> 
> Now I remember that long time ago such macros existed and using the
> wayback machine I found them. They were written around 2005 for OO 1.2,
> using the sxw format.

Great that you have interest for bringing the power features to LO.
I'm curious what the "reveal code" feature looks like in WP, and what it 
looked like in OOo with the said macros?

Personally I would love to see a greatly reworked style manager, with 
ability to show the settings applied to any piece of text in layers - 
from most basic (paragraph style, with its inheritance) through possibly 
several character styles, to the top manual formatting, where one could 
easily see the structure - with all intermediate properties - of what we 
see as the result. Possibly something like modern browsers' object 
inspectors. But I'm afraid that there's no "codes" in LO (if I 
understand it right - my understanding is that it shows something like 
"xml tags" or some such) - and if I'm right, then trying to fake the 
actual "property set"-based architecture into "codes" would result in 
much effort with small output.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC - QR Code] Week Report 5 (June 24 - June 30)

[Kaganski Mike]

Hi!

On 02.07.2019 11:40, shubham goyal wrote:
> Status of project
> - I will be left with calling QR Code feature in Word/impress/ and other 
> applications if requires.


Not sure that making the feature for Word is within the scope of the 
project ;-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Can mimalloc turn out to be useful for LibreOffice?

[Kaganski Mike]

MS has released its mimalloc [1] under BSD license as a drop-in 
replacement for malloc. It is said to have excellent performance. It's 
also cross-platform. Can it be useful for LibreOffice (on supported 
platforms)? What is required to actually make LibreOffice use it, and 
how to test possible performance effect?

[1] https://github.com/microsoft/mimalloc

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Request for review: Convert Fontwork to TextWarp on export

[Kaganski Mike]

On 15.06.2019 10:04, Regina Henschel wrote:
> My patch would implement the export from "Fontwork" to "TextWarp" 
> without character fill and outline. My question is, whether you agree, 
> that such step is useful? Even if character fill and outline will not be 
> implemented soon?

I suppose that this is a great improvement. Having this landed, it would 
be easier for others to develop further steps based on this.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sc_macros_test hanging indefinitely with font scaling on Windows

[Kaganski Mike]

Hi!

On Windows 10 x64 (1903 build 18362.116), having "all items scaling" set 
to 150%, with current master (now at 
b170256fb6ebaf774b02b89835b19d9f3a1afb89) built for x64 in dbgutil 
config, running

 > make CppunitTest_sc_macros_test

reliably hangs indefinitely. It never returns from 
Scheduler::ProcessEventsToIdle (specifically, never leaves the while( 
Application::Reschedule( true ) ) loop); the call stack is

> vcllo.dll!Scheduler::ProcessEventsToIdle() Line 480
>   at C:\cygwin\home\user\lode\dev\core\vcl\source\app\svapp.cxx(480)
> test.dll!test::BootstrapFixture::setUp() Line 119
>   at 
> C:\cygwin\home\user\lode\dev\core\test\source\bootstrapfixture.cxx(119)
> subsequenttest.dll!UnoApiTest::setUp() Line 28
>   at C:\cygwin\home\user\lode\dev\core\test\source\unoapi_test.cxx(28)
> test_sc_macros_test.dll!CppUnit::TestCaller::setUp() Line 181
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\include\cppunit\TestCaller.h(181)
> cppunitd_dll.dll!CppUnit::TestCaseMethodFunctor::operator()() Line 33
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestCase.cpp(33)
> vclbootstrapprotector.dll!`anonymous namespace'::Protector::protect(const 
> CppUnit::Functor & functor, const CppUnit::ProtectorContext & __formal) Line 
> 49
>   at 
> C:\cygwin\home\user\lode\dev\core\test\source\vclbootstrapprotector.cxx(49)
> cppunitd_dll.dll!CppUnit::ProtectorChain::ProtectFunctor::operator()() Line 21
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(21)
> unobootstrapprotector.dll!`anonymous namespace'::Prot::protect(const 
> CppUnit::Functor & functor, const CppUnit::ProtectorContext & __formal) Line 
> 90
>   at 
> C:\cygwin\home\user\lode\dev\core\unotest\source\cpp\unobootstrapprotector\unobootstrapprotector.cxx(90)
> cppunitd_dll.dll!CppUnit::ProtectorChain::ProtectFunctor::operator()() Line 21
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(21)
> unoexceptionprotector.dll!`anonymous namespace'::Prot::protect(const 
> CppUnit::Functor & functor, const CppUnit::ProtectorContext & context) Line 63
>   at 
> C:\cygwin\home\user\lode\dev\core\unotest\source\cpp\unoexceptionprotector\unoexceptionprotector.cxx(63)
> cppunitd_dll.dll!CppUnit::ProtectorChain::ProtectFunctor::operator()() Line 21
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(21)
> cppunitd_dll.dll!CppUnit::DefaultProtector::protect(const CppUnit::Functor & 
> functor, const CppUnit::ProtectorContext & context) Line 15
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\DefaultProtector.cpp(15)
> cppunitd_dll.dll!CppUnit::ProtectorChain::ProtectFunctor::operator()() Line 21
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(21)
> cppunitd_dll.dll!CppUnit::ProtectorChain::protect(const CppUnit::Functor & 
> functor, const CppUnit::ProtectorContext & context) Line 86
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(86)
> cppunitd_dll.dll!CppUnit::TestResult::protect(const CppUnit::Functor & 
> functor, CppUnit::Test * test, const 
> std::basic_string,std::allocator > & 
> shortDescription) Line 182
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestResult.cpp(182)
> cppunitd_dll.dll!CppUnit::TestCase::run(CppUnit::TestResult * result) Line 87
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestCase.cpp(87)
> cppunitd_dll.dll!CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult 
> * controller) Line 65
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestComposite.cpp(65)
> cppunitd_dll.dll!CppUnit::TestComposite::run(CppUnit::TestResult * result) 
> Line 24
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestComposite.cpp(24)
> cppunitd_dll.dll!CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult 
> * controller) Line 65
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestComposite.cpp(65)
> cppunitd_dll.dll!CppUnit::TestComposite::run(CppUnit::TestResult * result) 
> Line 24
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestComposite.cpp(24)
> cppunitd_dll.dll!CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult 
> * result) Line 48
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestRunner.cpp(48)
> cppunitd_dll.dll!CppUnit::TestResult::runTest(CppUnit::Test * test) Line 150
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestResult.cpp(150)
> 

Using Amazon Corretto as Oracle JDK replacement for building LibreOffice on Windows

[Kaganski Mike]

Hi,

Since Oracle JDK versions prior to 12 are now unavailable from the 
official site [1] for unregistered users (and version 12 is said to 
still have problems/needs workarounds [2]), I decided to give Amazon 
Corretto [3] a try. I downloaded and installed the two MSIs listed on 
that page (amazon-corretto-8.212.04.2-1-windows-x64.msi and 
amazon-corretto-8.212.04.2-1-windows-x86.msi) - I chose to setup full 
just in case, and I need the two packages to be able to build both 
32-bit and 64-bit LibreOffice, - and then setup and run lode. With that, 
LibreOffice x64 master build succeeded normally. So this is just to let 
you know in case you need an alternative JRE.

[1] http://www.oracle.com/technetwork/java/javase/downloads/index.html
[2] 
https://wiki.documentfoundation.org/Development/BuildingOnWindows#Install_Java
[3] 
https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/downloads-list.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Crash test update, now with backtraces

[Kaganski Mike]

On 26.05.2019 17:14, Caolán McNamara wrote:
> On Fri, 2019-05-24 at 10:31 +0200, Luboš Luňák wrote:
>>   Could you please name those .backtrace.txt? I can't view those files
>> online, because they get treated as binary files and so Firefox only
>> offers to download them.
> 
> Yeah, I changed that in the script after the first run, it'll be .txt
> in future ones.

I suppose it should be more about proper content type as reported by 
server, than about name.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Permission not granted to push my patch

[Kaganski Mike]

Hi,

On 04.05.2019 12:45, Cyrille wrote:
> I tried:
> git push ssh://lafric...@gerrit.libreoffice.org:29418/dictionaries 
> HEAD:refs/for/master
> 
> I got now this error:
> remote: Resolving deltas: 100% (1/1)
> remote: Processing changes: refs: 1, done
> remote: ERROR: [b5f81e8] missing Change-Id in commit message footer
> remote:
> remote: Hint: To automatically insert Change-Id, install the hook:
> remote:   gitdir=$(git rev-parse --git-dir); scp -p -P 29418 
> lafric...@gerrit.libreoffice.org:hooks/commit-msg ${gitdir}/hooks/
> remote: And then amend the commit:
> remote:   git commit --amend
> remote:
> To ssh://gerrit.libreoffice.org:29418/dictionaries
>   ! [remote rejected] HEAD -> refs/for/master ([b5f81e8] missing 
> Change-Id in commit message footer)

The cited hint seems pretty obvious? ;-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: is gerrit #26348 still somewhere?

[Kaganski Mike]

Hi,

On 29.04.2019 15:04, Eike Rathke wrote:
> Maybe changes marked as abandoned get purged after a while? I don't know.

... but definitely, if a user deletes a draft patch, without publishing 
it, it is deleted irreversibly (or at least irreversibly for the user).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Fwd: Tinderbox failure, Android-ARM@24-Bytemark-Hosting, MASTER, last success: 2019-04-26 20:22:54

[Kaganski Mike]

Hi!

After my commit ac419786b324 "Don't use std::function in scope guard for 
performance reasons", errors are generated by Android-ARM, as in the 
forwarded message below.

According to 
https://stackoverflow.com/questions/43514188/lambda-passed-to-template-not-defined,
 
it's https://bugs.llvm.org//show_bug.cgi?id=20296 . But why doesn't it 
show up on our jenkins builds; and what should I preferably do: just 
revert the commit, or silence the warning locally somehow (e.g., 
conditionally for Android only)?

--
Best regards,
Mike Kaganski

 Forwarded Message 
Subject:Tinderbox failure, Android-ARM@24-Bytemark-Hosting, MASTER, 
last success: 2019-04-26 20:22:54
Date:   Sat, 27 Apr 2019 00:31:19 +
From:   lohmaier+libreoff...@googlemail.com 

To: caol...@redhat.com , 
mike.kagan...@collabora.com , 
serval2...@yahoo.fr , thorsten.behr...@cib.de 
, tietze.he...@gmail.com 



Hi folks,

One of you broke the build of LibreOffice with your commit :-(
Please commit and push a fix ASAP!

Full log available at http://tinderbox.libreoffice.org/MASTER/status.html

Tinderbox info:

Box name: Android-ARM@24-Bytemark-Hosting
Branch: MASTER
"starttime": 1556323629
Machine: Linux libreoffice2.dh.bytemark.co.uk 4.19.0-4-amd64 #1 SMP 
Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux
Configured with: --build=x86_64-unknown-linux-gnu
--enable-werror
--with-android-sdk=/home/android/android-sdk-linux
--with-android-ndk=/home/android/android-sdk-linux/ndk-bundle
--with-distro=LibreOfficeAndroid
--without-export-validation
--enable-android-editing

Commits since the last success:

 core 
b01a4437c42b docx export: implement text-input field export
cddcab00b81a tdf#124658 - Improve text for the tip-of-the-day
1369a16651ab Fix typos
9b077c26a7a5 Fix typo
95e9b7b2d1a5 tdf#120797: Apply transformation also to the extents of damage
ac419786b324 Don't use std::function in scope guard for performance reasons
8a53befea7cf Removed executions flags on source files

The error is:

build failed - error is::

==
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_nds_DE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_nl_BE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_nl_NL.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_nn_NO.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_no_NO.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_oc_FR.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_pl_PL.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_pt_BR.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_pt_PT.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ro_RO.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_rue_SK.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ru_RU.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sc_IT.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sk_SK.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sl_SI.cxx
[build CXX] 
workdir/CustomTarget/i18npool/localedata/localedata_sr_Latn_ME.cxx
[build CXX] 
workdir/CustomTarget/i18npool/localedata/localedata_sr_Latn_RS.cxx
[build CXX] 
workdir/CustomTarget/i18npool/localedata/localedata_sr_Latn_CS.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sr_ME.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sr_RS.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sr_CS.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sv_FI.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sv_SE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_tr_TR.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_tt_RU.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_uk_UA.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_vec_IT.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_wa_BE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_af_NA.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_af_ZA.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ak_GH.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_am_ET.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_AE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_BH.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_DZ.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_EG.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_IQ.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_JO.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_KW.cxx
[build CXX] workdir/CustomTarget/i18n

Re: bug 74702

[Kaganski Mike]

Hi Adrien,

On 22.04.2019 12:43, Adrien Ollier wrote:
> sorry I meant impedit3.cxx, lines 2805 and 2806.
> 
> Ok I'll try to make some changes in gerrit.

Nice, looking forward to see it mentioned here in the thread.

Please note that answering someone's answer directly, without CCing the 
mailing list, excludes the message from common discussion. E.g, consider 
how this your reply didn't allow others to also know that you actually 
meant impedit3, and that made others (see Jan-Marek's reply) to waste 
time again. Please always reply to list, or to all, instead of private 
replies.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702

[Kaganski Mike]

Hi Adrien,

First of all, it's best to have a tentative change in gerrit, with your 
proposed changes, to have better overview. Please create if you haven't 
yet, and post the link here. Thanks!

On 22.04.2019 11:58, Adrien Ollier wrote:
>  2. In editeng/source/editeng/impedit2.cxx it is required to cast an
> OutputDevice* to a vcl::PDFWriterImpl* to know the real type of pOut
> (and test if the resulting pointer is nullptr or not). This requires
> to include vcl/source/gdi/pdfwriter_impl.hxx but this file is not in
> the common directory for inclusion. How can I include
> vcl/source/gdi/pdfwriter_impl.hxx?

I couldn't find something like "pOut" in 
editeng/source/editeng/impedit2.cxx - so which of the 4300 lines of the 
file you mean? ;-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Properly notify gpgme about spawn executable location on Windows

[Kaganski Mike]

On 21.04.2019 0:22, Thorsten Behrens wrote:
>> 1. First of all - do I understand it correctly that the problem is real
>> - so there are possible scenarios involving e.g. python (or another
>> process which executable is not in LO's instdir/program), that might
>> need gpgme?
>>
> See above - but even for uitests, the issue might become relevant, so
> I see at least no harm in keeping that fix (unless Popen can be fixed
> to not have Windows inherit too much parent process attributes).
> 

Just checked with master, that the call to gpgme is avoided now due to 
commit 7ac4e48687d7679927f5659e941024445946ffa7 "tdf#118593 sfx2: no 
need to call into xmlsecurity without signature streams", which added a 
check to SfxObjectShell::GetDocumentSignatureInformation. And thus - I 
believe that the patch is indeed useful for the cases where the 
signature streams would be present.

It's a pity that buildbots don't run those tests on Windows hosts. And I 
suppose that we should introduce such a python test with a document with 
signature stream, to properly test this on platforms with substantially 
different implementations. (Not volunteering to the task, though, 
because of lack of required skills.)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Properly notify gpgme about spawn executable location on Windows

[Kaganski Mike]

Hi Thorsten,

Thanks for your analysis!

On 21.04.2019 0:22, Thorsten Behrens wrote:
> Kaganski Mike wrote:
>> However, I suppose that it's possible in theory that some user python
>> script could ultimately need initializing gpgme. In that case, the
>> problem would hit the user. Having a modal dialog waiting on a possibly
>> headless server is not a correct behavior :-)
>>
> Hmm - so the uitests are rigging the office in a very specific way,
> using subprocess.Popen to spawn a child soffice process from python
> (which calls CreateProcess on Windows). Code for that is in
> uitest/libreoffice/connection.py, Python3 help blurb is
> 
>   https://docs.python.org/3/library/subprocess.html#subprocess.Popen
> 
> It is a tad surprising that this would somehow 'think' it is still the
> main python executable on Windows, perhaps there's a way to
> parameterize the Popen call differently to rectify that?

I am quite sure that's python.exe process that I debug in VS here (path: 
C:\lo\src\core\instdir\program\python-core-3.5.5\bin\python.exe, 
launched by python.exe in C:\lo\src\core\instdir\program); with a 
command line like this:

> "C:\lo\src\core\instdir\program\\python-core-3.5.5" "-m" "unittest" 
> "insertremovecells"

... and a call stack like this:

> xsec_xmlsec.dll!SecurityEnvironmentGpg::{ctor}::__l2::() Line 49
>   at c:\lo\src\core\xmlsecurity\source\gpg\securityenvironment.cxx(49)
> xsec_xmlsec.dll!SecurityEnvironmentGpg::SecurityEnvironmentGpg() Line 66
>   at c:\lo\src\core\xmlsecurity\source\gpg\securityenvironment.cxx(66)
> xsec_xmlsec.dll!SEInitializerGpg::createSecurityContext(const rtl::OUString & 
> __formal) Line 45
>   at c:\lo\src\core\xmlsecurity\source\gpg\seinitializer.cxx(45)
> xmlsecurity.dll!DocumentSignatureManager::init() Line 80
>   at 
> c:\lo\src\core\xmlsecurity\source\helper\documentsignaturemanager.cxx(80)
> xmlsecurity.dll!DocumentDigitalSignatures::ImplVerifySignatures(const 
> com::sun::star::uno::Reference & rxStorage, 
> const com::sun::star::uno::Reference & 
> xSignStream, DocumentSignatureMode eMode) Line 313
>   at 
> c:\lo\src\core\xmlsecurity\source\component\documentdigitalsignatures.cxx(313)
> xmlsecurity.dll!DocumentDigitalSignatures::verifyDocumentContentSignatures(const
>  com::sun::star::uno::Reference & rxStorage, 
> const com::sun::star::uno::Reference & 
> xSignInStream) Line 176
>   at 
> c:\lo\src\core\xmlsecurity\source\component\documentdigitalsignatures.cxx(176)
> sfxlo.dll!SfxObjectShell::ImplAnalyzeSignature(bool bScriptingContent, const 
> com::sun::star::uno::Reference
>  & xSigner) Line 1538
>   at c:\lo\src\core\sfx2\source\doc\objserv.cxx(1538)
> sfxlo.dll!SfxObjectShell::ImplGetSignatureState(bool bScriptingContent) Line 
> 1567
>   at c:\lo\src\core\sfx2\source\doc\objserv.cxx(1567)
> sfxlo.dll!SfxObjectShell::GetDocumentSignatureState() Line 1718
>   at c:\lo\src\core\sfx2\source\doc\objserv.cxx(1718)
> sfxlo.dll!SfxObjectShell::CheckForBrokenDocSignatures_Impl() Line 981
>   at c:\lo\src\core\sfx2\source\doc\objmisc.cxx(981)
> sfxlo.dll!SfxObjectShell::CheckSecurityOnLoading_Impl() Line 933
>   at c:\lo\src\core\sfx2\source\doc\objmisc.cxx(933)
> sfxlo.dll!SfxObjectShell::FinishedLoading(SfxLoadedFlags nFlags) Line 1081
>   at c:\lo\src\core\sfx2\source\doc\objmisc.cxx(1081)
> sclo.dll!ScDocShell::Load(SfxMedium & rMedium) Line 658
>   at c:\lo\src\core\sc\source\ui\docshell\docsh.cxx(658)
> sfxlo.dll!SfxObjectShell::LoadOwnFormat(SfxMedium & rMedium) Line 3041
>   at c:\lo\src\core\sfx2\source\doc\objstor.cxx(3041)
> sfxlo.dll!SfxObjectShell::DoLoad(SfxMedium * pMed) Line 723
>   at c:\lo\src\core\sfx2\source\doc\objstor.cxx(723)
> sfxlo.dll!SfxBaseModel::load(const 
> com::sun::star::uno::Sequence & 
> seqArguments) Line 1795
>   at c:\lo\src\core\sfx2\source\doc\sfxbasemodel.cxx(1795)
> sfxlo.dll!`anonymous namespace'::SfxFrameLoader_Impl::load(const 
> com::sun::star::uno::Sequence & rArgs, 
> const com::sun::star::uno::Reference & 
> _rTargetFrame) Line 693
>   at c:\lo\src\core\sfx2\source\view\frmload.cxx(693)
> fwklo.dll!framework::LoadEnv::impl_loadContent() Line 1141
>   at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(1141)
> fwklo.dll!framework::LoadEnv::startLoading() Line 375
>   at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(375)
> fwklo.dll!framework::LoadEnv::loadComponentFromURL(const 
> com::sun::star::uno::Reference & 
> xLoader, const 
> com::sun::star::uno::Reference & 
> xContext, const rtl::OUString & sURL, const rtl::OUString & sTarget, long 
> n

Properly notify gpgme about spawn executable location on Windows

[Kaganski Mike]

Hi Thorsten, *,

When working on a 6-0-based branch on Windows, in make check, two python 
tests emit modal error dialogs about missing gpgme-w32spawn.exe:

> ---
> GpgME not installed correctly
> ---
> gpgme-w32spawn.exe was not found in the detected installation directory 
> of GpgME
>   "C:\lo\src\core\instdir\program\python-core-3.5.5\bin"
> 
> Crypto operations will not work.
> 
> If you see this it indicates a problem with your installation.
> Please report the problem to your distributor of GpgME.
> 
> Developer's Note: The install dir can be manually set with: 
> gpgme_set_global_flag
> ---
> ОК
> ---

For completeness, the tests are sw_python and 
pyuno_pytests_insertremovecells, but this is not really important; 
obviously, the tests themselves don't need the initialization of 
security context, and the unneeded initialization was fixed somewhere 
down the road, and later versions don't block on the tests.

However, I suppose that it's possible in theory that some user python 
script could ultimately need initializing gpgme. In that case, the 
problem would hit the user. Having a modal dialog waiting on a possibly 
headless server is not a correct behavior :-)

The cause here is that by default, gpgme only expects to find the spawn 
process in the same location as the current executable (see 
_gpgme_get_w32spawn_path and _gpgme_get_inst_dir in 
gpgmepp/src/w32-util.c). It works when the executable is soffice.bin; 
but for python, which is located in a subdirectory of instdir/program, 
this is not true (see error message above). It needs to be told 
explicitly where to look for the executable; and it's only possible 
using gpgme_set_global_flag call.

So I went ahead and prepared a patch for this: 
https://gerrit.libreoffice.org/71014, which adds a check if the spawn 
executable is in the same directory as current process executable, and 
if not, queries UNO_PATH environment variable to check if it contains 
the executable, to notify gpgme about the path.

My questions are:

1. First of all - do I understand it correctly that the problem is real 
- so there are possible scenarios involving e.g. python (or another 
process which executable is not in LO's instdir/program), that might 
need gpgme? I'm not familiar with our scripting framework, so I might 
actually invent a non-existing problem after all. I see that problem 
happening only with those tests, and I don't know if the later fix has 
completely ruled away the possibility to run that code from python, or 
just made that called only when really needed (which implies that it 
will happen eventually).

2. To find the executable, I use UNO_PATH envvar. As far as I can tell, 
even directly running soffice.bin without having UNO_PATH set in 
environment, sets the variable correctly, so this works as expected. But 
is there a better way?

3. The patch needs to add a gpgmepp wrapper for gpgme_set_global_flag 
function, because the function itself is not accessible from the place: 
if I simply used it, linking it fails:

> [LNK] Library/xsec_xmlsec.dll
>Creating library 
> C:/lo/src/core/workdir/LinkTarget/Library/ixsec_xmlsec.lib and object 
> C:/lo/src/core/workdir/LinkTarget/Library/ixsec_xmlsec.exp
> SecurityEnvironment.o : error LNK2019: unresolved external symbol 
> gpgme_set_global_flag referenced in function "public: __cdecl 
> SecurityEnvironmentGpg::SecurityEnvironmentGpg(void)" 
> (??0SecurityEnvironmentGpg@@QEAA@XZ)
> C:/lo/src/core/instdir/program/xsec_xmlsec.dll : fatal error LNK1120: 1 
> unresolved externals

I could overlook how to use the function without the need of the wrapper 
- if so, please give me a hint how to do that properly. If there's no 
way to do that, then I'll create a pr to https://github.com/KDE/gpgmepp.

Thanks.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

FastSerializerHelper::singleElement/startElement internal API changed

[Kaganski Mike]

Hi!

This is just to notify those who might currently use 
FastSerializerHelper in patches being prepared.

Commit 1fe24bb1e2fbe44a4bf2c03297e259b3a18b1235 has modified the 
singleElement/startElement[NS] APIs by removing FSEND (which was a 
remnant of old C-style varargs implementation). So if you use these APIs 
in your ongoing work, please rebase.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702 - Issue with bool OutputDevice::IsNativeControlSupported(ControlType, ControlPart)

[Kaganski Mike]

On 15.04.2019 10:44, Adrien Ollier wrote:
> And what is written is not really equivalent to what you wrote because 
> if AcquireGraphics() is false, there is not a second check for mpGraphics

Also note that when AcquireGraphics() is false (telling it could not 
acquire mpGraphics successfully), we return false. It returning true 
means that now mpGraphics is non-nullptr, and then we proceed.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702 - Issue with bool OutputDevice::IsNativeControlSupported(ControlType, ControlPart)

[Kaganski Mike]

On 15.04.2019 10:44, Adrien Ollier wrote:
> OutputDevice::AcquireGraphics() is a pure virtual function, so we cannot 
> know in the general case what it does.
> And what is written is not really equivalent to what you wrote because 
> if AcquireGraphics() is false, there is not a second check for 
> mpGraphics. That's why it is an issue.

AcquireGraphics() is not just "any function". Despite someone could of 
course implement it to play poker, its purpose is to acquire mpGraphics 
and return if it succeeded. Failing that is programmer's error breaking 
contract. There's no use to introduce that kind of checks here. Please 
see existing implementations, like VirtualDevice::AcquireGraphics() in 
vcl/source/gdi/virdev.cxx.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702 - Issue with bool OutputDevice::IsNativeControlSupported(ControlType, ControlPart)

[Kaganski Mike]

On 15.04.2019 10:33, Adrien Ollier wrote:
> Hello everybody,
> 
> working on bug #74702 
>  led me to 
> read file core/vcl/source/outdev/nativecontrols.cxx.
> 
> I think there is an issue here:
> 
> 
> 
> If mpGraphics == nullptr and AcquireGraphics() == false, then the second 
> if does not return false and we execute the instruction of the return 
> statement but this will lead to a crash (because mpGraphics is false in 
> this scenario).

No, please check what AcquireGraphics() does. Namely, it is used here to 
acquire mpGraphics when it's not yet available. In fact, lines 166-167 
are equivalent to this: "if (!mpGraphics) AcquireGraphics(); if 
(!mpGraphics) return false;"

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sc_macros_test fails after commit 7282014e362a1529a36c88eb308df8ed359c2cfa

[Kaganski Mike]

Hi!

After commit 7282014e362a1529a36c88eb308df8ed359c2cfa, now 
CppunitTest_sc_macros_test fails when testing 
sc/qa/extras/testdocuments/Window.xls:

> C:/lo/src/core/sc/qa/extras/macros-test.cxx(338) : error : Assertion
> Test name: ScMacrosTest::testVba
> equality assertion failed
> - Expected: OK
> - Actual  : Test Results
> 
> 
>  Failed:  : Window.LargeScroll(ToLeft): ScrollColumn is: 10
>  Failed:  : Window.SmallScroll(ToLeft): ScrollColumn is: 10
>  Failed:  : Pane.LargeScroll(ToLeft): ScrollColumn is: 10
>  Failed:  : Pane.SmallScroll(ToLeft): ScrollColumn is: 10
> Tests passed: 26
> Tests failed: 4
> 
> - script reported failure in file Window.xls
> 
> Failures !!!
> Run: 5   Failure total: 1   Failures: 1   Errors: 0

Opening the said spreadsheet in master and performing the test also 
gives that error *if* Calc window is wide enough to show more than 16 
full columns. The problem is that after the first 64 columns, the width 
of them unexpectedly changes; so page-scrolling 3 pages right starts to 
show less then 16 full columns, which changes result of page-scrolling 3 
pages left.

I.e., with 17 full columns visible initially (last full column Q), 
calling LargeScroll to scroll 3 pages right makes first visible column 
AZ, and last visible full column is 52 (BO; 17*3+1) => 16 visible 
columns. Now calling LargeScroll to scroll 3 pages left moves to 16*3=48 
columns left => first visible would become D (while A expected).

Also the columns BM and later don't show normal grid.

Noel, does this ring a bell? How to make all unallocated columns to have 
standard width and grid?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: libreoffice converstion of egistrymodifications.xcu user items to systemwide xml registry share

[Kaganski Mike]

See also:

https://wiki.documentfoundation.org/Deployment_and_Migration#Post_deployment_configuration
https://ask.libreoffice.org/en/question/185522/how-do-i-turn-off-opengl-while-deploying-libreoffice/
https://ask.libreoffice.org/en/question/167622/how-to-disable-java-in-configuration-files/
https://ask.libreoffice.org/en/question/186732/how-to-change-default-ui-language-for-all-users-in-command-prompt-in-ubuntu-1804/

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Kaganski Mike]

On 06.04.2019 17:18, Luke Benes wrote:
> Mike,
> That is not an apples to apples comparison. In your browser open and compare 
> side-by-side:
> 
> https://git.libreoffice.org/core/+/6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
> and
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
> 
> Do you really like all of the extraneous information?

Do you mean the tree below? Well - it doesn't hurt me. But if it went 
away (with a link to easily reach the tree from that page), I'd not protest.

> Do you like the missing search bar?

It doesn't matter *for me*, because I don't use it anyway. But I can see 
how people might miss it.

> Do you like having to scroll down several pages to see the relevant 
> information?

I don't quite get that. Which information on that page requires to 
scroll down several pages in gitiles, which does not on cgit?

> Do you like the lack of a search bar?

This is not the fourth argument, but rather the second ;-)

> Besides the fact, these are not what the commits look like on our bug 
> trackers. From
> 
> https://git.libreoffice.org/core/+/bf2f0c913774c90e4c9a65119d0219187bb4498c%5E%21
> while the old cgit would be
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=bf2f0c913774c90e4c9a65119d0219187bb4498c
> 
> Now try to copy the commit ID from the gitiles and do the same for the cgit 
> URL. Do you really prefer the random symbols appended to the end? I can tell 
> you git does not and will puke if you accidentally include any of them.

For me, double-clicking commit number in the address bar in Chrome on 
Windows (e.g., between b and f in the URL above), selects the commit ID 
without the trailing part. Well - of course, if the commit diff were 
right on that initial page without ^! (after the changed files list), 
I'd also not protest.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Kaganski Mike]

Hi,

On 06.04.2019 1:46, Luke Benes wrote:
> No one in QA and no developers have voiced a preference for gitiles. 
> Because it's slower, it's UI and UX is harder to read, it lacks useful 
> tools like search,  and the URLs are a pain to work with. It's inferior 
> in every way.

Personally I like URLs like
https://git.libreoffice.org/core/+/6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
being (a) shorter than all alternatives; (b) being libreoffice-related. 
I'd like them to stay; I have no problems with expanded form of those, 
too. After my concerns about dates were addressed, I only would like if 
redirection to the actual (gitiles) address would be something internal, 
not resulting in browser URL change.

Of course, the performance issue is something to solve, too, but that is 
a technical task, which is not a blocker for me.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Kaganski Mike]

On 05.04.2019 19:55, Guilhem Moulin wrote:
> Hi Miklos,
> 
> On Fri, 05 Apr 2019 at 09:17:01 +0200, Miklos Vajna wrote:
>> One more aspect: perhaps I'm just unlucky, but on average, I found
>> cgit to load much faster than these git.libreoffice.org links.
> 
> Hmm that's interesting.  That's not something I'm able to reproduce by
> taking 100 random commits from the last 1 non-merge commits in
> master:

 From my observations, the older the commit, the longer it takes. It 
might even timeout for some commits from early 2000s.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Subpixel glyph positioning - Looking for a mentor

[Kaganski Mike]

On 04.04.2019 19:56, Alexander Farrow wrote:
> Hi Jan-Marek,
> 
> Thank you for your reply.
> 
>      I have added some potential mentors, which are normally also 
> interested in font
>      rendering. As much as I could potentially do some mentoring, as I 
> know a share
>      of SalLayout and VCL, I have just minimal idea about text rendering, 
> mainly from
>      the time writing the Qt5 VCL backend. I'm willing to do some larger 
> share of it.
>      Someone of you want to share?
> 
> I'm extremely glad to hear that you are happy to be a mentor for this 
> project, as
> I am very keen to continue working on this for GSoC. Thank you for CC'ing 
> Mike and
> Khaled, hopefully we can find another mentor to join us on this project.

Oh! I didn't realize that I was in the explicit CC list; since I never 
worked with font rendering stuff closely, I even didn't consider myself 
as a potential mentor. Sorry, but I don't have required skills. But of 
course, I'm ready to answer any questions in the course of the project 
(be it GSoC or otherwise) as much as I have knowledge. I consider this 
task an important thins, so it's in my scope of interest.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Difference in a test behavior on Windows and Linux

[Kaganski Mike]

In commit b37b299d5228beeecb913980780f463756c5a878 [1] I have tested a 
hung sc_stylefamilyobj problem on Windows, that was caused by a bug in 
IndexedStyleSheets::FindPositionsByNameAndPredicate fixed later in 
commit 362082b57b2d6e9119acb3fb033aefcbce8cf8bb [2]. It was introduced 
in 2014 [3], and apparently is not platform-specific.

Since gerrit_linux_clang_dbgutil builds the subsequentcheck tests, the 
problem should have been caught there, when 
https://gerrit.libreoffice.org/69029 was tested, and later, after its 
merge. However, it was passing fine, which shows some serious difference 
in obviously *platform-independent* behavior on Linux and Windows. 
Identically initialized document with identical stylesheet list, iiuc, 
should fail identically when executing the same faulty code, shouldn't 
it? What am I missing?

[1] 
https://git.libreoffice.org/core/+/b37b299d5228beeecb913980780f463756c5a878
[2] 
https://git.libreoffice.org/core/+/362082b57b2d6e9119acb3fb033aefcbce8cf8bb
[3] 
https://git.libreoffice.org/core/+/0c17ccc493d0c7a80f37600dae76a09a119bef78
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: offline help

[Kaganski Mike]

Hi S.!

On 28.02.2019 6:51, pnbs! wrote:
> I can not find where to download offline Help. I really need it, I also 
> wish it was easier to find and also I wished they would put a link in 
> office program.

Unfortunately, you didn't mention what is your LibreOffice version and 
operating system are, but assuming you run Windows, please check if 
https://ask.libreoffice.org/en/question/168924/off-line-help-for-6062/ 
helps.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: need help to insert an image with a caption with the Libo java API

[Kaganski Mike via LibreOffice]

On 13.02.2019 12:45, Miklos Vajna via LibreOffice wrote:
> Hi,
> 
> On Tue, Feb 12, 2019 at 09:27:15AM +, LORENZO Vincent 
>  wrote:
>> I would like to add a caption, to an inserted image in a text
>> document, but I don't find how to do that... Please do you have
>> pointer/documentation for me ?
> 
> I think captions are just a UI feature. The doc model just stores a text
> frame around the image and the image is followed by the caption itself.
> 
> (I.e. later it's not possible to reliably detect if some content around
> an image in a frame was created by hand or using the captions UI code.)
> 
> So you can do the same "manually" using the UNO API. When in doubt, see
> what UNO API the ODT import uses to create the doc model based on the
> input markup.

And actually, if an image is not intended to be floating, but (as seen 
in majority of cases) is a part of normal text flow, then the frame 
could be not needed at all - simply add an image anchored as character, 
then add a paragraph with required style and numbering range field, then 
continue with other paragraphs. This makes the document structure 
clearer. Just an advise based on own experience.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Trying to put LO Firebird patches upstream, license issue?

[Kaganski Mike]

On 09.02.2019 22:19, Michael Meeks wrote:
> Hi Julien,
> 
> On 04/02/2019 21:15, Julien Nabet wrote:
>>> Well - since our patches are modifications to Firebird, which requires
>>> all modifications to have IDPL licensing, then all our modifications
>>> cannot be under a different license?
> 
>   So - Mike is right; but I expect no problems here. We should contribute
> to Firebird under their own license, respecting that. This may mean that
> whomever wrote the patch / worked on it should contribute it up-stream
> to Firebird, and/or give permission for that.

Hmm... I'm sorry for not being clear. My point was that since our 
patches (in our tree) were changing Firebird, they *automatically* 
follow Firebird license - or otherwise we couldn't have modified it. So 
I meant that whatever LibreOffice licensing is, the patches in Firebird 
External subdirectory are already license-compatible with upstream Firebird.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Principle of least surprise

[Kaganski Mike]

Hi!

Well - I tend to agree that having the hyperlinks malfunctional is not 
nice. *Possibly* the idea behind showing "hand" cursor over such URLs 
even without holding CTRL required for their activation could be to 
allow user an easy way to identify the links... but even then, showing 
cursor does not necessarily imply that clicking should give both no 
following the hyperlink, and no cell selection.

On 09.02.2019 6:23, Joao S. O. Bueno wrote:
> Moreover, I spent sometimes in the options dialog box (that just the 
> looks the
> same ms office did in 1996), searching for a way to disable the "convert 
> e-mail
> to hyperlink" behavior applcation wise, and could not find any. (Which 
> does not
> mean it is not there, just that it is another broken point in the UI).

Heh, it looks like placing all controls for what changes input in one 
"AutoCorrect" dialog is indeed just another broken UI. We need better 
put it in many different places all over the application instead.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Trying to put LO Firebird patches upstream, license issue?

[Kaganski Mike]

Hi,

On 04.02.2019 22:36, julien2412 wrote:
> Following my abandoning of Firebird 3.0.4 upgrade, I wonder if it may help
> to try to submit some LO Firebird patches upstream.
> For example, Cygwin  is still not present in configure.ac file of Firebird
> master sources.
> Is it ok to submit a patch or is there license/agreement issue to take into
> account?

Well - since our patches are modifications to Firebird, which requires 
all modifications to have IDPL licensing, then all our modifications 
cannot be under a different license? (And I seem to remember something 
in these lines from some recent discussion here.)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Boolean configuration settings not editable in tools - advanced - expert configuration

[Kaganski Mike]

On 04.02.2019 11:53, Winfried Donkers wrote:
> (moving discussion from https://gerrit.libreoffice.org/#/c/67280/ to mailing 
> list)
> 
>>> For reasons unknown to me, boolean configuration settings are read only on 
>>> the
>>> expert configuration dialog, int/long values can be edited. This is not 
>>> just in master,
>>> but e.g. in version 6.0 as part of openSUSE too. I didn't investigate 
>>> whether this
>>> is as designed or a bug, as the focus of the current patch is the error 
>>> rectangle code.
> 
>> I don't understand exactly what you claim is broken. Can you be more 
>> specific please?
>> (As you mention "version 6.0", it seems that you are talking about a generic 
>> issue,
>> not a specific issue with this patch? But there are certainly many 
>> properties of boolean
>> type in the registry, and I don't see a reason why this specific property 
>> should be of
>> type int when it actually models a yes/no option.)
> 
> I noticed a general unexpected behaviour when working with LibreOffice in 
> Tools-Advanced-Expert Configuration.
> When the setting is of type boolean, I cannot change the setting. I tried 
> various existing settings, mainly in org.openoffice.Office.Calc and both with 
> current Master and version as distributed with openSUSE Leap 15.0.
> My conclusion was that for reasons unknown to me, boolean settings are not 
> editable and int settings are.

Could you please describe what exactly "not editable" means? I.e., "I 
double-click the boolean setting, and expect a dialog to pop up like for 
ints, but instead, the setting just changes from true to false and back 
in place, without dialogs"?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Conflict with submitted change

[Kaganski Mike]

Hi,

On 02.02.2019 9:48, Aditya Sahu wrote:
> Hi,
> I submitted a change ( Change-Id: 
> I440c637dd2a566f820a6e8fac826f35cabb9c05f ) but after doing that, I 
> found out that it is having conflict with some other change ( Change-Id: 
> I937ed12f2a96943664087ddcdd035f1347e84a57 ).
> What should be my move here?

As discussed on IRC, that was a misunderstanding: gerrit shown "Conflict 
with:" information about a change modifying the same file (in a 
different place: [1], [2]). The changes don't actually conflict.

[1] 
https://gerrit.libreoffice.org/#/c/67102/2/svtools/source/dialogs/PlaceEditDialog.cxx
[2] 
https://gerrit.libreoffice.org/#/c/66055/11/svtools/source/dialogs/PlaceEditDialog.cxx

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Possible extensions to OUString class

[Kaganski Mike]

On 31.01.2019 0:40, Stephan Bergmann wrote:
> Also, a better approach overall would probably be some string_view-based 
> getToken functionality (converting from an OUString to a string_view is 
> cheap), and then string_view-based toInt etc. functions.

Is there a C++ magic to automatically select a getToken variant 
returning string_view vs returning OUString based on if the original 
OUString object is a temporary?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Encoding problem when migration hsqldb->Firebird

[Kaganski Mike]

On 30.01.2019 14:00, Kaganski Mike wrote:
> ... a valid UTF-18 escape sequence ...

Why not, if there is UTF-9? :-) Sorry for the typo.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Encoding problem when migration hsqldb->Firebird

[Kaganski Mike]

Hi Julien,

On 30.01.2019 12:13, Julien Nabet wrote:
> Giving a try to tdf#123020 (which is finally a dup), I added some traces 
> and noticed this kind of string (OUString):
> "CREATE CACHED TABLE "\u00c5r"("\u00c5r" INTEGER NOT NULL PRIMARY KEY)"
> ...
> How to convert \u... to the "real" character?

It might be some artifact of the tracing machinery, which e.g. could use 
a font without the codepoint, or output all non-ascii chars like that? 
because \u00c5 is a valid UTF-18 escape sequence [1] (U+00C5, [2]), and 
so "\u00c5r" maybe is just "År" in the real string (i.e., the "\u00c5r" 
takes 4 sal_Unicode characters for ", Å, r, and " in the OUString, and 
the Å is actually the "real" character)?


[1] https://en.cppreference.com/w/cpp/language/escape
[2] https://www.fileformat.info/info/unicode/char/00c5

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: First-time development/C++ Contributor

[Kaganski Mike]

On 28.01.2019 14:40, Michael Weghorn wrote:
> The use of "lode" is not mandatory, you can also manually do the
> required setup, but be aware that lode will simplify the setup

True, but

> and
> you're more on your own if you encounter any issues while doing things
> by yourself.

Personally I feel more comfortable helping those on IRC who do it by 
themselves, because that's how I did, and so because I'm more familiar 
with that setup.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Bug 115747] Can't edit file on samba shares

[Kaganski Mike]

Hi Thorsten!

On 28.01.2019 5:32, Thorsten Behrens wrote:
> Kaganski Mike wrote:
>> My vision of this would me that if inability to create lockfiles
>> needs to be handled specially at all, then at maximum a warning
>> infobar telling that "no lockfile was created, so clashes are
>> possible" could be shown, but not limiting user's ability to work
>> (because technically nothing prevents users).
>>
> That appears backwards to me. My take is, software should always go
> the safe path by default, and offer the dangerous one only after
> explicit consent. So with the infobar idea, that would mean open
> read-only, but perhaps provide the option to switch to edit mode while
> keeping the filename?

Well - that'd be OK IMO :-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Could not determine MSC version (Visual Studio 2017)

[Kaganski Mike]

On 25.01.2019 14:06, julien2412 wrote:
> 
> Now to avoid to patch the package, the idea would be to know why I get
> something else than a plain space. Perhaps something to configure on Cygwin
> (codepage, LC, ...)
> Let's dig on Google...

You could change your VS language to English possibly. And file an issue 
to the package upstream.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Bug 115747] Can't edit file on samba shares

[Kaganski Mike]

On 12.01.2019 13:28, Thorsten Behrens wrote:
> Context:
>> https://bugs.documentfoundation.org/show_bug.cgi?id=115747
> 
>> Because
>> A) this is a regression,
>> B) which already had an alternate solution (SystemLocking = false),
>> C) and the description uses the terminology "Allow" instead of
>> "Mandatory",
>> D) involving an unnecessary file for normal operation,
>> E) caused by undocumented rationale for the changed behaviour,
>>
>> I suggest reverting this bit and introducing a MandatoryLocking variable to
>> handle the very unique situations where locking files actually have any 
>> value.
>>
> As always, one person's regression is another person's bugfix. Those
> OOo lockfiles have a rather long-winded history, and were introduced
> because especially on network shares, cross-platform system file
> locking never quite worked.
> 
> Since the change is shipped in versions for almost a year, instead of
> a revert I'd much prefer we take the occasion and better define
> requirements and semantics for file locking. From my memory:
> 
> - until 2008, there was just system file locking, which led to
>problems in preventing overwrites on documents accessed from different
>platforms. https://bz.apache.org/ooo/show_bug.cgi?id=85794 has quite
>some details, and a specification document
> - that change of course led to bugs, starting with:
>* https://bz.apache.org/ooo/show_bug.cgi?id=95809
>  (bring back system file locking)
>* https://bz.apache.org/ooo/show_bug.cgi?id=100123
>  (actually lockfiles _also_ break workflows, so add an option)
>* https://bz.apache.org/ooo/show_bug.cgi?id=102931
>  (cop-out, there's apparently still corner-cases left where _no_ locking
>happens)
> - then proper locking on WebDAV shares was implemented via
>tdf#82744
>* which inevitably led to problems when a user couldn't write
>* so UseWebDAVFileLocking was added to disable it
> 
> (please amend the history, especially if StarOffice old hands remember
> additional details)
> 
> Taking this all together, my mental model of the LibreOffice document
> file locking requirements is:
> 
> * when opening read-write, make sure the file is locked (via a number
>of configurable means). Failing to take _any_ of those locks should
>lead to read-only opening.
> * by default, use as many lock-signalling (system APIs plus lock
>files) as possible, so other programs have a chance to detect the
>access, too
> * as a safety measure, when saving, check if the document access time
>has changed, and warn the user that potentially someone else
>accessed the document
> 
> For corner cases or historical setups that cannot accomodate change,
> configuration options have been introduced (and I wouldn't object
> continuing down that path).

My opinion is that only existing locks may be a reason to open files 
read-only. If you can't write lockfiles, it's not a reason to limit 
one's ability to edit files. That can lead to the problems that 
lockfiles were meant to workaround, but if a specific shared (!) 
filesystem has some special properties that it (1) has no good FS 
locking; and (2) blocks writing lockfiles, then no measures will 
mitigate the problem:

- if users are forced to disable use of lockfiles in LO, this doesn't 
fix the problem anyway - they are just subject to those problems;

- if administrators could change the FS properties so that lockfiles are 
permitted, they should do that anyway when they allow users work on 
shares without reliable FS locking.

But it happens that a user has to work in a directory where they are not 
allowed to create new files at all (directory-level permissions), but 
are allowed to edit a specific file (file-level permissions).

Not all shared filesystems have unreliable FS locking; I had no problems 
with FS-level locking when administered a Windows domain.

Users work in heterogeneous environments; they open files locally (in 
different locations with different permission sets); on USB sticks; on 
network shares with different protocols; on the web; ... whatever a 
tomorrow OS would offer. On one filesystem, lockfiles might be great to 
know who opened your file; on another, they might be prohibited, because 
you as a subcontractor work for someone who gave you a limited access to 
their storage. You cannot require that "either all file systems you use 
support lockfiles, or you disable their usage".

My vision of this would me that if inability to create lockfiles needs 
to be handled specially at all, then at maximum a warning infobar 
telling that "no lockfile was created, so clashes are possible" could be 
shown, but not limiting user's ability to work (because technically 
nothing prevents users).

Anyway, we cannot treat our lockfiles as an ultimate guard, simply 
because LibreOffice only works with files also openable using many other 
applications (ODF is an ISO standard, you remember, and if we can open 
other formats, ot

Re: Building LO 6.1.4.2 --with-system-jpeg and jpeg-9c fails

[Kaganski Mike]

On 22.01.2019 23:56, Dilyan Palauzov wrote:
> Hello Caolán,
> 
> what is the usefulness of a test, that behaves differently with different 
> jpeg libraries, but none of the test-outcomes is clearly wrong?

You could notice that the failing test is called testCVEs. It tests that 
known vulnerabilities are detected and rejected by the library, rather 
than get opened, so it checks that LibreOffice uses library versions 
that are safe with regards of those vulnerabilities.

But some libraries versions may decide later to stop rejecting those 
samples, including for good reasons, e.g. they might mitigate the 
exploit differently, so that the file could get opened then. This is not 
something that we should just accept without noticing. If that happens, 
we need to see it and understand why has it happened (is that an 
unintended regression in that external library, which could make 
LibreOffice vulnerable if overlooked, or is that actually a safe change 
there, which needs to change our tests to cover this library version?). 
This is what Caolán told you ("Someone who wants to use a system 
libjpeg-9 would have to investigate if it succeeds for a good reason or 
if its pure luck, e.g. via uninitialized data"). This is not the same as

> removing it completely.
> ...
> So removing this tests makes life simpler and causes no side effects.


-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Stable, conservative, unsupported versions | libreoffice.com/download

[Kaganski Mike]

On 16.01.2019 15:41, Дилян Палаузов wrote:
> Hello,
> 
> it is confusing, when the most stable version does not compile, as it 
> happened to me, and when this is not going to
> change.
> 
> I suggest recomending only versions, which either compile, or in case they 
> don’t compile, they are supposed to be
> publically tweaked to compile.

Any version, however stable it were, cannot be guaranteed to compile 
with library versions released after its release. Also, no software is 
guaranteed to build in environments tweaked manually in unpredictable 
ways (as likely is in your case, as your previous thread suggests).

So I suppose, in this thread you are trying to fix not the real problem.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Stable, conservative, unsupported versions | libreoffice.com/download

[Kaganski Mike]

On 16.01.2019 14:49, Дилян Палаузов wrote:
> Hello,
> 
> what I wanted to ask was, why does the LO-ebpage recommend for enterprises 
> end of life products.
> 
> My understanding of the processes is, that there are usually a stable 
> version, that is not end-of-live, and a most
> current version, at the same time.  However there are gaps, when the webpage 
> offers only one version, that is not end of
> life, without stating this clear.

6.0 *is* the stable version at the moment, that is rightfully 
recommended now. EOL means only one thing: no more releases for this 
branch are planned. This happens at the moment when the last release of 
the branch comes out. The last release for 6.0 brought last portion of 
the fixes; and at this moment, 6.0.7 is considered the most stable - and 
for that reason, recommended; and at the same time, TDF won't release 
any more patches to it - so it's EOLed. So do you suggest to only 
recommend versions that don't have the last pack of fixes?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: xpdfwrapper/pdfioutdev_gpl.hxx:227:22: error: ‘virtual void pdfi::PDFOutDev::drawString(GfxState*, const GooString*)’ marked ‘override’, but does not override

[Kaganski Mike]

Hi!

On 15.01.2019 1:40, Дилян Палаузов wrote:
> Hello,
> 
> the LO source code requires const GooString*, but the 
> /usr/local/include/poppler/OutputDev.h file had no const in the
> declaration of drawString.  The installed poppler was newer than 0.64.0.
> 
> The hack is, that in the past I installed poppler and it installed 
> OutputDev.h .  When I later compiled newer version of
> poppler I have not passed ENABLE_XPDF_HEADERS / 
> ENABLE_UNSTABLE_API_ABI_HEADERS to cmake and in turn “make install” has
> not overwritten /usr/local/include/poppler/OutputDev.h.  This led to a 
> situation with new libpoppler and old OutputDev.h
> without const.  Indeed override triggered correctly.
> 
> --without-system-poppler mitigates.

All current LibreOffice branches, including 6-0-7, have the patch 
mentioned by Stephan previously. You may see the source here:

https://cgit.freedesktop.org/libreoffice/core/tree/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx?h=libreoffice-6-0-7

and the commit to 6-1 here:

https://cgit.freedesktop.org/libreoffice/core/commit?id=106b2c96e9807af14d6eb6e8f83dcf25095a093e

The commit conditionally makes the parameter const when reported poppler 
is 0.64 or newer, following the poppler change "Add const to several 
classes and members" (see 
https://poppler.freedesktop.org/releases.html). Poppler 0.64 and newer 
does have the const in the declaration of drawString - you may check its 
source code at 
https://cgit.freedesktop.org/poppler/poppler/tree/poppler/OutputDev.h?h=poppler-0.64.0,
 
and the commit is 
https://cgit.freedesktop.org/poppler/poppler/commit/poppler/OutputDev.h?h=poppler-0.64.0&id=c4af5981ab2a5f42a9a1194bb5929c2151fc2674.

So the problem in your situation is most likely that you have messed up 
with the mix of new and old headers and library.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: xpdfwrapper/pdfioutdev_gpl.hxx:227:22: error: ‘virtual void pdfi::PDFOutDev::drawString(GfxState*, const GooString*)’ marked ‘override’, but does not override

[Kaganski Mike]

On 14.01.2019 11:46, Stephan Bergmann wrote:
> On 13/01/2019 23:57, Дилян Палаузов wrote:
>> LO 6.0.7.3 fails compiling with gcc 8.2.1 20190101 I emitting:
>>
>> [build SPP] scp2/source/ooo/ure
>> [build SCP] scp2/source/writer/file_writer
>> [build SPP] scp2/source/xsltfilter/file_xsltfilter
>> [build SPP] scp2/source/xsltfilter/module_xsltfilter
>> [build SPP] scp2/source/gnome/file_gnome
>> [build SPP] scp2/source/gnome/module_gnome
>> [build SPP] scp2/source/sdkoo/sdkoo
>> [build SCP] scp2/source/writer/module_writer
>> [build CXX] sdext/source/pdfimport/xpdfwrapper/pnghelper.cxx
>> In file included from 
>> /src/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pnghelper.hxx:24,
>>  
>>
>>   from 
>> /src/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pnghelper.cxx:20:
>>  
>>
>> /src/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:227:22:
>>  
>> error: ‘virtual void
>> pdfi::PDFOutDev::drawString(GfxState*, const GooString*)’ marked 
>> ‘override’, but does not override
>>   virtual void drawString(GfxState *state, const GooString *s) 
>> override;
>>    ^~
>> /src/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:227:22:
>>  
>> warning:   by ‘virtual void
>> pdfi::PDFOutDev::drawString(GfxState*, const GooString*)’ 
>> [-Woverloaded-virtual]
>> make[1]: *** 
>> [/src/libreoffice-6.0.7.3/solenv/gbuild/LinkTarget.mk:293: 
>> /src/libreoffice-
> 
> You likely need a backport of 
> 
>  
> "fix build with poppler 0.64" (and maybe also backports of further 
> poppler-adaption fixes in that area), or configure 
> --without-system-poppler.
> 
> There is obviously always a chance that building old versions of LO 
> against current system components does not work.  Often enough, you will 
> find fixes for those issues in later versions of LO, and which are often 
> even easy to backport to the version where you need them.

I'm afraid that the message implies that the fix from spring 2018 is 
already there - the constness of the GooString parameter is there in the 
message. So possibly there's some problem detecting the poppler library 
version?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Problem in running make file on Ubuntu 16.04

[Kaganski Mike]

On 08.01.2019 10:44, Komal Bharadiya wrote:
> I have been trying to setup libreoffice dev-environment lately. After 
> executing ./autogen.sh file, I hit make command. The execution takes 
> ample amount of time. It hangs my laptop, and I end up switching it off. 
> I have tried multiple no. of times. But couldn't run it successfully, 
> what can I do? Please help!
> I have Dell Vostro 3568 model.
> Thanking you in anticipation!

https://wiki.documentfoundation.org/Development/BuildingOnLinux#Performance


> Building LibreOffice takes time, a lot of time. Exactly how much depends on 
> how powerful your machine is

Several lines below, there's "Approximate times" section, telling 
someone's experience with some unspecified repo revision, which took 1.5 
hrs. I can tell you that I used to have ~8 hrs build time on Kaveri 7700 
box with spinning HDD.

You should expect long build times on your laptop. But if you also are 
going to do other tasks on it during the build (to increase build times 
even more), then you may adjust it using --with-parallelism (discussed 
there), which defaults to use all your cores, but which you could want 
to set to a lower value to free some resources; or you may run make 
using nice (`nice make`) to decrease its priority and make system 
responsive to interaction without sacrificing cores.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: libreoffice pdfimport w/ poppler-0.72.0: build failure

[Kaganski Mike]

Hi Andreas!

On 08.01.2019 3:12, Andreas Sturmlechner wrote:
> In git master, libreoffice fails to build with:
> 
> sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx:558:70: error: ‘const
> class GooString’ has no member named ‘getCString’
> 
> The relevant change in poppler 0.72 release notes:
> * Rename GooString::getCString to GooString::c_str
> 
> The attached patch made it build successfully for me.

Could you please post the patch to gerrit [1] [2], and also post your 
license statement [3]?

[1] https://gerrit.libreoffice.org
[2] https://wiki.documentfoundation.org/Development
[3] 
https://wiki.documentfoundation.org/Development/Developers#License_Statements

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Fwd: About Build dependencies Environment setup

[Kaganski Mike]

Hi!

On 06.01.2019 21:13, Mohit Kumar wrote:
> Hi,
> I am trying to build dependencies in linux by following the coomand : 
> sudo apt-get build-dep libreoffice but it showing some error.I am 
> attaching the screenshot, Please Help

First of all, please always mention your OS information.
Next, the suggestion that Thorsten mentioned when tried to answer you on 
IRC (you seem to have *really* poor connection) was to try manually 
installing the dependencies, excluding the libpng12-devel; I'd also 
suggest to try installing a newer LibreOffice from PPA [1] which could 
have an updated list of dependencies, which could not have the outdated 
(for your version of OS) dependencies - but that's only my speculation, 
not something known to work.

[1] https://launchpad.net/~libreoffice/+archive/ubuntu/ppa

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: OpenGrok for core

[Kaganski Mike]

On 26.12.2018 16:38, Justin Luth wrote:
>  kompi: upgraded on xmas night (as announced to status.tdf) but 
> the index & history namespace changed so I had to trigger a full reindex 
> (which is still ongoing for core)
> 11:28  Possibly core has not indexed yet (as the one 
> largest opengrok project), since guilhem mentioned yesterday that 
> reindexing takes place
> 11:29  oh
> 11:29  shouldn't have taken that long but I didn't foresee the 
> namespace change and didn't notice until it was already too late
> 11:29  :-)
> 11:29  (the previous indexes are nuked)
> 
> 11:33  threw more power at the vm but full indexing takes ages 
> anyway, at the current pace it's unlikely to be done before the week-end 
> :-(

13:46  people wondering about opengrok are invited to check 
https://status.documentfoundation.org/incident/84 for updates

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppunitTest_chart2_xshape Failure with Display Scaling on Windows

[Kaganski Mike]

Hi,

On 16.12.2018 22:57, Luke Benes wrote:
> Mike,
> The fix for *Bug 121685* 
> , 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=7263d223ddf4
> ​
> Is causing the core Unit Test CppunitTest_chart2_xshape to fail when you 
> set,  Settings->Display->Scale=125%​
> ​
> Setting Scale=100% allows the build to pass with no errors. ​
> ​
> Build log:​
> https://pastebin.com/SpSiCm6u

This is addressed in https://gerrit.libreoffice.org/65595. Note that the 
change does not implement the approach suggested by jmux in [1] (because 
I don't have enough knowledge), and only properly fixes one test to 
consider system DPI. The other affected tests are disabled for now in 
cases of non-default DPI values, which of course would need to be 
reverted once a proper fix is implemented.

[1] 
https://lists.freedesktop.org/archives/libreoffice/2018-December/081591.html

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Libre Office Local Installation

[Kaganski Mike]

Hi Komal! Welcome!

On 23.12.2018 10:43, Komal Bharadiya wrote:
> Moreover, I have directly downloaded the libre office
> repository from github. Then followed the steps given on official site
> of libre office.

Although possibly unrelated to the problem, this is clearly wrong. Where 
have you read the directions to download from github read-only secondary 
repository? As far as I know, the official instructions [1] [2] mention 
cloning https://gerrit.libreoffice.org/core (preferrable IMO), or 
anongit, or downloading special tarballs.

Before proceeding, please start with correct repo.

[1] https://wiki.documentfoundation.org/Development
[2] https://www.libreoffice.org/about-us/source-code/

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: When file truncation happens by Basic's Open statement

[Kaganski Mike]

Hi!

On 21.12.2018 20:37, Takeshi Abe wrote:
> In order to tell whether the behavior reported in tdf#119102 [1] is a bug
> or not, I would like to understand the specification of LibO Basic's Open
> statement [2].
> 
> The following table summarizes what current (master) LibO does, which I read
> from SbiStream::Open() in basic/source/runtime/iosys.cxx.
> 
>ACCESS\FOR  | APPEND | BINARY | INPUT | OUTPUT | RANDOM |
> --+++---+++
> default|   -|   -|   -   |   X|   -|
>   READ  ("read only")  |   -|   -|   -   |   -|   -|
>   WRITE ("write only") |   -|  -(*)  |   X   |   X|  -(**) |
>   READ WRITE ("both")  |   -|  -(*)  |   X   |   X|  -(**) |
> 
> "X": the runtime deletes the file of given path first if already exists;
> "-": it does not.
> (*)  requested in i#18638 ;
>   see commit 23b49669ab70cac72d5f6d955e7d2af617e6934e.
> (**) requested in i#61277 ;
>   see commit 42a63dd0e81f13a84a5f551e03ede685e2bf34c7.
> 
> So here is a couple of questions popping up on a confused soul:
> 
> (1) What does the default ACCESS mode mean?
> Is it just the same as READ, WRITE, or READ WRITE?
> Or does it depends on given FOR mode?
> 
> (2) Does 'FOR INPUT + ACCESS WRITE' or 'FOR OUTPUT + ACCESS READ' make
> any sense?

Cannot answer the questions; just for completeness, something you could 
already know:

the current handling of BINARY opened for write was defined in commit 
23b49669ab70cac72d5f6d955e7d2af617e6934e [1] for #i18638 [2].

[1] 
https://git.libreoffice.org/core/+/23b49669ab70cac72d5f6d955e7d2af617e6934e%5E%21/
[2] https://bz.apache.org/ooo/show_bug.cgi?id=18638

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppunitTest_chart2_xshape Failure with Display Scaling on Windows

[Kaganski Mike]

Hi Luke!

On 12/16/2018 10:57 PM, Luke Benes wrote:
> The fix for *Bug 121685* 
> , 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=7263d223ddf4
> ​
> Is causing the core Unit Test CppunitTest_chart2_xshape to fail when you 
> set,  Settings->Display->Scale=125%​

Unfortunately cannot repro locally. Possibly it's worth trying to only 
add manifest to soffice.bin, not to all console applications. Will try 
that tomorrow.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Subsequent Unit Test CppunitTest_sc_ddelinkobj Failing Under Windows

[Kaganski Mike]

On 12/13/2018 3:05 AM, Jens Carl wrote:
> Hello Luke,
> 
> On 12/8/18 7:09 AM, Luke Benes wrote:
> 
>> Would you like any additional debugging info?
> 
> I personally don't have access to any Windows machines and my knowledge 
> about Windows Devolvement (Virtual Studio) is very limited. So I 
> unfortunately can't provide you with any instructions how to debug it.
> 
> I'll ask on the IRC if it's possible for me to get some kind of access 
> to a Windows machine. If it's possible I will start to debug the code.

https://gerrit.libreoffice.org/65079 handles this. Please ask about 
Windows access though, because it's mandatory to test on Windows.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows build failure - C2131: expression did not evaluate to a constant

[Kaganski Mike]

On 04.12.2018 14:18, Kaganski Mike wrote:
> On 04.12.2018 14:17, Kaganski Mike wrote:
>>
>> I have just pulled, and I confirm this with 64-bit build, with VS
>> version 15.9.3.
>>
> 
> I mean, I confirm that with my version of compiler, the problem is
> reproducible.
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
> 

Reported that to 
https://developercommunity.visualstudio.com/content/problem/398218/c2131-error-with-stdarray-and-stdmake-integer-sequ.html.

As noted there, I have discovered the code to succeed if I replace 256 
to any number up to 234.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Trying to create editor using LibreOffice

[Kaganski Mike]

Hi,

On 04.12.2018 13:33, Rohit Garg Satpal Garg wrote:
> Hi Team,
> 
> I am trying to create editing application for my one of the research 
> projects but I am stuck on implementation of  getLinreOfficeKitHandler() 
> which is missing from the source files.

It is not missing. See implementation in 
Java_org_libreoffice_kit_LibreOfficeKit_getLibreOfficeKitHandle() at 
sal/android/libreofficekit-jni.c:152.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows build failure - C2131: expression did not evaluate to a constant

[Kaganski Mike]

On 04.12.2018 14:17, Kaganski Mike wrote:
> 
> I have just pulled, and I confirm this with 64-bit build, with VS
> version 15.9.3.
> 

I mean, I confirm that with my version of compiler, the problem is 
reproducible.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows build failure - C2131: expression did not evaluate to a constant

[Kaganski Mike]

On 04.12.2018 10:37, Stephan Bergmann wrote:
> 
> Our recently-bumped MSVC baseline is Visual Studio 2017 version 15.7 
> (the "version 15.7" suffix is important, there are many different 
> releases of Visual Studio 2017, with ever-increasing C++ standard 
> compliance).  That should be enforced by configure since 
> 
>  
> "On Windows, check for at least Visual Studio 2017 version 15.7".
> 
>  "Compute 
> (un-)premultiply_table at compile time" was checked by Jenkins' tb78 at 
> , and the mention 
> of "14.14" in e.g. "export 
> COMPATH=C:/PROGRA~2/MIB055~1/2017/COMMUN~1/VC/Tools/MSVC/14.14.26428" 
> () 
> makes it look like that configuration indeed uses Visual Studio 2017 
> version 15.7 per the mapping from "MSVC++ 14.14" to "_MSC_VER == 1914 
> (Visual Studio 2017 version 15.7)" documented at 
> .
>  
> 
> 
> Not sure what goes wrong for you.  What version of VS are you using?

I have just pulled, and I confirm this with 64-bit build, with VS 
version 15.9.3.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows build failure - C2131: expression did not evaluate to a constant

[Kaganski Mike]

On 04.12.2018 9:30, Noel Grandin wrote:
> 
> 
>> I'm seeing the following build failure on Windows 32-bit release build:
>> D:/core/vcl/source/bitmap/BitmapTools.cxx(1078): error C2131: 
>> expression did not evaluate to a constant
>> D:/core/vcl/source/bitmap/BitmapTools.cxx(1097): error C2131: 
>> expression did not evaluate to a constant
>> make[1]: *** [D:/core/solenv/gbuild/LinkTarget.mk:293: 
>> D:/core/workdir/CxxObject/vcl/source/bitmap/BitmapTools.o] Error 2
> 
> You need the latest Visual Studio 2017 release.

So, it seems that commit establishes another VS baseline?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Help regarding Transliteration in LO writer

[Kaganski Mike]

Hi!

On 26.11.2018 13:39, Harshad Gorde wrote:
> Hello everyone,
> 
> I am interested in introducing transliteration facility (English to 
> Devnagari) to LibreOffice writer. But, after downloading the huge source 
> code I am unable to decide where to start.
> 
> Kindly suggest me some initial steps to be followed.

Personally I would suggest you to start by writing a (StarBasic) macro 
[1] for that. Not because I suppose it shouldn't be built in (I don't 
suppose that), but because for such a high-level task, a Basic macro 
could be very good initial approximation/plot for a future C++-based 
function, but allows you to avoid additional complexity at the first 
steps. IMO.

[1] http://www.pitonyak.org/oo.php

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: remove followed by a push_back of same var (SwSpellDialogChildWindow)

[Kaganski Mike]

On 24.11.2018 10:23, julien2412 wrote:
> I noticed these lines:
>  737 if(pCurrentTextObj)
>  738 {
>  739 m_pSpellState->m_aTextObjects.remove(pCurrentTextObj);
>  740
> m_pSpellState->m_aTextObjects.push_back(pCurrentTextObj);
>  741 }
> See
> https://opengrok.libreoffice.org/xref/core/sw/source/uibase/dialog/SwSpellDialogChildWindow.cxx#737
> 
> Is it a special trick so some other vars are notified or just a plain error?

Something to guarantee that there is only a single instance of it, and 
it's the top element?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Failing JunitTest_framework_complex

[Kaganski Mike]

On 21.11.2018 16:37, Jan-Marek Glogowski wrote:
> Hi Mike
> 
> Am 21.11.18 um 14:01 schrieb Kaganski Mike:
>> JunitTest_framework_complex fails reliably for me on current master with
>> assertion
>>
>>assert( mpWindowContext.is() );
> 
> Can you check if reverting
> 
> commit 6cdfe5ebb4f6c06bfa8b0e67e778dd68131c14e3
> Author: Jan-Marek Glogowski 
> Date:   Tue Oct 9 19:29:54 2018 +0200
> 
>  Drop some headless mode variants
> 
> helps?

Thank you!
It definitely helps. Just tested several times (it was failing reliably 
before the revert). Something more is needed for unit tests and OpenGL case.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Failing JunitTest_framework_complex

[Kaganski Mike]

JunitTest_framework_complex fails reliably for me on current master with 
assertion

  assert( mpWindowContext.is() );

failing at OpenGLSalGraphicsImpl::doFlush().

I could debug it to WinOpenGLContext::ImplInit() having m_aGLWin.hDC == 
nullptr, thus ChoosePixelFormat fails. The call stack for this point is


vclplug_winlo.dll!WinOpenGLSalGraphicsImpl::CreateWinContext
vcllo.dll!OpenGLSalGraphicsImpl::doFlush
vcllo.dll!OpenGLFlushIdle::Invoke
vcllo.dll!Scheduler::ProcessTaskScheduling
vcllo.dll!Scheduler::CallbackTaskScheduling
vcllo.dll!SalTimer::CallCallback
vclplug_winlo.dll!WinSalTimer::ImplHandleElapsedTimer
vclplug_winlo.dll!ImplSalYield
vclplug_winlo.dll!WinSalInstance::DoYield
vcllo.dll!ImplYield
vcllo.dll!Application::Yield
vcllo.dll!Application::Execute
sofficeapp.dll!desktop::Desktop::Main
vcllo.dll!ImplSVMain
vcllo.dll!SVMain
sofficeapp.dll!soffice_main
soffice.bin!sal_main
soffice.bin!main
soffice.bin!invoke_main
soffice.bin!__scrt_common_main_seh
soffice.bin!__scrt_common_main
soffice.bin!mainCRTStartup
kernel32.dll!BaseThreadInitThunk
ntdll.dll!RtlUserThreadStart


The mrWinParent.mhLocalDC is nullptr here; the nullprt value has been 
set when it was released *before that event* in 
WinSalFrame::ReleaseFrameGraphicsDC with this call stack:


vclplug_winlo.dll!WinSalGraphics::setHDC
vclplug_winlo.dll!WinSalFrame::ReleaseFrameGraphicsDC
vclplug_winlo.dll!WinSalFrame::ReleaseGraphics
vcllo.dll!vcl::Window::ReleaseGraphics
vcllo.dll!vcl::Window::dispose
vcllo.dll!ImplBorderWindow::dispose
vcllo.dll!VclReferenceBase::disposeOnce
vcllo.dll!VclPtr::disposeAndClear
vcllo.dll!vcl::Window::dispose
vcllo.dll!Control::dispose
vcllo.dll!Edit::dispose
vcllo.dll!SpinField::dispose
vcllo.dll!MetricField::dispose
vcllo.dll!VclReferenceBase::disposeOnce
vcllo.dll!VclPtr::disposeAndClear
vcllo.dll!VclBuilder::disposeBuilder
vcllo.dll!VclBuilderContainer::disposeBuilder
svxlo.dll!PanelLayout::dispose
svxlo.dll!svx::sidebar::ParaPropertyPanel::dispose
vcllo.dll!VclReferenceBase::disposeOnce
sfxlo.dll!VclPtr::disposeAndClear
sfxlo.dll!sfx2::sidebar::SidebarPanelBase::disposing
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::dispose

sfxlo.dll!cppu::PartialWeakComponentImplHelper::dispose
sfxlo.dll!sfx2::sidebar::Panel::dispose
vcllo.dll!VclReferenceBase::disposeOnce
sfxlo.dll!VclPtr::disposeAndClear
sfxlo.dll!sfx2::sidebar::Deck::ResetPanels
sfxlo.dll!sfx2::sidebar::SidebarController::CreatePanels
sfxlo.dll!sfx2::sidebar::SidebarController::CreateDeck
sfxlo.dll!sfx2::sidebar::SidebarController::SwitchToDeck
sfxlo.dll!sfx2::sidebar::SidebarController::SwitchToDeck
sfxlo.dll!sfx2::sidebar::SidebarController::UpdateConfigurations
sfxlo.dll!sfx2::sidebar::SidebarController::notifyContextChangeEvent
fwklo.dll!`anonymous 
namespace'::ContextChangeEventMultiplexer::BroadcastEventToSingleContainer
fwklo.dll!`anonymous 
namespace'::ContextChangeEventMultiplexer::broadcastContextChangeEvent

sfxlo.dll!sfx2::sidebar::ContextChangeBroadcaster::BroadcastContextChange
sfxlo.dll!sfx2::sidebar::ContextChangeBroadcaster::Activate
sfxlo.dll!SfxShell::BroadcastContextForActivation
swlo.dll!SwPagePreview::SwPagePreview
swlo.dll!SwPagePreview::CreateInstance
sfxlo.dll!SfxViewFactory::CreateInstance
sfxlo.dll!SfxBaseModel::createViewController
sfxlo.dll!`anonymous 
namespace'::SfxFrameLoader_Impl::impl_createDocumentView
sfxlo.dll!`anonymous namespace'::SfxFrameLoader_Impl::load
fwklo.dll!framework::LoadEnv::impl_loadContent
fwklo.dll!framework::LoadEnv::startLoading
fwklo.dll!framework::LoadEnv::loadComponentFromURL
fwklo.dll!`anonymous namespace'::Frame::loadComponentFromURL
sfxlo.dll!SfxViewFrame::LoadViewIntoFrame_Impl
sfxlo.dll!SfxViewFrame::SwitchToViewShell_Impl
sfxlo.dll!SfxViewFrame::ExecView_Impl
sfxlo.dll!SfxStubSfxViewFrameExecView_Impl
sfxlo.dll!SfxShell::CallExec
sfxlo.dll!SfxDispatcher::Call_Impl
sfxlo.dll!SfxDispatcher::PostMsgHandler
sfxlo.dll!std::_Invoker_pmf_pointer::_Call 
 >),SfxDispatcher * 
&,std::unique_ptr > >
sfxlo.dll!std::invoke 
 >),SfxDispatcher * 
&,std::unique_ptr > >
sfxlo.dll!std::_Invoker_ret::_Call 
 >),SfxDispatcher * 
&,std::unique_ptr > >
sfxlo.dll!std::_Call_binder 
 >),std::tuple 
 >,std::tuple 
 > &&> >
sfxlo.dll!std::_Binder 
 >),SfxDispatcher *,std::_Ph<1> const 
&>::operator() 
 > >
sfxlo.dll!st

Failing

[Kaganski Mike]

After last pull, JunitTest_chart2_unoapi reliably fails for me on master 
on Win10 with this call stack:

ucrtbased.dll!issue_debug_notification(const wchar_t * const message) 
Line 28
at minkernel\crts\ucrt\src\appcrt\internal\report_runtime_error.cpp(28)
ucrtbased.dll!__acrt_report_runtime_error(const wchar_t * message) Line 154
at minkernel\crts\ucrt\src\appcrt\internal\report_runtime_error.cpp(154)
ucrtbased.dll!abort() Line 61
at minkernel\crts\ucrt\src\appcrt\startup\abort.cpp(61)
ucrtbased.dll!common_assert_to_stderr(const wchar_t * const 
expression, const wchar_t * const file_name, const unsigned int 
line_number) Line 187
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(187)
ucrtbased.dll!common_assert(const wchar_t * const expression, 
const wchar_t * const file_name, const unsigned int line_number, void * 
const return_address) Line 420
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(420)
ucrtbased.dll!_wassert(const wchar_t * expression, const wchar_t * 
file_name, unsigned int line_number) Line 444
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(444)
vcllo.dll!ImplDbgTestSolarMutex() Line 46
at c:\lo\src\core\vcl\source\app\dbggui.cxx(46)
tllo.dll!DbgTestSolarMutex() Line 78
at c:\lo\src\core\tools\source\debug\debug.cxx(78)
vcllo.dll!OpenGLSalBitmap::Create(const Size & rSize, unsigned short 
nBits, const BitmapPalette & rBitmapPalette) Line 164
at c:\lo\src\core\vcl\opengl\salbmp.cxx(164)
vcllo.dll!Bitmap::Bitmap(const Size & rSizePixel, unsigned short 
nBitCount, const BitmapPalette * pPal) Line 108
at c:\lo\src\core\vcl\source\bitmap\bitmap.cxx(108)
vcllo.dll!o3tl::make_unique(Size & 
, unsigned short & ) Line 29
at c:\lo\src\core\include\o3tl\make_unique.hxx(29)
vcllo.dll!vcl::PNGReaderImpl::ImplReadHeader(const Size & 
rPreviewSizeHint) Line 665
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(665)
vcllo.dll!vcl::PNGReaderImpl::GetBitmapEx(const Size & rPreviewSizeHint) 
Line 342
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(342)
vcllo.dll!vcl::PNGReader::Read(const Size & i_rPreviewSizeHint) Line 1732
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(1732)
vcllo.dll!GraphicFilter::ImportGraphic(Graphic & rGraphic, const 
rtl::OUString & rPath, SvStream & rIStream, unsigned short nFormat, 
unsigned short * pDeterminedFormat, GraphicFilterImportFlags 
nImportFlags, 
com::sun::star::uno::Sequence * 
pFilterData, const WmfExternal * pExtHeader) Line 1813
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(1813)
vcllo.dll!GraphicFilter::ImportGraphic(Graphic & rGraphic, const 
rtl::OUString & rPath, SvStream & rIStream, unsigned short nFormat, 
unsigned short * pDeterminedFormat, GraphicFilterImportFlags 
nImportFlags, const WmfExternal * pExtHeader) Line 1281
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(1281)
vcllo.dll!GraphicFilter::FilterCallback(ConvertData & rData) Line 2509
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(2509)
vcllo.dll!GraphicFilter::LinkStubFilterCallback(void * instance, 
ConvertData & data) Line 2481
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(2481)
sofficeapp.dll!Link::Call(ConvertData & data) Line 84
at c:\lo\src\core\include\tools\link.hxx(84)
sofficeapp.dll!desktop::Desktop::ImplInitFilterHdl(desktop::Desktop * 
__formal, ConvertData & rData) Line 1752
at c:\lo\src\core\desktop\source\app\app.cxx(1752)
sofficeapp.dll!desktop::Desktop::LinkStubImplInitFilterHdl(void * 
instance, ConvertData & data) Line 1749
at c:\lo\src\core\desktop\source\app\app.cxx(1749)
vcllo.dll!Link::Call(ConvertData & data) Line 84
at c:\lo\src\core\include\tools\link.hxx(84)
vcllo.dll!GraphicConverter::Import(SvStream & rIStm, Graphic & rGraphic, 
ConvertDataFormat nFormat) Line 44
at c:\lo\src\core\vcl\source\gdi\cvtgrf.cxx(44)
chartcorelo.dll!chart::ChartModel::impl_loadGraphics(const 
com::sun::star::uno::Reference & 
xStorage) Line 621
at 
c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(621)
chartcorelo.dll!chart::ChartModel::impl_load(const 
com::sun::star::uno::Sequence & 
rMediaDescriptor, const 
com::sun::star::uno::Reference & 
xStorage) Line 576
at 
c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(576)
chartcorelo.dll!chart::ChartModel::load(const 
com::sun::star::uno::Sequence & 
rMediaDescriptor) Line 543
at 
c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(543)
chartcontrollerlo.dll!chart::ChartFrameLoader::load(const 
com::sun::star::uno::Sequence & 
rMediaDescriptor, const 
com::sun::star::uno::Reference & xFrame) 
Line 170
at 
c:\lo\src\core\chart2\source\controller\main\chartframeloader.cxx(170)
fwklo.dll!framework::LoadEnv::impl_loadContent() Line 1149
at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(1149)
fwklo.dll!framework::LoadEnv::startLoading() Line 38

Re: Unable to build with poppler 0.71.0

[Kaganski Mike]

On 19.11.2018 16:07, Andrey Cherepanov wrote:
> If build with poppler 0.71.0 I get errors for missing type GBool:
> 
> In file included from
> /usr/src/RPM/BUILD/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/wrapper_gpl.cxx:20:0:
> /usr/src/RPM/BUILD/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:153:17:
> error: 'GBool' does not name a type; did you mean 'bool'
>   virtual GBool upsideDown() override { return gTrue; }
>   ^
>   bool
> /usr/src/RPM/BUILD/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:156:17:
> error: 'GBool' does not name a type; did you mean 'bool'
>   virtual GBool useDrawChar() override { return gTrue; }
>   ^
>   bool
> ...
> 
> There is commit
> https://gitlab.freedesktop.org/poppler/poppler/commit/163420b48bdddf9084208b3cadf04dafad52d40a
> 
> Replace GBool, gTrue, and gFalse by bool, true, false, resp.
> 
> So type GBool (and so on) is no longer exist and it should be replaced
> by bool in sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx
> 

Should be fixed in commit 5e8bdd9203dd642111c62a6668ee665a20d4ba19 < 
https://git.libreoffice.org/core/+/5e8bdd9203dd642111c62a6668ee665a20d4ba19%5E%21/
 
 >.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Changing soffice.bin to be console application on Windows

[Kaganski Mike]

On 19.11.2018 18:48, Stephan Bergmann wrote:
> On 19/11/2018 16:38, Kaganski Mike wrote:
>> I have prepared a patch making soffice.bin a proper console Windows
>> application: https://gerrit.libreoffice.org/63572. The patch also
>> introduces a new launcher soffice.com (in addition to existing
>> soffice.exe). That is to make possible to call soffice from command
>> line, and have proper console launcher for that call.
> 
> If there's both soffice.exe and soffice.com in the same directory 
> (assuming the "new launcher osffice.com" also goes into program\), what 
> will happen if some client starts just soffice w/o extension (either 
> from a shell, or from Windows' equivalent of exec, if it's possible to 
> call that w/o an extension)?  (program\soffice.exe is part of the stable 
> 3rd-party interface on Windows, but I'm not sure whether we officially 
> announce it as "program\soffice.exe is part of the stable interface" (so 
> client code could be considered broken if it calls that w/o extension) 
> or as "program\soffice is part of the stable interface".)

Yes, the soffice.com goes to the same program\ along with soffice.exe. 
And that's for the very purpose of the described scenario: when user 
calls soffice without an extension, .com is (usually) the preferred 
extension (subject to PATHEXT override), as described in [1]. Note that 
calling soffice without an extension is usually (always?) the case for 
console-like operation; while shell integration (including desktop 
shortcuts and registry) is done using explicit .exe. Also note that 
CreateProcess WinAPI only substitutes .exe in case the extension is 
omitted [2], so this scenario (calling soffice from a custom application 
without explicitly specifying .exe) should be unaffected.

The soffice.com is made to do exactly the same as soffice.exe (modulo 
being console application, and thus behave properly in different console 
and batch scenarios). In fact, the two are made as WinMain()|main() 
calling the real impl function which does everything that previously was 
in soffice.exe's WinMain.

Currently our help (and multiple resources everywhere) often (not sure 
if exclusively) mention commands like "soffice --switches". And both 
this and calling soffice.exe explicitly is currently inconsistent across 
platforms, because on other platforms, the call works as proper console 
call. So I see this as (hopefully) making the API consistent with what 
we announce.

[1] https://en.wikipedia.org/wiki/COM_file#Execution_preference
[2] 
https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessw
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Changing soffice.bin to be console application on Windows

[Kaganski Mike]

Hi!

Currently soffice.bin on Windows is built with subsystem set to GUI. 
This creates a number of problems, including impossibility to output 
--version/--help into a text using command like

soffice --help > somefile

(or do similar things piping the output to other commands in batch 
files); absence of debug output in the console (if not launching from 
cygwin).

I have prepared a patch making soffice.bin a proper console Windows 
application: https://gerrit.libreoffice.org/63572. The patch also 
introduces a new launcher soffice.com (in addition to existing 
soffice.exe). That is to make possible to call soffice from command 
line, and have proper console launcher for that call.

I now ask for opinions from those who might know (or suspect) why that 
is a wrong move. Thank you for reviews/opinions!

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Replacing /.vs by *.vs in .gitignore

[Kaganski Mike]

Hi!

On 15.11.2018 9:43, Kévin Dlle wrote:
> With VS2017 integration, when a module solution in opened (for example
> vcl/vcl.sln), VS2017 creates a folder vcl/.vs
> These folders are not masked by the actuel gitignore.
> We should replace the line /.vs by *.vs

Please come with a patch to gerrit. Thanks!

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Please update XML Security Library to 1.2.27 for LibreOffice 6.2/6.1.4/5.5 from Windows/Linux.

[Kaganski Mike]

Hi,

On 12.11.2018 19:50, maxbook2020 maxbook2020 wrote:
> Please update XML Security Library for LibreOffice version 6.2/6.1.4/5.5 
> from Windows/Linux.
> 
> Current xmlsec 1.2.23 to new xmlsec 1.2.27.
> 
> Because now is old
> 
> https://wiki.documentfoundation.org/ReleaseNotes/5.3
> 
> 
>   Document signing
> 
>   * The bundled libxmlsec library has been upgraded to 1.2.23, including
> our "OOXML Relationships Transform Algorithm" implementation
> upstream. blog entry
>  (Miklos Vajna,
> Collabora)

... 
https://git.libreoffice.org/core/+/ad319fdfcaaa6092ea1ff76935e088c5122e0d2e 
(May 10 2017) "Upgrade libxmlsec to 1.2.24"

... 
https://git.libreoffice.org/core/+/321c2d4426bf9f856e780c3ad089286d92265047 
(Sep 20 2017) "Upgrade libxmlsec to 1.2.25"

... 
https://git.libreoffice.org/core/+/71198fe7d9539859883b6226738fbea52a08a5c4 
(Jun 20 2018) "xmlsec: update to 1.2.26"

... 
https://git.libreoffice.org/core/+/9630a2dfc79b08e3417e6e69b083f5124614499c 
(Oct 30 2018) "external: upgrade libxmlsec to 1.2.27"

:-) Please don't worry about xmlsec - it's secure in LibreOffice

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

[Kaganski Mike]

On 11/6/2018 4:12 PM, Miklos Vajna wrote:
> So what to change?

https://git.libreoffice.org/core/+log/HEAD

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

[Kaganski Mike]

On 10/31/2018 9:15 AM, Guilhem Moulin wrote:
> On Tue, 30 Oct 2018 at 16:18:36 +, Luke Benes wrote:
>> The date gitiles displays in the log is the author date, rather than
>> the much more useful commit date.
> 
> Quoting my own <20181023142926.GB21836@localhost.localdomain>:
> 
> | It's shows the authored date, not the commit date.  We can easily tweak
> | the template, but IMHO it's more consistent to show the authored date
> | given that the name that's beside it is the author's not the committer.
> | Gitweb, on the other hand, shows the *commit* date along with the
> | *author* name.
> 
>> When trying to track down regressions, you care about the order of
>> commits, not when they were authored.
> 
> I'm confused, neither commit date nor author date give any guaranty
> regarding the order of commits.  AFAICT the only thing that helps here
> is to follow the Merkel tree (child → ancestor) back to the root.
> Unlike ordering by date, performing a topological order of the tree
> (e.g., following the output from git-log(1)) is reliable, as the
> relations are cryptographically secured.

Well - of course, there's no guarantees; but given the workflow, when we 
have the author date recorded when the first version of commit was 
created, which might be months before the commit gets into the final 
shape (which can be drastically different from the first version), the 
"author date" has ~no value, while commit date has at least some, and is 
actually helpful.

Thus, given that

> I don't care which of author or committer is shown in
> the log view.  I believe it should be both committer name + date, or
> both author name + date for consistency, but if QA wants to mix the two
> then so be it.

please do the change :-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Seg fault on Windows in xmlsecurity_signing Unit Test

[Kaganski Mike]

On 10/31/2018 7:13 PM, Luke Benes wrote:
> Both my Windows box and @42 and @62 are failing with the following error:
> [build CUT] xmlsecurity_pdfsigning
> /usr/bin/sh: line 1:  8100 Segmentation fault  ( 
> PATH="C:\core\instdir\program;C:\core\instdir\program;C:\core\workdir\LinkTarget\Library;C:\core\workdir\UnpackedTarball\cppunit\src\cppunit\ReleaseDll;$PATH"
>  $W/LinkTarget/Executable/cppunittester.exe 
> $W/LinkTarget/CppunitTest/test_xmlsecurity_signing.dll --headless 
> "-env:BRAND_BASE_DIR=file:///$S/instdir" "-env:BRAND_SHARE_SUBDIR=share" 
> "-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource" 
> "-env:UserInstallation=file:///$W/CppunitTest/xmlsecurity_signing.test.user" 
> "-env:CONFIGURATION_LAYERS=xcsxcu:file:///$I/share/registry 
> xcsxcu:file:///$W/unittest/registry" 
> "-env:UNO_TYPES=file:///$I/program/types.rdb 
> file:///$I/program/types/offapi.rdb" 
> "-env:UNO_SERVICES=file:///$W/Rdb/ure/services.rdb 
> file:///$W/Rdb/services.rdb" -env:URE_INTERNAL_LIB_DIR=file:///$I/program 
> -env:LO_LIB_DIR=file:///$I/program 
> -env:LO_JAVA_DIR=file:///$I/program/classes --protector 
> $W/LinkTarget/Library/unoexceptionprotector.dll unoexceptionprotector 
> --protector $W/LinkTarget/Library/unobootstrapprotector.dll 
> unobootstrapprotector --protector 
> $W/LinkTarget/Library/vclbootstrapprotector.dll vclbootstrapprotector 
> "-env:CPPUNITTESTTARGET=$W/CppunitTest/xmlsecurity_signing.test" ) > 
> $W/CppunitTest/xmlsecurity_signing.test.log 2>&1
> SigningTest::testDescription finished in: 1816ms
> 
> Error: a unit test failed, please do one of:
> make CppunitTest_xmlsecurity_signing CPPUNITTRACE=TRUE
> 
> https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1540911001.21480
> 
> 
> The failure started in this range: 
> https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=9ebcc7c9a21f33cf42146786e4463856d373f114..7b0f2ee441b0cbcb88f3020df40c49e7cd6f9fb1
> 
> Most likely this commit:
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=9630a2dfc79b
> external: upgrade libxmlsec to 1.2.27

Fixed in commit 3ea3611b2bb552bf103fc2c2dcbf05f2ba5ddf07.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cppcheck: Reduction of False Positives: Manual Approach

[Kaganski Mike]

Hi Luke,

I believe that continuing the "manual approach" is moot. It was 
mentioned that the correct way is to generate the proper project 
structure for cppcheck using our existing tools that generate IDE 
integrations (and they have correct include correct includes, deps and all).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

[Kaganski Mike]

On 10/23/2018 12:29 PM, Adolfo Jayme Barrientos wrote:
> Gitiles lacks this kind of per-file-diff links, so I can only load a
> diff of all the files touched by the commit. This isn’t nice for my
> underpowered computer, and it really breaks my workflow.

Well - e.g., 
https://gerrit.libreoffice.org/plugins/gitiles/core/+/b0c6d587405af9e2263dc5073a9a965db46ff986
 
shows the individual links for each file like this:

icon-themes/breeze/links.txt[diff]
icon-themes/breeze_dark/links.txt[diff]
icon-themes/breeze_svg/links.txt[diff]
icon-themes/colibre/links.txt[diff]
icon-themes/karasa_jaga/links.txt[diff]
officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu[diff]
sw/uiconfig/sglobal/popupmenu/frame.xml[diff]
sw/uiconfig/sweb/popupmenu/frame.xml[diff]
sw/uiconfig/swform/popupmenu/frame.xml[diff]
sw/uiconfig/swreport/popupmenu/frame.xml[diff]
sw/uiconfig/swriter/popupmenu/frame.xml[diff]
sw/uiconfig/swxform/popupmenu/frame.xml[diff]
12 files changed

Note the [diff] next to the filename.

What seems odd to me is why the log like 
https://gerrit.libreoffice.org/plugins/gitiles/core/+log/HEAD shows 
commit creatin time that is different from the time the commit was 
pushed to the branch. I would like to see just-pushed commits to tell "5 
minutes ago" instead "3 days ago" like it might be now.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: "GpgME not installed correctly" in unit tests

[Kaganski Mike]

On 10/18/2018 2:48 AM, Thorsten Behrens wrote:
> Ah - so it seems also LinkTarget\Executable needs a copy of that silly
> program - can you try to add a line to
> 
> external/gpgmepp/ExternalPackage_gpgmepp.mk
> 
> that copies it there?

I have prepared a gerrit change: https://gerrit.libreoffice.org/61903 - 
that tries to do that. Please review and give some advise (I'm not good 
in makefile-foo).

> (there's already $(eval $(call
> gb_ExternalPackage_add_file,gpgmepp,$(LIBO_LIB_FOLDER)/gpgme-w32spawn.exe,src/gpgme-w32spawn.exe))
> - perhaps that is now redundant? Sorry, no finished master build right
> now for me to test myself)

The line puts the executable into the instdir and subsequently to 
installer and user system - is than redundant? (didn't test that myself)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

"GpgME not installed correctly" in unit tests

[Kaganski Mike]

Hi!

While doing make check on my Windows box with gpg4win 
(default-installed, but not configured), I get these dialog boxes 
popping up a dozen of times, e.g. in test_xmlsecurity_pdfsigning or 
test_sw_odfexport:

---
GpgME not installed correctly
---
gpgme-w32spawn.exe was not found in the detected installation directory 
of GpgME
"C:\lo\src\core\workdir\LinkTarget\Executable"

Crypto operations will not work.

If you see this it indicates a problem with your installation.
Please report the problem to your distributor of GpgME.

Developer's Note: The install dir can be manually set with: 
gpgme_set_global_flag
---
ОК
---

My autogen.input is

--with-distro=LibreOfficeWin64
--with-external-tar=c:/lo/src/lo-externalsrc
--with-junit=c:/lo/src/junit-4.10.jar
--with-ant-home=c:/lo/src/apache-ant-1.9.5
--with-galleries=no
--with-visual-studio=2017
--enable-pch
--enable-release-build
--enable-dbgutil
--enable-symbols
--without-help
--with-lang=ru
--with-myspell-dicts
--without-package-format
--enable-64-bit
--enable-werror
--with-gdrive-client-id=XXX
--with-gdrive-client-secret=YYY
--with-ucrt-dir=D:/Downloads/ucrt/WindowsUCRT
--enable-breakpad
--disable-mergelibs

What is missing in the build process to avoid the problem? I believe 
that there should not be requirement to explicitly configure anything 
here to avoid these errors in the middle of the build process; if 
required, the checks/errors/suggestions must be in autogen.sh phase?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice