Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHsV2-0003Ae-Bl for pgadmin-hackers@arkaria.postgresql.org; Fri, 16 Dec 2016 13:24:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cHsV1-0000ut-Q5 for pgadmin-hackers@arkaria.postgresql.org; Fri, 16 Dec 2016 13:24:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cHsV0-0000um-L3 for pgadmin-hackers@postgresql.org; Fri, 16 Dec 2016 13:24:35 +0000 Received: from mail-io0-x236.google.com ([2607:f8b0:4001:c06::236]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cHsUx-0002S0-F3 for pgadmin-hackers@postgresql.org; Fri, 16 Dec 2016 13:24:33 +0000 Received: by mail-io0-x236.google.com with SMTP id d9so97009548ioe.0 for ; Fri, 16 Dec 2016 05:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uKgruBiU0hapPVLnZn039j5Q/x6ZI+DxKDIp42KZ5Qk=; b=YwlG2II0nI9xF4/8XISkcXC4UoduHVTXZsMvxC2BP3LGunOdtUmRhI8M9rgmNhaEV0 nxYzK1Be+eiN4nv+QB1ETCgUHf1wGiQAd3LwtpUSgUayrZkcYaulqI1kPw0BaHO3Hvoe nSezLQgeAbgeoUrIzB7m1Tmr+bxsRDWCycBdJX315dNb3WPhsDO2o3tZtILemhwuQrZo xie8X2CxaaWCMOZYEqyrendjL8K9VvE3jRU3VWSPl9xYI8iaRQ+VbnWB/VlSi5PDI3Z0 Sk+rBQ1C3/ruuQ7b6BMIVBc2cdfBy5lSkEiVCqh8LXDy4v2kNylGxawvBdsNAaREpNrP l3MQ== 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=uKgruBiU0hapPVLnZn039j5Q/x6ZI+DxKDIp42KZ5Qk=; b=Whhwi7ID5ALGApoxu57Qrk0V0QENsp+UE9/FZGTZN/1XZHRTWKx4LrxhC83iZAM9y/ fUZzcQ6hvZeEHqhW7PfyevEBosizQHAXwPAwFHRfWt8yA6FzlkU+1G7UdlNgoykWkpcS rxMX/UMlc4XTNl8qzgL9UgMhS78PQI3LPShcY3dy9NWKtCPxwFdxmx7YY+VOMHqBpFem zM0MedQvo7FSH0g6ujOICGgX97H4ySKP1Rc8qkw9XzAzdXBb38YPd6N5QcbZVN7MKUKX G6XVXxHiOHas7m2UUhka8zw7r5EOzrFIy02mhikYNn+GGAupu87rQcMIRMKkje1QsDnn HcWw== X-Gm-Message-State: AIkVDXIb8vWElJPepmsSDuOktwT0GH187ZZth+wlBDg0KnhLaGe6epY9Fb9adLnXhnpqdhpAR/VhEhQow37aMeps X-Received: by 10.107.168.223 with SMTP id e92mr2545662ioj.40.1481894670663; Fri, 16 Dec 2016 05:24:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.129.10 with HTTP; Fri, 16 Dec 2016 05:24:29 -0800 (PST) In-Reply-To: References: From: Akshay Joshi Date: Fri, 16 Dec 2016 18:54:29 +0530 Message-ID: Subject: Re: [pgAdmin4][Patch]: RM #1807 Query Tool Does Not Recognize When File Changes Have Been Saved To: Dave Page Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary=001a114275bc709a600543c67dd7 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a114275bc709a600543c67dd7 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 16, 2016 at 6:28 PM, Dave Page wrote: > Hi > > On Fri, Dec 16, 2016 at 12:46 PM, Akshay Joshi < > akshay.joshi@enterprisedb.com> wrote: > >> Hi Dave >> >> On Fri, Dec 16, 2016 at 5:22 PM, Dave Page wrote: >> >>> Hi >>> >>> On Fri, Dec 16, 2016 at 8:47 AM, Akshay Joshi < >>> akshay.joshi@enterprisedb.com> wrote: >>> >>>> Hi All >>>> >>>> Please find the attached patch to fix the RM #1807 Query Tool Does Not >>>> Recognize When File Changes Have Been Saved. >>>> >>> >>> If I open a file with the patch applied, and make a change (add a space >>> to the end), it's correctly detected. >>> >>> If I then undo the change by deleting the space, the file is still >>> marked as dirty. >>> >> >> This was an old behaviour. To achieve this we need to compare the >> original content with changed content on each key press event. >> > > OK, but it's inconsistent with what happens if I'm not working with a file > - in that case if I add a character and then remove it (so the query is > empty again), then it does mark the editor as clean again. > > If you look at pgAdmin III, then any change to either an opened file, or a > blank editor will mark it dirty. It never marks it as clean again. That > means no content comparison, and consistent behaviour. > With current implementation if we are not working with file then there is no dirty(*) mark on the tab and if query is empty then no point in saving/creating empty file that's why save button is disabled. Do you want me to add an (*) mark there as well ? > > > >> >>> If I then clear the window entirely, the save button is disabled, but >>> the tab still shows the file is dirty (the *). >>> >> >> Again this was an old behaviour, I have added only one if condition to >> check whether to popped up "Unsaved Changes" message or not. >> > > Maybe - but the point is to fix the old behaviour :-). The dirty marker > and enabled/disabled state of the save option should be in sync shouldn't > they? I shouldn't expect to see a file marked as dirty that I cannot save > (even if it is empty). > OK. I'll enable the save button in that case for consistency. > > >> >>> Also - the patch seems to undo the change I made >>> in 4a280b251755091af9bf56bcdee964601df104ae. >>> >> >> As per commit id 4a280b251755091af9bf56bcdee964601df104ae, you have >> made following changes: >> >> - self.setTitle(self.gridView.current_file.re >> place(/^\/|\/$/g, '')); >> + self.setTitle(self.gridView.current_file.sp >> lit('\\').pop().split('/').pop()); >> >> And as per me I haven't change any thing there, I have only disabled the >> save button when file is loaded which was not there previously. >> > > Ahh, no - I see the issue. When the file is marked as dirty, it uses the > full path again. Can you fix that to use just the filename please? > Sure. > > Thanks. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- *Akshay Joshi* *Principal Software Engineer * *Phone: +91 20-3058-9517Mobile: +91 976-788-8246* --001a114275bc709a600543c67dd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 16, 2016 at 6:28 PM, Dave Page <dpage@pgadmin.org><= /span> wrote:
Hi

On F= ri, Dec 16, 2016 at 12:46 PM, Akshay Joshi <akshay.joshi@enter= prisedb.com> wrote:
Hi Dave

On Fri, Dec 16, 2016 at 5:22 PM, Dave Page <= ;dpage@pgadmin.org> wrote:
Hi

On Fri, Dec 16, 2016 = at 8:47 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:
Hi All

Please find the attached patch to fix the RM=C2=A0#18= 07 Query Tool Does Not Recognize When File Changes Have Been Saved.

If I open a file with the patch= applied, and make a change (add a space to the end), it's correctly de= tected.=C2=A0

If I then undo the change by deletin= g the space, the file is still marked as dirty.=C2=A0

=C2=A0 =C2=A0This was an old beha= viour. To achieve this we need to compare the original content with changed= content on each key press event.
=
OK, but it's inconsistent with what happens if I&= #39;m not working with a file - in that case if I add a character and then = remove it (so the query is empty again), then it does mark the editor as cl= ean again.

If you look at pgAdmin III, then any ch= ange to either an opened file, or a blank editor will mark it dirty. It nev= er marks it as clean again. That means no content comparison, and consisten= t behaviour.

=C2=A0= =C2=A0With current implementation if we are not working with file then the= re is no dirty(*) mark on the tab and if query is empty then no point in sa= ving/creating empty file that's why save button is disabled. Do you wan= t me to add an (*) mark there as well ?=C2=A0
=C2=A0
=C2=A0

If I then clear the window ent= irely, the save button is disabled, but the tab still shows the file is dir= ty (the *).

= =C2=A0 =C2=A0Again this was an old behaviour, I have added only one if cond= ition to check whether to popped up "Unsaved Changes" message or = not.=C2=A0

M= aybe - but the point is to fix the old behaviour :-). The dirty marker and = enabled/disabled state of the save option should be in sync shouldn't t= hey? I shouldn't expect to see a file marked as dirty that I cannot sav= e (even if it is empty).

=C2=A0 =C2=A0 OK. I'll enable the save button in that case for co= nsistency. =C2=A0
=C2= =A0

= Also - the patch seems to undo the change I made in=C2=A04a280b251755091af9= bf56bcdee964601df104ae.

<= /div>
=C2=A0 =C2=A0 As per commit id 4a280b251755091af9bf56bcdee= 964601df104ae, you have made following changes:=C2=A0

-=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= self.setTitle(self.gridView.current_file.replace(/^\/|\/$/g,=C2=A0''));
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0self.setTitle= (self.gridView.current_file.sp= lit('\\').pop().split('/').pop());
<= div class=3D"m_5963848438476348979m_2137903784184468155gmail-diff m_5963848= 438476348979m_2137903784184468155gmail-add" style=3D"font-family:monospace;= white-space:pre-wrap;color:rgb(0,136,0)">
And as per me I haven't change any thing there, I have only d= isabled the save button when file is loaded which was not there previously.=

Ah= h, no - I see the issue. When the file is marked as dirty, it uses the full= path again. Can you fix that to use just the filename please?=C2=A0
<= /div>

=C2=A0 =C2=A0Sure.=C2=A0<= /div>

Thanks.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



--
Akshay Joshi


<= b>Phone: +91 20-3058-9517
Mobile: +91 976-788= -8246
--001a114275bc709a600543c67dd7--