Re: [pgadmin-hackers] [pgAdmin4] [PATCH] History Tab rewrite in React

Hi

On Wed, Jun 21, 2017 at 3:23 PM, Sarah McAlear <smcalear@pivotal.io> wrote:
> Hello!
>
> Thank you for committing the patch!
>
> We are currently looking into CEF
> (https://bitbucket.org/chromiumembedded/cef) as an alternative to QTWebKit.
> So far it looks promising. It works on all platforms. It is the base for
> Google Chrome, so it should be maintained for some time to come. Version 60
> is currently in development. At this point we are developing a prototype for
> Mac as a proof of concept. We will keep you posted as we go.

Cool - we looked at CEF before, but...

> We are able to launch the server in one terminal and launch our browser app
> in another and use pgAdmin from that app.

... if memory serves, the problem we found was that on Windows it's
built using VC++ 2015, which doesn't play nicely with Python which
uses 2013 (as do the PostgreSQL utilities). Moving everything to 2015
would be non-trivial to say the least.

> It would be useful to have a framework to follow to decide what library will
> be used to support pgAdmin in the future. What metrics are you currently
> using? What data should we collect on prototypes in order to help the
> selection process?

Oh, it's highly scientific :-p. As the biggest issue between the
options is finding one which will work with our set of dependencies,
and supports new windows/tearable tabs (if it were no longer to be
embedded in our runtime), it's really down to:

- Getting a startup time of ~20 seconds or less in my test VM and on
my 16GB i7 SSD based desktop under Windows 10
- Ensuring that node expansion/load times are basically instant with a
local database server.

> Thanks!
> João & Sarah
>
> On Wed, Jun 21, 2017 at 6:37 AM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi George
>>
>> On Tue, Jun 20, 2017 at 10:29 PM, George Gelashvili
>> <ggelashvili@pivotal.io> wrote:
>> > We learned that the underlying issue was related to react-dom's
>> > SyntheticEvent.augmentClass function being undefined.
>> >
>> > This seems to be caused by attempted property assignment after the
>> > SyntheticEvent had been replaced by a Proxy of itself. This works fine
>> > in
>> > Chromium et al, but QtWebKit doesn't deal with Proxy Event objects well.
>> > Moving the augmentClass definition and assignment up above the Proxy
>> > stuff
>> > resolves the issue in a PR to React:
>> > https://github.com/facebook/react/pull/10011
>> >
>> > This has a decent chance of being rejected, as QtWebKit appears to be
>> > losing
>> > support.
>> >
>> > While and if this is being sorted out, we vendorized React, as one does.
>> > Here are patches on the version we were using previously, and the fix
>> > from
>> > the above PR.
>>
>> Thanks - committed.
>>
>> > We started talking to some Pivotal folks about QtWebKit to see if we can
>> > fix
>> > the Proxy Event issue in the browser.
>> > We are also looking into replacements for QtWebKit.
>>
>> Yeah, so here's the current state of play there:
>>
>> - Some major Linuxes don't seem to have added QtWebEngine to their
>> packages yet.
>>
>> - QtWebEngine has multiple issues under Windows; it's *very* slow, and
>> doesn't play nicely with some graphics cards and Remote Desktop.
>>
>> - QtWebKit (official) has rendering issues, and has been deprecated by Qt.
>>
>> - QtWebKit (annulen) fixes the rendering issues, and generally works
>> well, but is very slow on Windows (though not as bad as QtWebEngine).
>>
>> - QtWebKit (annulen) is a fork, which may or may not live for long.
>> It's also still quite far behind the latest WebKit code.
>>
>> - ActiveQt is looking extremely promising on Windows, embedding IE as
>> the browser. It's speed is on par with QtWebKit on Mac. We're
>> currently working on handling multiple tabs/windows and sharing
>> cookies between them.
>>
>> - Electron and Node-Webkit are performant options, but don't support
>> tabs, and may not even support multiple windows in the same session.
>>
>> Neel is currently working on the ActiveQt option for Windows. I've
>> been very impressed by its speed, and of course, JS support is per the
>> installed version of IE. If that pans out, we could potentially move
>> back to QtWebEngine on Linux/Mac (where the latest versions may well
>> be improved), and use ActiveQt on Windows, thus dropping WebKit
>> altogether.
>>
>> Another option would be to help get the annulen QtWebKit port up to
>> par; fix the performance issues on Windows, and get it up to the
>> latest WebKit code. That seems like it would take much more work, and
>> I don't think our team has the capacity for that. If yours does, then
>> it's certainly worth exploring.
>>
>> Ashesh is also planning to spend a little more time looking more
>> deeply at Electron/Node-Webkit as well as other options, once he's
>> finished his current work.
>>
>> Other thoughts/experiences are definitely welcome.
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company