On 24 May 2004, at 02:31 PM, David W. Fenton wrote:
The articles at Ars Technica and Ask Tog certainly caused me to think that it was a contributing factor -- having to calculate every stack of pixels down to the first non-transparent one seems to me like a fairly computationally intensive process.
Well, it is, but not for the CPU. Modern graphics cards are designed to do very sophisticated graphics processing on-the-fly (transform, lighting, bump-mapping, anti-aliasing, and whatnot) at upwards of 60 frames per second in today's 3D video games. A little transparency in the GUI hardly makes them break a sweat, and it's all offloaded to the graphics card so its no skin off the CPU's nose. (This is all provided your Mac + graphics card supports Quartz Extreme, which all but the oldest Macs do.) Since most of the time, for non-gaming applications your graphics card is just sitting there twiddling its thumbs, its good to give it something to do once in a while, especially if it takes some of the load off the CPU.
[I remind everyone that Sibelius uses modern graphics cards *very* effectively.]
Next, transparency *is* actually useful, at least to me, and also for anyone with a laptop or a small monitor. Ironically, probably the best use of transparency I've seen is in a Microsoft product (albeit the Microsoft Mac Business Unit). In Office 2004 Mac, you have the option of having the Formatting Palette automatically fade -- to as much as 90% transparency -- if it's not being used. . . .
How is this less useful than a windowshade UI?
Because first, it's not automatic. With windowshade, if I want to show or hide the palette, I have to click a widget. And let's say I wanted to adjust something at the bottom of the formatting palette, I would first have to mouse up to the top of the palette, click the windowshade widget, then mouse all the way down to the bottom of the palette and make the adjustment.
With transparency, I just mouse directly over to the item at the bottom I want to adjust, and the palette goes opaque. I make the adjustment, mouse out of the way again and it fades.
The only disadvantage is that if you dock the palette on the far right of the screen (as I do), you lose access to the vertical scroll bar. That's not a big deal for me, though, because I almost always use the mouse wheel for scrolling. But you could, of course, solve the problem by moving the palette a few pixels to the left so that it doesn't overlap the scroll bar.
. . . This means that people with 1024x768 screens can use *all* of their limited screen real estate for the document they are working on. The Formatting Palette becomes opaque when you mouse over it, and fades again when it's no longer needed. This system actually works exceptionally well, and I'd like to see other apps -- like Finale! -- adopt fading palettes.
OK, you've come up with *one* UI component where transparency is useful. Why, then, should it be implemented system-wide?
It's implemented system-wide so that each individual developer doesn't have to write their own transparency code themselves if they want to use it. For instance, my launcher app (DragThing) supports transparency. I don't use that feature myself, but I can see why it would be useful, and I'm sure lots of people do.
As for the transparency behind menus, you're right that it's not particularly functional, but it's subtle and (I think) attractive. Anyway, since it doesn't incur a noticeable performance hit (in the current version of the OS, at least), I'm not sure what the big deal is.
To give you another Finale-specific example, I've been bugging Tobias for a while to add the option to control the transparency of TGTools dialogs, especially the Staff List Manager. The big problem with the Staff List Manager is that it's, well, so *big* -- the dialog box is huge (unnecessarily huge, IMO, with lots of wasted space) and it tends to cover up the music that you are trying to adjust. Of course, you can move the dialog around the screen, revealing bits of it at a time, but whole point of using the Staff List Manager is that you want to be able to see the entire page (or, at least, an entire system) at a glance. So yeah, transparency here would be an enormous help.
On Windows, Tobias has implemented his plugins with a windowshade like roll-up when the plugin window doesn't have the focus. This means the dialog not only leaves more of the Finale window visible, but it also actually takes up less space. Isn't taking up less space more desirable, since it reveals more of the windows behind it while also making those visible areas fully accessible, which, so far as I can tell, a transparent pallette would not?
David, I'm not sure if you use the Staff List Manager regularly, or if you use it the way I use it, because your suggestion that windowshade is an acceptable alternative to transparency in this case doesn't make sense to me. I often work on orchestral or big band scores, where there are many staves per system and I need to make a lot of adjustments. Obviously, when the window is collapsed, I can't make any adjustments. I want to be able to see what I'm adjusting *and* make those adjustments without having to collapse and expand the window all the time. Transparency (especially if it's user-adjustable) would do that nicely.
(Also, BTW, nothing is fully accessible when using the Staff List Manager -- one of the major drawbacks to that plugin is that you cannot scroll the screen without closing the plugin.)
- Darcy
-----
[EMAIL PROTECTED] Brooklyn NY
_______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
