aboutsummaryrefslogtreecommitdiff
path: root/source/uz/writerperfect/messages.po
blob: ba1158205e2fdae9a3abf27a15402d8940ebef1c (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169

#. extracted from writerperfect/inc
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: https://bugs.libreoffice.org/enter_bug.cgi?product=LibreOffice&bug_status=UNCONFIRMED&component=UI\n"
"POT-Creation-Date: 2018-05-16 16:54+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Accelerator-Marker: ~\n"
"X-Generator: LibreOffice\n"

#: writerperfect/inc/strings.hrc:15
#, fuzzy
msgctxt "STR_ENCODING_DIALOG_TITLE"
msgid "Import file"
msgstr "import filtri"

#: writerperfect/inc/strings.hrc:16
msgctxt "STR_ENCODING_DIALOG_TITLE_MSMULTIPLAN"
msgid "Import MS Multiplan for DOS file"
msgstr ""

#: writerperfect/inc/strings.hrc:17
msgctxt "STR_ENCODING_DIALOG_TITLE_MSWORKS"
msgid "Import MS Works file"
msgstr ""

#: writerperfect/inc/strings.hrc:18
msgctxt "STR_ENCODING_DIALOG_TITLE_MSWRITE"
msgid "Import MS Write file"
msgstr ""

#: writerperfect/inc/strings.hrc:19
msgctxt "STR_ENCODING_DIALOG_TITLE_DOSWORD"
msgid "Import MS Word for DOS file"
msgstr ""

#: writerperfect/inc/strings.hrc:20
#, fuzzy
msgctxt "STR_ENCODING_DIALOG_TITLE_LOTUS"
msgid "Import Lotus file"
msgstr "Lotus fayllarini import qilish"

#: writerperfect/inc/strings.hrc:21
msgctxt "STR_ENCODING_DIALOG_TITLE_SYMPHONY"
msgid "Import Symphony file"
msgstr ""

#: writerperfect/inc/strings.hrc:22
msgctxt "STR_ENCODING_DIALOG_TITLE_QUATTROPRO"
msgid "Import Quattro Pro file"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:8
msgctxt "exportepub|EpubDialog"
msgid "EPUB Export"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:91
msgctxt "exportepub|generalft"
msgid "General"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:122
#, fuzzy
msgctxt "exportepub|versionft"
msgid "Version:"
msgstr "~Versiyasi:"

#: writerperfect/uiconfig/ui/exportepub.ui:139
msgctxt "exportepub|epub3"
msgid "EPUB 3.0"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:140
msgctxt "exportepub|epub2"
msgid "EPUB 2.0"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:175
msgctxt "exportepub|splitft"
msgid "Split method:"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:192
#, fuzzy
msgctxt "exportepub|splitpage"
msgid "Page break"
msgstr "Sahifa ajratuvchisi"

#: writerperfect/uiconfig/ui/exportepub.ui:193
msgctxt "exportepub|splitheading"
msgid "Heading"
msgstr "Sarlavha"

#: writerperfect/uiconfig/ui/exportepub.ui:228
msgctxt "exportepub|layoutft"
msgid "Layout method:"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:245
msgctxt "exportepub|layoutreflowable"
msgid "Reflowable"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:246
msgctxt "exportepub|layoutfixed"
msgid "Fixed"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:281
msgctxt "exportepub|coverimageft"
msgid "Custom cover image:"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:311
msgctxt "exportepub|coverbutton"
msgid "Browse..."
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:355
msgctxt "exportepub|mediadirft"
msgid "Custom media directory:"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:385
msgctxt "exportepub|mediabutton"
msgid "Browse..."
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:429
msgctxt "exportepub|metadataft"
msgid "Metadata"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:470
msgctxt "exportepub|identifierft"
msgid "Identifier:"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:485
msgctxt "exportepub|titleft"
msgid "Title:"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:511
msgctxt "exportepub|authorft"
msgid "Author:"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:537
msgctxt "exportepub|languageft"
msgid "Language:"
msgstr ""

#: writerperfect/uiconfig/ui/exportepub.ui:563
msgctxt "exportepub|dateft"
msgid "Date:"
msgstr ""

#: writerperfect/uiconfig/ui/wpftencodingdialog.ui:67
#, fuzzy
msgctxt "wpftencodingdialog|label"
msgid "_Character set:"
msgstr "Kodlash usuli"
generated by cgit (git 2.34.1) at 2025-01-15 11:25:15 +0000
alue='libreoffice-5-0-5'>libreoffice-5-0-5 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/include/svx/sdr/contact/viewobjectcontact.hxx
AgeCommit message (Collapse)Author
12 daysDrop unneeded forward declarations from include/Gabor Kelemen
test drive the new bin/find-unneeded-includes --fwdecl mode Change-Id: I507fa2b172ec9e348d1d91066ea241f02187b5ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179321 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-29IASS: Update edited Text in other ViewsArmin Le Grand (allotropia)
This was not working for multiple Windows for a document, and also not supported for SlideShow until now. If you edit a Text on a Slide (Object, PresObj, ...) that text is not yet set at the Model until the TextEdit ends. In that situation those changes are now propagated to other views visualizing that object. This is done with slight slowdown to not do it all the time while typing, (currently 350ms, grepped from other places in the office). It will be shown in a running open SlideShow (and evtl. trigger an effect at the Object as Preview). This will allow to get a good preview for how it looks in the SlideShow. This is also done for further EditViews opened for that Document. This was not done before. It is fine-tuned to do this only for the Views besides the EditView with the running TextEdit to not cause slowdowns in that active view - the TextEdit is already running on the Overlay to have no problems with speed, this needs to be preserved. I had to fix a multi-view error in the a11y stack that implied that only one view exists and thus has to have an Outliner - that is wrong for multiple views, only one will have one. Change-Id: I781d32a8fcb8732ee8fcfbae72c02d1f99b6cd06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164160 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-07-21tdf#154955 svx: PDF/UA export: tag SdrObjGroup properlyMichael Stahl
ISO 14289-1:2014, 7.3 Graphics Graphics that possess semantic value only in combination with other graphics shall be tagged with a single Figure tag for each group. Also produce the missing alt-text. Change-Id: I78e802d8e17a29c2d19fcf3a7ec9961f8f04e391 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154684 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-05-26tdf#155190 svx,sw: PDF export: don't tag SwNoTextFrame as ArtifactMichael Stahl
The problem is that inside of the Figure tag, in SwNoTextFrame::ImplPaintPictureGraphic(), ViewContactOfSwNoTextFrame and ViewObjectContactOfSwNoTextFrame are used to create and process another primitive sequence. ViewObjectContactOfSwNoTextFrame does not have access to a SdrObject, because that was already processed by the outer layer of code that called the SwFlyFrame painting code. Avoid running the code that assumes anything without an SdrObject is an artifact by disabling PDF tags altogether in ViewObjectContactOfSwNoTextFrame. (regression from commit 81ef84648515965bf67afaced946227d0f63a71e) Change-Id: I9fabe7f7e5296f8d850448ac44865f87cd164591 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152335 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-01-12used cache value in ViewObjectContact::getPrimitive2DSequence (2nd attempt)Noel Grandin
Rely on the cached primitives in VOC. But only enable it for calc and draw right now, by adding a flag at the SdrModel level. This way we can leave it disabled for writer, where it definitely doesn't work. Change-Id: I11ca4836eb773c0f078cdb82056c6e0309d15a8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128319 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-24tdf#146132 tdf#146327 tdf#146330Noel Grandin
regression from commit fe6a140a537eda1b6703c44ff5ee49d2ba875b81 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Tue Dec 7 14:55:13 2021 +0200 used cache value in ViewObjectContact::getPrimitive2DSequence Unfortunately various things like scrolling/zooming/moving item to new page do not seem to invalidate the VOC, and I can't track down the right place to do that, so just revert. Change-Id: I8009c99417f634b26adc770b6d6d2eb6969d9629 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127389 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-17Fix typosAndrea Gelmini
Change-Id: I7f1636226c4fbe29d9d2ef850318a9d57f1b5450 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127009 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-12-17fix for crash converting ooo31011-1.sxw and tdf#146132Noel Grandin
./instdir/program/soffice.bin --headless --convert-to odt ./ooo31011-1.sxw regression from commit 681e10eecf67a1a01bdec2cc9b834e0345e25206 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Thu Dec 9 11:12:49 2021 +0200 tdf#146137 tdf#146132 image redrawing It is because we cache high-level primitives, and then during paint, we decompose those high-level primitives, and that triggers layout, which triggers an invalidate i.e. an ActionChanged(), which blows away the cached data we are iterating over. Change-Id: Id18e47b6c2b71a5404f24b075a43d2040a5e3509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126995 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-06Revert "lose the caching in ViewObjectContact" because it breaks...Noel Grandin
bitmap caching. Added some notes for future would-be optimizers. This reverts commit 7f02cb80ac2075b65ee1adee4e29d1d5c4819424. Change-Id: I39c41ea95d23d4a65edd3cef46a5d86fab48a044 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126425 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2021-12-05use visitor in ViewObjectContact::createPrimitive2DSequenceNoel Grandin
to reduce intermediate object creation Change-Id: I03d34d15e88f82027f865868aca08503e38fd6ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126372 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-03lose the caching in ViewObjectContactNoel Grandin
we reload the data every time anyway, so the caching is useless Change-Id: I575cc2fbe5a2fe9f42c58894f471cabb842cdd46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126273 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-03no need to create Primitive2DContainer hereNoel Grandin
we can just use the visitor API and skip a whole bunch of object creation Change-Id: If3dfa2fc1811e708963b8e6ecf4af6508b9f2a23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126216 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-20use Primitive2DDecompositionVisitor in ViewObjectContact (tdf#105575)Noel Grandin
..to avoid container construction Change-Id: Iae7a8ea8c31b6c8bcf4d161273be7b32fe41a021 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120779 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-16do less copying when constructing 2d sequence (tdf#105575)Noel Grandin
instead of constructing a child sequence, and appending that a parent sequence, just pass the parent sequence down the call hierarchy, so we end up doing less copying. Change-Id: If39a0779e543c6aa01f5e2e3ae63d395e0c85f7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120521 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-03tdf#42949 Fix IWYU warnings in include/[t-x]*/*hxxGabor Kelemen
Recheck after 7-0 branchoff Also drop the now unused file include/vcl/field.hxx Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-03use more compact namespace syntax in /includeNoel Grandin
excluding the UDK headers of course Change-Id: Iac7ab83d60265f7d362c860776f1de9d5e444ec0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93268 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-02tdf#128302: Split SVXCORE_DLLPUBLIC from SVX_DLLPUBLICStephan Bergmann
Using SVX_DLLPUBLIC for both Library_svxcore and Library_svx had started to cause failures with clang-cl on Windows now, presumably due to devirtualization: > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::DataChanged(class DataChangedEvent const &)" (?DataChanged@SvxMetricField@@MEAAXAEBVDataChangedEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::PreNotify(class NotifyEvent &)" (?PreNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::EventNotify(class NotifyEvent &)" (?EventNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::Modify(void)" (?Modify@SvxMetricField@@MEAAXXZ) > linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::PreNotify(class NotifyEvent &)" (?PreNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::EventNotify(class NotifyEvent &)" (?EventNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z) > C:\lo-clang\core\instdir\program\svxcorelo.dll : fatal error LNK1120: 6 unresolved externals Replacing certain uses of SVX_DLLPUBLIC with the newly introduced SVXCORE_DLLPUBLIC (include/svx/svxdllapi.h) has been done on Linux as follows: > git grep -w --line-number -e SVX_DLLPUBLIC --and --not -e '#define SVX_DLLPUBLIC' >LINES to produce a file LINES containing all 640 uses. (Conveniently, all uses happen to be on different lines.) Manually create a file TOKENS with 640 corresponding lines, each containing the (class or function) name that is made SVX_DLLPUBLIC by in the corresponding line in LINES. Then > nm -D --def instdir/program/libsvxcorelo.so | grep -ivw '[vw]' | c++filt >SVXCORESYMS > nm -D --def instdir/program/libsvxlo.so | grep -ivw '[vw]' | c++filt >SVXSYMS > n=$(cat TOKENS | wc -l) > for ((i=1;i<="$n";++i)); do > tok=$(head -n "$i" TOKENS | tail -1) > printf @ > grep -Fw "$tok" SVXCORESYMS >/dev/null && printf svxcore > printf @ > grep -Fw "$tok" SVXSYMS >/dev/null && printf svx > printf '@ ' > head -n "$i" LINES | tail -1 > done to generate 640 output lines detailing for each SVX_DLLPUBLIC name occurrene whether it is mentioned in exports from neither (@@@), only from svx (@@svx@), only from svxcore (@svxcore@@), or from both libraries (@svxcore@svx@). The numbers that gives is 10 @@@ 180 @@svx@ 424 @svxcore@@ 26 @svxcore@svx@ The 10 @@@ ask for follow-up clean up, but most of them are just left as SVX_DLLPUBLIC for now. The exceptions are sxv::ITextProvider (include/svx/itextprovider.hxx) and SdrCustomShapeGeometryItem::PropertyPairHash (include/svx/sdasitm.hxx, where PropertyPairHash is a member struct of SVXCORE_DLLPUBLIC SdrCustomShapeGeometryItem). Keeping them as SVX_DLLPUBLIC would cause "unresolved externals" errors when linking Library_svxcore on Windows. The 180 @@svx@ are fine to keep as-is, and the 424 @svxcore@@ need rewriting. The 26 @svxcore@svx@ needed manual inspection to decide (in some cases, the chosen name in TOKENS was a too generic function name like Fill, in other cases it was the name of a class exported from one library but also mentioned in the arguments of a function exported from the other). And for sdr::table::SdrTableObj the class itself is defined in svxcore while the static member functions ExportAsRTF and ImportAsRTF are defined in svx. But MSVC does not allow to mark the class as SVXCORE_DLLPUBLIC and the two static member functions as SVX_DLLPLUBIC, so move the two functions out of the class. (There appears to be no real necessity that they were static member functions in the first place; they don't even need to be friends of the class. Nevertheless, this mixture of functionality from svxcore and svx in include/svx/svdotable.hxx may ask for follow-up clean up, one way or another.) All the output lines that need rewriting (all the @svxcore@@ ones, and the manually picked subset of @@@ and @svxcore@svx@ ones) are copied into a new file CHANGE (containing 451 lines). Then > sed -E -e 's|^@.*@.*@ ([^:]+):([0-9]+):.*$|sed -i -e "\2 s/SVX_DLLPUBLIC/SVXCORE_DLLPUBLIC/" \1|' <CHANGE >COMMANDS > . COMMANDS to do the changes. Change-Id: If9b6dd1c9e9ba2eb883dbdac4385d28c6fc8a203 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87794 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-03tdf#42949 Fix IWYU warnings in include/svx/sdr/*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Iec39b6508a43746c99eddb71f444d921cd8cff1a Reviewed-on: https://gerrit.libreoffice.org/73368 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-11-27Refactor calc non-linear ViewToDevice transformArmin Le Grand
This change solves the non-linear World-To-View trans- formation that calc uses due to it's screen rendering as good as currently possible (AFAIK). Calcv view is layouted on pixel base (due to better homogen distances and full pixel lines between cells), but this leads to having a non-linear transformation between discrete units (pixels, view) and model coordinates (World). In principle, each cell has it's own (so called) ViewTransformation -> the position on screen depends on the mappings of all cells top/left from it. This is obvioulsly non-linear and can sometimes be seen by producing 'offset' errors when many cells (small and thin) are shown in low zoom stages. No better solution for this comes to mind easily. The extremes are - on the one hand AntiAliasing the whole calc edit view and accept 'unsharp/AAed' lines - on the other hand what we have now. Maybe a future solution could find a mapping that gets close to linear mapping for the full view. On the long run this state is hard to keep correct. Even with this extended solution the mapping of SdrObjects spawning mutiple cells is assumed 'linear' in that area - which is in reality currently not the case (!) Note: This is only true for the screen visualization, print and/or PDF export do not do that pixel-based layouting. Note2: This mechanism is general in DrawingLayer (look for '.*GridOffset.*'. If it is deactivated by providing no offsets, the result is the unchanged, linear mapping. First step: Add interfaces to get a possible GridOffset at ViewObjectContact. There it belongs, we have a view- dependent offset per object and view. Add mechanisms to create on-demand and reach back to the view (aka calc's derivation of it). Second step: Implement the on-demand creation, adapt to use it in ViewObjectContact::getPrimitive2DSequence, add stuff to reset on zoom change, disable temporarily old mechanism -> paint already works. Need to adapt the places from old mechanism where the GridOffset was used, but no longer the geometry creations. Third step: Isolated and disabled old mechanism (by already removing SetGridOffset). Marked all places that possibly need change with '//Z' tag. Main work now will be to adapt in the SdrView implementations in svx to know about having a SdrObject-dependent ViewTransformation at all (currently not known, was hard-coded at some places from the old code, ViewTransformation set as MapMode at a target OutputDevice, not member at SdrView at all...). Fourth step: Adapt the Handles and OverlayObjects to use an evtl. existing GridOffset. The mechanism is that the SdrHdl(s) can be seen as 'Model-Objects', these get converted to OverlayObjects in the ::CreateB2dIAObject() implementations, for all SdrMarkView and SdrPageView, so this is the place where the ObjectContact is known (the SdrPageWindow *is* a ObjectContact) and the view- dependent GridOffset can be calculated per SdrObject. I modified OverlayObject to be able to work with a set Offset that embeds the created visualization using this additionally. Handles get now correctly set and have a working HitTest (due to that already using the primitives). Some inter- action stuff already working, some will need more adaption. We simply have no concept for this stuff... Refactored to not get dependencies to SdrObject in ObjectContact. Fifth Step: Make HitTest work by adding the View-And- Object dependent GridOffset in the View when HitTest is triggered. This is in SdrMarkView::CheckSingleSdrObjectHit where pObj->GetCurrentBoundRect() is used that gets the view-independent form. To make HitTest work, add a possible GridOffset. Since this will be necessary more often in SdrView hierarchy, added a tooling method (getPossibleGridOffsetForSdrObject) at that level after checking that at that level will be reachable at all potential spots. Inside that method the correct ObjectContact will be identified and the object-specific offset requested there. Sixth Step: Adaptions and started some cleanups. Still some adaptions needed: - After creation of new object, need to relocate from used GridOffset setting to WorldCoordinates - Interactions, e.g. start with dragging handles or full object/points Seventh Step: React on EndCreateObj. Here, the created SdrObject is in model coordinates and needs to be adapted to evtl. GridOffset. This is 'tricky' due to calculating the possible offset based on new coordinates 'close' to the target position, but may be in the wrong cell. Nonetheless this is the best we can do here. Last (hopefully) missing are now all interaction viszualizations. They already work and are applied correctly, but wrong visualized. Have taken the time to unify adding OverlayObjects for selection visualization to OverlayManager, see handleNewOverlayObject. This does all needed when adding OverlayObjects in one place where the GridOffset can also be handled. It makles things more safe - not possible to forget one of the three steps for others. Eighth Step: Do the same unification for creating the OverlayGeometry, also rename methods to make usage more clear. We now have SdrHdl::insertNewlyCreatedOverlayObjectForSdrHdl SdrDragMethod::insertNewlyCreatedOverlayObjectForSdrDragMethod which can do the needed GridOffset changes centralized. Needed to get a ObjectContact for this at SdrDragMethod, so adapted ::CreateOverlayGeometry implementations accordingly. Missing is now the implementation in insertNewlyCreatedOverlayObjectForSdrDragMethod to add the GridOffset - if used. This has no SdrObject at this time, so we will need a fallback to do the same using a Range (Rectangle). The stuff doing this for SdrObject already has a fallback and is based on using the Rectangle from the SdrObject anyways, so this will be possible. Ninth Step: Cleanup of old stuff (no more //Z), adapted some usages of OverlayObject creations to use getViewIndependentPrimitive2DContainer instead of the view dependent parts so that offset applied to drag-overlays is correct and not already added. Adapted insertNewlyCreatedOverlayObjectForSdrDragMethod to use calculateGridOffsetForB2DRange. Use now that instead of SdrObject-based approach in calc - is more generic. Getting closer, but still not complete - there is an error with dragging the grepped handle somehow - the offset for drag is somehow wrong. Tenth Step: Corrected that offset error. Of course at interaction start and progress (move) the coordinates are in GrifOffset coordinates and need to be corrected to Model coordinates. Done that at ::BegDragObj and ::MovDragObj, works well. Of course there are exceptions for the crop-handles, so needed to add setting the correct parameters at SdrHdl when these got created, then all works as expected. The strategy is to *not* change the model data itself in any way, instead do all changes/adaptions in the view-only code. This has minimal impact and is needed due to having a 1:n relationship between model and views anyways. There are two directions: All visualizations are adapted to take the GridOffset into account (SdrObjects, overlay, handles, InteractionObjects, ...). In the other direction input like MousePosition is in principle in calc EditView in 'GridOffset'-coordinates and needs to be mapped back before usage. Change-Id: I2ecdd409def96a7248a26a65a22e59eb962880a0 Reviewed-on: https://gerrit.libreoffice.org/64057 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-02-05loplugin:useuniqueptr in ViewObjectContactNoel Grandin
Change-Id: I69721e71f5351276d43d04107058eeb14d4925aa Reviewed-on: https://gerrit.libreoffice.org/49213 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-30rename getViewIndependentPrimitive2DSequence..Noel Grandin
to getViewIndependentPrimitive2DContainer to match it's new return type Change-Id: I767bdef45316e355d49f6509ca1b50138a45b3fa
2016-09-13Remove nonsense comments: // bitfieldTor Lillqvist
Surely the actual bitfield syntax is enough to tell the code reader that it is a bitfield. Change-Id: Ic9552e01b19c8b34b2a17db56b9ff63e7c7de926
2016-07-27improve passstuffbyref return analysisNoel Grandin
Change-Id: I4258bcc97273d8bb7a8c4879fac02a427f76e18c Reviewed-on: https://gerrit.libreoffice.org/27317 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2016-02-09Remove excess newlinesChris Sherlock
A ridiculously fast way of doing this is: for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \ --exclude-dir=workdir --exclude-dir=instdir '^ {3,}' .) do perl -0777 -i -pe 's/^ {3,}/ /gm' $i done Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c Reviewed-on: https://gerrit.libreoffice.org/22224 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
2015-12-11tdf#69977: uno::Sequence is expensiveNoel Grandin
when used as a mutable data-structure. Plain std::vector halves the time taken to display the chart dialog Create a class to represent the std::vector we are going to be passing around, and move some of the utility methods into it to make the code prettier. Also create an optimised append(&&) method for the common case of appending small temporaries. Change-Id: I7f5b43fb4a8a84e40e6a52fcb7e9f974091b4485
2015-11-10loplugin:nullptr (automatic rewrite)Stephan Bergmann
Change-Id: I71682f28c6a54d33da6b0c971f34d0a705ff04f5
2015-09-30Fix typosAndrea Gelmini
Change-Id: If877778a98d8f06f6f596b4c186d9c4cf5c33438 Reviewed-on: https://gerrit.libreoffice.org/18957 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2015-07-16loplugin:unusedmethods svxNoel Grandin
Change-Id: I92158457b3ffaaf7c84c6f4c87708d766c8c9f61 Reviewed-on: https://gerrit.libreoffice.org/17117 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>