Thanks for the explanation, Dave. It’s good to hear that the options are being periodically reviewed; hopefully a better one will present itself. I think I remember trying pgAdmin back when it was running on WebEngine, as I remember having a lot of display issues on my Mac. pgAdmin has certainly come a long way since then. I know from experience that it’s tough trying to be everything to everyone, and I appreciate your ongoing efforts to deal with all these different usage scenarios.
Keep up the good work!
Hi
It seems like a lot of effort is being spent on supporting all of the major browsers out there, and working around the quirks that arise from pgAdmin4 being browser-based. Recognizing, however, that using a browser as he basis for screen output achieves a major goal of platform independence, I have to wonder if it might make more sense to target someone’s “web view” software (e.g. a lightweight browser designed for generating output from a local server/daemon, and not loaded down with all the extra “stuff” that comes from hitting any web server in the world and trying to be everything to everyone as the major browsers do.
One example of the quirks that I refer to are the hoops you (as the software developers) and us (as the users) have to go through to get a “standalone” desktop version that does a reasonable job “as compared to other desktop software” of restoring state when reloaded. All the extra work of configuring the local system, etc. would be unnecessary with a dedicated web view. All the effort to support all of the major browsers would be unnecessary, etc.
Are there sound technical reasons why this approach has not been adopted?
2 actually:
1) We need to support different browsers for people running in web/server mode. We know this is a popular option so it can't really be ignored (50M+ pulls on Docker alone now -
https://hub.docker.com/r/dpage/pgadmin4)
2) Early versions of pgAdmin in desktop mode worked exactly as you suggest - it used browser components in Qt instead of running as a tray app and calling the system browser. We originally used Qt WebEngine (based on Chrome), but it turned out that the performance of that on Windows was pretty poor, and we got a lot of complaints. We switched to Qt Webkit (which was forked at
https://github.com/qtwebkit/qtwebkit after it was superseded in Qt by Qt WebEngine), but that was problematic on macOS where there were various rendering issues, plus it's not got the level of maintenance we really need.
There has also been a PoC of hosting pgAdmin inside of Electron, the NodeJS runtime used by things like Visual Studio. That's potentially viable, but it is quite kludgy because it's using Node to spawn the Python code. The other option (which I think is the most likely to succeed, but also requires by far the most work - many months probably - is to integrate CEF (Chromium Embedded Framework) into Qt. There have been a couple of PoC projects to do that, but they're not maintained and only supported Windows iirc.
I do periodically re-review the options, in the hope that someone will have done the work we need with CEF, but unfortunately that hasn't happened yet (I last checked maybe a month back).
--
