Re: GNUstep Apps, iPhone.

[Dr . H . Nikolaus Schaller]

Am 22.10.2007 um 11:07 schrieb David Chisnall:

> On 21 Oct 2007, at 19:25, hns@computer.org wrote:
>
> > Well, I would assume that it really looses essential functionality  
> > for
> > a **desktop** system.
>
> Quite possibly.  I would imagine they'd lose palettes, for example,  
> and anything related to displaying multiple windows at once.
>
> > My assumptions:
>
> I'd disagree with some of these.

That is ok - we are on a discussion list :-)

> > * it is not based on floating point coordinates (ARM has no FPU) -
> > smooth magnification becomes tricky for arbitrary views
>
> This can be done very fast using the mipmap calculation hardware on  
> the iPhone's GPU (yes, it has one; almost the same design as the  
> one in the Sega Dreamcast).

Yes, that is correct. But you can't probably benefit from it for code  
like [[NSTableView alloc] initWithFrame:NSMakeRect(0.0, 0.0, 100.0,  
100.0)]

I.e. what I mean is that AppKit is float-coordinate oriented but you  
probably don't need it for a fixed-screen-size device. I have not  
looked into it (I think I have seen a reverse engineered @interface  
list for UIKit but I don't remember where I did) but I would use  
integers for all those coordinates. And use the GPU to smoothly scale  
images for fractional proportions.

> > * it is not NIB (GORM) based
>
> I doubt it would gain much from this.  You'd either need to create  
> UIs in code or via something like Renaissance and I don't see that  
> either of these would be better than nibs for a mobile device.  On  
> the contrary, where you have a fixed (but known) size screen having  
> a graphical UI designer is very important.

Agreed. But if they have done it with their own interface designer -  
this might explain why they need some more time for publishing the  
SDK. Again, one could look into the @interfaces of UIKit...
> > * it does not separate NSView and NSCell
>
> I don't see what this would gain them.  The division was originally  
> there for efficiency, to help AppKit scale down to the 25MHz CPU in  
> the old NeXT machines.  Removing this division would add some  
> overhead.  If I were designing an SDK for a relatively slow system,  
> I wouldn't spend effort making things slower.

But only if you assume they have reused any code from AppKit in  
UIKit. If you write something from scratch with multi-touch handling  
and integer coordinates in mind, you would probably come to a  
different approach.


Nikolaus