Age | Commit message (Collapse) | Author |
|
Change-Id: I0f6e284d232388019bfa33f07a4afc864e0040a9
|
|
Change-Id: I325141f90104496c62af8704d75568df3418952a
Reviewed-on: https://gerrit.libreoffice.org/43050
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Do away with an early hack to create the floating window with every
invalidate.
This gets rid of persistent blinking when moving the mouse over a
listbox, for example.
Change-Id: Ida9367156605edc9835529f83529363ad97beaee
|
|
Change-Id: I193e0ab82e998905b670f7de73daae784de3ef00
|
|
Change-Id: I4ccef76cc3b2926dd8916f825671bb732e101027
|
|
We can specify whether it is an invalidation or something else in the
payload.
Change-Id: I95c5fc0a0a88b5277eaa93c8d1f9b937bddce7b3
|
|
Change-Id: I06a081835d246f752e57f8cc289162ed31fc91d4
|
|
With this, key events successfully work now.
Change-Id: I6dc6aff91dea08fcbc7ab840a77e2542ab9048ce
|
|
gtk_window_move them to the position broadcasted to us by vcl
Change-Id: Id27b52a24e721b51d7a153cc7c0e03197a99ee2f
|
|
Now gtktiledviewer can show floating window dialog widgets when user
clicks any of such widget in the dialog.
Change-Id: I13d756f236379bc8b2041ed41cb7b502f7fd9b24
|
|
Change-Id: Icfc210b08c7f1d8ebaf9c731ed64bb128cfc4356
|
|
Change-Id: I1d744c91f01eb098e9273d2459b63a5444558f39
|
|
For now, temporarily trigger paints for all the opened
dialogs whenever a dialog invalidation callback is emitted. This solves
the problem for some of the dialogs where hard coded uno command, which
we are using as dialog IDs in GTV, doesn't match with the dialog id
contained in the payload of the invalidation callback.
With this SearchDialog, AcceptChangeTracking and few others are
responding well to mouse clicks and invalidate instantaneously while to
invalidate and repaint some other dialogs, one needs to refocus them.
Change-Id: Iac2acbda60c8e2d0eabe65440f3fbda3ef271d7a
|
|
The current implementation works well - the mouse events are properly
handled by the opened dialog changing the dialog states.
However, since the uno commands (dialog IDs) are different from what is
returned by LOK_CALLBACK_DIALOG_INVALIDATE, the invalidation doesn't
instantaneously, so one have to make the dialog window out-of-focus and
then again back to focus to trigger the paint and see the updated dialog
state.
The mouse coordinates are forwarded in pixels as of now.
Enable mouse GDK Motion mask too for mouse move operation.
Change-Id: Ia915f734e8cbf4586da2b70da5840fe1568b39bd
|
|
Events from the dialog in GTV are forwarded correctly, but the events
are still not processed by the dialog in core.
Change-Id: Ib95ac0a3cd23f6cc2763c21425a67402b15f2de2
|
|
Change-Id: I081508674a71c3beb89175e4f8ac3256e6bc6c6a
|
|
Change-Id: I7cb320a740cdb21da5a654cf99c887f5c7a8979d
|
|
For now, just invalidate the whole dialog whenever any of the controls
in the dialog get invalidated.
Since during dialog painting, many such invalidations are triggered,
don't listen to them when we are painting.
Change-Id: Ia8fc12cf9469691d60e91ef770d687e5ff01a7ef
|
|
Hardcode modeless dialogs available in writer (very few) as of now in
the combobox.
Change-Id: I82d1442fbc71776dd64640ad048a0375ca041a67
|
|
Change-Id: I06e0923980b98b37b06ab45d8db68424b01d4f71
Reviewed-on: https://gerrit.libreoffice.org/42645
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
|
|
Change-Id: Ic11634ca28396fd156390c511087bae03bd5fb70
Reviewed-on: https://gerrit.libreoffice.org/42156
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
adding commands to fetch and changee ruler state
'.uno:RulerState' and '.uno:RulerStateChange'
Change-Id: I66107039a7ae5893691feb45c8ab2e4aa476ea76
Reviewed-on: https://gerrit.libreoffice.org/40727
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: pranavk <pranavk@collabora.co.uk>
|
|
extend oncevar to any POD type
Change-Id: Ia98ee0a67f183e40fb0c38477760124b2c411dc0
Reviewed-on: https://gerrit.libreoffice.org/40564
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
|
|
Change-Id: If6023dfa1d90f79185197622a738373a189ea6af
Reviewed-on: https://gerrit.libreoffice.org/40118
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ic3aacb79a3e828e59fede437213f2b7298e49bc1
|
|
Change-Id: I0fec2abc1bed9c0cfcd78d1b0f6daebc335831be
Reviewed-on: https://gerrit.libreoffice.org/39982
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ifb7bf759e87cb654401005914ed8906ef9456fdd
|
|
Change-Id: Iba449fc66423959340c7967c64bc422a28fc75dd
|
|
Put all the UI content in UI XML file.
Unfortunately, lots of boilerplate code because
G_DECLARE_* macros are available only since glib 2.44
Change-Id: Idc74ba8565d482c28abd00b6f6f75646ab3d40b9
Reviewed-on: https://gerrit.libreoffice.org/39913
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: pranavk <pranavk@collabora.co.uk>
|
|
Change-Id: I0c4c2f3389cae243dbbfd16667d44d3ab8851860
Reviewed-on: https://gerrit.libreoffice.org/39914
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
|
|
Change-Id: I5710b51e53779c222cec0bf08cd34bda330fec4b
Reviewed-on: https://gerrit.libreoffice.org/39737
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8b82d46d4688b1a59d6fe1b05da7d5c8dfc13ca6
Reviewed-on: https://gerrit.libreoffice.org/38766
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If9c7a3239fceba9a2db3a5905ccaa7fa9adadb08
Reviewed-on: https://gerrit.libreoffice.org/39099
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iba6b13871222d591bce49d04990e7c85ff154cce
Reviewed-on: https://gerrit.libreoffice.org/38915
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I1131f246c43806adb8a83f6eeafca2b734851a0e
Reviewed-on: https://gerrit.libreoffice.org/38888
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I80d850d23ab0e95bb4b105efa5a1ae1e59933a95
|
|
Change-Id: I82e366fefd2e31928b99840fe76649cc3521e623
Reviewed-on: https://gerrit.libreoffice.org/38789
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I99211e2dc016fb97b6744799b35e05acd7470464
|
|
A new callback has been introduced for notifying the client:
LOK_CALLBACK_CELL_ADDRESS
Change-Id: I40b38a3cb8fb658c3f00332d56cfcbaf98e13771
Reviewed-on: https://gerrit.libreoffice.org/37357
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
|
|
accept that once initted that LibreOffice cannot be deinitted and reinited
(without lots of work), but allow the main loop to quit and restart so LOKs
thread can run and exit successfully, new LOK connections will restart the main
loop.
The buckets of global state continues to be valid the whole time this way
Change-Id: Ide54c0df2ce4065f7c192ae8c2cedfaaa2b58d72
Reviewed-on: https://gerrit.libreoffice.org/37399
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
when LOK Widget is destroyed, it may instead happen during GC of javascript,
like in the in gnome-documents case, but "destroy" will be called promptly. So
close documents and office in destroy, not finalize
Change-Id: I1dd7b828839894cb2d87f5c087194fe458ca22f0
Reviewed-on: https://gerrit.libreoffice.org/37398
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
When it failed, it always failed like this:
libreofficekit/qa/unit/tiledrendering.cxx:311:TiledRenderingTest::runAllTests
equality assertion failed
- Expected: 3
- Actual :
It's not clear yet what triggers the failure, sounds like some kind of timing.
Change-Id: Ib5f44523f9a29c892aeda9eb881f452b57adb8a8
Reviewed-on: https://gerrit.libreoffice.org/36445
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
With this the test passes for me 10 times in a row, while previously it
failed from time to time, hopefully this fixes the false negatives.
Change-Id: I233276ddfe4e9d8c86557f7f1c29d997f2fb51f6
Reviewed-on: https://gerrit.libreoffice.org/36420
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ibe2108984df8f4fef9ed681941d517ca9ad9479c
Reviewed-on: https://gerrit.libreoffice.org/36177
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Iee2f4540cddeb05fcf0ae2ecadf7de8fbb4e3a0d
|
|
Change-Id: Id5811d092917c872715559f4508d01e4173d090c
Reviewed-on: https://gerrit.libreoffice.org/35636
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Idf4d3ba6b55be1f885f9d8fc89157e7e498d4e42
|
|
Change-Id: I59b71ee6815cbcfa4c8b5f68ae6dc9299856d49e
Reviewed-on: https://gerrit.libreoffice.org/35494
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
|