Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


*_Introduction_*

Did you know that *each LibreOffice theme is sporting 3336 icons*? That
means a default distribution gets shipped with about 13000 icons. Many
icons are duplicates in various levels: different sizes and such. Making
iconthemes is a mad job!

Currently a designer would edit the icons in inkscape and then export them
by binding IDs between objects in the XML structure to the filepaths. I
think there is a script for that. This solution does not give any help in
exploration and comparison. It also makes it hard to find equivalent icons
in different folders, which is very important if your goal is to have a
consistent icontheme. Usually this means only a new "style" affects a
sub-selection of a complete iconset. Currently I think I have seen at least
5 different "document" base styles...

The icons are normally stored in various github repositories. If you want
to find them and compare their looks you have to click through various
pages and open png - renderings. Very innefficient!

Reworking the iconset is yet the easiest way to "refresh" the UI for the
user, at least in comparison to rewriting the UNO code for user experience.
Some users are dreaming about "a new look"  and a "flat" iconset is
probably the easiest way to achieve this.

*My solution: IconManager Web App*
I have set out to create a web app which can display large batches of icons
quickly.

It should be possible to* tag* the icons so that browsing for various
categories (like "shape", or "document", or "navigate" or "filter") is
possible. This would make it possible to browse all available icons across
folders/themes/tags etc. They should be rendered in filepath groups/theme
groups or other meaningful ways.

Once this is done it should be possible to* upload new images *directly
into the theme - e.g. replacing the image. A history should be stored so
that when you build a new theme you can continue on other peoples work.

The best part is how I would like to work with svgs. My vision is to
separate the svg vector/shape data from color. If the icons are made with
nothing but a predefined set of static colors, these can be "considered"
variables. You could then have a regular expression replacing these colors
before rendering them client-side (or before exporting them to an actual
image_theme). Thus - changing the colorscheme of an iconset is as simple as
changing colors in a global colortable. This would - IMHO - be an
astounding improvement of the workflow! The designer would not have to have
angsiety of which colors to pick - that would be a later question. Of
course, the colors they pick would have to have some thought behind it.
Variable Red-1 would probably never become a blue-hue.

_My work so far_
I have completed the exploration/tag search part. All 13000 icons are
stored as homogenized base64 blobs in the database. Retrieving all of them
in one HTTP request takes perhaps 1.6 seconds as localhost (on my slow
laptop). Download speed as well as client rendering speed is of course not
included, but it's quite snappy! Its way faster then opening all icons in
gimp! I made a rough UI where you can select icons based on filepath,
filepath-tag, theme, icon-tag. You can also change the background color
between KDE/Ubuntu/Windows settings.

Next step is to build a icon-inspector and icon-uploader, so that the user
can switch between different icons and read data. There is also a direct
search link to the OpenGrok site so that you can have a direct inspection

*_Help wanted_*
I have not built complicated web services before - just hacking on smaller
things. I know have the brains and skills to complete this, but I need help
in design/architectural questions to make it great.

Currently I need help in database design, specifically schema design
advice, so that I pick the most optimal solution. Also beta testers are of
course always welcome. Right now I only have it as a localhost project, but
my plan is to at least host a version for a small select number of
interested people on my experimental domain.

Another topic which is important is advice in how icons are actually
implemented in the codebase. Should my app support making larger versions
or are the pixelsizes hardcoded? Are there more icons floating around
somewhere which I have missed. Things like this will be very useful once I
get to the point where the svgs and png blobs should be packaged into
installable themes.

If you want to see what I have so far, I can email the folder with the
database and web-files (php etc.) Its about 25MB, since I have jquery
included...

/oskar

-- 
To unsubscribe e-mail to: website+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/website/
All messages sent to this list will be publicly archived and cannot be deleted

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.