Hi Rodolfo,
On Wed, 2013-04-10 at 18:28 -0300, Rodolfo wrote:
I'm ok with that. If we can count how many duplicate images (for UNO
commands) does exist, we could know it is pointless or not.
Previously we just ran:
find -name '*.png' | xargs md5sum | sort | uniq -c | sort -n
Which gives that reasonably easily. At one stage I tried to keep a list
of duplicates in:
icon-themes/industrial/duplicates
I spent (wasted) a lot of my life digging through a much dirtier icon
tree in the deep past here ;-) so I'd love to see it cleaner.
In general short filenames have some benefits - they are duplicated
twice un-compressed in each .zip file - in the directory and also in the
zip pre-amble to each file.
Of course, some of our names are quite long anyway; it would be nice to
know what the freedesktop ones are like (I forget) are they reasonably
terse - if so, there is no problem adopting those.
Indeed - if there is a standard, we could (arguably) move them to the
top-level, and re-use them in various places via the textual symlinks -
and thus save space overall [ without the cmd/ ;-].
In particular, we can't rename UNO commands without breaking backwards
compatibility - so IMHO the only really useful approach here is to have
a mapping.
Hm... I didn't mean to renaming UNO commands, I just said that how it
is implemented leads to some duplicates.
Sure; currently though the UNO command maps -> cmd/lc_filename so - we
need the mapping before we can rename the icons - assuming we can't
change the UNO commands :-)
What about other icons, then ?
Anything outside cmd/ can be renamed without breaking anything as far
as I'm aware - particularly if the icon is just referenced in a .src
file - there is no reason not to do some nice renaming / cleanup. It
would also make sense in parallel to see if the icon we include in
the .src file is actually used anywhere in the code at all ;-) [ my
suspicion is that we still have a number of malingering un-used pieces
of artwork there we could well do without ;-] - it's a worthwhile
cleanup.
That's a way to go. Simple to implement and simple for an
artist/designer/"themer" to do it also.
Neato :-) is that something you could hack on ? I hope it's not so
hard; I would use:
tools/inc/tools/stream.hxx's SvStream
since it's already used; use the handy 'ReadLine' and split the string
with getToken() into the src & dest pieces and whack them into a
boost::unordered_map or similar.
2013/4/10 Stefan Knorr <heinzlesspam@gmail.com>:
I think this might be what you wanted to find on the wiki:
https://wiki.documentfoundation.org/Development/Icon_Themes
Thanks for that Stefan !
Yes, that's it =)
But the concerns about name sizes pointed by Meeks ruin this
concept... Unless things like this [2] show duplicate images.
Wow - well the scope for cleanup and duplication reduction is rather
significant according to the wiki - it'd be wonderful to have that
cleaned up and those obsolete names removed. In very many of those cases
we can just use a single new icon name instead of several others - so
(assuming we get a better sizing scheme worked out than pre-pending lc_
and sc_) there are lots of nice wins there I think.
So don't be discouraged; I'd start on the lower hanging fruit of
consolidating duplicated 'missing icon' icons, and other bits in .src
files, as well as the symlink magic first though. I'm most happy to help
out if you need patch review / other pieces.
Thanks for working on fixing that mess ! :-)
All the best,
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Context
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.