Lots; or: I has a bucket (Source, kinda, sorta)

[Jesper]

I'm not quite there, but I've got to get something out there.

First things first: I ended up picking hg (Jens Alfke's Murky frontend
does what I need) for source control.

At <http://bitbucket.org/wootest/rouse-sikrit>, you'll find the code
I'm working with now. Snow Leopard, Xcode 3.1 required. There's no
runnable application; this is intentional. I've blocked public forking
in Bitbucket; this is also intentional. Once this leaves the workshop
floor I'll check it into the Google Code project repository (which
will also switch to hg at that time). Private forks are still very
much okay.

There are bugs, oversights, large swaths that are more haphazardly
stacked than designed. There's also bits that are thought-through.
It's all uneven.

Find, Print, View source, x resources loaded of y, https lock icon,
draggable tabs; none are implemented. Some parts that are there are
perfectly serviceable. IDL is supported, but not the complete Safari
character set-affinity smarts (replace latin letter with
similar-looking letter, purchase domain name) yet.

Here are some of my more immediate plans:

* Swap the NSTableView tab implementation with TDListView. I started
out with NSTableView but I actually wanted a
a) sane,
b) collection-view-like,
c) table view alternative
d) using on-demand, reusable
e) views
f) of optionally different row length [not a priority right now, but
it'd be nice]
g) that can be reordered
h) by drag and drop
i) nicely.
The current cell-based architecture is a pain and a half and will
never make it easy to go to Core Animation layers. NSCollectionView
did not completely fit the above bill either. TDListView... well, just
mute your speakers and watch <http://vimeo.com/9446805>.
* Figure out how to get the SSL/TLS certificates as they're loaded and
display that info.
* Find panel.
* Plug into everything WebKit's delegates can provide to get a good
baseline functionality.
* Work out tab coloring.

Don't ask for permission. If you want to help out, just do it. If you
want feedback on what to do, just let me know, but asynchronously.
Don't let me keep you until I reply.

/Jesper

[Mark Norman Francis]

> There's no runnable application; this is intentional.

Oh noes!

> Don't ask for permission. If you want to help out, just do it. If you
> want feedback on what to do, just let me know, but asynchronously.

Is there anything other than writing Objective-C that needs to be done, or should I just treat this as an "opportunity" to learn Obj-C? :)

-- Norm.

[Jesper]

>> There's no runnable application; this is intentional.
>
> Oh noes!

This is not the final state Rouse will ever be in. I just want to get
a few more things in order before I make it a bit more public.

>> Don't ask for permission. If you want to help out, just do it. If you
>> want feedback on what to do, just let me know, but asynchronously.
>
> Is there anything other than writing Objective-C that needs to be done, or should I just treat this as an "opportunity" to learn Obj-C? :)

Of course feedback is always appreciated, which I realize is hard
right now, without a running app in your hand. I know most of you who
are subscribed here have strong opinions; now is probably a good time
to summarize them.

I'd like you to spend a short amount of space for each feature you'd
like. Also mention how crucial this is for getting work done (if it's
something that already exists), how long time, roughly, you estimate
that it will take to implement (more on the scale of magnitudes -
hours, days, weeks - than exact units) and how soon, given the
timeline I've given and the three big milestones, you think it should
arrive. List them by immediate priority.

For every three things you list, also mention one thing in one of your
current browsers that you'd really like to be different. As soon as
this quota is not met, I'll stop reading - if you post five things and
two "mentions" per the previous sentence, I'll read them all, but if
you post nine things and one "mention", I'll only read the first
three. But I will read the first three; thus the ranking by priority.
This will be interesting.

/Jesper

[Jesper]

> At <http://bitbucket.org/wootest/rouse-sikrit>, you'll find the code
> I'm working with now. Snow Leopard, Xcode 3.1 required. There's no
> runnable application; this is intentional. I've blocked public forking
> in Bitbucket; this is also intentional. Once this leaves the workshop
> floor I'll check it into the Google Code project repository (which
> will also switch to hg at that time). Private forks are still very
> much okay.

It has come to my attention that the RBSplitView Interface Builder
plugin is needed. I've checked in this in a folder. I've also removed
BWToolkitFramework, since nothing really depends on or uses that.

/Jesper

[Mark Norman Francis]

> I'd like you to spend a short amount of space for each feature you'd
> like.

Oh boy ... "can ... worms ... everywhere!" ;)

Before I go finishing and sending my huge draft response to that, two quick questions.

1. Does that include "obvious" features such as being able to rearrange tabs in a window? Or just anything "new" and "shiny"?

2. Does "List them by immediate priority." mean as if I were a project manager; or as if I were a client asking for the logo to be made bigger whilst ignoring the results of the signup form usability study telling me I'll get no customers? (What I _want_ or what I think we _need_?)

-- Norm.

[Jesper]

> Oh boy ... "can ... worms ... everywhere!" ;)
>
> Before I go finishing and sending my huge draft response to that, two quick questions.
>
> 1. Does that include "obvious" features such as being able to rearrange tabs in a window? Or just anything "new" and "shiny"?

That's up to you. There may be things that you think are just as
important as being able to rearrange tabs that's not on my mind at
all.

> 2. Does "List them by immediate priority." mean as if I were a project manager; or as if I were a client asking for the logo to be made bigger whilst ignoring the results of the signup form usability study telling me I'll get no customers? (What I _want_ or what I think we _need_?)

With somewhat regards to the three big milestones: something basic now
(really basic for most things but a semi-mature tabs implementation),
something more full-featured later (everything's getting good),
something awesome even later (crazy Buck Rogers
access-to-page-resources-from-custom-scripts science). Let's assume
that you *want* for the project to get what it *needs*. (I'm going to
be an ass and pretend that we all agree with that rough plan because
that's the plan I'm going to follow, and if five or ten Cocoa
programmers that are better than me on this jump in and proclaim a
more speedy and inclusive agenda, I think I'd be flexible in that
scenario and tackle such misfortune when it arrives.) What would
further that goal best? Would the sepia tone on Flash players plugins
be a killer feature to implement before bookmarks?

/Jesper

[Peter Hosey]

On May 17, 2010, at 11:02:09, Jesper wrote:
> I'd like you to spend a short amount of space for each feature you'd like. Also mention how crucial this is for getting work done (if it's something that already exists), how long time, roughly, you estimate that it will take to implement (more on the scale of magnitudes - hours, days, weeks - than exact units) and how soon, given the timeline I've given and the three big milestones, you think it should arrive. List them by immediate priority.

Here's the post with the “three big milestones”, for anyone else who'd forgotten them:

http://waffle.wootest.net/2010/04/18/rouse-feasibility-and-scope/

> For every three things you list, also mention one thing in one of your current browsers that you'd really like to be different.

Good thing I wrote a bunch of these down last month and have been waiting for a good opportunity to post them to the list!

R-numbers are requests; D-numbers are difference requests.

---
R1. Warning against loss of form text

In Safari, if you enter text in a form, then attempt to close the page without submitting it, Safari will warn you.

A way to improve on Safari: Don't warn if the form has been submitted into a new tab (⌘-return/⌘-click on Submit).

Tier one. I have no idea how to implement this, so I'll call it several weeks.

---
R2. Ability to set an application, which would ostensibly be a download manager, with which to “open” every URL to be downloaded

I use Leech and love it. I wish my browsers would use it for all their downloads.

This would save us from having to implement one ourselves, at least built in. Those who want a download manager and don't want to pay for one could join together to write a simple free download manager for the Rouse project to recommend and possibly to include as a bundle.

Tier two. This would take 1–2 weeks, I think. Low priority—we can get by on dragging to our favorite download managers for now.

---
R3. Ability to keep the Location field hidden except while in use

In OmniWeb, I keep all toolbars hidden except when I'm using either the Location field. This reduces distraction from the browser content. I would like Rouse to have the same feature.

(The only bar I keep visible at all times is the status bar, which includes loading status, the Load All Images button, the Cookies button, the AutoFill, the Subscribe to Detected Feed button, the Secure Site indicator, and the Site Preferences button.)

Tier one. If D1 (below) is accepted, there will be only one toolbar, which means we can implement this with NSToolbar, which means it should be fairly easy. Let's call it a few days, up to a week.

---
D1. The Search field (if indeed there one is implemented) should be on the same line as the Location field.

Quite frankly, I see no reason to have a toolbar of the classical form in a 2010-vintage browser, especially one for sophisticated users. Those who want mouse control over such things as back/forward navigation can either use the Go menu (or whatever Rouse calls it) or right-click on the background and use the contextual menu.

Of course, if the Search field and the Location field are the same field, then the Search field is on the same line as the Location field, which satisfies this request inherently. ☺

Tier one. Two separate fields on one toolbar: See R3. One field doing both jobs: Harder, but well within our reach; perhaps a few weeks for that.

Incidentally, we could use Stephen Holt's AIHyperlinks framework (BSD license) to tell URL from search query.

https://bitbucket.org/sholt/autohyperlinks2
~~~

---
R4. Ability to enforce styles

OmniWeb provides several predefined styles and an option to enforce them to varying degrees upon all sites (except those explicitly excepted using Site Preferences). This is good for preventing sites from blinding me with terrible colors.

Tier two. I'll estimate several weeks to implement this, not knowing exactly how to do so. The Web Inspector in OmniWeb offers a vague hint.

---
R5. Shift-click a link to focus it without activating it

In OmniWeb, you can drag a link and let it go to put focus on it without activating it. This is very handy in conjunction with tabbed browsing, as you can use ⌘-return and tab in alternation to quickly open a dozen or so tabs from a starting page (e.g., pages 1 through eleventy of a multi-page article, or images in a gallery).

Tier one. I have absolutely no idea how to implement this, so I will guess that it could take weeks to months to implement.

---
R6. Ability to view source while it's still loading

With a progress bar at the bottom of the window tracking the progress of the main resource load.

Tier one. This shouldn't be too hard, but maybe I'm underestimating it. 1–2 weeks.

---
D2. Break ability for JavaScript to break left-/right-click

This could come with a user-editable whitelist for sites like Dropbox, but the default should be that no site not on the list can break the contextual menu.

The same feature should also guard dragging in the page. Some sites break dragging in a foolish attempt to prevent you from selecting anything on the page.

Tier three. Probably hard.

A stopgap solution is to enable me to do what I do in OmniWeb: Turn JavaScript off, and turn it on for specific sites using Site Preferences.
~~~

---
R7. Copy list items from the Activity and Downloads windows without having to select text in a field

(“Downloads”, obviously, assumes the unfulfillment of R2.)

In OmniWeb, in order to copy the URL for an item in the Activity or Downloads window, you must first select the item, then select the text of the URL in a separate field, then copy it. Rouse's Activity window (and Downloads, if it has one) should enable the user to copy the URLs of items by copying the items directly.

This is handy for downloading videos served as MPEG-4 (e.g., by YouTube and PATV) for offline viewing, as well as audio and Flash games from some sources.

Tier one. This won't take more than a couple of hours out of each window's implementation—it's basic table-view data-source stuff.

---
R8. Type-ahead find

OmniWeb allows the user to type into the browser window to focus a link. This is *extremely* useful for browsing Apple's framework references, to the extent that I prefer OmniWeb over Xcode's built-in doc viewer, as I wrote here:

http://boredzo.org/blog/archives/2009-07-15/my-documentation-viewer

I think we can improve on it. The problem with OmniWeb's type-ahead find is that it doesn't work if a browser frame isn't focused; in particular, ⌘T, ⌘2, “NSBlahBlah” doesn't work like I want it to (as OmniWeb inexplicably leaves the Location field focused, with URL selected, after ⌘2). I have to use ⌘⌥⇣ a couple of times to focus the first link on the page, *then* start typing, and that doesn't always work.

For one thing, activating a bookmark should deselect and blur (and hide, if the user has it hidden according to R3) the Location field and focus the main browser frame.

For another, I suggest making ctrl-s a shortcut to put the focus on the main frame. emacs and advanced Cocoa-text-view users should notice the evocation right away: You would press ctrl-s, then start typing, and the first match would be selected (focused).

Tier two. This is another where I have absolutely no idea how to implement it, so I will guess that it could take weeks to months to get working.

---
R9. Paste URLs directly into the main frame

I'm sure this used to be supported in some browser or another, but I know the current versions of Safari, Chrome, OmniWeb, iCab, and Firefox, plus Camino 1.0.3, don't support it. (Opera critically failed this test: It pasted the URL into the search field.)

Incidentally, iCab 4's browser chrome is worth studying. I'd cut one or two of those buttons, but overall, I like the design.

Anyway, this might be nice to have.

Tier two+. Shouldn't be *too* hard to implement; let's say a week.

---
D3. Store bookmarks somewhere other than an HTML file

The slowest part of OmniWeb's launch process, the last time I got frustrated enough to profile it, was loading the bookmarks. It's possible that they're just Doing It Wrong, but I don't see the merit of a Bookmarks.html file in the modern era anyway.

The replacement could be a plist. Some will leap to mention Core Data, but enabling users to set arbitrary order is very tricky with Core Data.

With plist storage, a day, maybe two or three. With Core Data, weeks.

Tier one. Bookmark storage is necessary for bookmarks, so this is high priority within the priority of the bookmarks feature at large.
~~~

Other anti-wants:

- Feed reading
- AutoFill, except for usernames and passwords
- Mail Contents of/Link to This Page
- Bookmark polling
- Mark Page (OmniWeb)
- A start page preference—Top Sites might be good eventually, but I think we should just use a blank page until then
- *Certainly* not a start page set by default
- Source editing, as opposed to viewing

[Mark Norman Francis]

> I'd like you to spend a short amount of space for each feature you'd like.

Background: I always have multiple windows containing multiple tabs open. Most of my browser woes are centred around this fact.

Estimations: utter guesswork, since I'm not an Obj-C programmer.


++ Saved session state - days - tier 1
Save/restore of open tabs and windows is a pre-requisite for any browser, but especially my primary browser. Should save state at any change, not on quit, so crashes don't lose my recent tabs.


++ Flash plugin blocking - weeks - tier 1
I disagree with ad blocking, but multiple tabs containing multiple animated/video flash ads will peg the CPU at 100%. This is unacceptable. Therefore without Flash blocking the browser is just a curiosity.


++ Tabs on the left - hours - tier 1
I'm left-handed, which often means I want/need things arranged in the opposite way to what seems obvious/correct.


~~ No search field
I turn off search fields in every browser I can. It irks me that I can't do it in Safari (my current primary browser).


++ Work with Choosy - days - tier 1
http://choosyosx.com/. I use this as my link broker. If it doesn't know about Rouse, I can't use Rouse.


++ Improved session state - days - tier 2
Keep a (separate?) cache of the currently active tabs, including history, form data and scroll position. Use this by default when restoring the session, so it is as if I had paused/resumed not closed/reloaded. This is most useful when offline or on 3G tethered connections, but also when there are 100 tabs to restore, which can take ages even on broadband.


++ Session restore dialog - days to weeks - tier 2
Restoring a crashed session that immediately results in another crash is awful UX. Upon launch, offer a dialog that allows removal of individual windows/tabs in the session state before restoration. Allow it to appear only after a crash, or always. Optional polish would be to view thumbnails/cached views not just a list of URLs.


~~ JS should not be all-or-nothing
I can turn off JS support in Safari. But only cross-browser. Like custom styles and flash blocking, this should be per-tab and site whitelistable. In fact, I want ClickToJS. ;)


++ Combine the status bar and the location fields - days - tier 2
No-one with any sense uses the status bar for anything in JS anymore. It is only for "where does this link go?" There is already a place that displays URLs. Use that when hovering/focusing a link. Logical extension of putting the page loading progress bar in the location field.


++ 1Password integration - weeks - tier 2
Not being able to log into websites renders them useless. I no longer remember passwords to almost every site I use, keeping them in 1Password instead. The bookmarklet would be an acceptable holding action only. No bookmarklet support either would render Rouse practically useless.


++ Page vault - weeks - tier 3
Allow me to put individual tabs/windows of the session into a stored state which guarantees that they are cached for immediate restoration. Allow me to later restore/merge these into the current session. Think OmniWeb's workspaces, but not all-or-nothing.

Use case: I have several tabs open on a topic I'm researching, but that gets postponed for two weeks whilst I work on something more high priority. Currently I minimise the window and ignore it until needed. I have _many_ minimised Safari windows.


~~ Chrome has tabs above the location
Dumb. I am _always_ hitting the tabs instead of the window area, because there just isn't enough target area.


++ Intelligent location bar - days to weeks - tier 3
Typing into the location bar should match the titles/content of pages in the history, not just the URL. Frequently visited and bookmarked pages should rank _way_ higher. Typing "rouse" should match http://waffle.wootest.net/2010/04/18/rouse/ as well as http://groups.google.com/group/rouse-dev/, but typing "rouse google" should only match the latter (deliberate example - don't make me remember in the same order as the URL, allow me to mix both URL fragments and content fragments).


++ Spatial keyboard navigation - weeks - tier 3
Being able to press Tab to move from link to link is nice. Up/Down/Left/Right is better. Find links in page is perfect (especially if I don't have to type it exactly as shown; see "Intelligent location bar"). Keyboard-only "open in new window/tab/background tab" also required.


++ iPhone OS-style page zooming - weeks, if indeed at all possible - tier 3
Text-only zoom is lame. Layout-aware zoom is awesome.


~~ Fluid shares state with Safari
Among the many reasons to create a single-site browser is so you can have multiple copies for multiple logins (think Gmail personal and work), or to stop cookies being shared across every page you visit on the internet (think Facebook), or to maintain a completely clean environment (think internet banking). SSBs should be stand-alone programs with their own state, not telekinetic clones of another browser.


++ Shared bookmarks - weeks - tier 3
Bookmarks in the browser doesn't work for anyone who routinely uses multiple browsers. Mostly I just use Google again, or store them in delicious.com. A handful (mostly bookmarklets) are stored in Safari, and only so I can sync them to my iPhone. I bring up bookmarked pages using LaunchBar, not a browser interface. Doing anything clever at all with bookmarks that doesn't result in them being stored in some shared location (Safari, a web service...) strikes me as a waste of time. The only bookmarks I'll keep in Rouse are bookmarklets such as Instapaper's "Read Later".



-- Norm.

[Mark Norman Francis]

> I use Leech and love it. I wish my browsers would use it for all their downloads.

+1.

> R4. Ability to enforce styles

> [...] Tier two. I'll estimate several weeks to implement this, not knowing exactly how to do so. The Web Inspector in OmniWeb offers a vague hint.
A quick-and-dirty way would be to simply look up the current hostname in a "styles" folder, and add any matching CSS files (eg. ".../styles/www.google.com.css") to the document head as extra linked stylesheets. Then later put a UI on that. Then even later (like never) allow you to fiddle around in the Web Inspector until you're happy and then save the changes you've made.

> - Source editing, as opposed to viewing

I know this was an anti-want, but don't we get that for free with the Web Inspector?

-- Norm.

[Jesper]

Here are some comments.

> ++ Saved session state - days - tier 1
> Save/restore of open tabs and windows is a pre-requisite for any browser, but especially my primary browser. Should save state at any change, not on quit, so crashes don't lose my recent tabs.

Strongly agree.

> ++ Flash plugin blocking - weeks - tier 1
> I disagree with ad blocking, but multiple tabs containing multiple animated/video flash ads will peg the CPU at 100%. This is unacceptable. Therefore without Flash blocking the browser is just a curiosity.

I'm interested in making sure that Rouse can deliver stronger support
than ClickToFlash, but it's hard to ignore that ClickToFlash works
now.

> ++ Tabs on the left - hours - tier 1
> I'm left-handed, which often means I want/need things arranged in the opposite way to what seems obvious/correct.

I've been hearing this. It's a matter of personal taste; nothing else
needs be said.

> ++ Improved session state - days - tier 2

> ++ Session restore dialog - days to weeks - tier 2

I'm really interested in being able to solve this, but I'll have to study it.

> ~~ JS should not be all-or-nothing
> I can turn off JS support in Safari. But only cross-browser. Like custom styles and flash blocking, this should be per-tab and site whitelistable. In fact, I want ClickToJS. ;)

Per-site preferences are on the todo list.

> ++ Combine the status bar and the location fields - days - tier 2
> No-one with any sense uses the status bar for anything in JS anymore. It is only for "where does this link go?" There is already a place that displays URLs. Use that when hovering/focusing a link. Logical extension of putting the page loading progress bar in the location field.

This was one of the first things I investigated at all; the point
being that they both deserve prime placement, but are rarely used
simultaneously. My conclusion was that it needs to be done well, and
that I'd have to settle for what to place in them both in the first
place. But I like that people are thinking what I'm thinking.

> ++ 1Password integration - weeks - tier 2
> Not being able to log into websites renders them useless. I no longer remember passwords to almost every site I use, keeping them in 1Password instead. The bookmarklet would be an acceptable holding action only. No bookmarklet support either would render Rouse practically useless.

This is starting to become weird because I have no idea how 1Password
would like to integrate. They have what basically amounts to some
hacks to get into Safari, and Firefox requires an extension which also
does a lot more. I think I'm going to have to talk to someone there to
get this down.

Bookmarklet support is coming in a big way.

> ++ Page vault - weeks - tier 3
> Allow me to put individual tabs/windows of the session into a stored state which guarantees that they are cached for immediate restoration. Allow me to later restore/merge these into the current session. Think OmniWeb's workspaces, but not all-or-nothing.

Good point; solve a problem in the right way.

> ++ Intelligent location bar - days to weeks - tier 3
> Typing into the location bar should match the titles/content of pages in the history, not just the URL. Frequently visited and bookmarked pages should rank _way_ higher. Typing "rouse" should match http://waffle.wootest.net/2010/04/18/rouse/ as well as http://groups.google.com/group/rouse-dev/, but typing "rouse google" should only match the latter (deliberate example - don't make me remember in the same order as the URL, allow me to mix both URL fragments and content fragments).

Planned.

> ++ Spatial keyboard navigation - weeks - tier 3
> Being able to press Tab to move from link to link is nice. Up/Down/Left/Right is better. Find links in page is perfect (especially if I don't have to type it exactly as shown; see "Intelligent location bar"). Keyboard-only "open in new window/tab/background tab" also required.

I want my favorite Firefox hidden features: type-ahead find, along
with ' to put you in link-type-ahead mode.

> ++ iPhone OS-style page zooming - weeks, if indeed at all possible - tier 3
> Text-only zoom is lame. Layout-aware zoom is awesome.

Easy on the Buck Rogers, sir.

> ~~ Fluid shares state with Safari
> Among the many reasons to create a single-site browser is so you can have multiple copies for multiple logins (think Gmail personal and work), or to stop cookies being shared across every page you visit on the internet (think Facebook), or to maintain a completely clean environment (think internet banking). SSBs should be stand-alone programs with their own state, not telekinetic clones of another browser.

This is hard because WebKit uses the NSURL subsystem, which shares a
system cookie jar by default. There's a workaround and maybe it works
perfectly fine everywhere, but it *looks* nasty on account of being
brittle manual labor.

> ++ Shared bookmarks - weeks - tier 3
> Bookmarks in the browser doesn't work for anyone who routinely uses multiple browsers. Mostly I just use Google again, or store them in delicious.com. A handful (mostly bookmarklets) are stored in Safari, and only so I can sync them to my iPhone. I bring up bookmarked pages using LaunchBar, not a browser interface. Doing anything clever at all with bookmarks that doesn't result in them being stored in some shared location (Safari, a web service...) strikes me as a waste of time. The only bookmarks I'll keep in Rouse are bookmarklets such as Instapaper's "Read Later".

I'd like to see feedback on suitable places to store these.

Feedback on Peter's message will be forthcoming.

And with regards to source editing, I think I know what Peter's
referring to. If you stumble upon a site you really want or have to
read but it's got awful styles, in OmniWeb, which has a serviceable
source editor, you can just pop that open and hand remove the stuff
that's making it illegible, and tell the source editor to update the
page inline to have the changes 'take' without reloading anything.
That kind of swift editing takes time, thought and care when using the
Web Inspector. There's a reason Firebug lets you drop into "edit this
node's outerHTML" mode; expediency.

/Jesper

[Peter Hosey]

On May 19, 2010, at 16:22:22, Jesper wrote:
> And with regards to source editing, I think I know what Peter's referring to. If you stumble upon a site you really want or have to read but it's got awful styles, in OmniWeb, which has a serviceable source editor, you can just pop that open and hand remove the stuff that's making it illegible, and tell the source editor to update the page inline to have the changes 'take' without reloading anything. That kind of swift editing takes time, thought and care when using the Web Inspector.

The anti-want is for the entire source editor. Viewing is enough for me. I have never found a use for the source editor, before or since the addition of the Web Inspector.

> There's a reason Firebug lets you drop into "edit this node's outerHTML" mode; expediency.

Editing HTML (Firebug) and editing styles (Web Inspector) are two different things. I do change/override styles in my browser; I do not change/override HTML in my browser.

Moreover, the ability to edit the source gets in the way of viewing the source (for one example, a stray keystroke in the source editor means I will have to confirm closing the source). A source viewer-only does not have such problems.

[Peter Hosey]

On May 19, 2010, at 15:37:55, Mark Norman Francis wrote:
>> - Source editing, as opposed to viewing
> I know this was an anti-want, but don't we get that for free with the Web Inspector?

I didn't know they'd added document editing to it. Cool!

It's not a *source* editor, though. It has a source view, but that's not editable.

The WebKit team could add a source editor to the Web Inspector and I would not oppose it, since it is sufficiently hard to get to that I would not run into it when after something else. The problem with OmniWeb's separate source editor is that I run into it when trying to *view* the source.

If Rouse does have a separate source editor, it should require a button click within the viewer to enter, perhaps with a preference option to enter it by default.

[Jesper]

> The anti-want is for the entire source editor. Viewing is enough for me. I have never found a use for the source editor, before or since the addition of the Web Inspector.

I consider the source editor something I have to port because I do
depend on it in the way I described. It might not necessarily open up
in edit mode by default, though.

/Jesper

[Mark Norman Francis]

> I didn't know they'd added document editing to it. Cool!
> It's not a *source* editor, though. It has a source view, but that's not editable.

It is in the nightlies. You can either double-click on an element to alter it's attributes or right-click and choose "Edit as HTML". It is a deliberate action, and hard to do accidentally.

I use it a lot when developing web pages. Change some HTML, add some styles, see if what I'm thinking actually works. When happy, replicate in templates and reload the page. Rinse, cycle, repeat.

-- Norm.

[Peter Hosey]

On May 20, 2010, at 04:35:27, Mark Norman Francis wrote:
>> I didn't know they'd added document editing to it. Cool!
>> It's not a *source* editor, though. It has a source view, but that's not editable.
>
> It is in the nightlies. You can either double-click on an element to alter it's attributes or right-click and choose "Edit as HTML". It is a deliberate action, and hard to do accidentally.

Very good.

At any rate, I wasn't proposing blocking off the Web Inspector or any part of it, merely not having a source editor like OmniWeb's.

On May 19, 2010, at 23:28:34, Jesper wrote:
> I consider the source editor something I have to port because I do depend on it in the way I described. It might not necessarily open up in edit mode by default, though.

That would work, assuming you aren't using the Web Inspector's editor by then.

[Jesper]

>> I consider the source editor something I have to port because I do depend on it in the way I described. It might not necessarily open up in edit mode by default, though.
>
> That would work, assuming you aren't using the Web Inspector's editor by then.

I just might, if Edit as HTML works as advertised and is available in
Safari by the time I make that decision.

/Jesper