Side note: we broke the 100 posts mark in the thread -- congratulations, everyone, on a centithread ;-)
We have an HTML viewer, and it's quite good at that. But it's not a browser, and should not be -- it's too much work for too little benefit, not to mention performance can only suffer.
Well, with this way of argumentation you could say:
GNUstep is an old-fashioned technology demo and is quite good at that. But it is not an OS or desktop and should not be -- it's too much work for too little benefit, not to mention performance can only suffer.
I.e. such arguments do not help.
You are misinterpreting my words.
I did not run SWK and Vespucci locally (never got around to it), but Riccardo has demoed it at the Dublin meeting. I am impressed by it, but not as a replacement for a full browser. Instead I view it as an excellent lightweight tool for viewing simple HTML documents, such as our documentation. I value it as GNUstep's graphical alternative to w3m, links and lynx -- not as a GNUstep alternative to Firefox and Chrome.
Does that clarify?
- Can it do 3d transforms?
If someone writes a patch (and the backend supports)
- Does it do WebRTC and WebGL?
If someone writes a patch (and the backend supports)
- Will I be able to access
Outlook.com and Google Docs in it?
If someone writes a patch (and the backend supports)
- How well do web applications self-declare support for it?
If someone writes a patch (and the backend supports)
But this is exactly the point. How much 'someone should write the patch' does one go into to support modern web? How many developers work on WebKit, Blink and Gecko?
SWK has value and is worth improving. But a GNUstep-based desktop needs a modernized engine wrapped inside a GNUstep-based chrome*, with bitmaps for certain commonly-themed form elements are provided by GNUstep's theming code. Which is where Vespucci-over-Blink using CEF** becomes interesting.
* chrome, in this context, being the term used for 'web browser's elements displayed around the contents of the page'.
There are really good engines that support running web-based applications well.
Yes, they have become really big beasts to support thousands of pages of standards.
Yes, which SimpleWebKit should not be, but which
Yet even long-standing, reasonably well written engines such as Opera's Presto are being dropped.
SWK fills a need for a performant HTML viewer, but is not a proper web browser engine.
As an observation of the current status you are very very right. But is it limited by principle or by manpower?
Manpower.
But I don't object to viewing that as a matter of principle either.
Once you start doing all the crazy things modern browsers are doing, how simple is SimpleWebKit going to be and how fast is it going to be? Will SWK, for security reasons, start separating tabs into different processes? Will its renderer run in separate process(es)? Will its JS implementation start supporting multiple security contexts (which, I recently discovered, Chrome does -- extension code injected into a web page seems to run with different permissions, even though it lives in the same web page)?
It's not a problem of can it eventually become a beast supporting thousands of pages of standards.
As its principal author, do you personally view that it should?
A good GNUstep browser would use an existing engine, but integrate with a GS-centric environment:
- by using GNUstep's theme for its chrome,
Isn't that working out of the box? Vespucci & SWK just use the NSView subclasses provided by GUI.
It does.
But please consider what a modern-day user expects of something that s/he would call a browser: if we assume that on top of that list is "it should open Facebook and Gmail" (arbitrarily chosen websites), then we do not currently have a fully-featured GNUstep browser.
Let's look at options:
- Vespucci, being a GS-based chrome for SWK, definitely is themed, that is not disputed. But it cannot open Facebook or Gmail.
- Chrome, being a GTK-based chrome for Blink, is fully featured, but is unaware of GNUstep's themes, save panels, et al.
- Firefox, being a GTK-based chrome for Gecko, is fully featured, but is unaware of GNUstep's themes, save panels, et al.
- by exposing GNUstep's Services in its textboxes and for its images,
- by using GNUstep's save panels, by understanding the concept of bundles,
what do you mean/expect by that?
If I right click->"save as" on a photo, whatever is generally accepted as "a GNUstep browser" should display GNUstep's save panel.
- by storing its preferences and cache inside GNUstep's folder structure (~/GNUstep/),
AFAIK it uses NSUserDefaults and WebPreferences which can be adapted to GNUstep's folder structure (if they don't do already).
Not disputed, if we talk about Vespucci + SWK.
But will it *currently* open and correctly render
cnn.com (and any interactive elements it may have)? Will it do so in the next two years? If it ever does, it will become as bloated and slow as any other engine. Should it?
If we talk about Chrome and Firefox, neither currently does that.
- by registering web shortcuts (e.g. .url files) with GNUstep's extension registry,
- by using GS menus (whatever they are as configured by the user) and therefore by using GS-like keyboard shortcuts
In Vespucci, nothing is missing there.
- in case we have a 'quit app quickly, but restore NSDocuments and its windows on start', integrate with that
etc.
Only Vespucci (which will not serve as my browser any time soon) could hypothetically integrate with such an upgrade to NSDocumentController.
Providing an alternate implementation for use by Vespucci seems useful.
You can extend Vespucci and replace SWK if you like. It should in theory be as simple as replacing the WebKit.framework or linker search path.
Which is exactly the ideal outcome.
But I don't want to argue at all against any alternatives to SWK and Vespucci. I just make aware that "something" exists.
The alternatives may be much better and easier to develop, but do not exist.
I am aware it exists, and I am impressed by SWK.
But it does not, and should not, serve every use.
If we would contribute as much code as we recently started to write e-mails what *should* be done, there would be more progress :)
I do not disagree here.
Of course, I see other areas in GS as currently needing more love than wrapping a browser engine in a way that can be integrated into Vespucci. :-) For example, I would really like to be able to direct people to 'apt-get install gnustep-session', or 'download the live CD ISO here'. Crucially, I would also like to be able to provide an updated gnustep-session with a single command.
Simple goals, but they are proving to be tricky to actually bring to completion.
If achieved, perhaps I will still feel that the lack of a browser integrated into the gnustep-session impacts the UX. But I'm not there yet. :-)