Thread: SVN Commit by dpage: r5179 - in trunk/pgadmin3: . src/frm
Author: dpage Date: 2006-05-22 16:51:19 +0100 (Mon, 22 May 2006) New Revision: 5179 Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5179&view=rev Log: Display the current character number in the query tool status bar. Modified: trunk/pgadmin3/CHANGELOG trunk/pgadmin3/src/frm/frmQuery.cpp
svn@pgadmin.org wrote: > Author: dpage > > Date: 2006-05-22 16:51:19 +0100 (Mon, 22 May 2006) > > New Revision: 5179 > > Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5179&view=rev > > Log: > Display the current character number in the query tool status bar. Another reason for me to fork, I'd never accept wasting space for this. I wonder when more useless info like current date/time, mem usage etc. are added to the statusbar. If this was supposed to aid the ".. at character nnn" error messages (it doesn't unless the query starts at (0,0)), I already have an 8.2 compatible and enhanced error handling done, based on 5109 and thus uncommittable. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 23 May 2006 15:45 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r5179 - > in trunk/pgadmin3: . src/frm > > Another reason for me to fork, I'd never accept wasting space > for this. Wasting space that's not used anyway? > I wonder when more useless info like current date/time, mem > usage etc. Why on earth would we add that? Current character is useful for precisely the reason you note below. > are added to the statusbar. > If this was supposed to aid the ".. at character nnn" error > messages (it doesn't unless the query starts at (0,0)), No, in that case it doesn't help but that doesn't mean it isn't useful in other situations. > I > already have an 8.2 compatible and enhanced error handling > done, based on 5109 and thus uncommittable. The current code works perfectly against CVS-tip from Friday. I was also planning on adding a highlight to the word at the error position (taking into account the actual start of the query). You are welcome to commit what code you have though - I'm sure you're more than capable of merging it. Regards, Dave.
Dave Page wrote: > > > >>-----Original Message----- >>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] >>Sent: 23 May 2006 15:45 >>To: Dave Page >>Cc: pgadmin-hackers@postgresql.org >>Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r5179 - >>in trunk/pgadmin3: . src/frm >> >>Another reason for me to fork, I'd never accept wasting space >>for this. > > > Wasting space that's not used anyway? > > >>I wonder when more useless info like current date/time, mem >>usage etc. > > > Why on earth would we add that? Current character is useful for > precisely the reason you note below. > > >>are added to the statusbar. >>If this was supposed to aid the ".. at character nnn" error >>messages (it doesn't unless the query starts at (0,0)), > > > No, in that case it doesn't help but that doesn't mean it isn't useful > in other situations. > > >>I >>already have an 8.2 compatible and enhanced error handling >>done, based on 5109 and thus uncommittable. > > > The current code works perfectly against CVS-tip from Friday. I was also > planning on adding a highlight to the word at the error position (taking > into account the actual start of the query). You are welcome to commit > what code you have though - I'm sure you're more than capable of merging > it. A commit would rollback every change to frmQuery and ctlSQLResult after 5109. I will *not* merge my code in a version that doesn't allow wxListView inherited ctlSQLResult. Other changes to svn prevent me from updating as well. I'm still on VC6, and don't intend to change now. As I mentioned earlier, prerequisites for me to commit are not met any more. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 23 May 2006 16:12 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r5179 - > in trunk/pgadmin3: . src/frm > > A commit would rollback every change to frmQuery and > ctlSQLResult after 5109. I will *not* merge my code in a > version that doesn't allow wxListView inherited ctlSQLResult. Well, that's your choice. As you have no actual reason other than not liking wxGrid though, I'm not going to change it unless someone comes up with a patch that will re-implement *all* existing functionality using the list view. > Other changes to svn prevent me from updating as well. I'm > still on VC6, and don't intend to change now. As I mentioned > earlier, prerequisites for me to commit are not met any more. Well, it was you that said: --- Apparently, VC2005 links mandatorily/unavoidable to .NET CRT libs which aren't necessarily present on the system, and which should not be delivered with the app (according to MS). If this wouldn't be the problem, we'd have VC2005 projects in svn for some months now... --- And as we *are* explicitly allowed by Microsoft to ship the CRT (which doesn't actually include .NET itself), there should be no problem. In fact, it is all in the latest win32 snapshot on the website, and is actually slightly smaller than the previous snapshots! Regards, Dave
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 23 May 2006 17:35 > To: Dave Page > Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r5179 - > in trunk/pgadmin3: . src/frm > > > Well, that's your choice. > > Wrong, it's *your* choice. You pissed me off by removing the > listview code *twice*, which makes me stop > committing/contributing anything at all. And are you honestly surprised I decided to ignore you? Let's review the facts: - A patch was supplied that added useful functionality, and significantly increased the speed of the Query Tool. - You objected to the speed increase changes because they weren't done in the ideal way, but point-blank refused to explain what you did expect to see. I committed on the grounds that it was an improvement, if not the ultimate solution. - You committed a patch that reimplemented the speed fixes but completely broke the other functionality introduced in the patch which you then dismissed as not being useful and did nothing to fix, despite there clearly being people who did find it useful. - A new patch was supplied restoring the functionality which you refused to review for no reason other than it used the wxGrid. - I reviewed the patch and found it to be of good quality, restoring the broken functionality, without breaking your speed improvements. I applied the patch. - You objected to the new patch saying you hadn't yet reviewed it (despite saying earlier you were not going to do so anyway), but *gave no reasons whatsoever* why it should not have been applied other than your own dislike of the wxGrid. I'm sorry, but much as I appreciate the significant contributions you have made to the project, I *will not* allow the community or the project to suffer without good reason, just for the sake of what appears to be nothing more than your dislike of a control. <snip to VC 2005 stuff> > Not the point, So what is the point? I raised the issue before doing it and that was the only concern you raised. > and no reason to remove the VC6 project files. Yes there is - the *nix makefiles often get forgotten when new files are added, never mind having to deal with the maintenance of multiple versions of "do not edit by hand" project files. It's not like people are forced to use VC++ 6.0 now that 2005 is free. Regards, Dave.
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 23 May 2006 22:08 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r5179 - > in trunk/pgadmin3: . src/frm > > Dave Page wrote: > > > > - I reviewed the patch and found it to be of good quality, > restoring the > > broken functionality, without breaking your speed improvements. I > > applied the patch. > > > To me, *your* patch broke the source. > You removed the code I insisted to retain until the other stuff is > completely accepted a second time; simple #ifdef would have > been enough. You never asked for any such thing!! You simply said you wouldn't accept a wxGrid based patch, but would give no reason why! > I made very clear that messing around with the query tool is > unacceptable to me since it was and is *the* essence of pgadmin to me. pgAdmin is a community project, it is not *your* project. Unless there are legitimate reasons, not to accept any new, useful functionality, then will will do exactly that to improve the product for our users. > You want me out, I am out. When did *anyone* say they wanted you out? I just want you to calm down and seriously consider if there are actually any actual problems with the current code, or if you are fighting for no real reason. Regards, Dave.
Dave Page wrote: > > - I reviewed the patch and found it to be of good quality, restoring the > broken functionality, without breaking your speed improvements. I > applied the patch. > To me, *your* patch broke the source. You removed the code I insisted to retain until the other stuff is completely accepted a second time; simple #ifdef would have been enough. I made very clear that messing around with the query tool is unacceptable to me since it was and is *the* essence of pgadmin to me. You want me out, I am out. Regards, Andreas
> -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of Dave Page > Sent: 23 May 2006 22:43 > To: Andreas Pflug > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r5179 - > in trunk/pgadmin3: . src/frm > > > > You removed the code I insisted to retain until the other stuff is > > completely accepted a second time; simple #ifdef would have > > been enough. > > You never asked for any such thing!! On further thought I realise that this is most likely what you meant when you said "Use the macro, it won't hurt.", for which I apologise for misunderstanding. Consequently I have re-committed the wxListView based code, macro'ed as suggested. The default remains the wxGrid however, as there have still been no actual problems reported with it's use. Regards, Dave.