Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHs5k-00028k-Sj for pgadmin-hackers@arkaria.postgresql.org; Fri, 16 Dec 2016 12:58:29 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cHs5k-0004t6-Ft for pgadmin-hackers@arkaria.postgresql.org; Fri, 16 Dec 2016 12:58:28 +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 1cHs5j-0004qa-AB for pgadmin-hackers@postgresql.org; Fri, 16 Dec 2016 12:58:27 +0000 Received: from mail-it0-x235.google.com ([2607:f8b0:4001:c0b::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cHs5g-0001uI-FA for pgadmin-hackers@postgresql.org; Fri, 16 Dec 2016 12:58:26 +0000 Received: by mail-it0-x235.google.com with SMTP id y23so18858390itc.0 for ; Fri, 16 Dec 2016 04:58:24 -0800 (PST) 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=1rlmTmkkl49oG2ZNqT20e3Ni2qlbjiwX+QAlZREWnTs=; b=szDK9CBJ6au6ADEiHq8qN2tWsRK5UDv3RMjDebbGfhWpsnLCfgfnIr6ZB6QkRYiDsq FqYLmdu5sAxkemAwuMZRw+za/hmaWrJe304Bt6lYg912ng3Wc0VS/UtzSqWMYNFKQsZ2 B8rikFYbAzjTwGG/d8LaYlNNF9qXlMQEgb/S6ru0CkkbqXY9SUW/nTSKOrVndn6lBH9h gK7LcLuv5cfCdvhYTna4L2S9iBhLHYoa8yueZBuDuNA7EApZmGrfgT+DMy3Kyv2QeaB+ Cc4yATYfdCgnXjw+qLBJClS+UIiOVjprW8//hhBoezbt6cqyr52J2vOS8OdwfxoVXM8w 3pmw== 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=1rlmTmkkl49oG2ZNqT20e3Ni2qlbjiwX+QAlZREWnTs=; b=dOc4HRsMLT1LSkZ0vhj2Ah4+ahc3PgN2Hdg3wIkYStnub0yvzgkaS74D0C9wdTzC3l pF0mSoyuDkBPwu1NbHi9EeOJGzBBhhLjFs9kQRjP1Fg/TrXeie/0i2oXKrjbFy3mL+Pe ndhLi7f1FRTd/sRyMAGC9CoVjKrP3szPV02isgjguHwZL7pLxyb7iASZOP0SkvgCejze Kim8njaRwVctOVQdGOsMfoemM8Cag06oEcrjTejWtFlfYozIsJ0Z2SrTRR0Xe5PyOwJk UoDKj+NmlGXBt0i0fGOtkkXatJ7Dn7H/gbonCBz7VHtKUEoJC4idjaG3/lmmT7PRvdOQ x7CA== X-Gm-Message-State: AKaTC00C2yPrABe0D9YJuLxnUQ7Ba7ntMWXvsWHxoxX6MKdi+BzqNDLQo9El71BiwW6aq4967fP51XXciMW2qA== X-Received: by 10.36.39.6 with SMTP id g6mr2511676ita.94.1481893103346; Fri, 16 Dec 2016 04:58:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.224.198 with HTTP; Fri, 16 Dec 2016 04:58:22 -0800 (PST) In-Reply-To: References: From: Dave Page Date: Fri, 16 Dec 2016 12:58:22 +0000 Message-ID: Subject: Re: [pgAdmin4][Patch]: RM #1807 Query Tool Does Not Recognize When File Changes Have Been Saved To: Akshay Joshi Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary=001a1147c938053f5f0543c62028 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 --001a1147c938053f5f0543c62028 Content-Type: text/plain; charset=UTF-8 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. > >> 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). > >> 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. > replace(/^\/|\/$/g, '')); > + self.setTitle(self.gridView.current_file. > split('\\').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? Thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --001a1147c938053f5f0543c62028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

On Fri, Dec 16, 2016 at 12:46 PM, Akshay Joshi <= akshay.j= oshi@enterprisedb.com> wrote:
Hi Dave

On Fri, Dec 16, 2016 at 5:22 PM, Dave Page <dpa= ge@pgadmin.org> wrote:
H= i

On Fri= , Dec 16, 2016 at 8:47 AM, Akshay Joshi <akshay.joshi@enterpri= sedb.com> wrote:
Hi All
Please find the attached patch to fix = the RM=C2=A0#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.=C2=A0

If I then undo the ch= ange by deleting the space, the file is still marked as dirty.=C2=A0
<= /div>

=C2=A0 =C2=A0This = was an old behaviour. To achieve this we need to compare the original conte= nt with changed content on each key press event.

OK, but it's inconsistent with what happe= ns if I'm not working with a file - in that case if I add a character a= nd then remove it (so the query is empty again), then it does mark the edit= or as clean again.

If you look at pgAdmin III, the= n 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 c= onsistent behaviour.
=C2=A0
=C2=A0

If I then c= lear the window entirely, the save button is disabled, but the tab still sh= ows the file is dirty (the *).
=C2=A0 =C2=A0Again this was an old behaviour, I have add= ed only one if condition to check whether to popped up "Unsaved Change= s" message or not.=C2=A0

=
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 sho= uldn't they? I shouldn't expect to see a file marked as dirty that = I cannot save (even if it is empty).
=C2=A0

Also - the pat= ch seems to undo the change I made in=C2=A04a280b251755091af9bf56bcdee= 964601df104ae.

=C2=A0 =C2=A0 As per commit id 4a280b251755091af9bf56bcdee964601df1= 04ae, 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=A0self.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.split('\\').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 previ= ously.

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?=C2=A0

Thanks.

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

EnterpriseDB UK: http://www.enterprisedb.com
The= Enterprise PostgreSQL Company
--001a1147c938053f5f0543c62028--