Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ez34r-0002y0-H1 for pgadmin-hackers@arkaria.postgresql.org; Thu, 22 Mar 2018 16:28:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ez34q-00058c-3T for pgadmin-hackers@arkaria.postgresql.org; Thu, 22 Mar 2018 16:28:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ez34p-00057t-Sp for pgadmin-hackers@lists.postgresql.org; Thu, 22 Mar 2018 16:28:31 +0000 Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ez34l-0003k6-II for pgadmin-hackers@postgresql.org; Thu, 22 Mar 2018 16:28:31 +0000 Received: by mail-wm0-x236.google.com with SMTP id f125so17201220wme.4 for ; Thu, 22 Mar 2018 09:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M4mPcBqeKi01tkTQmfIs5E/q5XWFWAKXfxSSdNecOCo=; b=AvPxs4lx4rKR0xcturEUSjGxraqDn0GM6OrLiXytYzv0wHOFI3UMLK6VLooD8CuWHM VrOapncvteS4zyB0r0ZiNN1Oy5Isotg8rKwkvtlizCXgsUu+wH49j741+2bwT+ZvtBQh Le90tHe0rXKdPTHSIPSBJmwWxRgxrHo9/1oDOFWQmQlYh24e0X0vs3lRXxHE47VcK+cs sQw81urJIihbmA+HlOYJj0CPZPjKivHZsxnx94j2xtL8lyr2XHTRTfAaNWUd4u5/zyas NBnE22ng8vXel7eM2N/iQTGNHlMXu9Re1FM67wP3VTkzKNXIByyE9PSEUIab1TElANCS lPjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M4mPcBqeKi01tkTQmfIs5E/q5XWFWAKXfxSSdNecOCo=; b=DpkRsYlCDmOt3f8w1L3Hs/Y6sjHKujDV7kBboh2Ug/CB/QXIln397G2paEVmh/9Vmt k7miakYosxVOAPnl+8MlElne4cFTnvHRk65/sRaVPZLiplR2qt7cy8wbXg5Jtkfj80WA GN88TRxtTU8cjEwJpmX2qHD9s/Cyiace3k3qARdhDD+/Uarvqxm57DnBsMvgAJETL16f Xe7xNKF/j+9Tx8NPBXF0N/vGz5iqJmMBCTGmjXk2BHV/ZkfK7EHrurhnMNqb8y3lphQI KpxcemIpLVbXiBx9slRHGdAgbkEXBVcGPyLrMzx33NBIgWanuwT8fxZHHkWjN//rclBt TX/Q== X-Gm-Message-State: AElRT7GQ1rUbFVr4gclkIuisymKccgeQp2oVilZKEtGSW2KT6lCTJolp HzPYU82t8yUDSAvE6TIei/8JFF7WLKYNmxrf1TdFrQ== X-Google-Smtp-Source: AG47ELuXfwCXcnfLW6Qo38C0bQC11mk8uZHtfy5wb88jPZJHf0l9oCwXD8iek4ZgD5sMd+O/O9ygHdPQlIFK2S4sFM4= X-Received: by 10.28.91.65 with SMTP id p62mr1327424wmb.140.1521736106448; Thu, 22 Mar 2018 09:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.69.220 with HTTP; Thu, 22 Mar 2018 09:28:25 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Thu, 22 Mar 2018 16:28:25 +0000 Message-ID: Subject: Re: Showstopper desktop runtime issue To: Magnus Hagander Cc: Joao De Almeida Pereira , Murtuza Zabuawala , pgadmin-hackers , Akshay Joshi , Neel Patel , Ashesh Vashi , Robert Eckhardt Content-Type: multipart/alternative; boundary="001a1144161a11304e056802cc7b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --001a1144161a11304e056802cc7b Content-Type: text/plain; charset="UTF-8" Hi On Thu, Mar 22, 2018 at 4:17 PM, Magnus Hagander wrote: > > > On Thu, Mar 22, 2018 at 3:57 PM, Joao De Almeida Pereira < > jdealmeidapereira@pivotal.io> wrote: > >> Hello Hackers, >> Here is our take on the 3 options present: >> > > This looks like a good summary, so I'm going to pick this one to comment > on :) > :-) > > > > >> 1) QtWebkit and QtWebEngine >> > >> Pros: >> - Webkit is a mature technology that as been around for some time >> - Apparently the Fork of Webkit we were using as been catching up >> Cons: >> - We are using a Fork >> - It is to far behind of the today browsers and the competition keep >> evolving making it even harder for them to catch up >> - Problems with the environment from the past, lagginess, lack of support >> >> > Yeah, this one hasn't exactly caused a "little" set of complaints so far. > It might be workable for absolute stop-gap, but not beyond that. > Right. > > > >> 2) Rework runtime to find a running PGAdmin and attach to it >> >> Pros: >> - We already made the big move from Webkit to this version >> - Add smarts to the application to do not run itself if it is already >> running, or kill the currently running application >> >> Cons: >> - More C++ code thrown around >> - Add more dependency on our QT application >> - Have specific code for Gnome, not even a OS version but a window manager >> > > > Annoying as it is, I think this is the least bad option at this point. > > > 3) Electron >> >> Pros: >> - Full Javascript runtime, no more C++ code to handle >> - Self packaging for all the environments >> Cons: >> - No fully supported on Linux based OS with old libstdc++, (This might >> solve the problem: https://github.com/mattermost/desktop/issues/312) >> > > > Losing support for things like RHEL6 would make it completely unworkable > for several of my largest customers. Particularly in large enterprise > organisations, this would be a very substantial issue. > That's good to know. There are clunky workarounds (shipping different libcs for example, but that potentially adds licensing issues). Sidenote: It would only be an issue for desktop mode. Web mode should not be affected. > > > >> - CPU/RAM high utilization (Found a issues around and the majority of >> them have solutions like CSS animations running or settings on the created >> windows) >> > > This does sound bad. But do we actually know if this is worse in Electron > than it is in the option #2? I mean sure, we point to things like Slack, > but that may not be because of electron, it may be because the app running > inside it? > We don't know for sure, but we do know that Chrome in general is a bit of a hog. It's certainly not a stretch to think a combination of those things are why people (correctly) see browser based apps as being more resource hungry. > > > >> - Electron does not support tabs by default, only HTML tabs >> > > I think that also makes it a showstopper. This was another one of the main > complaints I have personally heard from people going from pgadmin3 -> > pgadmin4, and enough to make people not want to use it at all. It would be > really bad to go back to that. > To clarify; it would mean no tabs, but not single window. That was already working in the PoC. In other words, helpfiles, the debugger and query tools could all be opened in new windows, just not tabs on the same window that could be docked and un-docked. I suspect for most people that would be enough. > > > > After combing through these options with some pros and cons here are my >> thoughts: >> 1) This options was always cluncky from the beginning, the fact that we >> are working with a browser that is currently 26k commits behind >> Webkit:master is concerning. So I do not believe this is a viable option. >> As a personal opinion is we need to release fast, then we should go with >> what we have now and not go back to this option. >> > > Yeah, that option definitely has no future long-term. > > > >> 2) This option is not very appealing to me, because we would be pilling >> code into the QT portion of the application, that I hope we remove in the >> future, that currently is untested to solve a problem caused by a Window >> Manager...... >> I would be more in favor of creating a Application Indicator that would >> support 2 actions, Kill running pgAdmins and launch the browser to access >> them. There is a lot of interesting websites that talk about this, and how >> to develop. I had to download one to have a docker indicator..... But as I >> said in a previous thread, I believe that this should be a 3rd party >> application and not a first class citizen on pgAdmin, as the majority of >> the ones that I found are. >> > > I can't comment on the specific ways to sort it out, but I think *basing* > things in option 2 is by far the best option. If it's just an additional > add-on that can be made a dependency of the packages it's not a huge > problem (provided this add-on is available on the major platforms like > rhel, ubuntu, debian of course) > It would just be a modified version of what we have. Instead of having an icon in the system tray, we'd probably have multiple Start Menu icons to replace the tray icon menu. They would have to signal a running instance to do something, or become a new instance and then do the something if nothing is running already. > > > > >> 3) Electron can to play, first when we though about removing QTWebkit, >> because it always packs a browser with it and also and there is a very big >> Open Source Community being it. It came back again when when we saw that we >> were ready to ditch the browser. (As a personal note I dislike applications >> that I install in my machine and pop browser open to do anything, this is a >> personal issue that I would like to see if it was shared by others that was >> why we decided to park Electron for a second time. Because if our users are >> ok with it there is no need to add extra complexity to the product) >> The most interesting thing about the cons that I found in Electron there >> is an issue open for them and a bunch of different solutions to try to >> handle it, or even advises on how to handle it. This option also allow us >> to focus less on browser compatibility as the main target of our >> development will become Chromium which is the base of browsers like UC >> Browser, Vivaldi, Opera, Google Chrome. >> > > Please don't ever give up browser independence for the *web* version of > pgadmin. Don't be That Project (TM). > Not on my watch! > > (And don't give up on proper tabs either, but I'm sure Electron might > catch up in that eventually -- and the issue around RHEL6 will also go away > eventually) > RHEL 6 is in support until 2024, though it's already halfway through the maintenance 2 phase. It's definitely going, but we really don't know how many folks might still be using it in production on systems they're updating and using pgAdmin on. That last bit is important; many folks will continue to run production servers on RHEL/CentOS 6 for years, but how many are using them for client-side stuff or actively updating things like pgAdmin on them? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --001a1144161a11304e056802cc7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Thu, Mar 22, 2018 at 4:17 PM, Magnus Hagander &l= t;magnus@hagander.= net> wrote:


On Thu, Mar 22, 2018 at 3:57 PM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.io> wrote:
Hello Hackers,
Here is our take on the 3 op= tions present:

This look= s like a good summary, so I'm going to pick this one to comment on :)

:-)
=C2=A0=


<= /div>
=C2=A0
= 1) QtWebkit and QtWebEngine=C2=A0

Pros:
- Webkit= is a mature technology that as been around for some time
- Appar= ently the Fork of Webkit we were using as been catching up
Cons:<= /div>
- We are using a Fork
- It is to far behind of the toda= y browsers and the competition keep evolving making it even harder for them= to catch up
- Problems with the environment from the past, laggi= ness, lack of support


Yeah, this one hasn't exactly caused a "little" = set of complaints so far. It might be workable for absolute stop-gap, but n= ot beyond that.

Right.
=C2=A0

=C2=A0
2) Rework runtime to find a running PGAdmin = and attach to it

Pros:
- We already made= the big move from Webkit to this version
- Add smarts to the app= lication to do not run itself if it is already running, or kill the current= ly running application=C2=A0

Cons:
- Mor= e C++ code thrown around
- Add more dependency on our QT applicat= ion
- Have specific code for Gnome, not even a OS version but a w= indow manager


=
Annoying as it is, I think this is the least bad option at this point.=


3) Electron

Pros:
- Full Javascript runtime, no more C++ code to handle
- = Self packaging for all the environments
Cons:
- No full= y supported on Linux based OS with old=C2=A0libstdc++, (This might solv= e the problem:=C2=A0htt= ps://github.com/mattermost/desktop/issues/312)
=


Losing support= for things like RHEL6 would make it completely unworkable for several of m= y largest customers. Particularly in large enterprise organisations, this w= ould be a very substantial issue.
=
That's good to know. There are clunky workarounds (shipp= ing different libcs for example, but that potentially adds licensing issues= ).

Sidenote: It would only be an issue for desktop= mode. Web mode should not be affected.
=C2=A0

=C2=A0
- CPU/RAM high utilization (Found a issues around and the majority of= them have solutions like CSS animations running or settings on the created= windows)

= This does sound bad. But do we actually know if this is worse in Electron t= han it is in the option #2? I mean sure, we point to things like Slack, but= that may not be because of electron, it may be because the app running ins= ide it?

We don'= t know for sure, but we do know that Chrome in general is a bit of a hog. I= t's certainly not a stretch to think a combination of those things are = why people (correctly) see browser based apps as being more resource hungry= .
=C2=A0
=C2=A0
- Electron does not support tabs= by default, only HTML tabs

=
I think that also makes it a showstopper. This was anothe= r one of the main complaints I have personally heard from people going from= pgadmin3 -> pgadmin4, and enough to make people not want to use it at a= ll. It would be really bad to go back to that.

To clarify; it would mean no tabs, but not sing= le window. That was already working in the PoC. In other words, helpfiles, = the debugger and query tools could all be opened in new windows, just not t= abs on the same window that could be docked and un-docked.

I suspect for most people that would be enough.
=C2=A0



After combing through these options wit= h some pros and cons=C2=A0 here are my thoughts:
1) This options was always cluncky fr= om the beginning, the fact that we are working with a browser that is curre= ntly 26k commits behind Webkit:master is concerning. So I do not believe th= is is a viable option. As a personal opinion is we need to release fast, th= en we should go with what we have now and not go back to this option.

Yeah, that opti= on definitely has no future long-term.

=C2=A0
2) This option is not very appealing=C2= =A0to me, because we would be pilling code into the QT portion of the appli= cation, that I hope we remove in the future, that currently is untested to = solve a problem caused by a Window Manager......
I would be more in favor of creating = a Application Indicator that would support 2 actions, Kill running pgAdmins= and launch the browser to access them. There is a lot of interesting websi= tes that talk about this, and how to develop. I had to download one to have= a docker indicator..... But as I said in a previous thread, I believe that= this should be a 3rd party application and not a first class citizen on pg= Admin, as the majority of the ones that I found are.

I can't comment on the speci= fic ways to sort it out, but I think *basing* things in option 2 is by far = the best option. If it's just an additional add-on that can be made a d= ependency of the packages it's not a huge problem (provided this add-on= is available on the major platforms like rhel, ubuntu, debian of course)

It would just be a m= odified version of what we have. Instead of having an icon in the system tr= ay, we'd probably have multiple Start Menu icons to replace the tray ic= on menu. They would have to signal a running instance to do something, or b= ecome a new instance and then do the something if nothing is running alread= y.
=C2=A0
<= br>

=C2=A0
3) Electron can = to play, first when we though about removing QTWebkit, because it always pa= cks a browser with it and also and there is a very big Open Source Communit= y being it. It came back again when when we saw that we were ready to ditch= the browser. (As a personal note I dislike applications that I install in = my machine and pop browser open to do anything, this is a personal issue th= at I would like to see if it was shared by others that was why we decided t= o park Electron for a second time. Because if our users are ok with it ther= e is no need to add extra complexity to the product)
The most interesting thing about = the cons that I found in Electron there is an issue open for them and a bun= ch of different solutions to try to handle it, or even advises on how to ha= ndle it. This option also allow us to focus less on browser compatibility a= s the main target of our development will become Chromium which is the base= of browsers like UC Browser, Vivaldi, Opera, Google Chrome.<= /div>

Please don't ever gi= ve up browser independence for the *web* version of pgadmin. Don't be T= hat Project (TM).

N= ot on my watch!
=C2=A0

<= /div>
(And don't give up on proper tabs either, but I'm sure El= ectron might catch up in that eventually -- and the issue around RHEL6 will= also go away eventually)

RHEL 6 is in support until 2024, though it's already halfway thr= ough the maintenance 2 phase. It's definitely going, but we really don&= #39;t know how many folks might still be using it in production on systems = they're updating and using pgAdmin on. That last bit is important; many= folks will continue to run production servers on RHEL/CentOS 6 for years, = but how many are using them for client-side stuff or actively updating thin= gs like pgAdmin on them?=C2=A0


= --
Da= ve Page
Blog: = http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK= : http://www.ente= rprisedb.com
The Enterprise PostgreSQL Company
--001a1144161a11304e056802cc7b--