office-gobmx/svx
Tomaž Vajngerl 36b17f0307 devtools: handle the doc. model tree with attached obects
Instead of filling the document model tree with fill* methods,
refactor that to use objects that are attached (via get_id) to the
tree nodes directly. For this introduce DocumentModelTreeEntry
and subclasses, which implement what the current UNO object is
that is being shown for a tree node and a "fill" virtual method,
which is used to fill the child nodes of the tree when expanding
a tree node.

This makes the code much easier to work with and in addition it
makes it possible to have all the tree nodes to fill the content
on demand when expanded.

Change-Id: Id5a027e060af90e483181439568f17d0172d1b35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109500
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-01-18 07:09:18 +01:00
..
doc
inc remove sdrgrafprimitive2d.{cxx,hxx} from excludelist 2021-01-09 01:09:30 +01:00
qa fix coverity parse errors 2021-01-10 21:01:05 +01:00
sdi Bring uno:RefreshView to Calc 2021-01-18 03:53:50 +01:00
source devtools: handle the doc. model tree with attached obects 2021-01-18 07:09:18 +01:00
uiconfig/ui devtools: handle the doc. model tree with attached obects 2021-01-18 07:09:18 +01:00
util Revert "Very early work-in-progress commit for the "DevTools" dockable toolbar" 2021-01-09 12:07:04 +09:00
AllLangMoTarget_svx.mk
CppunitTest_svx_dialogs_test.mk
CppunitTest_svx_gallery_test.mk
CppunitTest_svx_unit.mk
Executable_gengal.mk Don't lock galleries build into DESKTOP 2020-12-23 01:52:11 +01:00
IwyuFilter_svx.yaml
JunitTest_svx_unoapi.mk
Library_svx.mk devtools: separate DocumentModelTreeHandler into its own file(s) 2021-01-18 03:35:35 +01:00
Library_svxcore.mk
Library_textconversiondlgs.mk
Makefile
Module_svx.mk Don't lock galleries build into DESKTOP 2020-12-23 01:52:11 +01:00
Package_gengal.mk
README
UIConfig_svx.mk devtools: Implement development tools docking window 2021-01-09 04:01:39 +01:00
UITest_svx_table.mk

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 for general information about drawinglayer.

Below is the class diagram that comes from
http://www.openoffice.org/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 an SdrView)
- there are X*Y ViewObjecContact instances (1:N relation to both
  visualizable objects and SdrViews)