789a737ac9
There are some CrashReports in 7.6 which have
DeleteItemOnIdle on the stack, but there is nothing
reproducable. So I took a look...
I first thought it's a MCGR regression, due to classes
on the stack. But the Item involved is just random, can
happen with any Item.
Then I thought it may have to do with ITEM refactorings,
but it happens with DeleteItemOnIdle involved, so also
not the case. I already saw DeleteItemOnIdle when doing
these and qualified as 'hack' in the way. already
It is only on Windows and DeleteItemOnIdle is involved.
This again (took a deeper look now) is an old hack to
keep an SfxPoolItem 'alive' for some 'time'. For that,
it triggers an async reschedule which then deletes the
Item when being called. If the Item will be used after
that is pure coincidence - seems to work in most cases.
It seems as if for Windows the timing slightly changed
for some scenarios, so a reschedule is too early. This
can happen with this hack anytime.
DeleteItemOnIdle is used in scenarios where SfxPoolItem*
is e.g. returned, but is *not* anchored, so e.g. not
member of an SfxItemSet. Or in short: Lifetime is not
safe.
DeleteItemOnIdle exists since 1st import, but was
changed to AsyncEvent ca. 4 months ago (see
|
||
---|---|---|
.. | ||
doc | ||
inc | ||
qa | ||
sdi | ||
source | ||
uiconfig/ui | ||
util | ||
AllLangMoTarget_svx.mk | ||
CppunitTest_svx_core.mk | ||
CppunitTest_svx_dialogs_test.mk | ||
CppunitTest_svx_gallery_test.mk | ||
CppunitTest_svx_removewhichrange.mk | ||
CppunitTest_svx_unit.mk | ||
Executable_gengal.mk | ||
IwyuFilter_svx.yaml | ||
JunitTest_svx_unoapi.mk | ||
Library_svx.mk | ||
Library_svxcore.mk | ||
Library_textconversiondlgs.mk | ||
Makefile | ||
Module_svx.mk | ||
Package_gengal.mk | ||
README.md | ||
UIConfig_svx.mk | ||
UITest_svx_table.mk |
Graphics Related Helper Code
Contains graphics related helper code. Lots of the draw and impress code is in this shared library.
-
xoutdev
this is where a lot of wht work would happen to move to the canvas. (what does that mean?)
-
svdraw
transparent gradient stuff. [seriously? surely much more, too]
SdrObject
The shapes you can see in LibreOffice (like rectangle, etc.) are SdrObjects. They are declared as a hierarchy:
SdrObject <- SdrAttrObj <- E3dObject <- E3dCompoundObject <- E3dCubeObj
^ ^ ^ ^ ^ | | ^ ^
| | | | | | | | +--- E3dExtrudeObj
| | | | | | | +----- E3dLatheObj
| | | | | | +------- E3dPolygonObj
| | | | | +--------- E3dSphereObj
| | | | +--- E3dScene...
| | | |
| | | +--- SdrTextObj <- SdrObjCustomShape...
| | | ^ ^ ^ ^ ^
| | | | | | | +--- SdrEdgeObj...
| | | | | | +----- SdrMeasureObj...
| | | | | +------- SdrPathObj...
| | | | +--------- SdrRectObj...
| | | +----------- SdrTableObj...
| | +--- SdrObjGroup...
| + ---- SdrPageObj...
+------- SdrVirtObj...
The above is incomplete of course.
SdrModel / SdrView
Copied from svdview.hxx
:
First of all the app creates a SdrModel
.
Then it opens a Win and creates a SdrView
.
ShowSdrPage()
announces a page at SdrView
.
It's possible to show SdrView
in any Wins at once.
SdrView
can show as many Wins as it wants at once. Pages are announced
or checked out with the help of ShowSdrPage()
/HideSdrPage()
. For every announced
page there is a SdrPageView
instance in container aPages. If more than one page
is showed, you have to pay attention that the offset parameter of ShowSdrPage()
is conformed to the size of the page (to prevent overlapping of two pages).
SdrView
itself is inherited from many objects in a chain of inheritance (all
that starts with SdrPaintView
- that is itself inherited from few classes
too):
SdrPaintView <- SdrSnapView <- SdrMarkView <- SdrEditView <- SdrPolyEditView
^
+----------------------------------------------------------------+
|
SdrGlueEditView <- SdrObjEditView <- SdrExchangeView <- SdrDragView
^
+----------------------------------------------------------------+
|
SdrCreateView <- SdrView
From SdrView
on, it is not flat, but a real hierarchy again.
Drawing Layer / SdrObject(s)
See drawinglayer/README.md
for general information about drawinglayer.
Below is the class diagram that comes from https://web.archive.org/web/20160827020830if_/http://www.openoffice.org:80/marketing/ooocon2006/presentations/wednesday_g11.odp slide number 6.
.------- Model --------------. .------- View -----------------------------------------.
| SdrObject - ViewContact | 1..* | ViewObjectContact |
| getChild() |------| getPrimitiveList() -----> Object(s) ---> SdrView |
| getVOC() | | getRecPrimitiveList() Contact |
| getViewInd... | |________|_____________________________________________|
| ...ependentPrimitiveList() | |
|____________________________| generates
| ______
V / |
.----------------------. |
| basePrimitive | |
| getRange() |<---'
| getDecomposition() |
|______________________|
For SdrObjects
, there are own DrawingLayer
primitives in
svx/source/sdr/primitive2d
The ViewContact
/ ViewObject
/ ViewObjectContact
are in svx/source/sdr/contact
Decomposes the SdrObjects
, and does all sort of operations on them.
If the number of visualizable objects (e.g. SdrObjects
) is X
, and the number of
SdrViews
is Y
, then:
- there are
X
ViewContact
instances (1:1 relation with a visualizable object) - there are
Y
ObjectContact
instances (1:1 relation with anSdrView
) - there are
X*Y
ViewObjectContact
instances (1:N relation to both visualizable objects andSdrView
s)