Avoids a number of compile time conditionals and adds flexibility.
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Change-Id: Iff6b294b504526e70715e436ad33d47c8df4752c
This enables the kit-in-process re-factor.
Change-Id: I93eb0a721945fb7b03e145b6c9d037ef3ce62589
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
L.Browser.touch is sometimes nice, but it's ultimately a flawed concept
to use it for input events. Using L.Browser.touch for input handicaps
people with mice if it's too liberal in what it classes as touchscreens,
and handicaps people with touchscreens if it's too conservative. There's
also no sweet spot: it's impossible to choose correctly if someone is
using both a touchscreen and a pointer device, as there's no right
option!
Previously many of our event handlers and some of our UI was gated
behind L.Browser.touch. This commit adds a new "window.touch" property
which is used instead. It has functions to help with event detection,
allowing you to easily make event handlers that work for only the input
devices they are designed for, without gating them behind feature
detection. This has the added bonus that - as you register all the
events - switching between a touchscreen and pointer is now not only
possible but already implemented!
For cases which don't have reasonable events to tag onto (e.g. the
teardrop for cursor movement) this commit adds "hasPrimaryTouchscreen"
and "hasAnyTouchscreen" which use the CSS media queries to detect if
there's a touchscreen attached to your device (either as the primary
input mechanism or at all). This works a lot more similarly to
L.Browser.mode, but being dynamically updated allows you to effectively
swich between touchscreen and not at-will. This still has all of the
disadvantages that L.Browser.touch did when used to register event
handlers, so my advice would be to avoid using it with events.
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: I9016fc15ad3ccb3664af348fdcdca006495b0778
problem:
some times we order comments before parent-child relation is established,
this caused reply count not being updated correctly for other users
steps to reproduce:
User A open ODT, let us say already with comment or add one, and keep Sidebar open so that comments are short.
user B opens the same ODT with full comments. adds reply
User A does not update ticket number, does not have +1
Signed-off-by: Pranam Lashkari <lpranam@collabora.com>
Change-Id: If3360c8dd938c6bd177764d3c1383d7f3f845990
This is safe to do as it's not interactive, so it happens synchronously.
The matching uno command was added on core.git co-23.05 in commit
1f5c20352725cd6133e68e80e8523d865006161f (sw floattable, delete UI: add
an uno command to unfloat frame from context menu, 2023-11-17).
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I74736c7d589c2062a8e9255a42f81bf790b7d3e3
The PopUp dialog is not closed, and side effects
are unresponsive key input
Change-Id: Id72ef0c6d081aa73acb39a07eb3e8b33d0e8dc85
Signed-off-by: Henry Castro <hcastro@collabora.com>
problem:
User A writes Comment 1 and saves
User A replies to himself, write something, click away to autosave, Cancel
user A modifies Comment 1 and OK - comment disappears, although it is there, seen after reload, but without modification.
Signed-off-by: Pranam Lashkari <lpranam@collabora.com>
Change-Id: I5d83936f26939b5a05a0ce3099c01923a55c9606
The ThreadPool::work function can get its condition signalled -very- late.
With bad timing, this can occur after all the work is done, and when the
next batch of work is being fed into the pool.
This can mean that it takes work from the queue, and subverts the:
bool useThreads = _threads.size() > 1 && _work.size() > 1;
check in ThreadPool::run - which can believe we are in a single
threaded, single tile mode - and not wait for this thread to complete.
That's not good [!] so ensure that threads are only runnable during
ThreadPool::run.
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Change-Id: Ifebb0f15cbb4c22ef33ffba06e7c6c87493818be
so it would be use on the other metrics for lookup with promql group_left
Change-Id: eaba5e26f99b4cb0843c16f6f5b840c6
Signed-off-by: genofire <geno+dev@fireorbit.de>
in:
commit 24f0819337
Date: Wed Jul 12 10:09:10 2023 +0100
tile debug: render updates as well as deltas in the tile.
one is typo for the other
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I9cb27d7912aa86373b8ef399fca442f85cfd69fb
- will fix Misaligned ui-tabs in mobile wizard
- also added scrollable property that will handle more fields in tabs if it does not fit into screen
Signed-off-by: Darshan-upadhyay1110 <darshan.upadhyay@collabora.com>
Change-Id: Ib982a59c141d937c7f92eb9684b91fc7f2548df5
Remove unused co-ordinates parameter, and unhelpful L.Log call
locations, ensure that all protocol messages are logged.
Increase the buffer to record startup and replay it for easier
debugging after startup.
Now when enabling "Protocol Logging" in the first minute from
document load, we get:
INCOMING[!fullyLoadedAndReady].statusindicator: find
INCOMING[!fullyLoadedAndReady].statusindicator: connect
INCOMING[!fullyLoadedAndReady].statusindicator: ready
INCOMING[!fullyLoadedAndReady].perm: edit
INCOMING[!fullyLoadedAndReady].filemode:{"readOnly": false, "editComment": true}
etc.
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Change-Id: I5d2a8639e8038dbcc31d6e8fd1b8f8ebf2fff7bc
presumably a regression from 158fe2f93:
Trying to init LOKit cause mysterious runtime error...
Change-Id: I28603a98a7c9015afc76d46a302a23ccf4ece261
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Tabbed mode doesn't have a menu bar, instead it has tabs. These can't be
hidden. Unfortunately, the post messages to hide the menu bar have the
side effect of hiding the tabs. This commit prevents the tabs being
hidden when in tabbed mode, and shows the tabs again when switching from
compact mode into tabbed mode.
When switching back from tabbed into compact mode, the state that you
would like the menu bar to be in (hidden/shown) will be remembered and
restored. This includes any postmessages that were not acted on while in
tabbed mode.
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: I1177903fe965e354538e6e7bbc3c83af3177938e
Previously, when using the Collapse_Notebookbar postmessage or
equivalent ui_defaults (SpreadsheetToolbar=false, etc.), particularly in
compact mode, it was possible to additionally hide the menu bar. As the
button to show the menu bar is on the notebookbar, this meant that you
couldn't reactivate either notebookbar or menubar until you refreshed
the page. This is particularly annoying in integrators that may not
provide an easy way to reload the page
This commit makes it so that hiding the menu bar automatically
uncollapses the notebookbar and won't let it be collapsed again. Whether
the notebook bar should be collapsed (the last thing done to it was a
collapse) is remembered and restored after the menu bar is shown again,
so if you send a postmessage that will affect the state of the
notebookbar after the menu is shown (even though it will not affect the
notebookbar's state immediately)
Caveats:
- If you are hiding the notebookbar to limit the control the user has,
that's broken by this commit as it makes it impossible to hide both
the menu and notebook bars at the same time.
- The notebook bar will be hidden again when re-showing the menu bar,
however there still isn't a way to hide the notebook bar in normal
use (i.e. without using either postmessage or ui_defaults) while in
compact mode (although there is a workaround to show it- switching
into tabbed mode and then back!). It might be nice to have one.
Other considered solutions:
- We could add a new button that allowed you to reopen the menu if both
menu and notebookbar were hidden
- Not sure there's much benefit to this over just doing what we're
doing here, and it's harder to implement
- We could disable the button to hide the menu bar when the notebookbar
is collapsed
- As far as I know, there's no button in the UI to show the notebook
bar. This would make it impossible to hide the menu bar if the
notebookbar was hidden via postmessage or ui_defaults
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: Ieab6d72a6be181aba88e9a5b21dda16a369b9e54
When creating NEW bug in GITHUB, there is template text, it includes OS, Browser, Version, but missing is COLLABORA Version.
I am seeing reports with all fillied, but missing that which is most important.
In addiiton, I set Browser with Versoin to be single line with e.g. Chrome 114.
Signed-off-by: Timur Gadžo <timur.gadzo@collabora.com>
Change-Id: I2d88a635474580189eb82a25ff6c55284b36692c
To test:
sudo mkdir /sys/fs/cgroup/memory/0
echo "900M" | sudo tee /sys/fs/cgroup/memory/0/memory.limit_in_bytes
echo $$ | sudo tee /sys/fs/cgroup/memory/0/tasks
make run # and check the log.
Change-Id: I81cf5f6212418d1f900a56cdfe476e1594f4fe77
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
- before this patch used send uno:ReplyComment on every autosave which was duplicating the comments
Signed-off-by: Rash419 <rashesh.padia@collabora.com>
Change-Id: I82b41783d97f5651c486011ac105750acf9589aa
this is visible even with hello-world.odt in the debugging overlay where
I have 9 cols and 7 rows visible.
Load hello-world.odt and from the 4th row, 8th col onwards each tile has
a "upd: 1" of an additional empty delta update to the original tile
browser-side:
a) we have one OUTGOING: tilecombine request which which requests an
initial 72 tiles (9 cols, 8 rows)
b) we then receive 72 tiles as requested
c) and browser sends back tileprocessed for each
d) but we then get a series of (38) delta: requests after that which are
unexplained
server-side:
a) on the initial tilecombine, DocumentBroker::handleTileCombinedRequest
sends the 72 requested tiles for rendering and registers to send each when
ready.
for (auto& tile : tileCombined.getTiles())
{
...
tilesNeedsRendering.push_back(tile);
...
tileCache().subscribeToTileRendering(tile, session, now);
}
// Send rendering request, prerender before we actually send the tiles
if (!tilesNeedsRendering.empty())
sendTileCombine(TileCombined::create(tilesNeedsRendering));
and stores what tiles it want to send in session->getRequestedTiles()
before calling sendRequestedTiles(session);
b) at this sendRequestedTiles (also later when tileprocessed is seen from
each tile response from the browser which also calls sendRequestedTiles), then:
c) DocumentBroker::sendRequestedTiles loops over existing requests and drops
from session->getRequestedTiles() both the tiles that it can send immediately,
and those that are queued to get rendered.
d) But it only does this for a max amount of tiles, based on beingRendered, up to
a tilesOnFlyUpperLimit. beingRendered is bumped for each tile not ready yet,
on the assumption that it needs to be rendered.
e) But we already have some getting rendered, and bump beingRendered anyway,
so tilesOnFlyUpperLimit can easily get exceeded on a first page, typically this
first sendRequestedTiles loop stops early, and stops dropping tiles from the
request queue that are already queued to be rendered.
f) at some point we get a tileprocessed and sendRequestedTiles is called again,
the request queue wasn't emptied, and by now it is likely the tile cache has
results for them (which were already sent) and sendTileNow is used to send those,
resulting in additional empty deltas sent for fulfilled queries.
logs will show "Redundant request to subscribe on tile" warnings in this case
Here as a conservative improvement only increase beingRendered if the sendRequestedTiles
subscribeToTileRendering actually does anything.
There is a mismatch in what handleTileCombinedRequest does vs what
sendRequestedTiles does. Maybe handleTileCombinedRequest should leave it
to sendRequestedTiles to do the sendTileCombine, or maybe
handleTileCombinedRequest shouldn't add those tiles to the session
requestedTiles.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I3044f4b3e47f00c680aa5b87dd7bdad2f27e8c73
It seems that datepicker control expects only a language input
in regional property (e.g. fr) instead of language-country (e.g. fr-FR).
Signed-off-by: Gabriel Masei <gabriel.masei@1and1.ro>
Change-Id: I7d5ac40cfa4a72cdc7862a8b4c4d14bdecad6c3b
