Am 03.12.2015 um 20:57 schrieb Ivan Vučica <i...@vucica.net>:

> On Thu, Dec 3, 2015 at 6:45 PM H. Nikolaus Schaller <h...@goldelico.com> 
> wrote:
> just for the records because it might look like a green field:
> 
> we have a browser and a browser framework for quite a while.
> 
> But currently nobody is working on them:
> 
> http://www.gnustep.org/softwareindex/showdetail.php?app=8
> http://wiki.gnustep.org/index.php/SimpleWebKit
> 
> 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.

> 
> 
> - 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

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Reply via email to