@devseppala: Well - the GridOffset needs to be applied in both cases, so
this makes not really a difference...
>From the logic I think (2) is the better option - will now do that and check
>if it works as intended. Keep in mind that the GridOffset stuff itself is a
>compromize fix for the (hard)
Works well, but need to update local master 1st to prepare commit ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1846940
Title:
[upstream] Loop in libreoffice-calc when scrolling to top of
spre
Proposed fix at https://gerrit.libreoffice.org/#/c/82031/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1846940
Title:
[upstream] Loop in libreoffice-calc when scrolling to top of
spreadsheet
To
Okay, comitted and checked by Xisco
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1846940
Title:
[upstream] Loop in libreoffice-calc when scrolling to top of
spreadsheet
To manage notifications a
The embedding to TransformPrimitive2D is indeed created by
ViewObjectContact::getPrimitive2DSequence and taking
supportsGridOffsets/getGridOffset into account - what is completely corect and
core element of the change.
What seems wrong OTOH is more that in
ViewObjectContactOfUnoControl_Impl::po
Problem is that ViewObjectContactOfUnoControl_Impl::positionAndZoomControl is
used in two scenarios:
(1) During paint -> GridOffset is already part of ViewTransformation2D
(2) Other (IsVisible, getPrimSeq, ...) -> GridOffset *not* added
while (1) is coming from LazyControlCreationPrimitive2D::get2
Seems to be special stuff with controls - sigh.
When breaking in svx\source\sdr\contact\objectcontactofpageview.cxx:290 in line
pProcessor2D->process(xPrimitiveSequence);
it can be seen that the ViewInformation2D from *this and at the processor is
the same, while later in Laz
In adjustControlGeometry_throw aViewTranslate is sometimes *not* zero,
but has some values. Thi seems to be the reason for the offsets - tried
to hunt down where this comes from, but hard to find - about 25 stack
levels involved...
--
You received this bug notification because you are a member of
Happens when the Control is live (not edit mode) and the mapping is -
due to non-linear ViewMapping in Calc - dependent on pixel sies. In
these cases, ViewObjectContactOfUnoControl_Impl::positionAndZoomControl
is called. That uses adjustControlGeometry_throw where
aTopLeft, aBottomRight change whi
ALG: Adding ORW to CC...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/150937
Title:
[Upstream] Large footnotes not fully displayed when mouse is over the
number
To manage notifications about thi
10 matches
Mail list logo
