Behaviour of web view / default web view document?

Celbridge Development
1

I was just working on a README for an example project, and linked to a website in the markdown

when I clicked on the link in the markdown preview panel, I got the option to open the web page in a external web browser

  • in this case it was a single page to view, and opening in a webview panel in Celbridge would have been find

when I’m working in Celbridge I try to note the actions that lead me to have to move out of the app - and see if there is a way to add that functionality in Celbridge to improve workflow and keep users in the app

so I suppose it’s a debate about how much web browser functionality the “.webapp” webview should offer?

some suggestions / alternatives:

  1. default (hidden) web view panel (along with “.webapp” files)
  • each Celbridge project comes with a hidden, default webview, so when an external link is clicked from, say, a markdown file, it will open in that web view
  • projects can have other (visible) “.webapp” files, linked to URLs in their properties
  • but when an external link is clicked from a webview, then it will open in / user be asked to choose an external browser application
  1. single webview panel per project
  • every project has a single web view
  • no individual “.webapp” files - but instead a list of URLs for that webview (a bit like bookmarks)
  • so if an external URL link clicked from webview or markdown viewer or whatever, then it will open in that single webview
  • can add “Back” buttons (and perhaps simple “History” for basic web browser functionality
  1. full web browser functionality - built into Celbridge
  • although Celbridge is a workbench application, going off to look at web pages is a basic sub-task of any project, so we could offer full browser functionality inside Celbridge - such as a separate ‘browser mode’ for each project where there is a set of tabs for browser URL pages, shortcuts etc.
  • so user would switch from files TABS to URL/webpage TABS somehow
  • could have a “.celbridge” setting to use either built-in browser or a named or the system default browser for web links… so users aren’t forced to use built-in Celbridge browser if they don’t want to

I suppose I think we can improve the current weblink experience from the current one

  • it seems odd / a bit of work to have to create several different “.webapp” files, when all I’m doing is writing a URL for each one - why can’t I just write that list of URLs somewhere, and easily choose from that list to view a web page within Celbridge
  • the lack of a “Back” button is annoying, if I’m testing, say, Sphinx pages or navigation of web pages I’m editing with Celbridge (perhaps some function key works? or backspace? but I’d like a simple <- arrow please :slight_smile:

I think this all goes back to the philosophy of a general-purpose workbench application like Celbridge

  • it needs to provide enough functionality for basic/code tasks for each use case
  • but not attempt to replace a dedicated app for every use case under the sun
  • so it’s a matter of the balance

perhaps these issues will be less of a problem once the new extension system is working

  • someone may implement a full web browser mode in an extension, for users focussing on that use of Celbridge within their project work
  • and another one for more sophisticated HTML or Python or Svelte editing and so on etc.
2

I agree with a lot of your points here Matt. The current .webapp implementation is based around the idea of treating web applications like documents. This has some real advantages compared to the traditional browser bookmark/favourites approach, the main one being it neatly avoids the common problem of having to navigate through a gazillion open tabs.

That said, there are a multitude of use cases for an integrated web-browser and the current .webapp approach definitely isn’t a fit for all of them. We’re also constrained by the relatively limited API for WebView2, as it doesn’t expose a lot of the functionality you would need to implement a full browser experience (e.g. password management).

I’m thinking a pragmatic and user-centered approach would be to give the user lots of ways to control the behaviour of the .webapp document via the inspector. For example, how to handle navigating to external websites, downloading files, permitting cookies, blocking known tracking URLs, that kind of thing. To avoid overwhelming the user with options we would also likely want to provide pre-built presets for the most common use-cases.