AKA svp: always release SolarMutex on yield, v2
Implement the TODO when yielding a non-main thread: "use a
SolarMutexReleaser here and drop the m_bNoYieldLock usage"
This whole concept of "deferred yield" is prone to spurious
"deadlocks", if DoYield spawns a nested event loop. This will
not only block one yielding threads, but all indefinitly. And
not releasing the SolarMutex is also not fair for any other
threads waiting. That whole m_nNoYieldLock hack is just needed
to defer GUI processing to the main thread without releasing
the SolarMutex, the exact opposite of what yielding does.
While we can't do anything for the main thread as long as the
whole nested event loop concept prevails, we can prevent the
yielding thread deadlock using conditionals.
With all the special m_nNoYieldLock gone from SvpSalYieldMutex
there isn't any reason to keep it around.
Change-Id: I87c006ad36b4959f7e0dd18dda99a58c4e25032d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117900
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... and renove the wrong framesize hack in the Qt backend
This wastes a few additional pixels in the frame backing store,
actually covered by the real native menu bar, to get rid of all
the hacks and eventually fix quite a bunch of bugs in Qt (and
maybe other backends).
This seems to work correct with Qt using either QPainter or Cairo
as the painting backend. It's much simpler then my previous failed
attempts to fix the Qt related bugs. I would like to convert every
implementation to my interpretation of the API (at least I now
documented the API). It looks like Win and Mac will just work,
because Win has no native menu bar and Mac uses a global menu,
so always returns the size of 0. And Gtk also seems to work, if
it also lies about the menu bar size being zero. That just seems
consequent, if the frame size is reduced by the menubar size.
This fixes at least:
tdf#64438 - Dockable panels in LibreOffice not dockable using KDE
Works.
tdf#130893 - XWindow::SetPosSize resizing based on
XWindow::GetPosSize shrinks the window
The document macro from tdf#130841 now doesn't resize the window.
This is just fixed for Qt.
tdf#134704 - KDE5 - unable to dock sidebar by dragging frame
not fixed, because the sidebar window is now a dialog, which is
not dockable. FWIW the same has happend the Navigator (F5), which
also renders it non-dockable. No idea, if this is intentional.
tdf#137471 - CMIS dialog advances beyond lower right corner of the
screen
So commit 3f8d3fd464 ("tdf#137471 Qt
return frame pos + client area size") was really not enought as a
fix (at least it didn't break anything). The whole parent-based
repositioning is wrong and it really depends on the correct frame
size, so I'm keeping this as fixed by this patch.
Change-Id: I7faeace61b456c2b0f42c7a826f58018b70d46ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135082
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
So on Windows a window's state is stored in:
- maGeometry, inherited from SalFrame
- maState, which is the same type then maGeometry
- mnWidth and mnHeight, which are just set, never read
- mbFullScreen, which can be encoded in the vcl::WindowState
IMHO we can get rid of mnWidth, mnHeight and mbFullScreen. Which
leaves the mystery of the extra maState. But at least it looks
like we can simply cache an vcl::WindowState instead.
And this is a little start to make WinSalFrame variable members
private; it'll be a long way...
And it also changes a SW_SHOWMAXIMIZED to SW_SHOWMINIMIZED in the
cleaned UpdateFrameState(), which looks like an error.
Change-Id: I5895313d87a6f81371e2b77af6c813d35f591725
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135809
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
To have a constructor as the counterpart of the toStr() function.
Better then some unrelated independant function.
Change-Id: Iba4cb3d400a92704753db6b35d12f2189b23077e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135807
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This follow-up on commit 483f3125ec
("WIN drop effectively empty ImplDrawMenuBar") should probably
have been included in it. Windows was the only implementation of
that API, but the API is just called for a native menubar, which
Windows doesn't use (VisibleMenuBar returns false). Maybe Windows
SalFrame::SetMenu should also be dropped?
Change-Id: Ic3600e66c91ce9d56d7f911bce5674e0a9ee833c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135633
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
SalFrameStyleFlags::PARTIAL_FULLSCREEN is just ever read in
X11SalFrame, so there is no need to have it as a "global" flag.
Just save it as a member boolean and drop it from gtk3.
FWIW: consolidating all the booleans in X11SalFrame as a bitfield
(AKA reorder the fields and declare them bool myvar : 1;) might
be a nice easy hack.
Change-Id: I6a94310d3b734ecfd083b520d613a076b1e7670a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135805
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... and use it to remove a duplicate and simplify code.
Should mostly be a refactoring, which was mainly done by some
larger sed calls, except for the new API calls, which helped
shrinking some LOC. All data is also now private.
Originally two of the "replaced" "classes" had unsigned width
and height and one had signed. Noel pointed out, that during
calculations, the value might get negative temporarly, so this
now settles with signed values. Still the set size should never
be negative and this is enforced this way. Not sure that is what
Noel had in mind.
This also includes:
- rename WindowState => WindowData
- rename WindowStateMask => WindowDataMask
- rename WindowStateState => WindowState
- move WindowState and WindowDataMask to vcl/windowstate.hxx
- move WindowData(Mask) and WindowState into vcl namespace
- readability: replace or'ed WindowState enums with "meta" enums
+ add "meta" WindowState enums PosSize and PosSizeState
Change-Id: Icd16cfb498531aa7238ddbde83fcb0ed6d9e4f77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135426
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
My code comment about "drawable area" and Michaels bug comment
12 about the "frameGeometry()" usage were both half right. LO
expects the window's frame position and the drawable client area
size almost everywhere when "geometry" is involved. The frame's
border is stored in the decorations members of SalFrameGeometry.
Change-Id: Ic00ad1f1d74d7afadcaca0c01e1a41ea7f2833de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135434
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... and if there is no need to create a Cairo surface if it
doesn't exists, there is no need for a fresh QImage either.
Change-Id: If607e03d246f3c31d66953b1e07a7af55659e64b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135209
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Rechecking the QImage documentation, this actually can be easily
done; no more bit twiddling, which I got wrong to begin with.
LO's alpha mask is inverted to Qt's expectations, but we have
invertPixels() and then apply it with setAlphaChannel(). And we
can even set the fAlpha using setOpacity()!
Change-Id: If2030d3f87d3a4698d1cd9af005d307c2ee63061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135044
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
... instead of its QWindow
No idea, why my initial implementation used the QWindow. Neither
do I know, why it's now somehow broken. The code is called, but
the cursor doesn't change. But it seems to work via QWidget, so
just do that. IMHO less QWindow is preferable generally; let Qt
handle more of the low-level stuff.
Change-Id: Id23fba719c9a4d7e760991c51e6021c6f89be345
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135051
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
This turned out much more complicated then expected:
1. The QMenuBar needs explicit adjustSize() calls to position a
changed corner widget (or a resize...).
2. The adjustSize() results in a temporary, minimal QMenuBar
layout, so GetMenuBarButtonRectPixel needs to account for the
extra space itself, instead of just a mapTo call.
3. I didn't know, that you can't add shown widgets to a layout,
but must call show() after add / insert, otherwise they are
ignored in the layout (but show up as the layout items) and
are painted in strange positions.
This also includes the transparency flags for our QtWidget, so the
updater "bubble window" is properly alpha-masked / shaped.
And this maybe has too many asserts...
Change-Id: I86a708175e9f9be786f5dc1810ae0197a0d3fc39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135021
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... and therefore rename it to QtObjectWidget
Replacement of the QWidget with QWindow originally happened in
commit 56b19f9a81 ("tdf#121247,
tdf#121266 KDE5: Add basic support for OpenGL"), but that
unfortunately has a very sparce commit message with no reason
for this change. Then the code was further complicated in commit
25edbded99 ("tdf#125517 Qt5
implement a minimal Qt5ObjectWindow") and a few follow up fixes
to restore input and focus handling.
But appearingly all this QWindow handling isn't necessary and just
returning to a QWidget based class fixes the problems with the
video overlay (AKA QWidget::winId()) and video playback for good.
The OpenGL Impress transition (Fade) mentioned in the original
tdf#121266 bug still works.
This also adds the previously missing SolarMutexGuard to all the
overridden QtObjectWidget functions, which call the SalObject's
Callback function. I accidently triggered a DBG_TESTSOLARMUTEX
crashing Impress while debugging this.
Change-Id: Ia22cabfd4f3585dc7fa3f9f18a913c5bd1987dd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134864
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
I accidently almost introduced some subtle sytactic error in Qt,
because the default platform and toolkit values are actually valid.
So add an Invalid value to both enum classes and then sprinkle
some asserts, so these tests aren't working on invalid data.
Thanks Michael Weghorn for catching this in review.
Change-Id: Ic6a0764dfc5168181251023f4d1c66ffa32651d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134882
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Currently all implemented Qt platforms use freetype and fontconfig
to handle the font selection, so just move the font styling code
from the kf5 VCL plugin to qt.
This really minimizes kf5 by just keeping the special file picker
handling in that VCL plugin.
Change-Id: I0bbb2496379396afc46e34fe0d026702dce1492e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134862
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
I have no idea, if there can be multiple active popups in LO in
some way. There can be multiple FloatingWindow and gtk does count
them in m_nFloats... There is a whole lot going on in gtk3 related
to isFloatGrabWindow(), with "funny" comments like:
// FIXME: find out who the hell steals the focus from our frame
So this goes with some "optimistic" approach: there is just one
active popup, so we can track it in QtInstance. It WFM...
Change-Id: I9778587696e1ad9e641dba4f102e2e921266eee6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133249
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Currently just implemented for the QtWidget, but still as a static
function, so it may be used for QtObject at some point too.
But there is no (mouse) enter or leave event function in QWindow,
so no way to handle these there. And since we can't modify the
returned QWidget from QWidget::createWindowContainer, the only way
would be to expand the static QtWidget::handleEvent used by
QtObjectWindow::event ... if it's actually needed at some point.
Change-Id: If9009e5dfca508acd1e702df1a17eb8ad7c29690
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133190
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Instead of calling QToolTip::showText directly from LO, this
defers showing the tooltip to the QEvent processing, which takes
the tooltip timeouts into account. So tooltips are shown with
a slight delay, therefore they happen less fast on mouse move,
reducing / avoiding artifacts of fast changing windows.
This unfortunately comes with yet an other hack in the area of
our fake popup windows...
New handling is based on the code of the Qt Tool Tips example.
Change-Id: I42634ad36dd12171c30f52f07a02a88d3c48a718
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132841
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
When the QMenuBar of a QMainWindow is replaced, an existing
corner widget is preserved / transferred, but its connections
are still severed; a bit unexpected...
The documentation for QMenuBar::setCornerWidget is not really
clear what is happening, but the code has this nice comment:
"// Reparent corner widgets before we delete the old menu".
At least there is no need to explicitly delete the button.
Still we must reconnect an existing button on each SetFrame.
Regression from commit 9c4ef8ce31
("tdf#145954 Qt unshare QMenubar usage").
Change-Id: I13c31734e665b78231a08cd76ca6305122e08879
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132836
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Fixes the ODK cross-build used for Windows Arm64.
Regression from commit 40f2aee658
("Provide unoidl-write also for the SDK").
Change-Id: I54d2732358ed1d48911e206ed02bfca2d3a78782
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132718
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
LO doesn't provide any way to notify screen changes / scaling
factors of a window and in fact doesn't really handle scaling
factors in VCL. The QWidget doesn't receive a resize event,
because it's size doesn't change, just the scaling factor.
So we trigger a faked resize on QWindow::screenChanged signal.
Change-Id: I6928c4c62d1c0995c70fea0088cff17849bcd1d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132650
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
To reproduce the Impress crash, you need an IM, e.g. fcitx / ibus.
This is triggered by having an active input, like double-clicking
one of a presentations text fields, then leaving the window and
switching back to it.
This results in a stack exhaustion in a few seconds. The backtrace
is basically:
QWidget::setFocus
QtFrame::ToTop
sd::Window::GrabFocus
ImplHandleExtTextInputPos
QtWidget::inputMethodQuery
QInputMethod::cursorRectangle
QWidget::setFocus
QApplication::setActiveWindow
QtInstance::DoYield
main
I scratched my head over the longer backtrace for while, but there
seems to be no good way to prevent this from LO's POV. The only
alternative from the Qt VCL plugin is QtFrame::ToTop. That code
is less ugly (no mutable or cached result), but QtWidget::
inputMethodQuery is earlier in the backtrace.
Change-Id: Ief3a8e44bca295cc676e75050d52d70a1da98a88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132643
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The Qt code was sharing the menu bar from the top level frame, but
LO expects independent menu bars per SetFrame calls. So instead of
showing the new bar and then hiding the old one, this was always
show and hiding the same menu bar, resulting in a hidden menu bar.
As a result of unsharing, LO now must check that its menu bar
pointer is still valid for usage. The QMainWindows takes ownership
when a QMenuBar is assigned and destroy old ones.
Change-Id: I2c6b12199a1e17a5d9f88686a4b27b1413beda47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132581
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
So Michael Weghorn was somehow reminded of an abandoned
commit from me ("Qt5 rework parent handling") archived in
https://gerrit.libreoffice.org/c/core/+/73463.
The bug introducing the new QWidget parenting, tdf#145363, was
resolved in a better way by explicitly setting parents for the
modal dialogs, so LO doesn't break Qt anymore. The actual problem
is, that an additional modal dialog needs to be stacked to the
previous modal dialog; no "parallel" modal dialogs are allowed,
which my original fix tried to enforce by reparenting.
Then there is the problem with Qt::Popup's focus grabbing on show,
which breaks LO's editable ComboBox. So LO's popup / FLOAT windows
are mapped to Qt::ToolTip, which are automatically advertised as
tooltips via accessibility. For X11 / xcb, Qt:Window with the
Qt::BypassWindowManagerHint works well enough as an alternative,
but WASM and Wayland don't seem to implement it correctly, so this
just handles popups as Qt::ToolTip on all platforms.
This reverts commit b00a68a8e1
("tdf#145363 Qt reparent modal dialogs on show").
In addition the popup widgets are switched back to Qt::ToolTip.
Change-Id: If726771b4e9cc3f639f21cf502b3ec5985873643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132526
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Simply include the global transliterator in all builds.
Regression from commit de81c2545a
("Related: tdf#144245 Optimize case-insensitive handling").
Change-Id: Ica1c6e5d67c8458f9977f2ff87d9594a43b4cff2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132517
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Regression from commit e63fe68fb1
("Qt use asChild for pointer positioning"), which should just have
been a cleanup for commit ca28826a08
("tdf#131467 Qt set default position on first resize").
And scale the requested position by the device scale factor.
Change-Id: I50b3c628d22896e987d8cc2eaf5635cb12ba3464
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132518
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Building LO with WASM native EH and Emscripten 3.1.6+, the link
fails with a missing "emscripten_longjmp" symbol. Actually the
old build was simply wrong, because the emscripten_longjmp
function is just used for the Emscripten SjLj and not the native
WASM SjLj implementation. Linking just worked, because the used
libcompiler_rt-wasm-sjlj-mt.a lib was incorrectly providing that
symbol, which 3.1.6 removed.
But since running the NEH build still fails early in the same way
then before in FF nightly 100 and Chrome (= failure in the LO job
scheduler calling Task::UpdateMinPeriod for the "desktop::Desktop
m_firstRunTimer" timer, resulting in a WASM VM "RuntimeError:
indirect call signature mismatch"), there is still no way to know,
if nothing else it missing. The Emscripten / JS EH build still
works without any code changes. And it's not the first call on
a job object that fails...
And unfortunatly, because Qt itself also uses libpng, it also uses
SjLj for error handling, like LO in the image import, so the Qt
build must also be patched to build with "-s SUPPORT_LONGJMP=wasm".
Simply enough to do (see README.wasm.md). LO's configure now
detects that symbol and will bail out on incompatible Qt and LO
build setup.
See https://github.com/emscripten-core/emscripten/issues/16572
Change-Id: I3a1877f3aeb77873906176b9d3cd1ea92973f1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132139
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
While this fixes the build with --enable-wasm-exceptions, the
resulting binary generates an "indirect call signature mismatch",
which doesn't happen with the non-NEH build.
The Chrome DWARF backtrace points to CallbackTaskScheduling().
Further debugging reveals, it's actually the UpdateMinPeriod
call for the "desktop::Desktop m_firstRunTimer" Timer.
Disturbingly the debug dynamic_cast<Timer> at the start of the
job loop fails, and the fallback generic job output is
chosen, AKA:
info:vcl.schedule: 6516 0x3871618 i: 0 a: 1 p: 1 \
desktop::Desktop m_firstRunTimer
m_firstRunTimer is a Timer member in the Desktop class, so this
looks like some memory corruption or toolchain problem.
The size difference is more then 10% and it's supposed to be
faster too. FWIW the optimized link time is still high and needs
32GB+ memory compared to the 13GB non-optimized memory usage.
Change-Id: I06d37ecece09000fd3b72a73e7bf40f0b0f61457
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130216
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This reverts the special SjLj handling introduced in commit
ae22f7d062 ("WASM add option to
build with native exceptions"). This is supposed to work now;
at least it compiles.
Change-Id: I5ebceea9c7fe3c982d7c9a8818fd79f2018f03cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130219
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Extracting the version from the compiler defines is probably more
stable then the elaborative emcc -v output.
Change-Id: I491c0983be7f9811f4f6775b0a5f3cb172f0aefe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130218
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
All the tested cross builds don't build galleries, so the
cross-toolset won't contain gengal and no vcl is build.
To fix the full static build, add LIBWEBP to the list of
PERMITTED_BUILD_TARGETS and use gb_CONFIGURE_PLATFORMS to
provide the --host and --build flags.
Regression from commit 60eaa424c5
("support for the WebP image format (tdf#114532)").
Change-Id: I017c4fc72456859616d535ddfb2d568442ffa446
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129790
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
I build a full-language WASM build and the WASM linker was
complaining about mismatching function signatures for
get_zh_zhuyin and get_zh_pinyin.
Turns out LO has two exported functions with the same name
but different signatures. For a static build, these collator
functions are renamed, so they don't clash, and this was
silently calling the wrong functions from
i18npool/source/indexentry.
Change-Id: I6afe1c3a289dfccea5a5fec41a9a6db37f4e19bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129741
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Guess in all the fixing when upstreaming all the WASM changes,
that hunk got lost. This actually makes the WASM build run, not
just compile.
Change-Id: Ided621af284e62961eb47957d74b31871a30a2bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129105
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... and drop --system-icu-for-build.
Seems all the special handling was introduced for MingW in commit
d1cc4bb69e ("mingw: allow forced use
of system icu tools"). MingW support was removed for a long time.
I'm not sure the cross-compiling with --system-icu is really a
usable scenario, but this keeps the system tooling setup. Neither
do I know, if ICU >= 4.6 (release 2011-03-11 for ICU4C 4.6.1) is
a sensible configure check.
Change-Id: I00da8d6fc383e7e7d87d027074058ba7bec2d2b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128026
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
... it's just symlinked by the unxgcc.mk link target to binary
locations.
Change-Id: Idce067d82de6751cf422d924e00537d93fd716bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128730
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Adds DoQuit and SAL_USE_SYSTEM_LOOP to complement DoExecute.
Makes it easier to switch between a LO with and without nested
event processing. Unfortunatly the recovery dialogs run outside
of Application::Execute(), so this currently also disables
recovery handling.
Follow-up (and no more Emscripten-specific) change to commit
93133585b5 ("WASM optionally run
any app via system loop").
Change-Id: I1b622065d7fa0c5ad03a7c7daaf8241dcc3f09a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128717
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
If any of the optional component lists contain a non-optional
component implementation, fail the component file generation and
show a diff of the offending component implementation name.
Change-Id: Ieac876e613f6945362186d4586dd2aacc5669920
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128645
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
I quickly gave up trying to understand what exactly clashes
between the Emscripten macros and OUString templates /
initializers. Not sure it can actually be "fixed".
Also disables the makeshared clang compilerplugin; currently
there is no way to get rid of all the false positive hits
when assigning the std::shared_ptr from a function instead of
a constructor call.
Change-Id: I8b13f179629ea63ff221584030556d2bedadc01b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128604
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Even without XMLHELP support, the default English help strings
can be shown.
Change-Id: I0ac7a617d7209f70cc7c3cdd34bf0f17a5d4133a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128626
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
We probably want to pre-create the fontconfig cache in the image.
Startup time still is not really worse for me, but YMMV.
Change-Id: I419682339dd6d943753de9043ff82f2fb877b168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128624
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Allows LO to run via system event loop instead of having an
own one and processing system events as needed. Needed for
WASM, so the browser isn't blocked, as there is no way to
run the browser mainloop from WASM. Generally an alternative
to running LO in a WebWorker and communicating to some
frontend.
Change-Id: I24955638827f3b8c04240845ffc781cd28f2aa29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128602
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Currently disabled, as literally no runtime has a working
implementation. It also currently conflicts with LLVM's SjLj
(AKA setjmp / longjump) when generating WASM bytecode, but
the only offending code doesn't use exceptions, so this can
be avoided in general.
Change-Id: I2b338f3529e7350d54a7950772c6e7aae2282fe7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128600
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
There are three posibilites to add files to the image:
- gb_emscripten_fs_image_files to add individual files
- gb_emscripten_fs_image_autoinstall to add files from AutoInstall
- gb_emscripten_fs_image_filelists to add files from a .filelist
Change-Id: If6804e282a37a37ffae1d291d2af8430e60b59d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128598
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Doesn't include VCLplug flags and it should work with gtk3 too.
But normally you want to use:
--disable-gtk3
--enable-qt5
Change-Id: Ifea5e5b1e63633ff1fa709cdeb49afdb43fa0e8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128588
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Currently includes environment.js for general environment settings
and soffice_args.js for soffice command line flags.
Change-Id: I1166c5a9ae53c56a69b9223c865b4df525d07450
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128590
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Changes the linker flags, so a debug build will not rewrite the
WASM binary code for instrumentation, as this takes ages and more
then 64GB of RAM, currently.
For the same reason - long link times - prefer DWARF debugging to
the external source maps.
Initial memory and thread pool size are linker flags, so move them.
Change-Id: I5cf39842e5091ef55b4fac719f881575e69fe8d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128589
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
* Don't create a native window handle
* Use a static QMimeData for non-working clipboard
* Use Qt::Tooltip for LO's popup windows
Change-Id: I6b6edfa26466814cb0500116098eafcbe41bba26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128587
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
All the small stuff, which is needed for the WASM build, but is
not really worth an extra patch.
* No soffice.sh script needed for WASM
* WASM soffice.bin executable extension is html
* Some small additional SAL_LOG output
* Default to colibre icon theme
* Test for qt5 even without X11
* Remove emconfigure artefacts at the end of the configure run
* No oosplash for WASM
* Disable the Office IPC thread
* Suppress -Wno-enum-conversion for Cairo builds
* Fix libnumbertext by using gb_EMSCRIPTEN_CPPFLAGS
* Map EMSCRIPTEN to LINUX nls
* No extra newlines for missing icon theme images
* Print the missing dependency in some gbuild error messages
* Copy Qt WASM loader, HTML template and SVG logo for binaries
* Especially build the vcldemo for Emscripten
Change-Id: I356370c72cc09357411e14d0c00762152877a800
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128584
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Quoting sberg: "an include file like this one that is part of
the published URE interface must not include an include file
like config_host/config_global.h that is not part of the
published URE interface."
I did grep for other config files in include, but that missed
the "ifdef LIBO_INTERNAL_ONLY" protection; most time this file
will be included via some other header, so just drop it.
Change-Id: I18b0792de3f8351efd00557a66d4ef8979ca6550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128555
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
Sperren is a German typography word related to Sperrsatz, which
refers to increased space between characters. German UI calls it
Zeichenabstand, English one "Character spacing". The English
Wikipedia has an alias "tracking", but that seems as obscure as
Sperren for most programmers.
Change-Id: I2066bccac5e430b9ac2708559a6f2f262f2dea52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128554
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
..., add the configure test flags and rename DLOPEN_LIBS to
UNIX_DLAPI_LIBS.
Initinally convert two dlsym callers to use HAVE_DLAPI and
osl_getAsciiFunctionSymbol.
There are a lot of places, which still use -ldl and even more
direct dlsym calls; good opportunity for many simple EasyHacks.
Change-Id: I4f2d2f7cb079a075af8f9d01eb5ee45de40c7f03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128523
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
While this makes the preprocessor usage even larger, the code in
salplug.cxx is now hopefully easier to follow. I added a comment
about the main code structure at the beginning.
It also includes changes to the generic plugin list to include
gtk3_kde5 before gen, qt5 and qt6 after gen, but still skips the
headless / svp plugin.
And I explicitly excluded salplug.cxx from the externandnotdefined
compiler plugin. I could have added a dummy, but that seemed not
worth the effort. My try on a non-dummy with correct includes and
defines made the code in salplug.cxx much harder to follow.
FWIW, the iOS VCL plugin actually seems to use the osx SalData, so
I think these changes to iosinst.cxx are more correct then commit
7d990aafdc ("VCL drop m_pInstance
from *nix SalData"). But hard to tell without a compiler.
Change-Id: I0e2944d4221ca5910fb2120cc8b24def5c5b3f33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128477
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
And just echo a rename info for the 'all' target and exit with
an error, so people will actually adapt. 'all' had been modified
to run 'allbuild' in the original commit anyway. And since there
is no toplevel 'all' target, this just seems consequent.
And .PHONY the new targets.
Also advertise "make help" a bit more at the end of configure.
Follow-up on commit d6496fce2e
("split gbuild's <module>.all to <module>.allbuild or .allcheck").
Change-Id: Ia74020375f0a024dc67ea37ae4b18655af9df084
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128490
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
LO just has a single display event, SalEvent::DisplayChanged, Qt
has a multitude. So this will generate multiple LO notifications.
I don't see any reasonable way to prevent that. Doesn't seem a
problem here.
Change-Id: I2f11e53765869a4ca292a1d337347e4e7470e3c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128474
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Fixes all the backends, where SolarMutex access needs SalInstance.
The ImplSVData::SalInstance is just set fron the return value of
CreateSalInstance, so it can't be accessed earlier, globally.
Regression from commit ad94bb5d23d9c4ecbb2ca84807f01623862de43e
("VCL drop m_pInstance from *nix SalData).
Change-Id: I13259009571a9973ea7e3ded20c0ea4c660ee214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128420
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
AKA the "*nix SalData untangling" commit.
The original plan was to get rid of vcl/inc/saldatabasic.hxx and
even SalData for all the *nix backends. But after many backs and
forths, reinspecting the code and imagining the resulting code, I
decided against that plan. All these variants would have resulted
in reinterpret_cast calls, I wanted to prevent. And they would
have required larger renames for no benefit.
An other, related idea was to include all SalData implementations
in the vcl/inc/svdata.hxx header, but that seemed like an include
explosion, so was also dropped.
I tried to untangling iOS from using GenericUnixSalData, as it
doesn't use any of it's features. The new, minimal SalData should
be sufficient.
I'm leaving the easier drop of mpInstance from the Windows and
MacOSX backend as a minimal interesting EasyHack.
Change-Id: I5be01c1f42131a7e31cb30899392308e1e2de53b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128402
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... and use a std::unique_ptr.
PrinterInfoManager::release() was just called from ~SalData(),
so this should make this more clear.
Change-Id: Ic4aade2db3813fdc96ede116a50604692ef3dbec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128399
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This allows to build a complete static LibreOffice on Linux,
except for linked externals. Since LO's static build implies
disabled dynamic loading, one must select one VCL backend to
be compiled in.
See the (large) comment in solenv/gbuild/static.mk trying to
explain, why this implementation was chosen (spoiler: seems
there is no other way) and what is actually implemented.
This will collect all libraries, statics and externals of
executables. If the executable uses components, it will get
linked to all static components. While it works with any
Executable, it just makes sense for soffice.bin, because the
static component map sucks every dependency in, bloating most
other binaries.
In theory on could generate the dependencies based on the list
of used components (see gb_CppunitTest_use_components), then
generate a specific static constructor map, directly include it
in the exe's cxx code and then link the minimal dependencies.
The static LO should build on Linux with:
--enable-customtarget-components
--disable-dynamic-loading
Tested VCL plugin config is:
--disable-gtk3
--disable-gen
--enable-qt5
The partial build support is split into a 2nd patch.
Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126790
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
The pkgdata tool basically not only generates the data, but
forces a non-parallel build for all data files for platforms,
which can't use the (single file) assembler mode. This hits
the WASM build, bringing down the parallel build to a crawl.
But there is already the "hidden" optimization implemented in
pkgdata to just write a single C source file, instead of one
per locale. For some reason, that is just enabled on OS400.
I don't think we have a platform, which would have a memory
restriction doing this, so just uncondition this pkgdata
build mode for everyone.
Feel free to otherwise condition this patch for your platform
in external/icu/UnpackedTarball_icu.mk.
Change-Id: I482d80e853128d00faa43687e38f5b88fbf6958c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128266
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
No need to recompile most of LibreOffice, because the --with-fonts
configure flag changed. This preprocessor define is just used by
unit tests anyway.
Change-Id: Ia2eae7d0c74e59e034fdd8513504a34e51ab428e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128197
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
show() isn't just some conveniently renamed setVisible(true), but
presents a window in a platform-dependant way, which - at least
for WASM - means maximized and without a title bar. This is not
really expected and WASM can also use multiple windows.
Change-Id: I3fbaec1dfc2cd32bf3a90a94dcee01ebc88e58c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128179
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Jan-Marek Glogowski