New terms and conditions have come down the pipe…a lot of non-objectivec
toolkits seem to be impacted by this (including Adobe).
To me that doesn’t appear to ban SDL, perhaps it impacts monotouch
though.
It seems to say that apps must be written in c, c++, or obj-c. LibSDL
counts as part of the app, not a private api.
By Private apple mean the non-public foundation libs that are present
on the device but not documented for use within the sdkOn 8 Apr 2010, at 22:53, erik wrote:
http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
New terms and conditions have come down the pipe…a lot of non-
objectivec
toolkits seem to be impacted by this (including Adobe).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
If it is the case that SDL is affected by this, it would seem that Apple is
alienating a whole lot of users and developers. Then again, the same can be
said about Flash…
-BrendanOn Thu, Apr 8, 2010 at 6:31 PM, Ian Norton wrote:
To me that doesn’t appear to ban SDL, perhaps it impacts monotouch though.
It seems to say that apps must be written in c, c++, or obj-c. LibSDL
counts as part of the app, not a private api.By Private apple mean the non-public foundation libs that are present on
the device but not documented for use within the sdkOn 8 Apr 2010, at 22:53, erik wrote:
http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
New terms and conditions have come down the pipe…a lot of non-objectivec
toolkits seem to be impacted by this (including Adobe).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
This doesn’t affect SDL applications. SDL is a mix of C and Objective
C and uses public documented API calls.On Thu, Apr 8, 2010 at 2:53 PM, erik wrote:
http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
New terms and conditions have come down the pipe…a lot of non-objectivec
toolkits seem to be impacted by this (including Adobe).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Sam Lantinga <slouken libsdl.org> writes:
This doesn’t affect SDL applications. SDL is a mix of C and Objective
C and uses public documented API calls.http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
New terms and conditions have come down the pipe…a lot of non-objectivec
toolkits seem to be impacted by this (including Adobe).
Well there’s a (huge) sigh of relief.
thanks everyone for the help in the clarification.
cheers,
Erik> On Thu, Apr 8, 2010 at 2:53 PM, erik <erikyuzwa gmail.com> wrote:
As was said before, SDL is a layer over documented APIs.
In order for Apple to ban the iPhone port of SDL, they would need to implement something that would ban all third party libraries that use their documented APIs, which would just be stupid.------------------------
EM3 Nathaniel Fries, U.S. Navy
As was said before, SDL is a layer over documented APIs.
In order for Apple to ban the iPhone port of SDL, they would need to implement something that would ban all third party libraries that use their documented APIs, which would just be stupid.
And then, even if they tried to do that – how would they enforce it? by scanning binaries for strings that come from certain “forbidden” libraries? Well, devs would just react by creating tools that “obfuscate” the library usage. And so on.
Bye,
MaxAm 10.04.2010 um 19:39 schrieb Nathaniel J Fries:
They could require access to the applications source code. After all they
need to validate that the program was written
originally in C, C++ or Objective-C.
This really kills Apple for me, not even Microsoft has done something
similar.–
Paulo
On Sat, Apr 10, 2010 at 8:15 PM, Max Horn wrote:
Am 10.04.2010 um 19:39 schrieb Nathaniel J Fries:
As was said before, SDL is a layer over documented APIs.
In order for Apple to ban the iPhone port of SDL, they would need to
implement something that would ban all third party libraries that use their
documented APIs, which would just be stupid.And then, even if they tried to do that – how would they enforce it? by
scanning binaries for strings that come from certain “forbidden” libraries?
Well, devs would just react by creating tools that “obfuscate” the library
usage. And so on.Bye,
Max
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I have extensively went over the whole iphone sdl 1.3 port, rewriting parts of it where needed. But the point is I haven’t seen anything that would forbid sdl , sdl uses only documented api methods. There are a couple places that are questionable in its open gl handling (loading classes via an object class loader) but if necessary that could be rewritten.
Unfortunately I think the sdl pascal coders are out of luck.
Paulo Pinto wrote:> They could require access to the applications source code. After all they need to validate that the program was written
originally in C, C++ or Objective-C.
This really kills Apple for me, not even Microsoft has done something similar.
–
PauloOn Sat, Apr 10, 2010 at 8:15 PM, Max Horn <max at quendi.de (max at quendi.de)> wrote:
Am 10.04.2010 um 19:39 schrieb Nathaniel J Fries:
As was said before, SDL is a layer over documented APIs.
In order for Apple to ban the iPhone port of SDL, they would need to implement something that would ban all third party libraries that use their documented APIs, which would just be stupid.
And then, even if they tried to do that – how would they enforce it? by scanning binaries for strings that come from certain “forbidden” libraries? Well, devs would just react by creating tools that “obfuscate” the library usage. And so on.
Bye,
Max
SDL mailing list
SDL at lists.libsdl.org (SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
I have extensively went over the whole iphone sdl 1.3 port, rewriting parts of it where needed. But the point is I haven’t seen anything that would forbid sdl , sdl uses only documented api methods. There are a couple places that are questionable in its open gl handling (loading classes via an object class loader) but if necessary that could be rewritten.
Unfortunately I think the sdl pascal coders are out of luck.
Paulo Pinto wrote:> They could require access to the applications source code. After all they need to validate that the program was written
originally in C, C++ or Objective-C.
This really kills Apple for me, not even Microsoft has done something similar.
–
PauloOn Sat, Apr 10, 2010 at 8:15 PM, Max Horn <max at quendi.de (max at quendi.de)> wrote:
Am 10.04.2010 um 19:39 schrieb Nathaniel J Fries:
As was said before, SDL is a layer over documented APIs.
In order for Apple to ban the iPhone port of SDL, they would need to implement something that would ban all third party libraries that use their documented APIs, which would just be stupid.
And then, even if they tried to do that – how would they enforce it? by scanning binaries for strings that come from certain “forbidden” libraries? Well, devs would just react by creating tools that “obfuscate” the library usage. And so on.
Bye,
Max
SDL mailing list
SDL at lists.libsdl.org (SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
Hi,
Freepascal produces binaries compatible with gcc compiler. You can
even mix .o files with freepascal and gcc. I don’t think they will
even know it was written in freepascal unless they get access to the
source code…
But I’m a little bit worried since I’m planning on writing some iPhone
games and iPad apps in freepascal.
PavelOn 11.4.2010, at 5:57, michelleC wrote:
I have extensively went over the whole iphone sdl 1.3 port,
rewriting parts of it where needed. But the point is I haven’t seen
anything that would forbid sdl , sdl uses only documented api
methods. There are a couple places that are questionable in its open
gl handling (loading classes via an object class loader) but if
necessary that could be rewritten.Unfortunately I think the sdl pascal coders are out of luck.
Paulo Pinto wrote:
They could require access to the applications source code. After all
they need to validate that the program was written
originally in C, C++ or Objective-C.This really kills Apple for me, not even Microsoft has done
something similar.–
PauloOn Sat, Apr 10, 2010 at 8:15 PM, Max Horn <> wrote:
Quote:
Am 10.04.2010 um 19:39 schrieb Nathaniel J Fries:
Quote:
As was said before, SDL is a layer over documented APIs.In order for Apple to ban the iPhone port of SDL, they would need to
implement something that would ban all third party libraries that
use their documented APIs, which would just be stupid.And then, even if they tried to do that – how would they enforce
it? by scanning binaries for strings that come from certain
"forbidden" libraries? Well, devs would just react by creating tools
that “obfuscate” the library usage. And so on.Bye,
Max
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Pavel Kanzelsberger
E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633
For sure they will require access to the source code. It is the only way to
prove what the original language was.
For example, the Borland compilers always shared a lot of code, for some
disassembled code snippets you
cannot say if the original code was Turbo C or Turbo Pascal.
If you compile without debug symbols or other optimizations is also very
hard to check what the original language
was.
The new license agreement clearly states what the original language must be.
So the only way to prove it is to require
access to the source code. Which I find really funny, first because of what
might be the legal implications, second because
it will increase a lot the time taken during the approval process.
This reminds of an episode long long time ago, when Borland forbade
developers to use Borland C++ 4.5 (I think this was the version)
to write compilers for languages developed by Borland! Even without
Internet, they got so much bad feedback that they ended up
removing that clause from the license.
Now I hope for the Mac community that Apple gets enough backslash to rewrite
the license again, but being Apple I have my doubts.
I am really happy to still be a Windows/Linux user, even though I already
been tempted a few times to switch.–
Paulo
On Sun, Apr 11, 2010 at 9:48 AM, Pavel Kanzelsberger wrote:
Hi,
Freepascal produces binaries compatible with gcc compiler. You can even mix
.o files with freepascal and gcc. I don’t think they will even know it was
written in freepascal unless they get access to the source code…But I’m a little bit worried since I’m planning on writing some iPhone
games and iPad apps in freepascal.Pavel
On 11.4.2010, at 5:57, michelleC wrote:
I have extensively went over the whole iphone sdl 1.3 port, rewriting parts
of it where needed. But the point is I haven’t seen anything that would
forbid sdl , sdl uses only documented api methods. There are a couple places
that are questionable in its open gl handling (loading classes via an object
class loader) but if necessary that could be rewritten.Unfortunately I think the sdl pascal coders are out of luck.
Paulo Pinto wrote:They could require access to the applications source
code. After all they need to validate that the program was written
originally in C, C++ or Objective-C.This really kills Apple for me, not even Microsoft has done something
similar.–
PauloOn Sat, Apr 10, 2010 at 8:15 PM, Max Horn <> wrote:
Quote:
Am 10.04.2010 um 19:39 schrieb Nathaniel J Fries:Quote:As was said before, SDL is a layer over documented APIs.
In order for Apple to ban the iPhone port of SDL, they would need to
implement something that would ban all third party libraries that use their
documented APIs, which would just be stupid.And then, even if they tried to do that – how would they enforce it? by
scanning binaries for strings that come from certain “forbidden” libraries?
Well, devs would just react by creating tools that “obfuscate” the library
usage. And so on.Bye,
Max
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Pavel Kanzelsberger
http://www.kanzelsberger.com
E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Yep. This whole thing is very disturbing, not only because
of what Apple has done, but because of the implications it
has for the future of computing. My take on the subject:
http://tech.turbu-rpg.com/116/personal-property-and-computing________________________________
From: Pavel Kanzelsberger
Subject: Re: [SDL] SDL 1.3 now banned from the iPhone?
Hi,
Freepascal produces binaries compatible with gcc
compiler. You can even mix .o files with freepascal
and gcc. I don’t think they will even know it was
written in freepascal unless they get access to the
source code…
But I’m a little bit worried since I’m planning on
writing some iPhone games and iPad apps in freepascal.
Pavel
Heh heh. Ever wondered what Apple would do if they got a controlling share
of the PC market? There you go.
Jonny DOn Sun, Apr 11, 2010 at 5:01 AM, Mason Wheeler wrote:
Yep. This whole thing is very disturbing, not only because
of what Apple has done, but because of the implications it
has for the future of computing. My take on the subject:http://tech.turbu-rpg.com/116/personal-property-and-computing
>From: Pavel Kanzelsberger
**>Subject: Re: [SDL] SDL 1.3 now banned from the iPhone?Hi,
Freepascal produces binaries compatible with gcc
compiler. You can even mix .o files with freepascal
and gcc. I don’t think they will even know it was
written in freepascal unless they get access to the
source code…But I’m a little bit worried since I’m planning on
writing some iPhone games and iPad apps in freepascal.Pavel
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I thought Apple iTunes store already required access to your source
code and had an anal-retentive review policy?On Sat, Apr 10, 2010 at 2:27 PM, Paulo Pinto wrote:
They could require access to the applications source code. After all they
need to validate that the program was written
originally in C, C++ or Objective-C.
Nope,
You sign a binary ( or more than one for different versions of
firmware ) and they analyze the object data.
IanOn 11 Apr 2010, at 21:07, Donny Viszneki <donny.viszneki at gmail.com> wrote:
On Sat, Apr 10, 2010 at 2:27 PM, Paulo Pinto wrote:
They could require access to the applications source code. After
all they
need to validate that the program was written
originally in C, C++ or Objective-C.I thought Apple iTunes store already required access to your source
code and had an anal-retentive review policy?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Ah, same difference really thenOn Sun, Apr 11, 2010 at 5:13 PM, Ian Norton wrote:
Nope,
You sign a binary ( or more than one for different versions of firmware )
and they analyze the object data.Ian
On 11 Apr 2010, at 21:07, Donny Viszneki <@Donny_Viszneki> wrote:
On Sat, Apr 10, 2010 at 2:27 PM, Paulo Pinto wrote:
They could require access to the applications source code. After all they
need to validate that the program was written
originally in C, C++ or Objective-C.I thought Apple iTunes store already required access to your source
code and had an anal-retentive review policy?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
You know SDL might not be banned but the way some people are discussing it it might just prompt apple to include it in the ban.
I usually go along with Apples decisions, most are logical and trying to keep with good programming practices even though I don’t agree with then. Such as not using private
api’s but this 3.3.1 clause seems like a knee jerk reaction aimed at flash which could have a ripple effect.
This stuff about cross compilers producing inferior code is garbage, Back in the day when I was in engineering schools, we use to write our c and pascal compilers (yes I wrote compilers they are not some mystical beast like a unicorn) then compile the compiler code with the new compile which produced tighter optimized code. We also used to build intermediate little “Control” languages and interpreters into our code.
Todays systems with all their complexity are more vulnerable than ever to hackers, why , because so many programmers only know how to program at a high level that they don’t know how to guard?against old school programmers who are going to come in thru a very low level back door. I might spot it but I promise you 70% of the coders out there won’t.
SDL for iphone is not and never will be a compatibility layer, for safety any reference to that terminology should be removed. The licensed version of sdl is just a statically linked library of c and c++ code.
Any so called compatibility level is simply achieved by a jump table that translates sdl methods to iphone api methods. if Steve jobs considers that a violation of 3.3.1 then opengl itself is guilty too.
3.3.1 is clearly aimed at tools such as montouch, freepascal and adobe cs which interpret foreign code such as actionscript or c# into objective-c compilable code. clearly that should be the demarcation if there should be one at all.
SDL on the iphone works because it is a layer between sdl and open gl, it is almost a one to one, sdl commands map to opengl commands or a set of sdl commands, you can get the exact same effect building your own methods, its just someone already took the time to do it for you.
SDL’s 1.3 implementation of open gl is so “Soft” in fact it makes it a pain to create anything resembling an iphone applications. understand I am not criticizing sdl and the overall package is much better than the “subset” intended for iphone and most importantly with abiet some extra work you can move games and other applications from other platforms WHICH DOES make it a powerful class library .
But the way sdl creates its windows and eagl views in code makes it harder to add common iphone ui elements like nib files and subviews. It can be done, but I am finding to my dismay it can’t be done in a generic way, every app requires the code to tailored in a slightly different manner.
Trying to write portable code on the iphone platform is an observitiy, Maybe 3.3.1 is Apples’s unique way of admitting they designed a system that is hostile to portable code, building apps on the iphone is all about customizing view controllers and stacking views and subviews, you can do all that in code but than you have to go out of your way to mirror all the hidden initialization you get from using IB.
Running sdl in the manner prescribed by the documentation would definitely feed an Apple argument to ban it, it uses no nib files (which isn’t exactly that bad, Erica Sadun wrote an entire iphone “cookbook” full of examples that only use a main.m without any nibs. But nibs do help in loading and unloading view controllers which you will find is true when you try to convert an sdl program to use splitview controllers on the ipad. Like me you are going to have to reintroduce the mainWindow.xib at startup otherwise you might get the splitview to show with some trickery but you won’t get the popoverview to work correctly.
treating sdl as just another statically linked library will probably be ok. Thats my opinion but if its wrong then virtually EVERY statically linked library could be at risk which I don’t think Apple intends to do.
Apple has always had access to the source, but based on my experience with similar work situations it doesn’t seem feasible they have the reviewer staff to go through every line of code. My guess is they just use the static analyser tools UNLESS they suspect from the behavior of the app that somebody is doing something weird.
Otherwise there would not be so many apps in the apps store that obj load the core surface private framework. Any apps that does on Device video encoding (not decoding) or video sharing ie. ivideocamera etc uses that api.
An app that uses absolutely no UIkit components could fall under that suspicion category.
Sadly I myself have come up with a contingency plan for my own apps, mind you it would set my development cycle back a month or two but I could save my apps.
I have analysed the sdl methods I used, those could be fairly easily duplicated as in app classes, again SDL is just a class lib of methods written in C and C++ which could easily be duplicated locally.(C++ is officially ok) That would save my particular apps would others be able to adapt that strategy I am not sure. technically renaming the static library and the main methods would have similar effect, that is how absurd this who 3.3.1 business is.
SDL is about as vanilla as it comes to using approved api’s, I have more fear of other libraries I have used such as 320 than sdl, it doesn’t seem to use any private api’s anywhere.
I know I’ve been rambling on but this whole business is going to be confusing until Apple clarifies its vague language, which I suspect they will, when that happens I think it will be clear sdl will be ok but freepascal, monotouch etc are clearly out. Which I think shows they are being childish . Also arguments about those cross-compilers producing terrible code are just plain stupid.
Already working on that and I think I have Sam’s blessing.
I doubt a fork will be necessary the iphone portions of 1.3 will never fly with iphone developers. Hopefully when I do publish some actual library mods we can sit done as a community decide what we like and what I need to change.
As I’ve mentioned to Sam, right now the priority is to get the app done, when I have that completed, I plan to look at my mods and see what would be appropriate as a permanent 1.3 patch and what won’t work.
Hopefully sdl won’t get caught in this backlash about 3.3.2. I’ve asked for clarification on the official forum but haven’t gotten a reply yet.
But understand that sdl and the iphone WILL never be a perfect match, the Iphone UI methodology will just never allow that.
I don’t know if you can class iphone as with any other phones other than maybe android. And the real gaming platform is ipad not iphone. Its a beautiful device to work with.
BTW
You are totally off base about hackers, I know from experience some very good and important developers who don’t know a thing about how OS’s work, that is ok, trouble is there are people out there like me who can probably hack any system I wanted to if I actually wanted to. I’ve had to do some of that legally for a client so I know.
Something about morals keeps me from doing anything further. OH Well.
Nathaniel J Fries wrote:>
michelleC wrote:
You know SDL might not be banned but the way some people are discussing it it might just prompt apple to include it in the ban.
I usually go along with Apples decisions, most are logical and trying to keep with good programming practices even though I don’t agree with then. Such as not using private
api’s but this 3.3.1 clause seems like a knee jerk reaction aimed at flash which could have a ripple effect.I’m the same way. Usually, although I greatly dislike Apple’s policy, I do see how they can be a very simple way of “controlled computing” – a principle I will never agree with.
However, it’s the way Apple decided to run with it, so let them.This time, though, I don’t see how it can be “controlled computing”. Like you said, their target was flash, but they took out with it many great projects like Unity3D and MonoTouch.
michelleC wrote:
This stuff about cross compilers producing inferior code is garbage, Back in the day when I was in engineering schools, we use to write our c and pascal compilers (yes I wrote compilers they are not some mystical beast like a unicorn) then compile the compiler code with the new compile which produced tighter optimized code. We also used to build intermediate little “Control” languages and interpreters into our code.
Well, certainly, flash sucks on ARM processors.
MonoTouch didn’t, though, and neither would Lua, Python, or the like.michelleC wrote:
Todays systems with all their complexity are more vulnerable than ever to hackers, why , because so many programmers only know how to program at a high level that they don’t know how to guard?against old school programmers who are going to come in thru a very low level back door. I might spot it but I promise you 70% of the coders out there won’t.
I disagree with that, basically. It’s not the high level programmers not understanding old school programmers – although I’ve done a tiny amount of low-level programmer, I’m really just a high level programmer with lower level interests. Even before I learned programming (granted, 6+ years ago, but still), I never found myself vulnerable to such attacks.
It has to do with the fact that people just don’t know how to protect themselves and are too lazy to learn, and thus have learned to rely on firewalls and other such things that will let many things slip through the cracks. Even then, some people with firewalls installed find them irritating and frequently turn them off… bad move on their part, but that’s okay because they probably already got something anyway.michelleC wrote:
SDL for iphone is not and never will be a compatibility layer, for safety any reference to that terminology should be removed. The licensed version of sdl is just a statically linked library of c and c++ code.
Any so called compatibility level is simply achieved by a jump table that translates sdl methods to iphone api methods. if Steve jobs considers that a violation of 3.3.1 then opengl itself is guilty too.
You’re right, it isn’t an “iPhone compatibility layer”, it is a “system UI compatibility layer”. It’s not just a compatibility layer for iPhone, it’s a compatibility layer for OS X, Linux, Windows, *BSD, and any other operating system that may find itself an SDL port in the future.
michelleC wrote:
3.3.1 is clearly aimed at tools such as montouch, freepascal and adobe cs which interpret foreign code such as actionscript or c# into objective-c compilable code. clearly that should be the demarcation if there should be one at all.
But what’s wrong with that…? That’s what I want to know.
Sure, Flash on iPhone pretty much blows and has probably been ruining the platform, but monotouch and freepascal? I think they’re fine…
Honestly, I think that if Apple has a problem with the third party doing it, they should port Mono and FreePascal themselves. Mono and FreePascal through Xcode would be great.
And, just to satisfy my own suspicions, I think the fact that those great projects were affected along with flash is really just their way of taking a poke at F/OSS again.michelleC wrote:
SDL on the iphone works because it is a layer between sdl and open gl, it is almost a one to one, sdl commands map to opengl commands or a set of sdl commands, you can get the exact same effect building your own methods, its just someone already took the time to do it for you.
SDL’s 1.3 implementation of open gl is so “Soft” in fact it makes it a pain to create anything resembling an iphone applications. understand I am not criticizing sdl and the overall package is much better than the “subset” intended for iphone and most importantly with abiet some extra work you can move games and other applications from other platforms WHICH DOES make it a powerful class library .
But the way sdl creates its windows and eagl views in code makes it harder to add common iphone ui elements like nib files and subviews. It can be done, but I am finding to my dismay it can’t be done in a generic way, every app requires the code to tailored in a slightly different manner.
Eh, you might be right. But that’s because SDL doesn’t create windows in the iPhone way, it creates them in the PC way; which is proper because PC systems are SDL’s biggest targets.
If you want better iPhone integration from SDL, we already know you have the familiarity with SDL to do it.
Make your own fork project; or simpler, write your own API to accompany SDL in performing these tasks. The great thing about F/OSS, the reason I love it, is that if you want to change how the product works to fit your wants and needs, it’s very simple. You should take advantage of this factmichelleC wrote:
Trying to write portable code on the iphone platform is an observitiy, Maybe 3.3.1 is Apples’s unique way of admitting they designed a system that is hostile to portable code, building apps on the iphone is all about customizing view controllers and stacking views and subviews, you can do all that in code but than you have to go out of your way to mirror all the hidden initialization you get from using IB.
Well, I don’t think it’s that bad. The truth is, a phone is not and never will quite be a PC. They have different needs, different capabilities, and extremely different hardware (although ARM seems to think it can step into the PC market soon, but, they’re not there quite yet). So of course writing code portable from a phone to a PC isn’t easy, and SDL might not be the ideal answer for that.
However, SDL is pretty much ideal for porting between PC systems…michelleC wrote:
Running sdl in the manner prescribed by the documentation would definitely feed an Apple argument to ban it, it uses no nib files (which isn’t exactly that bad, Erica Sadun wrote an entire iphone “cookbook” full of examples that only use a main.m without any nibs. But nibs do help in loading and unloading view controllers which you will find is true when you try to convert an sdl program to use splitview controllers on the ipad. Like me you are going to have to reintroduce the mainWindow.xib at startup otherwise you might get the splitview to show with some trickery but you won’t get the popoverview to work correctly.
So fork, or patch, or allow specification of your own nib files through a companion API. I don’t really know how nib files work.
I imagine it can’t be too hard to make a companion library to SDL specially made for the iPhone that implements everything you’ve described. At least not for someone used to them.
michelleC wrote:
Already working on that and I think I have Sam’s blessing.
I doubt a fork will be necessary the iphone portions of 1.3 will never fly with iphone developers. Hopefully when I do publish some actual library mods we can sit done as a community decide what we like and what I need to change.
As I’ve mentioned to Sam, right now the priority is to get the app done, when I have that completed, I plan to look at my mods and see what would be appropriate as a permanent 1.3 patch and what won’t work.
That’s good to hear.
michelleC wrote:
But understand that sdl and the iphone WILL never be a perfect match, the Iphone UI methodology will just never allow that.
I don’t know if you can class iphone as with any other phones other than maybe android. And the real gaming platform is ipad not iphone. Its a beautiful device to work with.
a proper Android port of SDL wouldn’t be easy, but I can’t say it’d be as intolerable as you’ve found SDL on iPhone to be.
Android, graphically, is just the Linux framebuffer with a nice-looking GUI toolkit written in Java. The hardest part of SDL on Android would probably be working with JNI.
michelleC wrote:
You are totally off base about hackers, I know from experience some very good and important developers who don’t know a thing about how OS’s work, that is ok, trouble is there are people out there like me who can probably hack any system I wanted to if I actually wanted to. I’ve had to do some of that legally for a client so I know.
Oh, I never disagreed completely. I’m definitely more at risk than a person with experience in breaking system security.
But I’ve yet to encounter anything ever since I’ve had a PC which only I accessed, despite regularly visiting shady websites and downloading shady files.
I think a level of technical knowledge just above what’s currently widely considered as “competence” is all that’s required to protect one’s self, unless their system is actually the sole target of an attacker.
michelleC wrote:
You don’t get it, apple doesn’t want competition from other platform, its not hard to see were a cross compiler could be easier to use and adapted more widely then the more official languages. In a way that could be bad for future development because the 3rd parties may not be able to catch up with an agressive development cycle.
I don’t see why they couldn’t add a Pascal/Delphi compiler to the mix, at the very least. It isn’t competition from another platform, it’s just the easiest way for a developer more familiar with Pascal than the C family to make applications for the iPhone.
Mono, too, why not? Java’s been pretty much standard in mobile device development for quite awhile now, and Mono does basically the same thing as Java, so why would any mobile device NOT want Java/Mono runtimes?
michelleC wrote:
So what, that hurts the 3rd paties not Apple, but they want to micromanage everything. Frankly, I think if Android starts getting a bigger share of the development arena these policies will change overnight. Its happened before in other industries and it will happen here.
[…]
I know of one company with a million dollars invested in using monotouch. It is not a small company, that much I will say.
Android won’t really get that until they provide better facilities for native developers, though, I’m afraid.
I know I’m still not developing for the Android, although I’d love to, because they simply don’t provide enough native APIs to make anything decent without using JNI (which looks like a royal pain to me, and requires me to learn not only Android’s APIs but a more complicated and confusing third-party API…).
Once I can know when a call is coming, access the menu at the top, use system widgets, and all that – I may actually make something. Until then, my loathing of some of the minor points of programming in Java will stop me from writing anything in Java, even for a platform I consider valuable…------------------------
EM3 Nathaniel Fries, U.S. Navy