path: root/vcl/source/window
AgeCommit message (Collapse)AuthorFilesLines
2015-09-15tdf#94213 - calc re-size flicker turns out to be the status bar.Michael Meeks2-1/+15
Using vdev's associated with old contexts, is un-necessary and a recipe for context switching & hence flicker. Change-Id: I37ed967a7816e5ca0240908ab4793ce1e68570ee Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Michael Meeks <>
2015-09-15convert Link<> to typedNoel Grandin2-6/+6
Change-Id: I5c4021c9cb3fdeace7f7d99d580dc7fe2f7c354a
2015-09-15remove Link<> field that is never Call()'edNoel Grandin1-9/+0
Change-Id: I416734c7c42709438e3bdcdb8922ce4ec576c95a
2015-09-14tdf#94213 - defer glFlushing until we've re-rendered after a re-size.Michael Meeks1-0/+8
Avoids a rather horrible flickering problem in GL mode. Change-Id: Id205f28de209dc2e4fb6d6fa48b86ee5bd38835d
2015-09-14convert Link<> to typedNoel Grandin2-11/+8
Change-Id: I1c501671d72edd5b998e80c7fa1e91dbeb507af8
2015-09-14ImplCallEventListeners and FireVclEvent can take referencesNoel Grandin2-4/+4
Change-Id: Ibfb5ae40edd0db1f6b99bd5178d4d871ede37d7d
2015-09-11vcl: tdf#88206 replace cppu::WeakImplHelper* etc.Takeshi Abe1-1/+1
with the variadic variants. Change-Id: I4499569f73b04cc7444787d51bf804c090a5c951 Reviewed-on: Reviewed-by: Michael Stahl <> Tested-by: Michael Stahl <>
2015-09-11tdf#93480: Don't send an EMPTY Invalidate() on .uno:DefaultBullet.Jan Holesovsky1-2/+0
When there was no modification to the document, and .uno:DefaultBullet was sent, we have got an invalidtion of the entire document. It seems that Invalidate() was not supposed to be called in the Validate() call, and instead, we should rely on what the Validate() invalidates :-) Change-Id: Ia65df90e4ff34078b59c1b2eb1ce1faac790b40d
2015-09-11convert Link<> to typedNoel Grandin2-19/+16
and remove unused maChildEventListeners Change-Id: I845a9af608c3429cf9ccb0e8041f24f423839513
2015-09-10convert Link<> to typedNoel Grandin1-8/+12
Change-Id: I603463d0486d4d0f21ebbdc6eca900db58bb090f
2015-09-10remove unused Link<> fieldNoel Grandin1-7/+2
Change-Id: I121f133513a9897f38bd87be96c2cea39fbfc836
2015-09-09convert Link<> to typedNoel Grandin3-7/+3
Change-Id: I3127752785b77672d37f99bc9eaa881377dabe7c Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Noel Grandin <>
2015-09-09remove unused Link<> fieldsNoel Grandin2-16/+0
Change-Id: Ifed1a8cfa774225cb450bb211b1b1b949ef02811 Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Noel Grandin <>
2015-09-09convert Link<> to typedNoel Grandin3-25/+9
Change-Id: I2f36a123662488ef5534f7bf0845d61e497fb0ec
2015-09-08tdf#94006 - need an explicit dispose for GLContext's SystemChildWindow.Michael Meeks1-1/+7
Previously we would get an explicit ~OpenGLContext - and potentially leave FMR's around for other OGC users, now we treat the other users properly - we need an explicit dispose() to get Window::dispose ordering right. Change-Id: I5edcbd73399b6db3dbcfb391570f364f9ab0c70d Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Markus Mohrhard <>
2015-09-08tdf#94006 - fix OpenGLContext mis-use in several places.Michael Meeks1-3/+4
gltf rendering, OpenGL canvas, GL transitions & GL capable (charts) Avoid GLX operations on un-initialized contexts. Change-Id: I7f523640f66ab656896181e5c865879234f6640e
2015-09-06Related: tdf#84277 Hide separator only between two windowsMaxim Monastirsky1-35/+36
Change-Id: I3176933d20dce9f595fd6a9c0ee434a3709fa560
2015-09-04Related: tdf#92982 vcl rendercontext: optimize non-buffered paint of CursorMiklos Vajna1-5/+11
Change-Id: Ic8065d4f656d42f1e2e7d8b4c602010fa0ae2d34
2015-09-04convert Link<> to typedNoel Grandin1-6/+4
Change-Id: I2136c3db2742afcb4722f69297276bea1e0119f4 Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Noel Grandin <>
2015-09-03clang-tidy clang-analyzer-deadcode.DeadStoresStephan Bergmann1-2/+0
...the two consecutive writes to nX had been like that ever since the code block's inception in 4716735ba7d0ad133ff018481f94d6b4f201bbd9 "#103362# improve positioning and resizing of system windows," so assume the first one is indeed unnecessary. Change-Id: I52a9a8a15fa38a0d14f9e521e15b7f71013f46c0
2015-09-03clang-tidy clang-analyzer-deadcode.DeadStoresStephan Bergmann1-1/+0 least since the commented-out code using it got removed with 99f58dc2a6d9d2976948b2fe01b1ed1ae63d685e "vcl: remove dead code and useless task comments from winproc.cxx" Change-Id: Idddd3af6d667370cb937aa065382c1913ab8e911
2015-09-03convert Link<> to typedNoel Grandin1-5/+0
Change-Id: I8bea5ac685b0076649412bd95501461242797d77 Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Noel Grandin <>
2015-09-02SetXXX(bool) with a default value of false are just wrongNoel Grandin2-2/+2
Change-Id: I4888d0474199bb10ca81d1ad03118a150f574671 Reviewed-on: Reviewed-by: Noel Grandin <> Tested-by: Noel Grandin <>
2015-08-31Extended GL painting debug tracing.Michael Meeks1-0/+8
Change-Id: I52158729d240ca3cb9e7977bc6d1f5acb14437ad
2015-08-31loplugin:stringconstant: OUStringBuffer: appendAscii -> appendStephan Bergmann2-2/+2
Change-Id: I69c2c27af718b1d3ff35348a69d8b57914e5ae82
2015-08-29tdf#93536 - avoid crash when calling ToTop on disposed window.Michael Meeks1-0/+2
Change-Id: I677f47f6b60271dc56c9d3d123cf982c00866eb9
2015-08-28make PostUserEvent Link<> typedNoel Grandin9-34/+19
Change-Id: I13f10bda985d55d419a5bff481130a456ae2db8a
2015-08-27No need for a vitual ~MenuWindowStephan Bergmann1-3/+1 least while MenuWindow is mostly a TODO still; and ImplHanldeHelpEvent can be protected Change-Id: Ice0bb37e7e774e51445a9d78b2cf5eaba12f6341
2015-08-27No need for IMenuBarWindow abstractionStephan Bergmann3-63/+33
Change-Id: I5be4cfb951100d36054e409043cb9becbe52338d
2015-08-27Help GCCStephan Bergmann1-1/+1
Change-Id: Ibeace7ce7621033cf04e3186c212bbb4a27492a1
2015-08-27Simplify ToolBox::GetQuickHelpTextStephan Bergmann1-4/+2
Change-Id: I2801f54cecf9c8b7d43f8e1c1699cfd7fdd918e3
2015-08-26Remove unused AddMenuBarButton parameterStephan Bergmann4-7/+5
...which had apparently been unused ever since the function's introduction in 86ef4422bc62f912f72c0bedda47ce0e6e2722e4 "INTEGRATION: CWS onlineupdate3," even though the function's code had always been careful to clip the value to m_aAddButtons.size() (which was now detected by clang-tidy's clang-analyzer-deadcode.DeadStores) Change-Id: Ic3542aaef04d059125d997cdc5e199d5edb1184a
2015-08-26Convert vcl Button Link<> click handler to typed Link<Button*,void>Noel Grandin5-24/+28
Change-Id: Ie80dfb003118d40741549c41ebcc7eda4819f05b
2015-08-26Bin the fairly useless DbgDialog stuff and handle falloutTor Lillqvist3-50/+0
See (short) discussion on the mailing list, "How was it again, is the DbgDialog useful?". Change-Id: Ibde1eb13f16edf94f1f7aebd0befd1b0b171d5c4
2015-08-23tdf#84277 Use the same logic for native separatorsMaxim Monastirsky1-18/+17
If in some cases we don't want a visible separator, I can't understand why it shouldn't apply also to platforms that support native separator drawing. Change-Id: Ib88bece62cfbb092808f3257a7ba9bd63f4cb1d7
2015-08-19for testing allow disabling configmgr for time critical pathsCaolán McNamara1-17/+35
Change-Id: I83396e7c90d3b182f353a77c9bdf06fd17af92a1
2015-08-17tdf#93482 vcl rendercontext: add Window::RequestDoubleBuffering()Miklos Vajna1-1/+13
This allows applications to request enabling/disabling of double-buffering of their VCL frame and all its children. It works after-the-fact, too: so in case the start center creates the frame and later that frame is reused for Writer, then Writer can turn on double-buffering, still. From a user's point of view, this means that next to VCL_DOUBLEBUFFERING_FORCE_ENABLE, there is now also a VCL_DOUBLEBUFFERING_ENABLE environment variable that enables a safe subset that is not supposed to draw directly at all. Enable this for Writer only, for now. Change-Id: Ie2cbf7d467eae2cee37fb58a1efc0a8984204408
2015-08-17tdf#93482 vcl rendercontext: introduce WindowImpl::mbDoubleBufferingRequestedMiklos Vajna1-3/+3
The intention is that currently double-buffering is either enabled globally or not. Double-buffering is known to be working in Writer, but not in other applications, so it would be nice if double-buffering could be also half-enabled: only in the applications where it's known to work. For that, we need to differentiate between "we have a buffer" (supports double buffering) and "we want to have a buffer if possible" (double buffering requested). Change-Id: If48d6dc0ddf5841497e78b856d803cc8abf23ac9
2015-08-17Put Polygon from tools under tools:: namespaceNorbert Thiebaud6-10/+10
Polygon is one of these names that Clash with some system objects A similar work has been done earlier with PolyPolygon. Change-Id: Icf2217cb2906292b7275760f1a16be0e150312f5 Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Norbert Thiebaud <>
2015-08-11tdf#93364 vcl rendercontext: fix area that is painted in PaintBuffer()Miklos Vajna1-1/+4
Usually the topmost window of a paint hierarchy has a paint rectangle that covers the paint rectangle of all its children, but this is not necessarly true in every case. One example is the cursor travelling described in the bug report, where the topmost DockingAreaWindow only paints a few buttons on the toolbar, and then even if children are painted correctly to the frame-level persistent buffer, only the DockingAreaWindow part of the buffer is copied to the screen. Fix this by building an union rectangle that covers all areas in a buffered paint run, and then paint that rectangle from the buffer, not just the paint rectangle of the topmost parent. Change-Id: Ib0b30413d83c4b3fdec27fa7ddad16c21fd094b6
2015-08-11loplugin: defaultparamsNoel Grandin18-42/+41
Change-Id: I79a889c68e91712d2abdacc559c78813f730e623
2015-08-07Resolves: tdf#92982 vcl rendercontext: handle buffered paint of vcl::CursorMiklos Vajna2-1/+16
Instead of painting on the vcl::Window directly, take a PaintBufferGuard, and use the vcl::RenderContext of it, that may be either the vcl::Window or the toplevel frame's buffer. Trigger the paint of the buffer by informing the guard what area was painted. In case of direct painting, both the ctor and the dtor of the guard is a NOP. This means that finally we can also assert Invert() calls on the output device, so that direct paint can't happen when double-buffering. Change-Id: I0322563369dc63b3c49061cbe7c4a911cb13a2e2
2015-08-07tdf#92982 vcl rendercontext: move buffer paint logic to PaintBufferGuardMiklos Vajna1-22/+39
The motivation is that this way vcl::Cursor will be able to reuse it. Change-Id: I7e89d5acb5d63d3297d7c3c8050ccd2172c8608d
2015-08-07tdf#92982 vcl rendercontext: make PaintBufferGuard visible outside paint.cxxMiklos Vajna1-80/+72
Change-Id: I4bafba3d99fc45d6d5fa875a91d498518d3a0c29
2015-08-06tdf#92982 vcl rendercontext: fix missing background repaint of EditMiklos Vajna1-12/+0
Change-Id: Ic45f65d10835eb39b6709e7adeed1392905ea631
2015-08-05tdf#92982 vcl rendercontext: fix buffer size with empty user profileMiklos Vajna1-0/+4
I did not notice this before, as my user profile had a custom window size; but with an empty user profile the buffer had a 0,0 size, so the buffered result was empty, as no ImplHandleResize() was invoked. Change-Id: Ie299ad1323944941afc407dc90f2459d72885d42
2015-08-04tdf#92982 vcl rendercontext: no need to tweak map mode in PaintBuffer()Miklos Vajna1-10/+0
This used to be necessary, but now that the "copy settings from the window to the buffer" is always guarded with PaintBufferGuard, it's actually one of the places that do modify the buffer settings without undoing that later. Change-Id: I7fde878635ffc7de7027d6d8f8de47935fc4870e
2015-08-04tdf#92982 vcl rendercontext: let PaintBufferGuard also manage pixel offsetMiklos Vajna1-23/+21
Change-Id: Ifd6a75c4312f93c815f5d137f515724f3629fa0d
2015-08-04tdf#92982 vcl rendercontext: PaintHelper: restore set buffer propertiesMiklos Vajna1-33/+71
If the buffer is persistent, then any member we change on it, so it suit our needs have to be undone once we're done with the painting. Change-Id: I7c5491b3b27601fb367af0856ac95cc3f845647a
2015-08-04tdf#92982 vcl rendercontext: set correct offset for the frame-level bufferMiklos Vajna1-20/+14
In case we had a toplevel window W1, the paint was triggered for window W2 and we had a sub-widget W3, then previously the buffer was created for W2, so the pixel offsets had to be set relative to W2 when rendering W3. As a consequence, if a single window was painted, then it was always painted in the top left corner. Now that the buffer is persistent and is always created for W1, make sure that we paint to the correct offset, and W3 is always painted at the same offset, regardless if it was painted directly, or just because it's a child of W2. With this, the buffer conents is closer to what is on the screen, even if it's not perfect yet. Change-Id: Ibf0e89ad18e5763bd2a01e69d91da163c24a309d