Possible tab implementation

[Peter Hosey]

I obviously have no idea how well this will work. Maybe not at all.

But I was thinking: What if, instead of capturing thumbnails of the WebViews, we actually *put the WebViews themselves* into the thumbnails?

A mock-up (using OmniWeb's appearance, obviously):

[Jesper]

> I obviously have no idea how well this will work. Maybe not at all.
>
> But I was thinking: What if, instead of capturing thumbnails of the WebViews, we actually *put the WebViews themselves* into the thumbnails?

Memory usage would probably balloon and you'd only see a fraction of
the viewport. And I just checked yesterday and apparently WebViews
don't take kindly to layer-backing with Core Animation, so using a
layout transform is right out (which would make memory usage balloon
even more, because you'd have it render everything in full proportions
just to shrink it down.

> Of course, since the active tab (Bar)'s WebView is in use in the main section of the window, it isn't in the tab view. This is fine, because why would you want a thumbnail for the active tab?

This might actually turn out to be a good idea.

Irrespective of this idea, another I've had is about the selected tab
always being visible in some way in the tab list. Even if it's
scrolled off to the top or bottom in actuality, it's shown near those
edges along with an indicator showing where it is relative to the rest
of the list and relative to the current range being shown. This might
work better without an image.

> Implementation would be something like an NSClipView, except that the view would scale instead of just clip.
>
> Obviously, we'd need to block mouse, key, touch, and probably accessibility access to the inactive web views.

A lot of work and unrealistic resource usage for a cool effect. I like
the wild idea.

> Potential downside: Animated ad banners. OTOH, we're going to have ad blocking anyway, right? And being able to watch a movie in a background tab would be cool. ☺

I think I'm going to leave ad blocking to the deeper WebKit
integration. If it comes to it, I'll port that Chrom(e|ium)
ad-blocking extension, but I'd rather not supply anything. OmniWeb has
a fairly sucky implementation of built-in ad blocking; everything
usable I've seen has been developed outside of the browser and had a
community-maintained white/blacklist. Which is not to say that it's
the only way to ever do it successfully, but there you go.

/Jesper


--
Subscription settings: http://groups.google.com/group/rouse-dev/subscribe?hl=en

[Peter Hosey]

On Apr 18, 2010, at 16:13:36, Jesper wrote:
> And I just checked yesterday and apparently WebViews don't take kindly to layer-backing with Core Animation…

Core Animation isn't necessarily necessary. NSViewAnimation hasn't gone anywhere; we should be able to use that for the animations.

> … so using a layout transform is right out (which would make memory usage balloon even more, because you'd have it render everything in full proportions just to shrink it down.

Not necessarily:

http://stackoverflow.com/questions/2181587/scale-webview-in-cocoa

An alternative to that approach would be for our tab-thumbnail view to implement `drawRect:` by scaling the CTM and sending `drawRect:` to the WebView.

> OmniWeb has a fairly sucky implementation of built-in ad blocking …

It works well enough for me. What, specifically, is wrong with it?

[Jesper]

> Core Animation isn't necessarily necessary. NSViewAnimation hasn't gone anywhere; we should be able to use that for the animations.

Scaling. See later.

>> … so using a layout transform is right out (which would make memory usage balloon even more, because you'd have it render everything in full proportions just to shrink it down.
>
> Not necessarily:
>
>        http://stackoverflow.com/questions/2181587/scale-webview-in-cocoa
>
> An alternative to that approach would be for our tab-thumbnail view to implement `drawRect:` by scaling the CTM and sending `drawRect:` to the WebView.

Yes, but when I say render everything in full proportions, I don't
really mean that I'm worried about the 500x500 bitmap produced to be
scaled down to 50x50, I mean that I'm worried about WebKit having to
draw everything at that resolution, which means accessing the full
version of everything on the page to be rendered. The transform
doesn't go deep enough within WebKit for it to figure out "oh, I only
need to use every tenth pixel of this because it won't be full
resolution". It needs to render at full resolution and have everything
handy. Maybe it could work if only the visible WebView render, but I'm
not entirely sure that's doable without constantly removing the
WebView from the view hierarchy altogether since things like Flash
have a habit to keep playing even in the background.

>> OmniWeb has a fairly sucky implementation of built-in ad blocking …
>
> It works well enough for me. What, specifically, is wrong with it?

First of all, blocking an image from the context menu just works some
of the time for me. Beyond that, it can't help you as far as Flash
goes - at least not that I've been able to make work. And finally,
there's no option to have it go update against a list on the web every
now and then.

/Jesper

[Peter Hosey]

On Apr 18, 2010, at 16:34:42, Jesper wrote:
> Yes, but when I say render everything in full proportions, I don't really mean that I'm worried about the 500x500 bitmap produced to be scaled down to 50x50, I mean that I'm worried about WebKit having to draw everything at that resolution, which means accessing the full version of everything on the page to be rendered. The transform doesn't go deep enough within WebKit for it to figure out "oh, I only need to use every tenth pixel of this because it won't be full resolution". It needs to render at full resolution and have everything handy.

That's exactly how it should work.

WebKit doesn't need to know or care that it's drawing scaled; it just needs to draw, *at full resolution*, and let Quartz take care of drawing it at the correct final resolution.

This works, at least for user-space scaling (configurable in Quartz Debug). If that works, then I think some form of transformation-matrix scaling will work as well.

If, somehow, that doesn't work, then we could put the view into an off-screen window with its user-space scale factor set, and screenshot that window to get thumbnails. No need for raster scaling.

(I was going to say that it would look better that way than OmniWeb's thumbnails do, but it looks like they fixed OmniWeb's thumbnails looking like crap. They looked pretty bad the last time I checked them, but they look fine now.)

[Peter Hosey]

On Apr 18, 2010, at 16:34:42, Jesper wrote:
>>> OmniWeb has a fairly sucky implementation of built-in ad blocking …
>>
>> It works well enough for me. What, specifically, is wrong with it?
>
> First of all, blocking an image from the context menu just works some of the time for me.

I don't think I've ever used it, probably because I initially set up OmniWeb the other way: Show no images, and let me *load* images one by one.

I finally gave up on that and turned images on, but I still haven't needed to explicitly block any.

On the flip side, the reason why I turned images on is that “Load Images” and “Load All Images” got flaky, and the latter (at least) still is.

> Beyond that, it can't help you as far as Flash goes - at least not that I've been able to make work.

ClickToFlash handles that pretty well.

In theory, I'd like a hypothetical Rouse ad blocker (or external ad-blocker Rouse plug-in) to block Flash and let me load it manually. In practice, this means I load it twice—once by clicking on the browser's “blocked” view, and again on ClickToFlash's view.

> And finally, there's no option to have it go update against a list on the web every now and then.

Fair point.

[Mark Norman Francis]

> In theory, I'd like a hypothetical Rouse ad blocker (or external ad-blocker Rouse plug-in) to block Flash and let me load it manually. In practice, this means I load it twice—once by clicking on the browser's “blocked” view, and again on ClickToFlash's view.

I would definitely want a Flash blocker of some sort, as I have a tendency to have a lot of tabs open at any one time. If they all had animating flash banners in, I'd have a battery life of around half an hour. ;)

Also, I find that a Flash blocker deals with every case that has made me want an ad blocker.

-- Norm.

[Peter Hosey]

On Apr 19, 2010, at 04:57:56, Mark Norman Francis wrote:
> I would definitely want a Flash blocker of some sort…

http://clicktoflash.com/

Works in every WebKit browser.

[Jesper]

> http://clicktoflash.com/
>
> Works in every WebKit browser.

http://bash.org/?338364

I deeply apologize for any mental images, and I actually happen to
think ClickToFlash is great, but I do think that Rouse should be able
to help an ad blocker out in blocking Flash (or Silverlight, or...) as
early as possible. ClickToFlash is a nifty hack that stops working the
moment people change the MIME types to the "futuresplash" one. There's
room to establish something more solid.

/Jesper

[Shawn Medero]

On Mon, Apr 19, 2010 at 1:03 PM, Jesper <woo...@gmail.com> wrote:
>> http://clicktoflash.com/
>>
>> Works in every WebKit browser.
>
> http://bash.org/?338364
>
> I deeply apologize for any mental images, and I actually happen to
> think ClickToFlash is great, but I do think that Rouse should be able
> to help an ad blocker out in blocking Flash (or Silverlight, or...) as
> early as possible. ClickToFlash is a nifty hack that stops working the
> moment people change the MIME types to the "futuresplash" one. There's
> room to establish something more solid.

Yes, but while you're working out other more critical bootstrapping
features you can always make sure that ClickToFlash works as expected
and advertise it as a stop-gap solution. ClickToFlash is a primary
reason of why I'm not using Chrome anymore. (The FlashBlock UI
experience & workflow is subpar compared to ClickToFlash)

I'm also not sure Adobe or anyone else could really take advantage of
application/futuresplash due to legacy content (<=1996). I haven't
done enough research on that to be clear on it though.

Cheers,
Shawn

[Jesper]

> Yes, but while you're working out other more critical bootstrapping
> features you can always make sure that ClickToFlash works as expected
> and advertise it as a stop-gap solution. ClickToFlash is a primary
> reason of why I'm not using Chrome anymore. (The FlashBlock UI
> experience & workflow is subpar compared to ClickToFlash)

Naturally. I just want to make clear where I stand in the long term.

> I'm also not sure Adobe or anyone else could really take advantage of
> application/futuresplash due to legacy content (<=1996). I haven't
> done enough research on that to be clear on it though.

I didn't mean that. I meant ad vendors switching to "futuresplash" to
get automatically "unblocked".

/Jesper

[Mark Norman Francis]

> http://clicktoflash.com/
> Works in every WebKit browser.

Sort of. Every WebKit browser that has chosen to implement support for "WebPlugIn" anyway -- http://rentzsch.tumblr.com/post/231032478/clicktoflash-on-chrome

Now I like CtF because of the extras, but I personally wouldn't make it a requirement to use CtF versus some built-in Flash blocker.

My main requirements would be:

* flash gets blocked automatically
* right-click/menu item activation and white-listing for flash that you always want (clipboard on bit.ly for example)
* some sort of notification about "hidden" and 1x1 flash elements (that are used for playing audio, for example) that would be too hard to activate with right-click

h264 on Youtube and sIFR support very optional although very welcome.

-- Norm.