Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hpfDv-0007n6-1s for pgadmin-hackers@arkaria.postgresql.org; Mon, 22 Jul 2019 20:47:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hpfDs-00035j-2h for pgadmin-hackers@arkaria.postgresql.org; Mon, 22 Jul 2019 20:47:52 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1hpfDr-00032d-NH for pgadmin-hackers@lists.postgresql.org; Mon, 22 Jul 2019 20:47:51 +0000 Received: from mail-yb1-xb44.google.com ([2607:f8b0:4864:20::b44]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hpfDo-000416-Dg for pgadmin-hackers@postgresql.org; Mon, 22 Jul 2019 20:47:51 +0000 Received: by mail-yb1-xb44.google.com with SMTP id a5so15421264ybo.13 for ; Mon, 22 Jul 2019 13:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mHrChjXzf3da4jKPphHI2wHfpyiPzA6vykgJypFYiqw=; b=uKPEuH8DgusgJ1JCYMwekXl+XuvFMEWJwxRAyElEoCWTNgD2VMooTHeZnV4axNTBL9 7Yt7Ya/ERmhWhIHrNZgFJDXf9nhVpE7xxmKQi+rIwxypbBphIYXnakERCFhc40nD+Pxm u33XeZUIO1B5DJoUNat2mg5dNUlOUq0YQWREh0dEx/r/2aTv7g9o6ADJPcPlKj89UMhQ Hg/jTPnBsVsVlSUdZDJsNRT3dK+muJll0oTgYlwsNLCA41O00HWiDjIKRZiRxtDoHKWY UKHr26jZqxkWIRGNGH1cR6N9iT8NkG1sq3GLFus8Z7xRd0zPKyXN7vWBHThrBakaMp0O P19Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mHrChjXzf3da4jKPphHI2wHfpyiPzA6vykgJypFYiqw=; b=RJCv2mRtzJnVcpblVw78496t4E2W4Tk8WEdTHy5dg53Vq4vvE42Q0/6zztG5PjrSJb Yd+SUkX9+/uTWwJjqlTuLgNr4OjznfBygVhAB2xCN2sKjVRmot8bSdVv3KWWAzSV0A8p bZbGhOgMIyrWZR+JktBxB3bYFMUXidw+VXab8oq2ryRVbFcADvnc95iUQx++5f62oY6v xsLrQRPbWcn4koYymp6DW8FD7ZpzNFtM2CF3NKS3OsfkcWVoLvvq9nDLO/ZZ1ur8YrLb 6NUTQNIr5bZvWMarYEQd5ow6H+rIEUGn0TWKc8kVZXBqOKn2+wRWae16eOuI1fYAg0to ZrIg== X-Gm-Message-State: APjAAAXOfy0grLX/pXIhBZy5Xms2IUNtjbKjS/AY1Cju6CIZKMx0oDLC c0EWxn9tNyNSiN6ZbqOqp9ZVr8mLHzSSlDIBm7Q= X-Google-Smtp-Source: APXvYqzNoOBgSgf4zZSgATRbHId8Kvvmsguz0/umgNxfu4IVAsQwbX00YHYeiJlbHAAlKBci8Xcolu5y9jNNnbCjMWk= X-Received: by 2002:a25:a265:: with SMTP id b92mr32768366ybi.273.1563828465516; Mon, 22 Jul 2019 13:47:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yosry Muhammad Date: Mon, 22 Jul 2019 22:47:34 +0200 Message-ID: Subject: Re: Bug in Database Nodes in the Tree To: Khushboo Vashi Cc: Dave Page , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000002d448d058e4b3045" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000002d448d058e4b3045 Content-Type: text/plain; charset="UTF-8" Hi, I tried just removing the lines responsible for connecting to the database on selecting a database node and it seem to work fine. Specifically the lines 254-257 in database.js (callbacks.selected function). Are there any specific scenarios I need to test to make sure everything is okay? Anywhere else in the code where I need to make changes? I also checked the tree state restore and it seems to work fine. Thanks. On Fri, Jul 19, 2019 at 7:01 AM Khushboo Vashi < khushboo.vashi@enterprisedb.com> wrote: > > > On Thu, Jul 18, 2019 at 1:44 PM Dave Page wrote: > >> Hi >> >> On Thu, Jul 18, 2019 at 6:40 AM Yosry Muhammad >> wrote: >> >>> Hi, >>> >>> On Thu, Jul 18, 2019, 7:27 AM Khushboo Vashi < >>> khushboo.vashi@enterprisedb.com> wrote: >>> >>>> Hi Yosry, >>>> >>>> On Wed, Jul 17, 2019 at 10:49 PM Yosry Muhammad >>>> wrote: >>>> >>>>> Hi Khushboo, >>>>> >>>>> There's a minor bug that I noticed a while back that when you right >>>>> click a disconnected database (to drop it for example) it automatically >>>>> connects to the database and expands the node. This behaviour is a little >>>>> annoying to users (me too), I am trying to fix it. >>>>> >>>>> This behavior is by design as we have considered some of the pgAdmin >>>> III behavior. One behavior we can change is that on the selection of the >>>> database node, we can just connect it and not expand it and when we expand >>>> the database node (by arrow icon or double click), we can connect and >>>> expand both. >>>> >>>> We need Dave's approval to change this. >>>> >>> >>> I think this makes more sense. >>> >> >> pgAdmin 3 automatically connects databases on select but not servers. I'd >> be fine with only connecting databases and servers on expand, and not on >> select. That should not affect auto-expand and treeview state restore at >> all, but will mean you can right-click a database or server without it >> connecting. FYI, I've found this behaviour annoying too. >> >> This change will definitely affect the auto-expand and tree-view state > restore, but that can be handled by some code changes. > >> I can't imagine it would require hacking aciTree to make that happen - >> we'd basically just move the connect function call from the onSelect >> handler (or whatever it's called) to onExpand wouldn't we? >> > Right, as we have implemented both expand and select calls, we just need > to remove the select handler. > >> >> >>> >>> >>>> I looked around the code in the browser module (node.js, database.js, >>>>> menu.js) and I couldn't find a way to modify this behaviour. Is this >>>>> handled internally by jQuery? Is modifying this behaviour feasible? >>>>> >>>>> >>>> I think the problem is that the right click event triggers the left >>>>> event click too. Am I correct? >>>>> >>>>> Basically, the browser tree is generated through the aciTree library, >>>> so when required, the public APIs (provided by aciTree) of the events are >>>> being called. >>>> In this case, on the selection of the database node, the selected event >>>> is used in the database.js file. >>>> >>>> Thanks for the clarification. >>> >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > -- *Yosry Muhammad Yosry* Computer Engineering student, The Faculty of Engineering, Cairo University (2021). Class representative of CMP 2021. https://www.linkedin.com/in/yosrym93/ --0000000000002d448d058e4b3045 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I tried just removing th= e lines responsible for connecting to the database on selecting a database = node and it seem to work fine. Specifically the lines 254-257 in database.j= s (callbacks.selected function).

Are there any spe= cific scenarios I need to test to make sure everything is okay? Anywhere el= se in the code where I need to make changes?

I also check= ed the tree state restore and it seems to work fine.

Thanks.


On Fri, Jul 19, 2019 at 7:01 AM Khushboo= Vashi <khushboo.vash= i@enterprisedb.com> wrote:


On Thu, Jul 18, 201= 9 at 1:44 PM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jul 18, 2019 at 6:4= 0 AM Yosry Muhammad <yosrym93@gmail.com> wrote:
Hi,

On Thu, Jul 18, 2019, 7:27 A= M Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:
Hi Yosry,

On Wed, Jul 17, 2019 at 10:49 PM Yosry Muhammad <yosrym9= 3@gmail.com> wrote:
Hi Khushboo,

There's a minor bug that I noticed a while back that when y= ou right click a disconnected database (to drop it for example) it automati= cally connects to the database and expands the node. This behaviour is a li= ttle annoying to users (me too), I am trying to fix it.

This behavior is by design as we have= considered some of the pgAdmin III=C2=A0behavior. One behavior we can chan= ge is that on the selection of the database node, we can just connect it an= d not expand it and when we expand the database node (by arrow icon or doub= le click), we can connect and expand both.

We need= Dave's approval to change this.

I think this makes more s= ense.

pgAdmin 3 automatically c= onnects databases on select but not servers. I'd be fine with only conn= ecting databases and servers on expand, and not on select. That should not = affect auto-expand and treeview state restore at all, but will mean you can= right-click a database or server without it connecting. FYI, I've foun= d this behaviour annoying too.

This change will definitely affect the auto-expand and tree-view stat= e restore, but that can be handled by some code changes.
I can't imagine it would require hacking aciTree = to make that happen - we'd basically just move the connect function cal= l from the onSelect handler (or whatever it's called) to onExpand would= n't we?
Right, as we have implemente= d both expand and select calls, we just need to remove the select handler.= =C2=A0
=C2=A0


I looked around the code in the browser m= odule (node.js, database.js, menu.js) and I couldn't find a way to modi= fy this behaviour. Is this handled internally by jQuery? Is modifying this = behaviour feasible?
=C2=A0
I think the problem is that the right= click event triggers the left event click too. Am I correct?

Basically, the browser tree is = generated through the aciTree library, so when required, the public APIs (p= rovided by aciTree) of the events are being called.
In this case,= on the selection of the database node, the selected event is used in the d= atabase.js file.

Thanks for the clarification.=C2=A0


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

Enterpri= seDB UK: http://w= ww.enterprisedb.com
The Enterprise PostgreSQL Company


--
Yosry= Muhammad Yosry

<= /i>
Computer Engineering student,
=
The Faculty of Engineering,
Cairo University (2021).
Class representative of CMP 2021.
--0000000000002d448d058e4b3045--