Jonas wrote

we even have administrative people at our university who have learned to be somewhat efficient with our SAP implementation, which is universally recognised by everyone here as a the most horrible user interface they have ever used).

------

Funny you mention this because my idea for a new application would directly compete with SAP for a particular industry. What is encouraging is that the opinion you cite is the same one I have found in my own informal poll of actual non advanced "Joe" users.

The question/comment of web apps is valid. Actually, you can officially create web applications for the iPhone right now and Apple has not officially/fully released the Cocoa development kit for the iPhone yet - still beta. So, Apple is a bit bipolar already.

Apple makes it hard for the individual "developer" to think their own way as far as human interfaces go. This seems contrary to their advertising - but their purpose is to make the end user's experience as unobtrusive as possible navigating ANY application right out of the box. Macs have been typically marketed to artists and if one looks at the computers shown in TV shows and movies, you will notice that Apple logo quite often. These artist types usually have a different mindset than computer programmers and often even struggle with Mac applications much less Windows or command line systems. If a more intuitive human interface was not an important feature, we would probably still be typing in commands at the C prompt. Thus Apple's philosophy has been to try to force programmers to think Apple's way. And it works for them. Their users are very happy with the consistency and it is very hard to get mac users to switch unless they have to because of pressures at the work place.

Actually, I like being able to let Apple dictate the human interface GUIDElines AND supply routines to implement those guidelines. It is a pain at first to have to learn, but after you learn it and have implemented a shell with them, you don't need to have to maintain a lot of code. This is Apple's strategy to keep end users happy and developers subservient. My complaint with Apple is (1) they switched from Pascal interfaces to Objective C and (2) you must learn their entire Cocoa development paradigm and not just the individual HI widgets if you want to be a "true" developer. They bundle an entire development system to make it easier for you to do it their way. That is why I haven't been programming for 10 years until now when FPC and a nice simple third party IDE came out for it and actually it was by semi accident I discovered it.

I fully understand and sympathize the issues of trying to get a port out and implementing a HI paradigm is a lot of work. I did this with some of 15 year old Mac programs at first but ended up learning (and still at the relative bottom of the hill) and implementing Apple's current API. Yeah, it is work.

What I am curious about is why are people porting programs from other platforms to the Mac? From the discussions, it seems that the end users are happy with their current implementation. Macs are more expensive. Macs have only maybe 5% of the corporate market share and maybe 15% (at most) of the home market. The end users are used to their current HI and seem to like it. A lot of work and money is needed just to make a bare bones port. This doesn't seem to be logical to me so I must be missing something. What is driving the port? Many developers have dropped Mac implementations since it was too expensive to maintain.

I , myself am thinking I might be able to sell a Mac application where there is NO currently available product. If I was fluent in Windows programming, I definitely would write the application for Windows since the end users mostly/all are used to and have windows computers. I have ideas how to address this but if I were working for a regular software company, I have no doubts that this implementation idea would be thrown out as being fiscally irresponsible. And it would be hard to argue. In this case, one does need to "think different" in order to attempt to accomplish this foolish idea. However, the converse of porting from windows to a Mac seems very problematic and has me scratching my head.

What I am curious about is why are people porting programs from other platforms to the Mac?

Simply because there is demand. Most of what is said goes for direct sales to mac people, which is often not the case for these ported software. It is a distinction that I somewhat miss in these discussions.

It is about selling your windows/Linux software that wants a "solution" for the one demented mac user that maintains the companies newsletter (and which the helpdesk was already glad to be able to wane from classic Mac OS, let alone move to something "horrible" as Windows).

The constant questions get fatigueing, so you search for some way to shut them up, and if you have to do it, at the same time make something out of it to add a bullet to your marketing. (we support Mac).

However it shouldn't cost too much, specially not something like reschooling a developer. (in Objective C and the Mac Way(tm) in general, exorcism included)

Of course this is an a bit cynical and slightly exagerrated (but true!) description, but the point is to try to avoid looking at this situation from a too Mac angle. Keep in mind that the home-user is not the bulk user of custom software, that is the industry.

If the devels targeting Mac with portable suites were so Mac centric and perfectionist as described in this thread, they would go the Apple prefered way, and invest massively in some ObjC solution, to not miss some word of mouth or a pat on the shoulder from Apple and/or partners.

So apparantly the porters are (in general) are not putting the Mac central to their world, so trying to force them to is useless. You can only enable them by making things easier. (which are often small things, like Lazarus introducing a widget to make dialogs that have the same button order under OS X)

Even several Mac-only developers do not do this because they have too much investments in existing code and skills. And they can make perfectly fine apps.

So apparantly the porters are (in general) are not putting the Mac central to their world, so trying to force them to is useless.

Nobody has asked for this. But flooding the Mac market with quick&dirty Windows ports is going to be as commercially successful as Kylix was on Linux, no matter how "demented" your targeted Mac users may be (and those will probably the only Mac users you'll ever have in that case).

Jonas

Hmm, how do they (plan to) deal with the 64-bit carbonicide then?

I do not agree with the analogy. The problem with Kylix was that it targeted a (not yet) existing market, namely corporate linux desktop users. Because despite the many problems (and me being the heaviest "fix that Kylix code" critic here), IMHO Kylix should have been enough for its target audience.

The problem was that the target audience didn't exist/didn't emerge as fast as expected. (we are 5-8 years further, and Linux on the desktop in corporations uptake is still slow to non existent.

The Mac users however are there, in publishing oriented departments, the occasional manager with a laptop, ok, not really numereous, but they are real.

no matter how "demented" your targeted Mac users may be (and those will probably the only Mac users you'll ever have in that case).

Hehe, I knew that would ruffle some feathers. However it was more than a cheap shot. It is really how the avg corporate admin or helpdesk regards Macers. They are "different", and there that "different" doesn't have the same positive connotations as in the Mac ads. They are simply a burden, because they upset contemporary large scale workplace maintenance.

So you seem to miss my point. Namely that for most of the porters a proper budget to do it right is simply missing.

So it's either "quick&dirty" or not. Both for the developers, as for the users. And IMHO it is arrogant to state that then there can be no such apps at all.

That's a different matter and may actually be a real reason to invest in Cocoa/Obj-C, but for most apps 64 bit needs are still quite far off. This can also happen gradually since you can perfectly combine Cocoa and Carbon in a single app (they're also adding functionality to make that easier).

And because the IDE was slow, buggy and crashing all the time to the point where it was virtually unusable (at least that's what I remember from Michael's mails). The reason (or at least one of the reasons): it was a quick&dirty Windows port using an early version of Wine rather than a native Linux port.

So you seem to miss my point. Namely that for most of the porters a proper budget to do it right is simply missing.

I'm very well aware of that, I'm just saying what the consequences are/ will be of that.

Who said there cannot be such apps? I'm only saying that in general it is a bad idea to create them because they won't be received very well by the Mac users/market at large (and if someone else creates one with a proper interface which does more or less the same as yours, your small investment will probably soon enough be largely in vain, except possibly for those helpdesks that only want to shut up annoying users).

It's just market advice, not a moral judgement. And obviously cost also plays a role in case of taking development decisions, but few non- Mac users in this discussion appear to agree on the importance of having a native look&feel, which may result in a cold turkey if they'd try their hand at the Mac market (you can consider it at least as important there as stability and performance).

Jonas

Richard Ward wrote

What I am curious about is why are people porting programs from other platforms to the Mac?

Because other people are paying them? Obviously those people paying developers to port apps to Macs beliave they will sell those apps to Mac users.

Or in some cases fun. But money is a strong factor. I wouldn't even have a Mac in the first place if I didn't receive to write an app for a Mac once, so I would not be able to develop in it for fun.

Nobody likes to invest in a trajectory that is uncertain.

Compared to Delphi standards it was bad. Of course since pretty much the only other choice was either primordial Eclipse or commandline, it was above its direct competition in every way, despite of the problems.

The reason (or at least one of the reasons): it was a quick&dirty Windows port using an early version of Wine rather than a native Linux port.

Winelib, and only the earlier versions iirc.

We'll see. Like the other commenters on the thread said, I also have the feeling that this is mostly the formal stand of the Mac innercrowd, echoed over various macfanatics websites.

I've no way to prove that point however, so I haven't brought it up before.

Fact is however that the center Mac will become increasingly outside the former strongholds. (I even saw FreeBSD core developers with macbooks on FOSDEM. And no, it wasn't running FreeBSD)

Well, the point is that you don't sell to sell to people that have to support Mac, and often grudgingly. They don't have a Calimero complex, and are not indoctrinated by Mac sites to have unrealistic expectations.

Most central IT organizations are not Mac oriented, and the standards for specialist custom software are generally much lower than for shrinkwrap software (excluding some of the bulksoftware on Windows. Whoever came up with the idea that something that resembled a blob if spilt paint is a perfect UI should be shot). Money is much harder to make in shrinkwrap software anyway.

It's just market advice, not a moral judgement.

If it is really about real life markets, then we should first discuss distribution channels. Selling is a lot less about technical details then most people think. Which is why big companies piece of the bulk shrinkwrap software market gets bigger every year.