Selection background color is now consistent across context menu
and menubars.
Don't change the cursor to 'pointer' in context menus on hover.
Change-Id: I25d1fcba113f2c27a8ab6d028244afd75c28cd59
* Center the label on top-level menubar items
* Remove padding off the top of menubar
* Little more padding-top to menubar
Change-Id: I70adc72bb93d7388f59f670ad76b1b4ac6741f68
1. Prune out all other items that are not possible now.
2. Add a seperator CSS class and use it between menuitems.
... and other minor functional/UI changes.
Change-Id: I037e2b6f751824c973072c52905d46b0fd4be38b
... with some CSS tweaks in sm-simple.css to make it look more
like LO menubar in desktop application.
Change-Id: I62c88d5876da752fb487e89a3613698c463d9f32
License: MIT
Additionally, the sm-simple.css file is indented appropriately as
we would need to modify it to our needs later.
Change-Id: Iab909d2e06af342b22ebeffc86b3efdc1bacb73e
Tile invalidation and painting can race with one another.
A race when the user types two characters in quick succession:
1. After the first key press, the tile is invalidated.
2. The client request the tile on receiving the invalidate.
3. TileCache doesn't find it, and adds subscription.
A. Sometime before rendering, the second key press is received.
B. This invalidates the very same tile.
C. The client request the same tile.
D. TileCache finds a subscription and ignores the new one.
4. The tile is rendered and sent back.
5. Subscription is found and the tile is forwarded to clients.
6. Subcription is removed as the request is fullfilled.
E. The second tile is rendered and sent back.
F. TileCache finds no subscription and the tile is dropped.
End result: Only the first character appears on the screen.
Versioning fixes the above situation by making sure that in
step 5 the subscription will show to belong to a different
(and newer version) and so the tile will be ignored.
Instead, at F the TileCache will find both subscription
and a matching version and the lastest version will always
be sent back to the client.
Change-Id: I7d7fe1407cda1908d794683c3ce4c2fd18609a2f
Reviewed-on: https://gerrit.libreoffice.org/25341
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Tiles can be rendered in large batches and sent back
as combined payloads, all reduce latency and overhead
significantly.
Initial tests show a reduction in total latency by 2x.
This without sending tiles back to the client in combined
form, which will reduce latency further.
Change-Id: Iee06503f2a6c741fadb2c890266ea514c809c0dc
Reviewed-on: https://gerrit.libreoffice.org/25339
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When sending back response of tile or tilecombine type the
payload of the PNG image is implicitly the remainder of
the WS message. While this works fine for single-tile cases
it prevents us from combining tile responses into one to
reduce latency and overheads.
Change-Id: Iefeeed7e1a46be322c973ccf74f2bdb668d7cf30
Reviewed-on: https://gerrit.libreoffice.org/25338
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Black tiles are returned when rendering fails.
This happened due to bccu#1610 where internally
core collected cell info on the first 1024 rows
only. Anything beyond that always failed.
This limitation is now removed using dynamic
array to collect the cell info.
Regardless, the test here needs only check that
the last tile (really, anything beyond the 1024th row)
doesn't return a black tile.
This single tile still takes over 10 seconds to render,
which is the other issue that Core suffers from when
collecting cell info on a huge tab.
Change-Id: I7a1a5b7c2b2ed2cc4399160e096be5e57895af77
Reviewed-on: https://gerrit.libreoffice.org/25333
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
A source file (.cpp) must include its own header first.
This insures that the header is self-contained and
doesn't depend on arbitrary (and accidental) includes
before it to compile.
Furthermore, system headers should go next, followed by
C then C++ headers, then libraries (Poco, etc) and, finally,
project headers come last.
This makes sure that headers and included in the same dependency
order to avoid side-effects. For example, Poco should never rely on
anything from our project in the same way that a C header should
never rely on anything in C++, Poco, or project headers.
Also, includes ought to be sorted where possible, to improve
readability and avoid accidental duplicates (of which there
were a few).
Change-Id: I62cc1343e4a091d69195e37ed659dba20cfcb1ef
Reviewed-on: https://gerrit.libreoffice.org/25262
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
