Re: [Cocoapsql-developer] please agree to changes in project settings

[Al K. <al...@ki...>]

Hi Olaf.
As it happens, due to the power of Cocoa the export sheet could not have 
been easier to create!!!! The entire export facility only took about 1.5 
hours total time to read the docs, learn how to do it, design and code. 
I like Cocoa and objective-C!!!!

As for the question about the cvs update before commit: I ran into a 
problem using an update command one time. As the CVS is text based and 
it tries to address differences in files in the text domain it can 
really screw up binary files, like the actual project files!!! I trashed 
a project file by doing an update on something I worked on on another 
machine and then I really had to play games to get everything working 
correctly again. I recommend simply doing the commit instead of an 
update and go from there. I have not made any changes since you checked 
out the source so your commits should be simple.

I am going to look into how we can keep the binary files (project 
definitions, nibs, other resource files) from getting trashed via CVS. I 
am sure there is a solution but I just have to find it. (Read, Read, 
Read, Read, Read, Read).

Hope you are having a great day!!

See ya, Al

On Wednesday, May 29, 2002, at 02:48 AM, Olaf van Oudenallen wrote:

> Hi Al. Thanks for your complete reply!
>
> First of all: your Export sheet works nice (and looks as if you have 
> spent a lot of time creating the sheet)! I have added a 
> validateMenuItem for this menuItem, bases on [tableView numberOfRows] > 
> 0.
>
> I subscribed to the cocoapsql-developer list so now I received your 
> mail twice. Once addressed directly to olaf@adm..... and once as the 
> subscriber of cocoapsql-developer list. So I suggest you send project 
> relative mail, with historical value, to the list and (all your other 
> nice mail) to me personally.
>
> I will alter the included library/framework libpq.q to be the one in 
> /usr/local/psql/lib/ and add to the HEADER Search Path
> 	/usr/local/pgsql/include/		/* for me */
> and	/sw/include/postgresql/		/* for you to have libpq-fe.h included*/
>
> I agree on the FirstResponder / NSWindowController issue. I planned to 
> make the application (sort off?) multi document as soon as I have added 
> my changes to the repository. I don't now yet how but I guess splitting 
> the PSQLController to PSQLController as a subclass of 
> NSWindowController and PSQLAppController. (So I will add PSQL to the 
> existing AppController.h an .m names) and move the windows and sheets 
> so we will be able to open multiple Connection windows and multiple 
> (future) Manager windows, reflecting the database structure etc.)
> Do you agree on leaving the structure as it is (with PSQLController 
> being the delegate of teh window) for the moment?
>
> I guess owr time-difference is 7 hrs. (we have daylight saving time 
> now). Here it's about 09:45. I will see that I commit tonight.
>
> Am I right that I don's HAVE to update before committing. As I 
> understood, on committing I will be prompted for eventual conflicts to 
> be solved.
>
> See you, Olaf
>
> On woensdag, mei 29, 2002, at 03:21 , Al Kirkus wrote:
>
>> Hi Olaf.
>>
>> You have a good point here. We should not assume any particular 
>> directory structure other than maybe the default imposed by the 
>> postgres package itself. Ideally it would be good if there was a way 
>> for project builder to reference an environment variable which we 
>> could set to point to the postgres installation directory if it 
>> differed from the default location, but I don't know if we can do 
>> that. I believe that the default location is /usr/local/pgsql just as 
>> you have it. Bottom line, I think that your path settings should be 
>> the default and we who do not have standard installation locations, 
>> because we used fink or whatever other reason, should be forced to 
>> deal with it. I think you should set project builder to reference 
>> postgres relevant includes in /usr/local/pgsql/include and relavent 
>> libraries in /usr/local/pgsql/lib.
>>
>> As for the second item relating to the the import statement, this goes 
>> directly to the path issue above. When postgres installed via fink it 
>> created a postgresql/ directory under /include. Since I was 
>> referencing the generic /include header directory I needed to include 
>> the /postgresql/ as part of the path name. You should double check but 
>> I believe that when a default install to /usr/local/pgsql is done, the 
>> relevant headers wind up in /usr/local/pgsql/include. If this is 
>> correct then your change is exactly right. As for the import, include 
>> discussion, you are correct. I only used the #include as a cue to 
>> myself to remember that these were postgres specific items written in 
>> ANSI C and not an objective C header.
>>
>> I have no problem with either change!!
>>
>>
>> As for the third item, your code looks like it will work but there is 
>> a larger mistake here that needs to be corrected to save a lot of 
>> future work. I wanted to discus this with you. As I began learning 
>> Cocoa from the Aaron Hilegass book his examples did not explain the 
>> responder chain and the related concepts until later. I had already 
>> begun coding this program. Simply put I believe that the 
>> PSQLController  should be coded as a subclass of  NSWindowController 
>> instead of the simple NSObject and be made the delegate of the 
>> relevant windows. Then the First responder object needs to be modified 
>> by adding the relevant action methods reflecting the code that is 
>> already present in the PSQLController object. Once done the 
>> PSQLController will automatically be the first responder whenever it 
>> is key and the menus will automatically activate/deactivate as needed. 
>> There may still be a small issue with the connect/disconnect menu 
>> items but everything else should work OK, I think?
>>
>> I hope that last part made some sense to you as I am having trouble 
>> keeping it all straight myself.
>>
>> Let me know what you think,  Al