boerned@mist.CS.ORST.EDU (Dan Boerner) (04/30/91)
Question #1, Highlighting color icons Irked by the lack of tookbox calls to draw Icons in the new Icon Family, I've written my own. Everything is hunky-dory except my InvertFamilyIcon routine follows TN #55 and looks lame in color (the colors are inverted). I'd like to use the same algorithm that Finder 7.0 uses (dim the icon's palette down some percentage), but I've never messed with the Palette Manager and I'm not sure how difficult this would be. So, has anyone already solved this problem or know how to? Any Finder 7.0 programmers out there? Question #2, Choosing the Best Icon I've written a routine PlotBestFamilyIcon that will draw the icon that best matches the current port's pixeldepth. I'm currently doing this by looking at the port's portPixMap^.pixelSize field. (Yes I make sure its a color port) One problem however, is that if the port is created when the screen is set to say 8 bits depth and then the user switches depth via the Monitors cdev, the port is still 8 bits deep and my routine fails to notice the change in depth, so it chooses the wrong icon to draw. Is checking the pixel size a legitimate and safe method to determine which icon to draw? Is there another way that will tell me when the user changes the screen depth on the fly? Ok, so that was three questions, but whose counting :). I'll be glad to post the routines when I get them finished and tested. Thanks, Dan Boerner CS Master's Student @ Oregon State University boerned@cs.orst.edu
d88-jwa@byse.nada.kth.se (Jon W{tte) (05/01/91)
In article <> boerned@mist.CS.ORST.EDU (Dan Boerner) writes:
written my own. Everything is hunky-dory except my InvertFamilyIcon
routine follows TN #55 and looks lame in color (the colors are
inverted). I'd like to use the same algorithm that Finder 7.0 uses
(dim the icon's palette down some
So, has anyone already solved this problem or know how to? Any Finder 7.0
programmers out there?
No Finder 7 programmer, but looking in IM gives some answers:
RGBColor c = { 20000 , 20000 , 20000 } ;
RGBColor q = { 0 , 0 , 0 } ;
PenMode ( subPin ) ;
RGBForeColor ( & c ) ;
OpColor ( & q ) ;
PenPat ( black ) ;
PaintRect ( & iconRect ) ;
If you don't like the look of subPin, try blend...
Happy hacking,
--
Jon W{tte
h+@nada.kth.se
- Power !boerned@mist.CS.ORST.EDU (Dan Boerner) (05/01/91)
I thought I'd post an update to my two color questions, here's what I've learned so far. First a clarification, in my last post I mentioned a problem with the screen depth changing as a result of the monitors cdev. Hogwash, (as Arnaud Gourdol pointed out to me) there was no problem with that, I just misremembered the bug. The actual problem was with dragging a window created at 8bits depth to a monitor of another depth. The depth does not change and so my routine picks the wrong icon and lets Copybits to the depth scaling. The solution (see below) is not to try to pick "one" best icon but to make the decision at draw time. Question #1, Highlighting color icons Turned out this one was easy, just use Copybits with the blend mode and set OpColor to rgb gray. Works great in color, but not in b&w so I'll have to special case that. I'd actually tried this before but forgot to set the OpColor. Question #2, choosing the best icon to draw Greg Anderson from Apple was nice enough to drop me a note and suggested I walk the GDevice list and draw the appropriate icon for each monitor that the icon intersects. So, I've decided to give up trying to statically determine the best icon to display and instead let my draw code pick the best based upon the GDevice list. Anyone out there that thinks this might not be safe? Thanks for everyone's help, --- Dan, alias "Joe Icon"
nerm@Apple.COM (Dean Yu) (05/02/91)
In article <1991May01.014734.25231@lynx.CS.ORST.EDU> boerned@mist.CS.ORST.EDU (Dan Boerner) writes: >Question #2, choosing the best icon to draw >Greg Anderson from Apple was nice enough to drop me a note and suggested >I walk the GDevice list and draw the appropriate icon for each monitor that >the icon intersects. > >So, I've decided to give up trying to statically determine the best icon to >display and instead let my draw code pick the best based upon the GDevice list. >Anyone out there that thinks this might not be safe? > Not only is this perfectly safe, but it's totally cool. In System 7, we provide a new call, _DeviceLoop, which does the walking for you, and all you have to do is pass a pointer to your drawing routine. If you want your program to work under 6 as well as 7, I can post the interface for _DeviceLoop (if you don't have access to IM VI) so you can use the supplied call under 7, and use your own call under System 6, but the two can share the same interface. -- Dean Yu Blue Meanie, Negative Ethnic Role Model, etc. Apple Computer, Inc. My opinions and so on and so forth...
deadman@garnet.berkeley.edu (Ben Haller) (05/05/91)
In article <1991May01.014734.25231@lynx.CS.ORST.EDU> boerned@mist.CS.ORST.EDU (Dan Boerner) writes: >Question #1, Highlighting color icons >Turned out this one was easy, just use Copybits with the blend mode and >set OpColor to rgb gray. Works great in color, but not in b&w so I'll have >to special case that. I'd actually tried this before but forgot to set the >OpColor. Actually, this works fine, but it *isn't* the method used by the Finder. The Finder only dims colors that are in the Apple Standard 34 Colors. Who thought of this originally should probably be shot. Whoever thought of the "Standard 34 Colors" in the first place should probably be shot. But that's how it works. The question is, has Apple issued a definite statement that this is how it will *continue* to work, or can we expect the Finder's algorithm for displaying icons to change again, as it has in every major release since version 1.0 (with perhaps an exception or two, but essentially this is true)? I'd love to know who thinks up ideas like this. -Ben Haller (deadman@garnet.berkeley.edu) "I remember the feeling / My hands in your hair..." - King Crimson
keith@Apple.COM (Keith Rollin) (05/06/91)
In article <1991May4.222227.9364@agate.berkeley.edu> deadman@garnet.berkeley.edu (Ben Haller) writes: >In article <1991May01.014734.25231@lynx.CS.ORST.EDU> boerned@mist.CS.ORST.EDU (Dan Boerner) writes: >>Question #1, Highlighting color icons >>Turned out this one was easy, just use Copybits with the blend mode and >>set OpColor to rgb gray. Works great in color, but not in b&w so I'll have >>to special case that. I'd actually tried this before but forgot to set the >>OpColor. > > Actually, this works fine, but it *isn't* the method used by the Finder. >The Finder only dims colors that are in the Apple Standard 34 Colors. Who >thought of this originally should probably be shot. Whoever thought of the >"Standard 34 Colors" in the first place should probably be shot. There was a lot of thought put into the handling of color icons in the Finder. The implemention of the "Standard 34" colors was to solve the problem of highlighting. Here's the problem: Assume that you allow any possible combination of colors in an icon. How do you highlight them? Do you simply darken the icon by subtracting 0x2000 from the R, G, and B components of all the pixels? What happens if one icon is drawn with (0xA000, 0, 0) and a second in another shade of red (0x8000, 0, 0). If the first one is selected and highlighted, then it becomes indistinguishable from the one that is unhighlighted. The choice of the magic 34 colors was to avoid the confusion, and was backed with a lot of use testing. Before you go shooting people, I'd love to hear your alternative. >But >that's how it works. The question is, has Apple issued a definite >statement that this is how it will *continue* to work, or can we expect the >Finder's algorithm for displaying icons to change again, as it has in every >major release since version 1.0 (with perhaps an exception or two, but >essentially this is true)? This problem will be solved eventually. Believe me. It just won't be solved at the same time 7.0 is released. Given how long it took to develop 7.0, we didn't want to have to solve _every_ problem as a requisite for shipping! -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
christer@cs.umu.se (Christer Ericson) (05/06/91)
While we're bashing Apple and their color icons we could as well flame the one who designed the cicn format. When there is a B&W bitmap why couldn't it have been the first entry of the record so we could have called PlotIcon with the CIconHandle directly on a non-color machine (ie an SE) instead of having to call CopyBits or having both cicn's (for color machines) and ICON's (for B&W). Okay okay, this is a pretty minor thing, but it seems pretty stupid to me anyway. Is there some sort of "hidden problem" here too?! :-) | Christer Ericson Internet: christer@cs.umu.se | | Department of Computer Science, University of Umea, S-90187 UMEA, Sweden |
grendel@aix01.aix.rpi.edu (Thomas E DeWeese) (05/07/91)
If you think that is bad what about the icl8 & icl4 formats. If you can't be certain that the screen is in standard colors (which you never can) you have to create a graphics device with the standard colors and then block move the icon resource into the graph port then CopyBits it to the screen. At least this was the simplest way I could get it to work. Is there now a system call to plot icl4,and icl8's? grendel@rpi.edu Thomas DeWeese
murat@farcomp.UUCP (Murat Konar) (05/07/91)
In article <1991May4.222227.9364@agate.berkeley.edu> deadman@garnet.berkeley.edu (Ben Haller) writes: >The Finder only dims colors that are in the Apple Standard 34 Colors. Who >thought of this originally should probably be shot. Whoever thought of the >"Standard 34 Colors" in the first place should probably be shot. But >that's how it works. [ the rest deleted ] I like to think that it's Apple's way of enforcing the color icon design guidelines. It'll keep all of us artist-wanna-be's and marketing experts from turning the user's desktop into a neon lightshow. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
deadman@garnet.berkeley.edu (Ben Haller) (05/07/91)
In article <52482@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1991May4.222227.9364@agate.berkeley.edu> deadman@garnet.berkeley.edu (Ben Haller) writes: >>The Finder only dims colors that are in the Apple Standard 34 Colors. Who >>thought of this originally should probably be shot. Whoever thought of the >>"Standard 34 Colors" in the first place should probably be shot. > >There was a lot of thought put into the handling of color icons in the >Finder. The implemention of the "Standard 34" colors was to solve the >problem of highlighting. Here's the problem: > >Assume that you allow any possible combination of colors in an icon. How >do you highlight them? Do you simply darken the icon by subtracting >0x2000 from the R, G, and B components of all the pixels? What happens >if one icon is drawn with (0xA000, 0, 0) and a second in another shade >of red (0x8000, 0, 0). If the first one is selected and highlighted, then >it becomes indistinguishable from the one that is unhighlighted. > >The choice of the magic 34 colors was to avoid the confusion, and was >backed with a lot of use testing. Before you go shooting people, I'd >love to hear your alternative. Oh, I only *talk* about shooting people. My gosh, Keith, this is my week for being shown up by you. But I really don't think you're right here. For starters: you haven't solved the problem. If one icon has stuff in one of the magic 34 and gets dimmed down, the dimmed version would probably be a color that *isn't* in the standard 34, and so another icon could contain that color, and when selected, look the same as the original, etc. You haven't solved anything, unless you can get *everyone* to use only the standard 34 colors. But in fact, I think people will use the standard 34 as dimming colors, and will use the other colors as non-dimming colors, and therefore get nifty dimming effects for their icons. I've already made many icons that take advantage of this property, actually. Secondly, the standard 34 are stupid. Who picked them? There are some good choices, such as having a flesh tone, and having several "system 7 blue" shades. But why 14 shades of gray (are they really *that* important?), no good orange (don't tell me the one in there is *good*), no dark brown, no fully saturated red, no half saturated yellow, etc. etc. Third, you ask what algorithm I would use. Personally, I don't see your example as a problem. If someone deliberately makes an icon that looks like it's dimmed when it's not, they deserve what they get. I really don't think anyone is that dumb. And if they are, I don't think you can prevent them from making fools of themselves. I think doing a weighted blend with black, or doing a SubPin with some shade of gray, would be much more consistent, and look just as nice. Besides, a selected icon has the text below highlighted, so if all else fails one can just look at that. I really honestly think that the Standard 34 Colors is one of the worst decisions I've seen come out of Apple. Luckily, it's not a particularly *important* decision. -Ben Haller (deadman@garnet.berkeley.edu) "You're much better off in twos If you're going to see the carnage in the backroom..." - John Cale & Brian Eno
francis@arthur.uchicago.edu (Francis Stracke) (05/10/91)
In article <362@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes: In article <1991May4.222227.9364@agate.berkeley.edu> deadman@garnet.berkeley.edu >The Finder only dims colors that are in the Apple Standard 34 Colors. Who >thought of this originally should probably be shot. Whoever thought of the >"Standard 34 Colors" in the first place should probably be shot. But >that's how it works. [ the rest deleted ] I like to think that it's Apple's way of enforcing the color icon design guidelines. It'll keep all of us artist-wanna-be's and marketing experts from turning the user's desktop into a neon lightshow. Also, and (perhaps) more importantly, it cuts down on color table allocations. If you know that the people you're sharing the screen with will probably use the same colors as you, you can have a better chance of getting the colors you ask for. Since they're probably quite close to covering what you'd want anyway, it should be all right. It lets you predict better what you'll get. And there's nothing to stop you from using the standard color table + your own stuff. It's just that, for most purposes, you'll probably be close to the table, and being exactly in the table gives you benefits, & I'm starting to babble (been up too long), so I'll shut up now. :-) -- /============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Welcome to the Real World. Enjoy the | | francis@zaphod.uchicago.edu | show. | \============================================================================/