Re: [Pyobjc-dev] New NibLoader.py

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> It works really well and has been integrated into the repository.  The 
> WebServicesTool project has been updated to take advantage of the new 
> nib management mechanism.
> 
> I changed a few minor things [all open to debate, of course -- except 
> where it was a stupid bug fix I caused in the first place]:
> 
> - I changed the names from loadNib* to loadClassesForNib*.   This 
> better fits with Cocoa in that NibLoader isn't truly loading nibs, it 
> is loading the classes associated with the nibs -- one may invoke the 
> loadNib: method on NSBundle many, many times after the classes for the 
> Nib have been loaded (and this is exactly how multi-doc apps work).

Agreed, except I would leave out the "ForNib" part, it's part of NibLoader after
all. Mind if I change that once my commit rights are actually working?

Perhaps the NibInfo should keep track of what nibs it already has parsed. That
way you can call loadClasses[FromBundle] multiple times for one nib without
doing double work.

> - fixed a bug where it was passing .nib instead of 'nib' to NSBundle's 
> pathForResource_ofType_ (dumb).
> 
> In any case -- it works and works quite well.   The performance hit is 
> negligible.  With the features that allow one to dump the current 
> configuration of a NIB, it rounds out quite nicely.
> 
> I agree w/Ronald in that some advanced debugging/analysis tools would 
> be welcome!

I think the NibInfo.printOverview() method could be changed (and renamed) to
print a Python template, as Jack suggested.

> BTW:  Technically, the classes.nib file does not have to be present for 
> a NIB to work.  It is only used by PBX/IB to store the class 
> information.  However, I don't see it as a problem that we require the 
> file given that the developer can always fall back to the traditional 
> means of doing things.
> 
> However-- be forewarned that certain versions of nibtool -- the command 
> line nib manipulation tool -- have a habit of blowing away the 
> classes.nib.   Definitely something to look for when automatically 
> processing NIBs.

Is classes.nob the only way to get at the info we need, or is it simply the
simples one?

***

I'm again having second (third? ;-) thoughts again about whether I like the
__metaclass__ syntax better or the "magic baseclass". After all, *a* baseclass
is added. Naming is crucial, perhaps "NibAutoBaseClass" is a good name:

  from AppKit.NibLoader import NibAutoBaseClass
  from AppKit import NSTableSource
  
  class PyModel(NibAutoBaseClass, NSTableSource):
      ...

Opinions?

Just