[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep Apps, iPhone.

From: Dr . H . Nikolaus Schaller
Subject: Re: GNUstep Apps, iPhone.
Date: Mon, 22 Oct 2007 12:03:50 +0200

Am 22.10.2007 um 11:07 schrieb David Chisnall:

On 21 Oct 2007, at 19:25, address@hidden 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]