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! > On Aug 25, 2020, at 1:42 AM, Dave Page <dp...@pgadmin.org> wrote: > > Hi > > On Sun, Aug 23, 2020 at 11:55 PM Jack Royal-Gordon <jac...@pobox.com > <mailto:jac...@pobox.com>> wrote: > 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 > <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 <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). > > -- > Dave Page > Blog: http://pgsnake.blogspot.com <http://pgsnake.blogspot.com/> > Twitter: @pgsnake > > EDB: http://www.enterprisedb.com <http://www.enterprisedb.com/> >
