[Mono-osx] Delphi Prism and all those Cocoa bridges

[Matt Emson]

Andrew Brehm wrote:
> It's a Mac mentality these days. NeXT solved the problem with the bundles
>   
> concept. It's still a whole bunch of files, but it looks like one file and
> can easily be copied (and installed by simply copying).
>   

It's not about the storage of the programme and data. In Windows, this 
is opaque. The user will have an entry on the Start menu and possibly 
Desktop, but are never expected to find the actual executable. The Mac 
tends to allow that because, as you rightly identify, the Mac 
application is self contained. What I'm trying to say is, I think you're 
attempting to solve a problem that either doesn't exist or at very most 
is minimal. If a developer doesn't supply an installer with for a 
Windows app, *they* are the exception to the norm these days. It is 
annoying, I know, but an unfortunate fact.

> I don't know how Linux wants its programs to be delivered (installer? RPM?
> ?) but I guess the Windows installer should install, into the program files
> directory a bundle.app containing everything needed to run the program on
> Windows and Mac OS X, and create a shortcut for the program menu. The root
> directory of the bundle should also contain a shortcut creator for Windows.
>   
Linux is a big old kettle of fish. Depends on vendor. You have 3 camps: 
(1) Redhat based distros expect a RPM file. (2) Debian based distros 
expect a DEB file. (3) Other distros expect a tar.gz that will either 
need to be compiled from source of contain a binary tree - usually a 
script would be included to install the components, but not all the 
time. With Linux you must ask yourself "who do I want to support?" If it 
is Ubuntu, Mint or Debian, a DEB file shoulf be produced and you would 
need to get that file included in a Debian repository for optimum 
simplicity. It it is SuSE/OpenSuSE/Fedora etc, an RPM, otherwise, you 
would need to devise your own mechanism. There are tools that will 
convert DEBs to RPMs and vice versa, but they can be very hit or miss 
sometimes - depending on how wide the library/framework dependencies for 
the app are.


> The Apple version should be distributed as a bundle.
>   

Most Mac users expect either an installer (.pkg/.mpkg) or an .app that 
they can drag to the Applications folder. Usually, this will be in the 
form of a .dmg, containing the files. Using a .dmg for app delivery is 
pretty much the way to go these days.

> This has the advantage of two versions for two platforms that both behave
> completely native, but are still interchangeable. I can copy the installed
> Windows version onto a Mac and it will be a bundle (because it is). And I
> can copy the Mac version (or installed Windows version) to a Windows
> computer's program files folder and run the shortcut creator and have a
> working Windows version again.
>   
Well, yeah. This was why I suggested that making a big deal about the 
app being a bundle when installed on Windows is not really as much of an 
issue as you think it is. To a Windows user, they'll see a shortcut and 
that's about it. How it works at a filesystem level is nothing they need 
ot be aware of.
> Objective-C 2.0 doesn't work on 10.4 and earlier, I think. (Or is it 1.3 and
> earlier.) And I believe the iPhone doesn't support Objective-C 2.0 at all.
>   
Okay, this is very much my own opinion and experience, but; in the world 
of Apple, every major release silently obsoletes the release 2 back in 
the history. This attitude sucks, but I got the same when using Panther 
(10.3) when Leopard (10.5) was released. You'll see a slow decline in 
the number of supported apps, tailing off towards the release of the 
next version (10.6). It's pretty hard to find Panther apps now - Mono 
does not even officially support it. The 10.4 death knell might be 
longer if the rumours of Apple not supporting any PowerPC machines with 
10.6 are true. Given a year, 10.4 will be in the same position as 10.3 
is now though.

The iPhone dev kit supports the Syntax. Properties and such, that were 
introduced in Objective C 2.0. It doesn't support everything though, yes.

> One advantage of using Objective-C is that the application can easily be
> ported to the iPhone (if it makes sense for the program). But I hear Novell
> have a solution for running .NET binaries on the iPhone hard-linked 
Yeah, Miguel has blogged about it. There is a company selling a product 
called Unity, that uses Mono and can create iPhone Games, but it uses 
custom code for graphics and isn't able to do GUI apps.
> with
> Mono using Windows Forms or Silverlight/Moonlight. So that advantage of
> Objective-C's might not be relevant any more.
>   
News to me. I heard last that there was no GUI for the iPhone. It's also 
worth noting that Miguel stated it was pretty complicated to get the 
build process for each app to work at the moment. I've not heard 
anything since January though, so things have obviously changed.

With Unity, the developers have solved much of the issues with building, 
but it is closed source and costs quite a bit of cash, so it's not 
really something to buy on a whim.

> My experiences with the Compact Framework was limited to finding out that
> Windows Mobile 5 supported .NET 1.1 and cannot be updated (at least on my HP
> device) and that Visual Studio 2005 (the earliest I have and I refuse to
> downgrade) supported .NET 2.0 and upwards. Hence I could never develop for
> Windows Mobile and gave up. Apple seem to be a lot better with the software
> update thing for mobile devices. The combination Xcode/iPhone works for me.
>   

You need to install the framework on the machine. They both sit there 
side by side happily. I was using both Dell Axim X50's and X51's as well 
as older O2 Win Mobile Phones that had 2003 on them. So long as they're 
ARM based, it shouldn't be a problem - though anything is possible with 
Microsoft. What you lose is a bunch of storage. I even has Framework 2 
running on a MIPS based handheld with 2002 on it - and that was pretty 
much as extreme as you can get ;-)

> Thanks for all the input.
No worries ;-)

M