Re: Plans for ahead

[H. Nikolaus Schaller]

Hi Greg,

Am 04.12.2015 um 08:04 schrieb Gregory Casamento <greg.casamento@gmail.com>:

> Nikolaus,
> 
> There are many reasons why SWK is behind:
> 
> 1) It has a very large head start...
> 2) WebKit has critical mass.
> 3) Tons of people are contributing to it and, more importantly, testing it
> 4)  it is well known and widely used.

Yes, you are right. But all those arguments also hold for the whole GNUstep
project compared to anything else. But do we stop it for any of these reasons?

> 
> The proper answer, instead of your repeated "if someone writes a patch
> and the backend supports it" should be a simpler "no"....

Well, where could we be today if there had been just 10 contributions per month
in the past ~5 years since I presented SWK the last time at FOSDEM...

For the same reasons I have reduced the number of my contributions to GNUstep...

>   SWK is
> missing many critical features, not the least of which is javascript
> support.

It has some rudimentary JS support (ECMAscript = JS)... E.g.

http://svn.gna.org/viewcvs/gnustep/libs/simplewebkit/trunk/Sources/ECMAScriptParser.m?revision=37330&view=markup

But indeed nothing which works for doing anything useful.
Mainly the connection between JS and the DOM trees is missing.

> 
> There are many man-years of work needed to bring SWK up to the level
> where it can be considered on par with WebKit and at this point it's
> not practical to wait for it to become so.  What I proposed earlier is
> the best way to go to get a browser up and running in the short term.

I am not saying "no" to alternate approaches. Yes, please go ahead!

If SWK is enough pain so that someone eventually provides a really better 
browser,
SWK has reached its goal :)

BR,
Nikolaus


> 
> GC
> 
> On Fri, Dec 4, 2015 at 1:52 AM, H. Nikolaus Schaller <hns@goldelico.com> 
> wrote:
>> 
>> Am 03.12.2015 um 20:57 schrieb Ivan Vučica <ivan@vucica.net>:
>> 
>> On Thu, Dec 3, 2015 at 6:45 PM H. Nikolaus Schaller <hns@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
>> 
> 
> 
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/