Cross-Platform Windows plus Mac

In article ,
"Chris Shearer Cooper" wrote:

> I'm a C++/Windows developer at a small (well, tiny) company, and I've been
> asked to explore what it would take to create an application that could be
> built for both Windows (XP + Vista) and Mac.
>
> I've never done any Mac programming, so I was hoping people could send me
> suggestions for books, web sites, tools, etc. that talk about ways to
> accomplish this.

<http://developer.apple.com/> should be your first stop. From there, you
will find
<http://developer.apple.com/documentation/Porting/Windows-date.html>

> The application has no UI except for an icon that lives in
> the system tray on Windows (which would be the ... what? ... on Mac),

That depends on what your tool exactly is doing. Apple has a lot of
things that can appear at the right edge of the menu bar (BlueTooth
status, sound volume, Airport status, etc), and there are ways to stuff
your own menu there (but, as far as I know, no officially supported way).

Alternatives might be
- an application that shows its status in its dock icon
- a preferences plugin
- an application that shows a small,
optionally floating and/or transparent window
- an application that registers a global hotkey
- any combination of the above

From the information you gave I can not even guess what's best for your
program.

Opinion: I use Windows at work for hours each day, and can not think of
anything that lives in the system tray that Microsoft did not provide by
default that I would miss if it wasn't there. I understand that
companies want to fight for my attention, but that does not mean I have
to like that.

> so that makes things easier.

In my book, that makes it harder. There is no 100% match for the System
Tray, so you may have to choose a whole different solution for your
application.

> 1) Have two totally separate codebases, one for Windows, one for Mac.

Could be the best idea, if all or almost all of the code would be
platform specific, anyways. I can not tell that from the information you
gave.

> 2) Have some code be Windows and Mac specific, and then the core
> functionality be shared code.

That is the normal thing to do, but, depending on what your tool does,
the amount of shared code might be so small that this is not worth the
trouble.

> 3) Buy a product like QT

I do not know QT, but would doubt that QT would help at all in creating
that system tray icon-like thing. I also would expect that whatever else
this thing does would not contain much UI stuff.

In some cases, the other QT (QuickTime) might be an option for
cross-platform development, but again, you do not give sufficient info
whether that would be a realistic option.

> Management has said that if QT is worth it, they'll spring for it, but I
> don't know enough about it to know if (QT + my learning curve on QT) < (my
> learning curve on Mac + time to support multiple code bases).

In general, you should check that whatever you create does not only look
like a Mac product, but also feels like it (and do check that both on
Tiger and on Leopard, due out any day now; I would not bother supporting
anything earlier than 10.4)

Opinion: I have my doubts that QT can pull that off (hm, I just
downloaded qt-mac-opensource-4.3.2.dmg and looked at a few sample
applications (I also saw a 'SysTray' example, but could not discover
that it actually did anything on my Mac). That did not change my
opinion. Examples:
- The hideous green off its installer window
- Text fields aren't real Mac text fields:
- no standard font panel
- services do not work
- highlight color is way too saturated
Overall, for me, a tool would have to be extremely useful for it to
counteract these shortcomings. I do not think that, in this respect, I
am that excentric for a Mac user.


Reinder
 >> Stay informed about: Cross-Platform Windows plus Mac 

having just finished writing exactly what you are ebarking upon.. I
can tell you a few things:

1. the equivalent to the windows tray app is a 'menulet' .. see :
http://www.mactech.com/articles/mactech/Vol.22/22.02/Menulet/index.html

2. Jeffery's point about writing your core functionality in portable C+
+ is bang on the money. Try to abstract out as much as you can.

3. the only platform dependent things tend to be UI or I/O ... so if
you can isolate those bits, then you are golden. For example, http
calls, file i/o ...

4. on the Mac, you should write the menulet in Cocoa/objective C ...
install XCode and grab the Hillegas book - you'll be up and running in
a week.

5. I needed to do things with XML, so I used libxml2 - it is cross
platform.

6. I implemented my Mac HTTP code using Carbon... CHTTPMessageRef and
friends.... it's all C++ ...


hope this helps
A
 >> Stay informed about: Cross-Platform Windows plus Mac 

On 11/10/2007, Chris Shearer Cooper wrote in
message
:

> I'm a C++/Windows
developer at a small (well, tiny) company, and I've
> been asked to
explore what it would take to create an application that
> could be built
for both Windows (XP + Vista) and Mac.

Hard to know how to answer this
without knowing what kind of application you're writing.

> The
application has no UI except for an icon that lives in
> the system tray on Windows (which would be the ... what? ... on Mac), so
> that makes things easier.

The equivalent might be an icon on the Dock, but it might be that the
application is more useful as a menubar extra. Or it might be best as a
Dashboard widget. Depends what it does. Developing menubar extras isn't
possible in most cross-platform development tools: they require the use of
hooks which occur only on the Mac.

Warning: the most common mistakes made
by people porting non-games applications to the Mac are that they port
something that (a) doesn't make sense on a Mac, or (b) the Mac OS itself
already does, or (c) already available as freeware or shareware on a
Mac.

Simon.
--
http://www.hearsay.demon.co.uk
 >> Stay informed about: Cross-Platform Windows plus Mac 

"Chris Shearer Cooper" a écrit dans le message de
13gt3ni4lntm141 RemoveThis @corp.supernews.com...
> I'm a C++/Windows developer at a small (well, tiny) company, and I've been
> asked to explore what it would take to create an application that could be
> built for both Windows (XP + Vista) and Mac.
>
> I've never done any Mac programming, so I was hoping people could send me
> suggestions for books, web sites, tools, etc. that talk about ways to
> accomplish this. The application has no UI except for an icon that lives
> in
> the system tray on Windows (which would be the ... what? ... on Mac), so
> that makes things easier. I'm imagining 3 approaches ...
> 1) Have two totally separate codebases, one for Windows, one for Mac.
> 2) Have some code be Windows and Mac specific, and then the core
> functionality be shared code.
> 3) Buy a product like QT
>
> Management has said that if QT is worth it, they'll spring for it, but I
> don't know enough about it to know if (QT + my learning curve on QT) < (my
> learning curve on Mac + time to support multiple code bases).
we gone the 3. way with wxWidgets (www.wxwidgets.org) which is free, this is
definitely a correct way.

Armel
 >> Stay informed about: Cross-Platform Windows plus Mac 

In article ,
"Armel Asselin" wrote:

> we gone the 3. way with wxWidgets (www.wxwidgets.org) which is free, this is
> definitely a correct way.

For a very loose definition of "correct". I haven't seen a single
wxWidget-based app that works the way a Mac user expects. Please point
me to yours by name, or any such app based on a portable library that
doesn't quite simply blow. Appealing to the lowest common denominator
ends up being very unappealing.

--
My personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com,
heapnode.com, localhost, ntli.net, teranews.com, vif.com, x-privat.org
 >> Stay informed about: Cross-Platform Windows plus Mac 

In article
,
Doc O'Leary wrote:

> In article ,
> "Armel Asselin" wrote:
>
> > we gone the 3. way with wxWidgets (www.wxwidgets.org) which is free, this
> > is
> > definitely a correct way.
>
> For a very loose definition of "correct". I haven't seen a single
> wxWidget-based app that works the way a Mac user expects. Please point
> me to yours by name, or any such app based on a portable library that
> doesn't quite simply blow. Appealing to the lowest common denominator
> ends up being very unappealing.

I know of exactly one cross-platform (and I mean many more than "2" when
I say "cross") toolkit that actually did a good job at presenting a
native experience. Unfortunately:

1. It's defunct.
2. It was prohibitively expensive to license for most developers when it
was around.
3. The binaries were huge, especially for the time.
 >> Stay informed about: Cross-Platform Windows plus Mac 

"Doc O'Leary" a écrit dans le message
de
droleary.usenet-258C41.06525922102007 RemoveThis @sn-ip.vsrv-sjc.supernews.net...
> In article ,
> "Armel Asselin" wrote:
>
>> we gone the 3. way with wxWidgets (www.wxwidgets.org) which is free, this
>> is
>> definitely a correct way.
>
> For a very loose definition of "correct". I haven't seen a single
> wxWidget-based app that works the way a Mac user expects. Please point
> me to yours by name, or any such app based on a portable library that
> doesn't quite simply blow. Appealing to the lowest common denominator
> ends up being very unappealing.
the definition of 'correct' definitely depends on what you expects from an
application.
From our point of view, the application should work and be reasonably
similar to a solution developped solely for the target platform.
Nonetheless, if a few widgets are not 'native-looking' and if we have no or
few platform-specific 'eye-candy' stuff, it's perfectly ok.

our app is ECMerge (a diff/merge tool): www.elliecomputing.com
for sure our definition stands well for a development tool. I presume that
it would not be OK for a game or something like that.

Best regards
Armel
 >> Stay informed about: Cross-Platform Windows plus Mac 

In comp.sys.mac.programmer.help Armel Asselin wrote:
>
> "Doc O'Leary" a ?crit dans le message
> de
> droleary.usenet-258C41.06525922102007 RemoveThis @sn-ip.vsrv-sjc.supernews.net...
>> For a very loose definition of "correct". I haven't seen a single
>> wxWidget-based app that works the way a Mac user expects. Please point
>> me to yours by name, or any such app based on a portable library that
>> doesn't quite simply blow. Appealing to the lowest common denominator
>> ends up being very unappealing.
> the definition of 'correct' definitely depends on what you expects from an
> application.
> From our point of view, the application should work and be reasonably
> similar to a solution developped solely for the target platform.
> Nonetheless, if a few widgets are not 'native-looking' and if we have no or
> few platform-specific 'eye-candy' stuff, it's perfectly ok.

You are of course free to do as you wish. If your target market is people
who aren't terribly concerned about user experience, or people who care
much more about being able to use your product than about how good its GUI
is, then this would definitely make sense.

However, I just wanted to point out that the major deficiencies in such
applications are not in how they *look*, but in how they *act*. These apps
often miss platform-specific expected behaviors such as keyboard
shortcuts, toolbar usage, proxy icons, dirty window indications, etc.
Poor looks can be ignored, but poor behavior is tougher.

Anyway, you may know all this already, but I thought I would mention it.
Much of this can of course be worked around if you devote sufficient
attention to the Mac port. Let us know how it works out for you.

--
Michael Ash
Rogue Amoeba Software
 >> Stay informed about: Cross-Platform Windows plus Mac 

On Mon, 22 Oct 2007 06:52:59 -0500, Doc O'Leary
wrote:
> In article ,
> "Armel Asselin" wrote:
>
>> we gone the 3. way with wxWidgets (www.wxwidgets.org) which is free, this is
>> definitely a correct way.
>
> For a very loose definition of "correct". I haven't seen a single
> wxWidget-based app that works the way a Mac user expects. Please point
> me to yours by name, or any such app based on a portable library that
> doesn't quite simply blow.

IMO Qt meets your requirements. It also has the huge advantage of not
being written in an obscure dialect of C that is virtually unknown in
the worlds of Windows and Unix.

A bientot
Paul
 >> Stay informed about: Cross-Platform Windows plus Mac 

In article ,
Paul Floyd wrote:

> On Mon, 22 Oct 2007 06:52:59 -0500, Doc O'Leary
> wrote:
> > In article ,
> > "Armel Asselin" wrote:
> >
> >> we gone the 3. way with wxWidgets (www.wxwidgets.org) which is free, this
> >> is
> >> definitely a correct way.
> >
> > For a very loose definition of "correct". I haven't seen a single
> > wxWidget-based app that works the way a Mac user expects. Please point
> > me to yours by name, or any such app based on a portable library that
> > doesn't quite simply blow.
>
> IMO Qt meets your requirements.

I can't speak for Doc, but I doubt it meets his requirements. I can spot
a Qt app a mile off.

> It also has the huge advantage of not
> being written in an obscure dialect of C that is virtually unknown in
> the worlds of Windows and Unix.

I know what language you think you're describing, but you're not.
 >> Stay informed about: Cross-Platform Windows plus Mac 

In comp.sys.mac.programmer.help Paul Floyd wrote:
> On Mon, 22 Oct 2007 06:52:59 -0500, Doc O'Leary
> wrote:
>> In article ,
>> "Armel Asselin" wrote:
>>
>>> we gone the 3. way with wxWidgets (www.wxwidgets.org) which is free, this is
>>> definitely a correct way.
>>
>> For a very loose definition of "correct". I haven't seen a single
>> wxWidget-based app that works the way a Mac user expects. Please point
>> me to yours by name, or any such app based on a portable library that
>> doesn't quite simply blow.
>
> IMO Qt meets your requirements.

Would you happen to know of any downloadable Qt apps which look and behave
like native Mac apps? I would love to see one. I think it would be great
if there were a viable cross-platform application framework, but so far
every single application I've seen which was written in one completely
failed to look or act the way I expected. If there are proper apps written
in Qt then perhaps my assessment is wrong.

> It also has the huge advantage of not
> being written in an obscure dialect of C that is virtually unknown in
> the worlds of Windows and Unix.

I never understood this argument. Objective-C takes virtually no time to
learn when compared against the time it takes to learn an application
framework. The fact that it's not the same language as the rest of your
code should be irrelevant; your platform-specific code isn't going to
compile on other platforms *anyway*, so what's the big deal if it's
failing to compile because it's missing a bunch of libraries and headers,
or if it's failing to compile because it's missing a bunch of libraries
and headers and is written in a language you don't happen to have a
compiler for?

If you could elaborate a bit on your reasons for thinking that
Objective-C itself is a problem without resorting to FUD words like
"obscure" and "virtually unknown", I would very much like to know what
they are.

I would also like to point out that your use of "the world of UNIX" is
extremely non-standard. Mac OS X is the most widely used UNIX* out there,
and it wouldn't surprise me in the least if it had more than 50% of the
UNIX market. I would therefore argue that Objective-C is in fact extremely
*well* known in the UNIX world, due to the massive dominance of the Mac in
this world. Given all this, I assume you meant to say the non-Mac UNIX
world.

* Note that I am deliberately excluding Linux from the term "UNIX" because
it is really just a very well done UNIX lookalike, but including it
wouldn't change the fact that Mac OS X has a very strong position in the
UNIX world and so anything that's commonly used on the Mac can't be
"virtually unknown" in this world.

--
Michael Ash
Rogue Amoeba Software
 >> Stay informed about: Cross-Platform Windows plus Mac 

On Mon, 22 Oct 2007 17:25:53 -0500, Michael Ash wrote:
> In comp.sys.mac.programmer.help Paul Floyd wrote:
>> On Mon, 22 Oct 2007 06:52:59 -0500, Doc O'Leary
>> wrote:
>>> In article ,
>>> "Armel Asselin" wrote:
>>>
>>>> we gone the 3. way with wxWidgets (www.wxwidgets.org) which is free, this is
>>>> definitely a correct way.
>>>
>>> For a very loose definition of "correct". I haven't seen a single
>>> wxWidget-based app that works the way a Mac user expects. Please point
>>> me to yours by name, or any such app based on a portable library that
>>> doesn't quite simply blow.
>>
>> IMO Qt meets your requirements.
>
> Would you happen to know of any downloadable Qt apps which look and behave
> like native Mac apps? I would love to see one. I think it would be great
> if there were a viable cross-platform application framework, but so far
> every single application I've seen which was written in one completely
> failed to look or act the way I expected. If there are proper apps written
> in Qt then perhaps my assessment is wrong.

I'm perfectly happy with Google Earth and Opera, which to my knowledge
ae both Qt based apps.

>> It also has the huge advantage of not
>> being written in an obscure dialect of C that is virtually unknown in
>> the worlds of Windows and Unix.
>
> I never understood this argument. Objective-C takes virtually no time to
> learn when compared against the time it takes to learn an application
> framework. The fact that it's not the same language as the rest of your
> code should be irrelevant; your platform-specific code isn't going to
> compile on other platforms *anyway*, so what's the big deal if it's
> failing to compile because it's missing a bunch of libraries and headers,
> or if it's failing to compile because it's missing a bunch of libraries
> and headers and is written in a language you don't happen to have a
> compiler for?

Porting issues between SUSv3 platforms aren't too serious. Windows poses
a lot more problems. However, Qt increasingly covers many non-GUI
aspects as well. I've been programming C since the late eighties and C++
since the early nineties, and I still consider that I have much to
learn. Is Objective-C really that trivial?

> If you could elaborate a bit on your reasons for thinking that
> Objective-C itself is a problem without resorting to FUD words like
> "obscure" and "virtually unknown", I would very much like to know what
> they are.

Well, in my career I've never met anyone that used Objective-C. This may
be due to the fact that I've always turned in engineering/telecomms
circles, which are dominated by C, C++ and Java running on Linux,
Solaris, Windows (and in the past, HP-UX, AIX, Irix and Tru64/DEC
unices). The simple lack of market present is already a pretty much
insurmountable barier to the Mac entering the EDA market. Any
expectation for code to be ported to Objective-C would be pure fantasy.
The simple lack of market present is already a pretty much
insurmountable barier to the Mac entering the EDA market. Any
expectation for code to be ported to Objective-C would be pure fantasy.

Outside of these circles, searching for "C++" on www.jobserve.com gives
me 3430 hits. Objective-C? 1. That's right, one hit. And the title for
the job offer? "C++ Mac Developer - Belgium - Cocoa Xcode OSX". (For
real job prospects, Java rules with 5968 hits).

Are you going to persist in arguing that Objective-C is not obscure and
virtually unknown?

> I would also like to point out that your use of "the world of UNIX" is
> extremely non-standard. Mac OS X is the most widely used UNIX* out there,
> and it wouldn't surprise me in the least if it had more than 50% of the
> UNIX market. I would therefore argue that Objective-C is in fact extremely
> *well* known in the UNIX world, due to the massive dominance of the Mac in
> this world. Given all this, I assume you meant to say the non-Mac UNIX
> world.

From a Qt standpoint, the three groups of supported platforms are
'win32', 'unix' and 'macx'. I'm aware of Mac OS X's unix
underpinnings (I've dabbled with FreeBSD since version 2.10).

A bientot
Paul
 >> Stay informed about: Cross-Platform Windows plus Mac 

In article ,
Paul Floyd wrote:

> I'm perfectly happy with Google Earth and Opera, which to my knowledge
> ae both Qt based apps.

I don't use Opera, but I can definitely say Google Earth is a train
wreck of an app, Mac-wise. Most glaring to me are the fake utility
window for things like the ruler and the search text fields don't tie in
to system features at all (e.g., no services). It is very much in the
"uncanny valley" of ported apps.

To be fair, though, there are plenty of Carbon ports that don't fit very
well with Mac OS X either, including the one I'm using right now
(MT-NewsWatcher). I think Apple bears a fair amount of the blame for
this, too. They've had years to unify their development and interface
models, but they're still all over the map when it comes to publishing
or following any reasonable guidelines. It's supposed to be better with
Leopard, but my gut feeling is that it's actually going to get worse.

> Outside of these circles, searching for "C++" on www.jobserve.com gives
> me 3430 hits. Objective-C? 1. That's right, one hit. And the title for
> the job offer? "C++ Mac Developer - Belgium - Cocoa Xcode OSX". (For
> real job prospects, Java rules with 5968 hits).
>
> Are you going to persist in arguing that Objective-C is not obscure and
> virtually unknown?

I would say it is the mark of a bad OO programmer to know more about C++
than ObjC. It mirrors quite well the ignorance of the Mac hating
Windows user that assumes that because they're in the with the 95% crowd
that they're doing the "correct" thing. Getting the job done right, for
any job I've ever had that matters, is more important than popularity.

--
My personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com,
heapnode.com, localhost, ntli.net, teranews.com, vif.com, x-privat.org
 >> Stay informed about: Cross-Platform Windows plus Mac