*_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: [email protected] 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
