[Mono-osx] Delphi Prism and all those Cocoa bridges
memsom at interalpha.co.uk
Fri Feb 27 08:15:06 EST 2009
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.
> 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 ;-)
More information about the Mono-osx