message viewing window partially transparent

More accurate description would be the ability to set transparent backgrounds for webkit styles such that a style could be constructed that had only the text boxes with nothing in between.

Why was this in the 0.81 milestone? Perhaps PM got confused with "Milestone" and "Version" ?

Take a look at how this can be done in the Colloquy code. Works on 10.3.9 and 10.4 (requires the new WebKit).

http://project.colloquy.info/trac/file/trunk/JVStyleView.m

@interface WebView (WebViewPrivate) // WebKit 1.3 pending public API - (void) setDrawsBackground:(BOOL) draws; - (BOOL) drawsBackground; @end

Let me know if you have any questions or need more help.

This is not something we intend to add. A transparent webkit view would not look good without a custom window title, source/destination selectors, text entry field, and tabs. We have no plans to allow complete skinning of the application.

Removing milestone, since it's misleading on the roadmap.

I've modified an old version of Adium to support this, if I create a patch off the trunk will you guys accept it?

Info and screenshots in this thread: http://forums.cocoaforge.com/viewtopic.php?p=49581

poisonousinsect: Depends on what the patch looks like, really...

Based on your forum post, poisonousinsect, it sounds like a clean implementation; please do submit a patch so we can take a look.

Lacks the permanent vertical scroll bar bgannin suggested in the forums (WebFrameView is not a descendent of NSScrollView). If it's not up to snuff, I'm happy to improve it.

Whoops, last version left in some extra code. Heh, sorry.

1. We're decreasing performance for the majority case (opaque background), which needs to be fixed. Most importantly, the invalidate shadows call after every drawing operation shouldn't happen for an opaque background.
2. Speaking of invalidate shadows, why is it necessary to wait until the next run loop to invalidate in the transparent case?
3. What happens if the webview doesn't have a background image given your setDrawsBackground:NO call?

1. Okay, I can fix that. 2. I'll add a comment to explain that. 3. -setDrawsBackground: works on the WebView the same way as it works on scroll views, in that the actual web content (background color, background image, etc.) is unaffected. The only change is that it doesn't draw solid white behind the background anymore (which understandably blocks any transparency).

Improved version, detailed comments in a second since this text field is tiny.

Okay. Optimized in a couple of ways:<br> 1. This version only calls -setDrawsBackground:YES if the background is opaque (which it tells either by an optional flag "DefaultBackgroundIsTransparent" in the message style [which defaults to opaque] or by looking at the user-entered custom color).<br> 2. The WebView store's whether it's opaque in an ivar so it doesn't even need to figure it out every time it draws.<br><br>

It seems you hinted at calling -setOpaque:NO on the window when the WebView is opaque. Theoretically that path is faster, but I chose not to use it because it does not make a noticeable difference in practical usage (even when looking for a regression on my 4+ year old iMac, I couldn't notice one). "Optimize later," and all that jazz. (Specifically, I understand that when drawing, it only backs up to the first opaque ancestor, which would be the Webview itself because I have it drawing its background when it's opaque.)<br><br>

Obviously, if you really want it to say it's opaque when it is, I will diligently work to improve it. But I really don't think its necessary.<br><br>

I also managed to get it to always draw the scroll bar, but I'll admit it's not particularly elegant. I am really not certain whether a permanent scroll bar should be used in this case. As the comment says, feel free to remove it.

Shoot, maybe someday I'll remember to use WikiFormatting...

I would vote against a permanent scroll bar.

poisonousinsect, sounds pretty good. I'll apply and review your patch; could you please attach a sample message style which uses a default transparent background so I can test that use case, as well?

I second that vote against a permanent scroll bar.

The default Eclipse style modified to have a single, transparent variant. The one limitation with this setup is that if any of the variants default to a transparent background, they all have to draw slower (the same thing is true with ShowsUserIcons for iconless variants, but that's not as big of a deal).

(In [15034]) Patch from poisonousinsect which allows selection of transparency for custom message style background colors and allows styles to use a DefaultBackgroundIsTransparent key to declare their backgrounds as transparent. Thanks :)

I also fixed a control dimming issue with the custom background controls in the Message preferences.

Closes #131

(In [15035]) Major optimization: Don't invalidate shadows for a transparent message view in the middle of a live resize. Refs #131

Success! Haha, thank you.