Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHsiq-0003pS-8B for pgadmin-hackers@arkaria.postgresql.org; Fri, 16 Dec 2016 13:38:52 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cHsip-00030x-Ec for pgadmin-hackers@arkaria.postgresql.org; Fri, 16 Dec 2016 13:38:51 +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 1cHsib-0002m5-7u for pgadmin-hackers@postgresql.org; Fri, 16 Dec 2016 13:38:37 +0000 Received: from mail-it0-x22a.google.com ([2607:f8b0:4001:c0b::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cHsiT-0002m2-LY for pgadmin-hackers@postgresql.org; Fri, 16 Dec 2016 13:38:35 +0000 Received: by mail-it0-x22a.google.com with SMTP id l8so8638385iti.1 for ; Fri, 16 Dec 2016 05:38:29 -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=3s8INVOreuBaXz8dT8sOvqTKP90KKXj0N9gv4/e5hm8=; b=jHoCtv37uot642rqhRudJjTPTX2AUDVw5hyZ22bEGBUugKpJDIxDsBWA3Ih03jt7HM NFNmAWLbAxquGmw94Q7UInvG4p8CKv6qEkO0eOMxhpMUay+ro3OPF1ioK7TRTtOyETTJ LmNr8rI1mty9rYowRkqgfs5fYJ9zrYtKoF1D3VrbLh2FGN5T4IU8RELfDjuIvS5XDKyJ o9Z3UpYqAgCLyj14U/rHi0GSGh60/xT5a2/5PtgeyA5K656WapXO3h/eiMi0MullDPLg gSmqxmKX24bdPBMy+VOAYqucuAF8O4KGJX0dZ8w/SzVW+tE9epQ//huEBzAh3WZ6x8YJ e0ow== 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=3s8INVOreuBaXz8dT8sOvqTKP90KKXj0N9gv4/e5hm8=; b=Xmwf9agj0BWaC/VV+qzEima4T4mO4z5OWHtd69Z4/NjMsvO7yCCwEY4zujxGX/nCX9 KWlluadGBrvuQh6x11KguQLkvv6yw4p8VtKAdBnGfET3azaHS/dvdkoZ+CPHCt/feyHw 35dwih+m/1L/DDsYs+RLtoMWqrz7K0oPAGsBpMtJ8YFEe80usNEYjBZr8LYHjO9XQbyz AU8+MC4H5jPvEqDCNO0vcZpLWHei4H/rRcnQe+oc89rmT/V7cGlQcC3gKnr6CTKKH61Z Ek2w6LjAlVcv0DFz9ZlhWT1/fg+AJ1BiDhqryLO6rE6UfpwQt+DeM0jmwlwFX4YNPRrG bJsg== X-Gm-Message-State: AKaTC00TgxrfMGQLmIIC91NnrLBoc4Xz3e2rE1eJb9kHZvD2bWcddc33akRpkeWHgOrnGWBrayCGTlYtY4vwZw== X-Received: by 10.36.175.82 with SMTP id l18mr3548850iti.113.1481895508912; Fri, 16 Dec 2016 05:38:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.224.198 with HTTP; Fri, 16 Dec 2016 05:38:28 -0800 (PST) In-Reply-To: References: From: Dave Page Date: Fri, 16 Dec 2016 13:38:28 +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=f403045da27867388d0543c6af22 X-Pg-Spam-Score: -1.9 (-) 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 --f403045da27867388d0543c6af22 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 16, 2016 at 1:24 PM, Akshay Joshi wrote: > > > 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 ? > Yes - and allow saving the empty file. Use pgAdmin III for reference - whilst there may be no point in saving an empty file, the behaviour is consistent and appropriate here. You don't run into a situation where you may have an empty editor with the ability to save one day, and without the next day. > >> >> >>> >>>> 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. > >> 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-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246* > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --f403045da27867388d0543c6af22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 16, 2016 at 1:24 PM, Akshay Joshi <akshay.josh= i@enterprisedb.com> wrote:
=


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

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

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

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

<= div style=3D"font-size:13px">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 cor= rectly detected.=C2=A0

If I then undo the change b= y 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 content wit= h changed content on each key press event.

OK, but it's inconsistent with what happ= ens 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 edi= tor as clean again.

If you look at pgAdmin III, th= en any change to either an opened file, or a blank editor will mark it dirt= y. It never marks it as clean again. That means no content comparison, and = consistent behaviour.

=C2=A0 =C2=A0With current implementation if we are not working wi= th file then there is no dirty(*) mark on the tab and if query is empty the= n no point in saving/creating empty file that's why save button is disa= bled. Do you want me to add an (*) mark there as well ?=C2=A0

Yes - and allow saving the empty= file. Use pgAdmin III for reference - whilst there may be no point in savi= ng an empty file, the behaviour is consistent and appropriate here. You don= 't run into a situation where you may have an empty editor with the abi= lity to save one day, and without the next day.
=C2=A0
=C2=A0
=C2=A0

If I then clear the window entirely, the save button = is disabled, but the tab still shows the file is dirty (the *).
=

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

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 ex= pect to see a file marked as dirty that I cannot save (even if it is empty)= .

=C2=A0 =C2= =A0 OK. I'll enable the save button in that case for consistency. =C2= =A0
<= div class=3D"gmail_extra">
=C2=A0

Also -= the patch seems to undo the change I made in=C2=A04a280b251755091af9bf56bc= dee964601df104ae.

<= /span>
=C2=A0 =C2=A0 As per commit id 4a280b251755091af9bf56bcdee964601df104ae, 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.curren= t_file.re= place(/^\/|\/$/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 pe= r me I haven't change any thing there, I have only disabled the save bu= tton when file is loaded which was not there previously.

Ahh, no - I see the i= ssue. When the file is marked as dirty, it uses the full path again. Can yo= u fix that to use just the filename please?=C2=A0

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

Thanks.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">
<= div dir=3D"ltr">

Thanks.

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

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



<= /div>--
Akshay Joshi
Principal Software Engineer=C2= =A0


=
Pho= ne: +91 20-3058-9517
Mobile: +91 976-788-8246



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

EnterpriseDB UK: http://www.enterprisedb.com<= br>The Enterprise PostgreSQL Company
--f403045da27867388d0543c6af22--