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.
- 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)
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. 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?
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. - 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? - 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). - 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
What is missing there? - in case we have a 'quit app quickly, but restore NSDocuments and its windows on start', integrate with that etc.
Do we have that?
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.
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.
If we would contribute as much code as we recently started to write e-mails what *should* be done, there would be more progress :)
BR, Nikolaus
|