Hi all,It's nice to see how fast this is going :)I don't understand much of the code, but LO uses
those bitmaps and takes the areas which contain the actual icon, right? Wouldn't it be much more
convenient to use single (SVG) images instead, or at least a vector-based set of handles?Thanks for
your effortAlex ---- On Mon, 31 Oct 2011 18:54:35 +0100 Michael Meeks
<michael.meeks@suse.com> wrote ---- Hi there, Last split out mail: On Mon, 2011-10-31 at
15:28 +0100, Astron wrote: > Lastly, there's the anchor image from Writer that is also in dire
need > of replacement. Oooh ! that could be pretty indeed :-) > What would be great: >
* to know the location of these images in the git repository (sorry, I > really tried finding
them, but there are too many icons) Not certain, but I tried: cd sw/ ; git grep ANCHOR
sw/source/ui/utlui/initui.src: BITMAP BMP_FRAME_ANCHOR { FILE = "anchor.bmp" ; };
sw/source/ui/utlui/initui.src: BITMAP BMP_FRAME_DRAG_ANCHOR { FILE = "danchor.bmp" ; }; Which
looks promising, but in fact both of these images are 'missing icon' icons ;-) I'll add an easy
hack to remove them & associated cruft when I can. In fact the anchors are in the images
attached - which have never been themed nicely (AFAIK). The second set have been 'improved' a bit,
but its unclear if we use them. It took me about an hour to find the code (finally from sc/) - the
handle object is a: svx/source/svdraw/svdhdl.cxx and we create in sc/ with: rHdl.AddHdl(new
SdrHdl(aPos, bNegativePage ? HDL_ANCHOR_TR : HDL_ANCHOR)); In -theory- we switch between these
two different images of anchor at the cursor blink frequency: // #98388# when anchor is used take
upper left as reference point inside the handle pRetval = new
::sdr::overlay::OverlayAnimatedBitmapEx(rPos, aBmpEx1, aBmpEx2, nBlinkTime); But I've
(personally) never noticed that - perhaps this is because the images are so similar ? or possibly
it is just broken - possibly OverlayAnimatedBitmapEx is having a bad year. > * to know what's
possible with these images – most importantly: alpha > transparency? So - it -looks- as if
all that good stuff is possible. It is entirely possible / probable that we should rip those anchor
icons out of their sets and enlarge / prettify / alpha-blend them. It'd be great if you could
experiment with using alpha / improving the look of those in your LibreOffice images*.zip ? > *
if someone could remove the additional UI/code > * if someone would make them themeable (if they
aren't > already/strictly optional) So - they are already themable, but (I guess) no-one
ever knew how to. There is also a theme-inside-a-theme of the sal_Bool
bIsFineHdl(pHdlList->IsFineHdl()); that switches between the two sets; from 'SetFineHdl'
only called from: void SdrMarkView::SetSolidMarkHdl(sal_Bool bOn) Which seems to be tied to
the 'SimpleHandles' config setting, and I guess the other images in that bitmap are in fact the
handles we use to edit line shapes etc. The question is - do we really want the "simple handles"
mode / configuration option anymore ? it seems redundant to me and the handles look even less
pretty. Thanks for caring about this detail ! ATB, Michael. --
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Context
- Re: [Libreoffice-ux-advise] [Libreoffice] Suggestions for improving the look 'n' feel of LibreOffice (continued)
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.