Skip to content

C
core
Dal (branch)/etiket değiştir
  1. 28 May, 2019 2 kayıt (commit)
    • Tor Lillqvist's avatar
      Fix build breakage when no localisations are present in an iOS build · c9719572
      Tor Lillqvist yazdı 
      Change-Id: I129bbd9a4c4ed7949fd81a06ebbcfbb6b5d01094
      c9719572
    • Tor Lillqvist's avatar
      tdf#124752: Add system clipboard interface for iOS · 1a0dfe5b
      Tor Lillqvist yazdı 
      Based on the corresponding macOS code. Work in progress. The image
support ifdeffed out still (because it uses some macOS specific APIs
for which I couldn't right away find the equivalent iOS ones).

I made it much simpler than the macOS code. I dropped the keeping of a
local in-process clipboard completely. Firstly, as far as I see, the
iOS clipboard API (UIPasteboard etc) does not even offer the
possibility to separately offer some formats and actually provide the
data on request. Secondly, we must be prepared anyway that the system
can kill an iOS app at any stage while the user is using some other
app, so we need to make sure everything that is copied goes onto the
system clipboard right away anyway.

I had to disable the copying of HTML to the clipboard as that lead to
a mysterious assertion failure. See comment in
DataFlavorMapper::openOfficeToSystemFlavor(). But RTF seems to work
well, too. I assume RTF is what gets used for cross-application
copy/paste (and cross-device, even, through Apple's Universal
Clipboard thing, where you can copy/paste between your Macs and iOS
devices on the same network).

I am not sure how relevant the various application/x-openoffice-foo
formats are.

Change-Id: I174495e33d86fc3990996c229243c05d6cbfcda7
      1a0dfe5b
  3. 27 May, 2019 2 kayıt (commit)
  5. 25 May, 2019 2 kayıt (commit)
    • Justin Luth's avatar
      tdf#123636 writerfilter: handle deferred breaks on frames · 403da742
      Justin Luth yazdı 
      and...
related tdf#123636 writerfilter: split newline also if PAGE_BREAK

...but only with old MSWord compat flag SplitPgBreakAndParaMark.

All of the other cases (COLUMN_BREAK and non-empty runs) split
the paragraph, so why not here?  This document shows it is needed,
but only for SplitPgBreakAndParaMark documents.

Note: Word 2003 doesn't display "modern" docx well in this regard.
It adds extra paragraphs where it shouldn't. There are already
example unit tests that ensure that extra paragraphs aren't written
for SplitPgBreakAndParaMark == false.

The actual bug's document is not related to the compatibility flag.
That will be handled in separate commit.

Reviewed-on: https://gerrit.libreoffice.org/70835
Tested-by: Jenkins
Reviewed-by: 's avatarJustin Luth <justin_luth@sil.org>
(cherry picked from commit 89e44da1)

tdf#123636 writerfilter: handle deferred breaks on frames

...similar to handling breaks before shapes in lcl_startShape.

Three different examples found to create/split a paragraph.
Which one to use? (addDummy, m_bIsSplitPara, and
lcl_startCharacterGroup). SplitPara is not good because the
paragraph properties probably should not be copied to the
dummy paragraph (like numbering for example). Slightly
modified the lcl_startChar example to ensure that the dummy
paragraph doesn't steal a part of the properties, but is
only default properties plus page-break.

This doesn't export very well, so roundtripping is very poor.

Research Note: There exists a compat flag showBreaksInFrames
(Display Page/Column Breaks Present in Frames)
"This element specifies whether applications should
honor the presence of page and/or column breaks which are
present within the contents of paragraphs which have been
defined as frames using the framePr element."
--Currently, LO does nothing with this flag. Probably too
exotic and irrelevant (word 2003 era?).

No existing unit tests found that have isSet(pg_brk) frames.

Reviewed-on: https://gerrit.libreoffice.org/71255
Tested-by: Jenkins
Reviewed-by: 's avatarJustin Luth <justin_luth@sil.org>
Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.com>
(cherry picked from commit f6f53f76)

Change-Id: I29f815355401c7af8b347a3ed9d0298bc9b27b93
      403da742
    • Michael Meeks's avatar
      gtktiledviewer: Fix crash on copy. · 53c507d6
      Michael Meeks yazdı 
      Change-Id: I1afc6278f6853d5e45a305b4f731cb6af0e00cc1
      53c507d6
  7. 24 May, 2019 3 kayıt (commit)
  9. 23 May, 2019 7 kayıt (commit)
  11. 22 May, 2019 2 kayıt (commit)
  13. 21 May, 2019 1 kayıt (commit)
  15. 20 May, 2019 2 kayıt (commit)
    • Tor Lillqvist's avatar
      tdf#125397: Avoid crash if GetpApp() returns null, can happen on iOS at least · 30b8d352
      Tor Lillqvist yazdı 
      Change-Id: Ib0dfb00c6a00640fe35769f21f167bf3eae8769b
      30b8d352
    • Tor Lillqvist's avatar
      tdf#125397: Fixes for threads and SolarMutex on iOS · e897310c
      Tor Lillqvist yazdı 
      We need to call SfxApplication::GetOrCreate() in lo_initialize() now.
Otherwise we will crash in sfx2. No idea why it worked earlier.

I think we want to avoid the "VCLXToolkit VCL main thread" ever
running in the iOS app. I don't think we had it running earlier, but
now for some reason it got started when creating a document from a
template, and that seemed to cause a hang.

Also, when creating a document from a template, lo_initialize() is
called from the app's real main thread (the one that the process
starts in). In that case we do want to release the SolarMutex after
InitVCL() if this was the first time we called InitVCL(). Awful crack.

Not really sure I fully understand all that is going on, but this
change does seem to fix recent problems... All this thread and
SolarMutex stuff is so incredibly fragile.

Change-Id: Ib04498ad199b64f27701f89d2df7003bca316406
      e897310c
  17. 19 May, 2019 5 kayıt (commit)
  19. 18 May, 2019 2 kayıt (commit)
  21. 17 May, 2019 1 kayıt (commit)
  23. 16 May, 2019 2 kayıt (commit)
  25. 15 May, 2019 8 kayıt (commit)
  27. 14 May, 2019 1 kayıt (commit)
    • Ashod Nakashian's avatar
      CppunitTest_sw_tiledrendering: close the document while LOK is still active · 31405b20
      Ashod Nakashian yazdı 
      When we destroy the document without LOK we leak the LOK Notifier
subsystem, which doesn't get destroyed, since LOK is inavtive by
then.

Though it's not entirely clear why only this test suffered this
issue, I avoided making unwarranted changes without reason
(i.e. failing tests).

Change-Id: Ib098b8ff3c828cb94a55d1f8cd1f0b010240a749
      31405b20