Re: Menu (Was: Re: Unimplemented AppKit classes)

[David Ayers]

Stefan Urbanek wrote:

> On 2003-01-23 01:38:41 +0100 Alan West <alan@alanz.com> wrote:
>
> > After all an XML description of the user interface should be platform 
> > independant.
>
> .gorm is not platform independen? If not, why? If it is because of 
> lack of .gorm file reader, then i do not see it as a problem of .gorm 
> file. 

.gorm (just like .nib) uses NSCoding and that is inherently 
library/framework dependant, as the "coding information" on how a 
specific object is encoded and decoded is part of the concrete 
implementation of the library/framework.  Now I'm not sure whether 
Gorm.app compiles agains OS X/4.2 Foundation/AppKit, but if it did, 
anyone creating .gorm files with that version will create files that 
only work with OS X/4.2 Foundation/AppKit.  Also using libFoundation 
instead of base will produce a different .gorm format (unless care was 
taken that they have identical coding code).  This is inherent of using 
NSCoding for archiving.

To have a plattform independant format for archiving objects (not merely 
UI objects), the "coding information" (i.e. the knowledge of how a 
concrete object is represented) must be independant of the 
framework/library which implements them.  This could either mean the 
format is public and everone adheres to it or it has to be implemented 
independant of the library/framework which contains the objects to be 
archived.  Now I haven't had time to look at Renaissance yet, but it 
seems promising:  If all the "coding information" is within this 
extension then it is the answer to technical plattform independance for 
standard objects.  If it also facilitates allowing custom objects, and 
allows the "coding information (how to code/decode a custom object)" of 
custom objects to be stored and extracted from the arcive file itself, 
then it is the greatest thing since IB in my view!

> Anyway, differences in interface *philosophy* cannot be solved by 
> using any kind of common single UI description. It does not matter if 
> it is 'platform independent' or not. And i think that the phrase 
> 'platform independet' is really inappropriate in connection with 'user 
> interface'.
Yes, we are talking about two different issues.  One is a plattform 
independent format for object archives and the other is how to place UI 
objects on screen, in windows and so forth, which would bring us back to 
the "Theme" issue or some other form of UI configuration method.  But 
I'd like to stay out of that discussion... (for now at least :-) )

Cheers,
Dave