Now, whatever the size of toolbar icons, the toolbar
context menu always shows small icons.
Change-Id: Id17df15278d74ae75a3e82d54ecf7af310e0ceb4
Reviewed-on: https://gerrit.libreoffice.org/16361
Reviewed-by: Philippe Jung <phil.jung@free.fr>
Tested-by: Philippe Jung <phil.jung@free.fr>
Idea originally from caolan.
Found using the following command:
find . -name *.cxx | xargs /opt/local/bin/grep -zlP '(?m)if\s*\(\s*\w+\s*\)\s*delete\s+\w+\;'
Change-Id: I3338f4e22193a6dfd6219c8c75835224a3392763
This should eventually enable more certainty that they are still
live by the time we emit the event later.
Change-Id: I7c9eb4c000753d4efe8c59a9e13ef3e11c93b2fa
Redrawing is done in-place at some places and not in Paint()
chain. This was refactored to delegate such places to
invalidateX method, so it can be changed later.
Refactored some static functions to methods, when that made sense.
Change-Id: Ibdf4211857f4911b48b61edd2ecc846a6e94c864
since
commit b8f2129828
Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Date: Mon Mar 2 20:57:32 2015 +0900
the color bar is always drawn under the icon and doesn't
get drawn to the right and fill all the empty space of
the tool item, e.g. in impress see the new toolbar color
selector
Change-Id: Ib70fec9c933b9d743e67475899938a5d9f405496
and fix bug in svx/source/xoutdev/_xoutbmp.cxx,XOutBitmap::MirrorGraphic
where it was not correctly translating between different flags types.
Change-Id: I78b4965544da2aa54b67ec18307fa54c8ffc3aee
Turn the Link class into a template abstracting over the link's argument and
return types, but provide default template arguments that keep the generic,
unsafe "void* in, sal_IntPtr out" behvior. That way, individual uses of the
Link class can be updated over time.
All the related macros are duplicated with ..._TYPED counterparts, that
additionally take the RetType (except for LINK_TYPED, which manages to infer the
relevant types from the supplied Member).
(It would have been attractive to change the "untyped" LinkStubs from taking a
void* to a properly typed ArgType parameter, too, but that would cause
-fsanitize=function to flag uses of "untyped" Link::Call.)
Change-Id: I3b0140378bad99abbf240140ebb4a46a05d2d2f8
In toolbox the images are scaled for HiDPI, which causes various
problems. This change preserves the original image and uses that
when adding images into the menu and also uses that when updating
the color related toolbox-es.
Change-Id: Ib7e7d82ccb1cd774e0e14dd6bab5626eaefea097
We need to adapt the accessibility code to handle VCLEVENT_TOOLBOX_ITEMUPDATED,
since it is now sent from vcl/source/window/toolbox2.cxx.
I have tested the patch successfully on Windows and Fedora.
Change-Id: Ia4328d3c34547cc28ce9a3946f90223442ee84e3
Reviewed-on: https://gerrit.libreoffice.org/14190
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
This cleanups up indentation and removes dead classes.
This is a followup patch to commit
272b1dd55797aacf511fb4342b0054e3697243f6
"new loplugin: change virtual methods to non-virtual"
Change-Id: I1c2139589cf8cb23bb9808defe22c51039d38de1
Where we can prove that the virtual method is never overriden.
In the case of pure-virtual methods, we remove the method entirely.
Sometimes this leads to entire methods and fields being
eliminated.
Change-Id: I138ef81c95f115dbd8c023a83cfc7e9d5d6d14ae
...not allowing certain o3tl::is_typed_flags::Wrap conversion operators to be
explicit, thus causing ambiguities here.
Change-Id: I5108885229eb185ceac57042e67405b393cdcf3b
We reuse the toolbox overflow menu for toolbarmanager's context
menu -- toolbarmanger previously added its menu listener to the
toolboxes menu permanently, meaning that it would try to handle
overflow menu items (in addition to the context menu items which
it should handle), instead we should only add the listener when
we are actually using the menu as a context menu.
Perhaps it would be better in the long run to actually use fully separate
menus instead, and ask toolbox to specifically add its items to that
rather than trying to hack the context menu on top of the overflow menu?
Change-Id: Iecface2c6eae9ab79dbcdb25ffdbaf446e2885ea
A simplified version of the semantic match that finds this problem is
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r1@
statement S;
position p,p1;
@@
S@p1;@p
@script:python r2@
p << r1.p;
p1 << r1.p1;
@@
if p[0].line != p1[0].line_end:
cocci.include_match(False)
@@
position r1.p;
@@
-;@p
// </smpl>
Change-Id: Ib9708d37fbb4c6060f88d5dae3814a2d37b2091e
Reviewed-on: https://gerrit.libreoffice.org/9493
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
...so declare them as such. This avoids the recurring mistake of storing such
IDs as sal_uInt32, truncating in 64 bit environments, causing RemoveUserEvent to
potentially not remove the event, it thus firing "too late" and probably causing
a crash.
While at it, consolidate the trivially unnecessary overloads of both
Application::PostUserEvent and Window::PostUserEvent. And in each of them, it
looks like deleting the mpLink member was missing from the failure branch.
Change-Id: Iab13afbb06e12ac15dec6a6b5b85a7e402a3c654
Previously the overflow/context menu should have had a separator shown
between the overflow items and the hidden items, however these were
inadvertently removed by ImplClearPopupMenu which filters the items
before the menu is displayed.
The previous ordering of items was also the REVERSE of the ordering in
the toolbar -- the overflow menu is a logical extension of the toolbar
hence items should be in the same order as they were in the toolbar.
Change-Id: I8444f4814fea64be1d8f8790445ad6aa01532e70
