Community
Participate
Working Groups
For bug 349237 I used http://spritegen.website-performance.org/ to generate sprites for the core and git plugins. The process was: 1. export a zip of the images from Orion 2. feed that zip to the tool above 3. prefix the css classes per plugin (core-sprite-, git-sprite-) 4. download the generated file and rename to something nice 5. zip the file so that I can import into Orion (would have been nice to just upload the file) 6. copy the generated css into the appropriate stylesheet There was an extra tweak in customsplitter.css because by default, the splitter arrow hit area was too small using just the normal sprite width/height (so I padded the width/height). We need a repeatable process, and perhaps some tooling, to make this go better. There is also some implied CSS reorg that has to happen. Reorg to-do's: - should the core sprites be defined in commands.css? probably not, perhaps they should bein ide.css or we have a sprite css - likewise should git sprites be in git.css or in a separate file - we might want to reorg our image directories so that widget graphics (custom splitter triangles, expand/collapse images, etc.) are separate from command and model objects, which change more often. Tooling ideas: - we could generate sprites and css in the build?? - we could automate the sprite process with an orion-plug-in. Being able to receive the file and css would be helpful, we'd also have to know where to put the css and what to name the file. Simon also suggested looking at data URI's in lieu of sprites. If we can't automate this process easily it's worth looking at, though it means all images would be loaded up front before rendering (whereas now we load them after). http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-obsolete/
marking 0.4. It would be cool to build two plug-ins: 1) use one of the sprite generators and automate the "get the zip and insert the css rules" step. 2) find a tool that similarly takes a zip and spits out data URI's and do the same thing. Allows us to compare the approaches easily this way. Gives us experience with two new integration points
(In reply to comment #1) > 2) find a tool that similarly takes a zip and spits out data URI's and do the > same thing. even better, these sites can be pointed to the file to encode so there's no need to upload. On our side we would embed the result into a CSS file. http://www.scalora.org/projects/uriencoder/ http://software.hixie.ch/utilities/cgi/data/data
another sprite tool: http://wearekiss.com/spritepad I'll assign this bug to myself to see if we can't come up with some decent integration for one of these tools in 0.5.
we're doing a consistency/usability pass during M2 so I don't see spending time on this feature. Adding back to inbox.
I happened to fall into this Bugzilla looking for something else. In 3.0, when resolving Bug 410233 , I created a somewhat repeatable process to update the core_sprites. I also took advantage of http://spritegen.website-performance.org/ I created core_sprites.sh that when run will create the core_sprites.zip I also created a core_sprites.html so that you could see the core_sprites.png as well as each of the sprite image. So to add a new image to the sprite: 1) copy the image into the images folder. 2) add the image to core_sprites.sh in it's alphabetical order. 3) run core_sprites.sh to create core_sprites.zip 4) go to spritegen, specify the zip file, horizontal and vertical offset: 2px and add the Class Prefix : core-sprite-. Leave the other defaults. 5) press the create sprite image and css button on spritegen. 6) click the save image button to download core_sprites.png. 7) cut and paste the css into images.css 8) add the new sprite entry to core_sprites.html 9) open core_sprites.html in a browser to see your new sprited image.
(In reply to comment #5) > I happened to fall into this Bugzilla looking for something else. > > In 3.0, when resolving Bug 410233 , I created a somewhat repeatable process > to update the core_sprites. > > I also took advantage of http://spritegen.website-performance.org/ > > I created core_sprites.sh that when run will create the core_sprites.zip > > I also created a core_sprites.html so that you could see the > core_sprites.png as well as each of the sprite image. > > So to add a new image to the sprite: > 1) copy the image into the images folder. > 2) add the image to core_sprites.sh in it's alphabetical order. > 3) run core_sprites.sh to create core_sprites.zip > 4) go to spritegen, specify the zip file, horizontal and vertical offset: > 2px and add the Class Prefix : core-sprite-. Leave the other defaults. > 5) press the create sprite image and css button on spritegen. > 6) click the save image button to download core_sprites.png. > 7) cut and paste the css into images.css > 8) add the new sprite entry to core_sprites.html > 9) open core_sprites.html in a browser to see your new sprited image. It will be nice if we can optionally convert those individual images into base64 URLs then redefine all core-sprite-*. I was thinking about this yestoday when I built the stand alone compare widget for 3.0 release. Currently together with built-compare.css, I have to always copy the images folder containing the core_sprites.png. It will be nice if I have a tool allowing me to convert individual images into new core-sprite-* definitions. I do not mind manually copying them into built-compare.css as it is just one time action after it is generated.
I just fixed Bug 411703 so that an additional manual step will remove the image folder from the build.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
