Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

WebBrowseTree

Hi,

This email details some ideas I've been having about a new way to browse. It's not a request for an answer to a specific problem I'm having with WebKit, but rather an appeal to the collective wisdom of the list for comments on the sanity / usefulness / internal consistency of the idea and suggestions of how to go about implementing it. If such things interest you, please read on.

I'm trying to create a bastard child of WebBackForwardList and WebHistory: the WebBrowseTree. The idea is to record the user's browsing history in such a way that information is retained about which links were followed from where. Therefore its interface might include:

@interface WebBrowseTree

// Inserts item as a child of the current item
- (void)addChild:(WebHistoryItem *)item;

// Moves to item in the WebBrowseTree by making it the current item.
- (void)goToItem:(WebHistoryItem *)item;

// Returns an ordered list of items browsed-to from the given item, or nil if there are none
- (WebHistory *)childrenOfItem:(WebHistoryItem *)item;

// Returns the item from which the given item was browsed to.
- (WebHistoryItem *)parentOfItem:(WebHistoryItem *)item;

// ..etc..
@end

Now, I want the WebBrowseTree to be automatically managed by the WebKit in the same way that WebBackForwardList and WebHistory's optionalSharedHistory are.

(http://developer.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/Tasks/DisplayingHistory.html#//apple_ref/doc/uid/20002031/118453 states "You can create WebHistory objects in one of two ways. You can assign each WebView object its own WebHistory object, or you can create one WebHistory object that is shared by all WebView objects in your application". I've never seen any evidence of the former, presumably because the latter is what everyone wants anyway.)

A non-shared WebBrowseTree would be similar to a WebBackForwardList except that instead of behaving destructively when there are items ahead of the current item, it would simply branch the browse tree (add another WebHistoryItem child). However, it really should be possible to share WebHistoryItems between the WebBrowseTree and the WebBackForwardList, so that goToItem: performed on one would change the index position of the other. Steps would have to taken to maintain consistency; for example, with a browse tree like:

A - B - C - D - E
\- F - G - H
\- I - J


[browsing having occurred in alphabetical order (e.g., the user has followed link to B from A, C from B, etc., then pressed 'back' twice from E and followed a link to F, etc.)]

The WebBackForwardList would contain (A, B, C, F, I, current=J), a goToItem:D would change that to (A, B, C, current=D, E), but a further goToItem:F would change that to (A, B, C, current=F) because without keeping a stack of 'recent paths' it wouldn't be possible to decide which of (G, H) or (I, J) should be forward of F.

A shared WebBrowseTree complicates things further. goToItem: would have to be replaced by goToItem:inWebView:, and/or a new method, goToBrowseTreeItem: (like goToBackForwardItem:), would have to exist in WebView. I think it would be sensible to add a child of the current WebHistoryItem to the shared WebBrowseTree if a link is followed into a new WebView, but the behaviour should maybe be controlled by a policy delegate. Any new WebView would have an empty WebBackForwardList, but a subsequent goToBrowseTreeItem: in that new view should probably populate at least the backward part of that list to the root of the browse tree (and perhaps the forward part to the next branch point). Creating a new WebView not from a link should either create a new child, a new sibling, or a new root node in the WebBrowseTree.

Of course, I want to present this browse tree within a browser and allow users to navigate around it. You can imagine it in Safari's bookmarks window (I have written hooks for a new BookmarkSource subclass to achieve this in an InputManager hack). I want the browse tree to be presented centred on the WebHistoryItem in the current WebView, with that item highlighted -- along with any items currently open in any other WebView (tab or window).

So, some questions:

1) Do you think such a browse tree would be a useful way of browsing? Myself, I open tabs to achieve branching, either in the foreground (for depth-first browsing) or in the background (for breadth-first). But sometimes I close them in haste, or fail to open enough of them, so I return to some reference point in my global history and retrace my steps from there. I think a browse tree would be a much more natural way of doing this.
2) Do you think it would be feasible to implement? Preferably entirely through categories using delegates / notifications via an entry point [WebBrowseTree setOptionalSharedBrowseTree]; next best through subclassing using public APIs; worst case using private APIs / class posing.
3) Do you have any suggestions for hooks I might use which provide information about the parent WebHistoryItem as well as the child?
4) Are there any gotchas you know of? (e.g., perhaps WebHistoryItems can cause problems if retained by more than one container?)
5) Do you want to help me write it? :) (Apple employees particularly welcome!)

Best wishes,
Hamish
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webkitsdk-dev/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.