Cross-Platform Windows plus Mac
Chris Shearer Cooper
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).
Thanks!
Chris
Reinder Verlinde
"Chris Shearer Cooper" <chri...@sc3.net> 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
Jeffrey Dutky
I think the equivalent of a system tray icon is a menubar icon. I
would think that the easiest approach for something like that would be
to build the application core functionality in portable C++ and wrap
it in an Objective-C wrapper on the Mac, and C++ or C# on Windows. All
the wrapper would be needed for would be to intereact with the part of
the OS that draws the system tray/menu bar icon. It's not clear to me
that Qt will support building a system tray/menu bar icon in a
portable way.
- Jeff Dutky
mlabs
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
Simon Slavin
message
<13gt3ni...@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.
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
Armel Asselin
"Chris Shearer Cooper" <chri...@sc3.net> a écrit dans le message de news:
13gt3ni...@corp.supernews.com...
definitely a correct way.
Armel
Doc O'Leary
"Armel Asselin" <armela...@hotmail.com> 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
Armel Asselin
"Doc O'Leary" <drolear...@4q2007.subsume.com> a écrit dans le message
de news:
droleary.usenet-25...@sn-ip.vsrv-sjc.supernews.net...
> In article <471c675c$0$25917$ba4a...@news.orange.fr>,
> "Armel Asselin" <armela...@hotmail.com> 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.
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
Gregory Weston
<droleary.usenet-25...@sn-ip.vsrv-sjc.supernews.net>,
Doc O'Leary <drolear...@4q2007.subsume.com> wrote:
> In article <471c675c$0$25917$ba4a...@news.orange.fr>,
> "Armel Asselin" <armela...@hotmail.com> 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.
Michael Ash
>
> "Doc O'Leary" <drolear...@4q2007.subsume.com> a ?crit dans le message
> de news:
> droleary.usenet-25...@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
Paul Floyd
<drolear...@4q2007.subsume.com> wrote:
> In article <471c675c$0$25917$ba4a...@news.orange.fr>,
> "Armel Asselin" <armela...@hotmail.com> 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
Gregory Weston
Paul Floyd <ro...@127.0.0.1> wrote:
> On Mon, 22 Oct 2007 06:52:59 -0500, Doc O'Leary
> <drolear...@4q2007.subsume.com> wrote:
> > In article <471c675c$0$25917$ba4a...@news.orange.fr>,
> > "Armel Asselin" <armela...@hotmail.com> 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.
Michael Ash
> On Mon, 22 Oct 2007 06:52:59 -0500, Doc O'Leary
> <drolear...@4q2007.subsume.com> wrote:
>> In article <471c675c$0$25917$ba4a...@news.orange.fr>,
>> "Armel Asselin" <armela...@hotmail.com> 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.
Paul Floyd
> In comp.sys.mac.programmer.help Paul Floyd <ro...@127.0.0.1> wrote:
>> On Mon, 22 Oct 2007 06:52:59 -0500, Doc O'Leary
>> <drolear...@4q2007.subsume.com> wrote:
>>> In article <471c675c$0$25917$ba4a...@news.orange.fr>,
>>> "Armel Asselin" <armela...@hotmail.com> 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
Doc O'Leary
Paul Floyd <ro...@127.0.0.1> 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.
Gabriele Greco
>> Are you going to persist in arguing that Objective-C is not obscure and
>> virtually unknown?
> 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.
I'm quite sure it is, but this doesn't clash with the original concept
that created this flame, that was the fact that Objective-C is obscure
and virtually unknown :)
Anyway I don't like to be forced to code in a particular language, I
think every system facility should have at least a C api (that can be
used to create bindings in almost any language, oo or procedural...).
--
Bye,
Gabry
Gregory Weston
Paul Floyd <ro...@127.0.0.1> wrote:
> On Mon, 22 Oct 2007 17:25:53 -0500, Michael Ash <mi...@mikeash.com> wrote:
> > 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?
In a word, yes. In more words: A competent C programmer should be able
to absorb Objective-C in its entirety in hours. Well under a work day.
G
Sherman Pendley
> I'm quite sure it is, but this doesn't clash with the original concept
> that created this flame, that was the fact that Objective-C is obscure
> and virtually unknown :)
>
> Anyway I don't like to be forced to code in a particular language, I
> think every system facility should have at least a C api (that can be
> used to create bindings in almost any language, oo or procedural...).
In that case, you're in luck - Objective-C has a C api that can be used
to create bindings to many other languages. :-)
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Michael Ash
> On Mon, 22 Oct 2007 17:25:53 -0500, Michael Ash <mi...@mikeash.com> wrote:
>> 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.
I haven't really used Opera very much, but a quick test reveals pretty
serious problems. Tabbing between controls basically doesn't work; it
picks a small set of controls on the web page and never moves out of them.
I can't tab into the address bar at all. If I start out in the tool bar
then I can't tab to the forward/backward buttons, despite having set my
system to allow keyboard focus on non-text controls. The toolbar also
isn't customizable, which is not good. The preferences window is modal for
absolutely no good reason that I can see. The font picker used is a total
joke, and both it and the color picker are *also* modal for no reason.
This is just what I saw in a few minutes, and is all stuff you will avoid
"for free" by using a native API.
It shocks and surprises me that you would think Google Earth would make a
good example. I use it quite a lot, and the only reason I don't throw it
away is because I can ignore its GUI most of the time by virtue of its
main task being a giant 3D view of terrain, and because nothing else can
do what it does. Even simple things like pressing control-A in a text
field don't work. GE really makes no pretense of either looking or
behaving like a native application.
>>> 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?
Yes, it is. It is literally about half a dozen keywords and a handful of
syntax additions on top of C. Your C++ experience has probably colored
your thinking in this regard. C++ is a language you can work with
constantly for a decade and still find strange new corners. Objective-C is
not that kind of language. It is C, plus a small set of extensions that
you can literally learn in a day. If you know C already, then the
difficult part in becoming a Cocoa programmer is not Objective-C, it is
Cocoa.
To see what I mean, check out Apple's The Objective-C Programming
Language:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html
The concepts are described in "Object-Oriented Programming", and the
syntax is described in "The Language". Everything in "The Runtime System"
except for "Type Encodings" is actually Cocoa, not Objective-C.
Perhaps now you can see why I think that Objective-C is not a real
obstacle. If Objective-C were dominant and everybody had to learn C++ in
order to program for some obscure platform, I could definitely see it. But
the reality is the opposite, and ObjC is really pretty 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.
Unfortunately I have no idea what EDA refers to, but I can't understand
why you think that your personal experiences in a single market would have
a bearing as to whether this language is known in general. I also can't
understand why you use the phrasing "ported to Objective-C", because
nobody in their right mind would do such a thing: you write your GUI in
Objective-C, and you keep your cross-platform code in C or C++ where it
belongs.
> 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?
Yes I am. If you can use personal anecdotes then so can I. I'm a Mac
programmer. I do Cocoa and Objective-C. All of the programmers I know
are also Mac programmers, either professionally or as a hobby, and they
all know Objective-C. Just because you don't know anyone doesn't mean it's
unknown and obscure overall, just that it's unknown and obscure in your
circles. There are tens of millions of Mac OS X machines in the world.
They all make extensive use of Objective-C. There are a lot of programmers
making software for those machines. Are you going to persist in saying
that objective-C is obscure and virtually unknown?
Sure, it's not as popular or well known as C, C++, or Java, but that's a
ridiculously unfair test, like saying that asking for UNIX is not
justified because UNIX is not popular or well known compared to Windows.
You seem to be making the common mistake of thinking of a language as a
critical bullet point on a resume. There's no reason it has to be that
way. If you need somebody to do Objective-C, find someone who's good with
C and who knows an OO language (something with duck typing preferred, Java
will do, and C++ could be sufficient if you absolutely can't find anything
else) and have him learn the language. It simply will not take long enough
to justify requiring him to have already learned it elsewhere. If *you*
need to do Objective-C, start learning. It won't take you long. Your
investment in time will be repaid rapidly. And sure, knowing that language
may not help you get a job directly, but who cares? That's not how *I*
decide whether or not to learn something.
>> 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).
I really couldn't care less about what Qt thinks about the issue.
Obviously for GUI frameworks, the Mac is going to have to be in a separate
category due to the fact that it doesn't use X11 natively. But that
doesn't mean that it makes sense to talk about a "world of UNIX" and not
include the Mac in that world.
Overall, you seem to have some common misconceptions about Objective-C and
Cocoa. You seem to think that ObjC is a vast, complicated, C++-like
language, which simply isn't the case; you can learn enough to get started
in hours. You seem to think that ObjC is an all-or-nothing prospect,
requiring you to "port" code to it, when the reality is that ObjC will
talk to C with no problems, and ObjC++ lets you interface directly with
C++ code.
Sure, no matter how great Objective-C and Cocoa are, it's still going to
be harder to write a native GUI than it will be to rely on something like
Qt. It's also going to be harder to translate your app into Chinese than
it will be to just leave it in English. But if you're releasing a special
China edition and you expect it to actually have any success, you're going
to have to get it translated. Likewise, if you're going to make a Mac
version of your software, it will pay to get it translated into the native
tongue.
Tom Harrington
Paul Floyd <ro...@127.0.0.1> wrote:
> On Mon, 22 Oct 2007 17:25:53 -0500, Michael Ash <mi...@mikeash.com> wrote:
> > In comp.sys.mac.programmer.help Paul Floyd <ro...@127.0.0.1> wrote:
> >> On Mon, 22 Oct 2007 06:52:59 -0500, Doc O'Leary
> >> <drolear...@4q2007.subsume.com> wrote:
> >>> In article <471c675c$0$25917$ba4a...@news.orange.fr>,
> >>> "Armel Asselin" <armela...@hotmail.com> 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.
For what it's worth, Google Earth is a prime example of Gregory Weston's
comment about spotting Qt apps a mile away. It's functional, but it
just reeks of a development team putting cross-platform convenience
ahead of native look and feel. I don't use Opera so I can't comment on
that.
--
Tom "Tom" Harrington
Independent Mac OS X developer since 2002
http://www.atomicbird.com/
Steven Fisher
Michael Ash <mi...@mikeash.com> wrote:
> 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.
Qt3 apps look horrible, and it's probably largely these you've seen. Qt4
apps look pretty decent. The behavior is largely up to you, though. My
product isn't shipping yet for Mac, but as a Mac developer (currently
being held captive in a "Windows first" workplace), I've been able to
achieve most of what I wanted.
The places Qt4 falls down are Mac only widgets rounded edit fields (i.e.
the search type) and progress animations (the "spinning arrows"). I've
seen solutions to the rounded edit fields, but they were inelegant for
developer and user alike.
It also doesn't support spell checking in edit fields yet, but I've seen
some evidence that may be coming soon.
At this point, I think I would use Qt4 to target a single platform.
Project management alone is worth it: you maintain a simple text file
(think Makefile, although it's much simpler) with a text editor instead
of an XML file that's manipulated with Xcode.
> 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.
For me, it's that even now as is poor integration with C++. If I want to
cross platform business logic, it's going to be in C++. We're almost in
2008, and exceptions can't be passed easily from C++ to the Objective C
UI code. That's a very big deal to me.
Michael Ash
> In article <11930919...@nfs-db1.segnet.com>,
> Michael Ash <mi...@mikeash.com> wrote:
>
>> 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.
>
> Qt3 apps look horrible, and it's probably largely these you've seen. Qt4
> apps look pretty decent. The behavior is largely up to you, though. My
> product isn't shipping yet for Mac, but as a Mac developer (currently
> being held captive in a "Windows first" workplace), I've been able to
> achieve most of what I wanted.
I have no doubt that a sufficiently comprehensive cross-platform framework
would allow a developer to implement Mac-like behavior, and that there are
such frameworks out there. The real question is how feasible it is. Every
time I put out such a request, the responses are terrible in many ways.
I'm forced to conclude that either everyone who uses these frameworks just
doesn't care enough to put in the requried effort, or that the amount of
effort required to add all the expected Mac behavior is just too large. I
think it's the latter, because the number of complex behaviors that Cocoa
(and to a somewhat lesser extent Carbon) provides is enormous, and I'd
hate to think of having to do all that on my own. And the stuff that you
don't get for free is often at odds with how other platforms work; for
example, the Mac preference for sheets over modal dialogs whenever
possible has large consequences for code flow.
> The places Qt4 falls down are Mac only widgets rounded edit fields (i.e.
> the search type) and progress animations (the "spinning arrows"). I've
> seen solutions to the rounded edit fields, but they were inelegant for
> developer and user alike.
I personally don't care very much if your app is using square text fields
instead of rounded ones. Visual defects don't bother me *that* much unless
it looks like the entire app has just come out of the Ugly factory like
Google Earth does. What bothers me about text fields is stuff like missing
support for standard keybindings, odd selection and dragging behavior,
weird context menu items, and other such things. Behavior counts for much
more than appearance.
> It also doesn't support spell checking in edit fields yet, but I've seen
> some evidence that may be coming soon.
>
> At this point, I think I would use Qt4 to target a single platform.
> Project management alone is worth it: you maintain a simple text file
> (think Makefile, although it's much simpler) with a text editor instead
> of an XML file that's manipulated with Xcode.
A minor nitpick: Xcode project files aren't XML, they're old-style
OpenStep property lists. Doesn't make it any easier to edit with a text
editor though.
How tightly are the Qt build tools tied to Qt? Seems like you ought to be
able to use them to build native apps too, if you like them that much.
>> 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.
>
> For me, it's that even now as is poor integration with C++. If I want to
> cross platform business logic, it's going to be in C++. We're almost in
> 2008, and exceptions can't be passed easily from C++ to the Objective C
> UI code. That's a very big deal to me.
You use Objective-C++ for the code that has to call into C++, and you wrap
the C++ calls with exception handlers, just like you would do if the GUI
code were C++. Seems no harder than it would be in something like Qt. Am I
wrong?
Paul Floyd
>
> In a word, yes. In more words: A competent C programmer should be able
> to absorb Objective-C in its entirety in hours. Well under a work day.
I find that hard to accept. The ANSI C standard (C99) runs to about 725
pages (Rationale + Standard). Sure, in a day you can learn to use basic
control statements and i/o. There's a long way to go from that to
writing a major application which uses signal handling, for instance.
A bientot
Paul
Paul Floyd
On Tue, 23 Oct 2007 21:40:56 -0500, Michael Ash <mi...@mikeash.com> wrote:
> In comp.sys.mac.programmer.help Steven Fisher <st...@pyile.com> wrote:
>> In article <11930919...@nfs-db1.segnet.com>,
>> Michael Ash <mi...@mikeash.com> wrote:
[snip]
>> It also doesn't support spell checking in edit fields yet, but I've seen
>> some evidence that may be coming soon.
>>
>> At this point, I think I would use Qt4 to target a single platform.
>> Project management alone is worth it: you maintain a simple text file
>> (think Makefile, although it's much simpler) with a text editor instead
>> of an XML file that's manipulated with Xcode.
>
> A minor nitpick: Xcode project files aren't XML, they're old-style
> OpenStep property lists. Doesn't make it any easier to edit with a text
> editor though.
>
> How tightly are the Qt build tools tied to Qt? Seems like you ought to be
> able to use them to build native apps too, if you like them that much.
The 3 main build tools are qmake, uic and moc. qmake is a Makefile
generator that understands uic and moc requirements. It is not strictly
necessary, as other build systems support Qt (notably cmake and bjam).
uic is the user interface compiler. It takes XML .ui files built with
Designer (Qt's equivalent of Interface Builder) and generates C++ code.
moc is the meta object compiler. Basically this parses your C++ class
defintions looking for a few special macros, and generates C++ code for
type information and message passing.
>> For me, it's that even now as is poor integration with C++. If I want to
>> cross platform business logic, it's going to be in C++. We're almost in
>> 2008, and exceptions can't be passed easily from C++ to the Objective C
>> UI code. That's a very big deal to me.
>
> You use Objective-C++ for the code that has to call into C++, and you wrap
> the C++ calls with exception handlers, just like you would do if the GUI
> code were C++. Seems no harder than it would be in something like Qt. Am I
> wrong?
No, I would imagine the Qt bindings are possible. PyQt has existed for a
while, Python bindings to Qt (I've never used it though).
A bientot
Paul
Tom Harrington
Paul Floyd <ro...@127.0.0.1> wrote:
What does that have to do with an already-competent C programmer wanting
to learn Objective C? It's not like they have to learn C all over.
Paul Floyd
> In comp.sys.mac.programmer.help Paul Floyd <ro...@127.0.0.1> wrote:
>> On Mon, 22 Oct 2007 17:25:53 -0500, Michael Ash <mi...@mikeash.com> wrote:
>>> 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.
>
> I haven't really used Opera very much, but a quick test reveals pretty
> serious problems. Tabbing between controls basically doesn't work; it
> picks a small set of controls on the web page and never moves out of them.
> I can't tab into the address bar at all. If I start out in the tool bar
> then I can't tab to the forward/backward buttons, despite having set my
> system to allow keyboard focus on non-text controls. The toolbar also
> isn't customizable, which is not good. The preferences window is modal for
> absolutely no good reason that I can see. The font picker used is a total
> joke, and both it and the color picker are *also* modal for no reason.
> This is just what I saw in a few minutes, and is all stuff you will avoid
> "for free" by using a native API.
I've never been bothered by any of the widgets or shortcuts used by
Opera. In what way is the font picker inferior to, say, Mac OS X's font
picker? It seems quite functional to me. There are very many keyboard
shortcuts, most of which I've never used. Perhaps amongst them all there
is one that does what you want. If you really want to find out, ask in
the Opera fora on their web site. I'm pretty certain that the toolbar is
customizable. It may not be easy (not entirely a bad thing, on a few
apps that I've used I've accidentally deleted toolbar actions, and then
spent a good while figuring out how to get them back). Right click on
the toolbar, and select Customize..., select the Buttons tab and you can
drag icons to tbe toolbar.
In a web browser, the things that count for me are
1. Is it stable (unlike Mosaic and Netscape 4.x).
2. Does it render pages correctly (a bit of an issue with Opera, with
web pages that only work with MS Explorer or the Mozilla family).
3. Performance (less of an issue these days as CPU/RAM capabilities
march on).
4. Cross platform. For this point, Mozilla is tops, Opera is quite good,
and everything else is just miserable.
5. Features like popup and ad blocking. Here Safari falls down badly,
and requires plugins or the like (Mozilla also requires a plugin for
flash blocking, never tried it with Opera).
> It shocks and surprises me that you would think Google Earth would make a
> good example. I use it quite a lot, and the only reason I don't throw it
> away is because I can ignore its GUI most of the time by virtue of its
> main task being a giant 3D view of terrain, and because nothing else can
> do what it does. Even simple things like pressing control-A in a text
> field don't work. GE really makes no pretense of either looking or
> behaving like a native application.
I agree that the UI is far from fantastic, but it gets the job done. And
what alternatives are there?
> Yes, it is. It is literally about half a dozen keywords and a handful of
> syntax additions on top of C. Your C++ experience has probably colored
> your thinking in this regard. C++ is a language you can work with
> constantly for a decade and still find strange new corners. Objective-C is
So is C!
> not that kind of language. It is C, plus a small set of extensions that
> you can literally learn in a day. If you know C already, then the
> difficult part in becoming a Cocoa programmer is not Objective-C, it is
> Cocoa.
>
> To see what I mean, check out Apple's The Objective-C Programming
> Language:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html
I'll save the bookmark. In fact, I've saved the PDF. 142 pages, not bad.
> Perhaps now you can see why I think that Objective-C is not a real
> obstacle. If Objective-C were dominant and everybody had to learn C++ in
> order to program for some obscure platform, I could definitely see it. But
> the reality is the opposite, and ObjC is really pretty trivial.
I'm still reserving judgement.
>> 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?
>
> Yes I am. If you can use personal anecdotes then so can I. I'm a Mac
OK, show me a general IT job site that has over 3000:1 Objective-C:C++
job ads. Today I was browsing Dr Dobbs, and I clicked on their job site
link. C++ 600 odd, Objective-C, zero.
> Sure, it's not as popular or well known as C, C++, or Java, but that's a
> ridiculously unfair test, like saying that asking for UNIX is not
> justified because UNIX is not popular or well known compared to Windows.
jobs != number of users
Windows may have 20x the number of users of Unix, but how many Windows
users buy software licences that run to 4 digits or more (in USD or
Euros)?
> You seem to be making the common mistake of thinking of a language as a
> critical bullet point on a resume. There's no reason it has to be that
> way. If you need somebody to do Objective-C, find someone who's good with
> C and who knows an OO language (something with duck typing preferred, Java
> will do, and C++ could be sufficient if you absolutely can't find anything
> else) and have him learn the language. It simply will not take long enough
> to justify requiring him to have already learned it elsewhere. If *you*
> need to do Objective-C, start learning. It won't take you long. Your
> investment in time will be repaid rapidly. And sure, knowing that language
> may not help you get a job directly, but who cares? That's not how *I*
> decide whether or not to learn something.
Well, I still simply do not see the point. I forsee no prospects of
using Objective-C in a professional context. So that leaves dabbling at
home. And since I mainly dabble at home on Solaris and Mac OS X (plus a
small amount on FreeBSD, Linux and Windows), then it makes sense to me
to stick to C++ and Qt, which covers all those platforms.
> Overall, you seem to have some common misconceptions about Objective-C and
> Cocoa. You seem to think that ObjC is a vast, complicated, C++-like
> language, which simply isn't the case; you can learn enough to get started
> in hours. You seem to think that ObjC is an all-or-nothing prospect,
> requiring you to "port" code to it, when the reality is that ObjC will
> talk to C with no problems, and ObjC++ lets you interface directly with
> C++ code.
I'm a bit of a perfectionist when it comes to learning programming
languages (verging on being a language lawyer). The grammar may be
straightforward, but what is difficult are the idioms.
> Sure, no matter how great Objective-C and Cocoa are, it's still going to
> be harder to write a native GUI than it will be to rely on something like
> Qt. It's also going to be harder to translate your app into Chinese than
> it will be to just leave it in English. But if you're releasing a special
> China edition and you expect it to actually have any success, you're going
> to have to get it translated. Likewise, if you're going to make a Mac
> version of your software, it will pay to get it translated into the native
> tongue.
A bientot
Paul
Paul Floyd
On Wed, 24 Oct 2007 15:33:16 -0600, Tom Harrington
<t...@pcisys.no.spam.dammit.net> wrote:
> In article <slrnfhvbf...@bourbiere.local>,
> Paul Floyd <ro...@127.0.0.1> wrote:
>
>> On Tue, 23 Oct 2007 09:26:15 -0400, Gregory Weston <u...@splook.com> wrote:
>> >
>> > In a word, yes. In more words: A competent C programmer should be able
>> > to absorb Objective-C in its entirety in hours. Well under a work day.
>>
>> I find that hard to accept. The ANSI C standard (C99) runs to about 725
>> pages (Rationale + Standard). Sure, in a day you can learn to use basic
>> control statements and i/o. There's a long way to go from that to
>> writing a major application which uses signal handling, for instance.
>
> What does that have to do with an already-competent C programmer wanting
> to learn Objective C? It's not like they have to learn C all over.
I would have given an example using a something that can give rise to
complex interactions in Objective-C, but I don't know enough of it to do
so. So I used C for the example.
A bientot
Paul
Michael Ash
That's a ridiculous thing to do. Not all languages are created equal. C is
the better part of a kilopage just to describe how it's supposed to work.
Objective-C, when counting only what it adds on top of C, could probably
be described in about ten pages. Most of Apple's document on the language
is actually tutorial, idiom, and library.
I'll say it again, even though you don't seem to want to believe it:
Objective-C is simple, small, and can be learned in extremely rapid
fashion. What's difficult is learning the library, Cocoa; that will take
months. But then learning any GUI library will take months, so that's
irrelevant. The question is whether having to learn a new language on top
of that adds significant difficulty. As someone who has learned that new
language, the answer is no. You seem to think the answer is yes because
you seem to think that the language's complexity is on par with C or C++,
and it's just not true.
Michael Ash
>> I haven't really used Opera very much, but a quick test reveals pretty
>> serious problems. Tabbing between controls basically doesn't work; it
>> picks a small set of controls on the web page and never moves out of them.
>> I can't tab into the address bar at all. If I start out in the tool bar
>> then I can't tab to the forward/backward buttons, despite having set my
>> system to allow keyboard focus on non-text controls. The toolbar also
>> isn't customizable, which is not good. The preferences window is modal for
>> absolutely no good reason that I can see. The font picker used is a total
>> joke, and both it and the color picker are *also* modal for no reason.
>> This is just what I saw in a few minutes, and is all stuff you will avoid
>> "for free" by using a native API.
>
> I've never been bothered by any of the widgets or shortcuts used by
> Opera. In what way is the font picker inferior to, say, Mac OS X's font
> picker?
- It's modal.
- It has no search box.
- It has no concept of collections, so I can't limit it to, say, Fixed
Width fonts. This is kind of important when choosing the "Monospace font".
- It does not display several of my Japanese fonts, for reasons I do not
understand.
- The Help button opens help in a new web page, behind the font chooser.
Since the font chooser and the preferences panel which spawned it are both
modal, hilarity ensues.
- Its modality is not strongly enforced. If you switch to another
application, then switch back by clicking on the Preferences window, the
prefs window activates and the font panel deactivates. Since the prefs
window is modal, I can't get the font chooser back. Well, unless I switch
apps and then click it again. If I take the obvious course of action of
clicking the font chooser button again, I get a *new* font chooser! This
entire sequence of events is utterly ridiculous and would be avoided by
using the standard Mac OS X font chooser and the standard idiom of a
modeless preferences window.
- The name of the Wingdings font is displayed in Wingdings, so I can't
read it. But the sample is normal alphabetic lettering. WTF?
This is just stuff I found in a few minutes. You can hopefully see why I'm
not eager to use it for any longer than that.
> It seems quite functional to me. There are very many keyboard
> shortcuts, most of which I've never used. Perhaps amongst them all there
> is one that does what you want. If you really want to find out, ask in
> the Opera fora on their web site.
I don't want Opera-specific keyboard shortcuts, I want the same keyboard
shortcuts I use everywhere else to work in Opera too.
> I'm pretty certain that the toolbar is
> customizable. It may not be easy (not entirely a bad thing, on a few
> apps that I've used I've accidentally deleted toolbar actions, and then
> spent a good while figuring out how to get them back). Right click on
> the toolbar, and select Customize..., select the Buttons tab and you can
> drag icons to tbe toolbar.
Normal Mac app:
- Cmd-opt-click button on right side of window title bar.
- Drag toolbar buttons to and from the sheet that appears.
- Click OK.
Opera:
- How the hell do you customize the toolbar?
- There's no button, so I guess it can't be done.
- Find out the special only-works-in-Opera way from an existing user.
- Right-click!
- Weird utility window appears with a bunch of checkboxes to control
things I don't care about.
- Find the button tabs. Try to drag a button onto the toolbar, fail.
- Oh wait, it's not failing, it's just not giving any *obvious* indication
that I'm actually dragging something.
- Accidentally add a button I don't want to the toolbar because of this
feedback defect.
- Attempt to delete new button by dragging it off the toolbar. Fail.
- Attempt to delete new button by dragging it back to the buttons tab.
Fail.
- Attempt to delete new button by dragging it to the trash. Fail.
- Realize that the fight is futile, reset the toolbar to its defaults, and
quit the app.
Normally I would give up much earlier than this, but you asked....
> In a web browser, the things that count for me are
The question was not, "Is Qt adequate for building a good web browser?"
The question was, "Is Qt adequate for building an application that looks
and behaves like a real Mac app?" The answer as given by Opera is a
resounding "No!"
>> It shocks and surprises me that you would think Google Earth would make a
>> good example. I use it quite a lot, and the only reason I don't throw it
>> away is because I can ignore its GUI most of the time by virtue of its
>> main task being a giant 3D view of terrain, and because nothing else can
>> do what it does. Even simple things like pressing control-A in a text
>> field don't work. GE really makes no pretense of either looking or
>> behaving like a native application.
>
> I agree that the UI is far from fantastic, but it gets the job done. And
> what alternatives are there?
Once again, discussion of alternatives is irrelevant to the question at
hand, which is whether Qt can be used to make an app that works like a Mac
app.
>> Yes, it is. It is literally about half a dozen keywords and a handful of
>> syntax additions on top of C. Your C++ experience has probably colored
>> your thinking in this regard. C++ is a language you can work with
>> constantly for a decade and still find strange new corners. Objective-C is
>
> So is C!
In my personal experience, the strange new corners in C stop after about
half a decade of intensive use. Maybe I learn faster, or I'm better at
avoiding new corners. In any case, C hasn't surprised me in quite a while.
When I get bored and read comp.lang.c, there is always new stuff I hadn't
seen there, but it's all language lawyering that doesn't affect how I
actually use it.
C++, on the other hand, looks like the kind of language you can use
intensively forever and still have lots of new, important things to learn.
(I do not consider this to be a good thing in any way, in case it wasn't
obvious.) I haven't done this myself but I get that distinct impression
from talking to people who have.
>> Perhaps now you can see why I think that Objective-C is not a real
>> obstacle. If Objective-C were dominant and everybody had to learn C++ in
>> order to program for some obscure platform, I could definitely see it. But
>> the reality is the opposite, and ObjC is really pretty trivial.
>
> I'm still reserving judgement.
That's fine, I just want you to keep an open mind about it instead of
assuming that Objective-C is an uglier, less popular clone of C++ like so
many people do.
>>> Are you going to persist in arguing that Objective-C is not obscure and
>>> virtually unknown?
>>
>> Yes I am. If you can use personal anecdotes then so can I. I'm a Mac
>
> OK, show me a general IT job site that has over 3000:1 Objective-C:C++
> job ads. Today I was browsing Dr Dobbs, and I clicked on their job site
> link. C++ 600 odd, Objective-C, zero.
Why do I have to show you a general IT job site with a particular ratio to
prove that Objective-C is not obscure and virtually unknown?
Sure, it's not a hugely popular language. I never said that it was.
However the simple fact that there are thousands of people making a living
from it all over the world, and that it is the primary development
language on tens of millions of computers, should be more than enough.
>> Sure, it's not as popular or well known as C, C++, or Java, but that's a
>> ridiculously unfair test, like saying that asking for UNIX is not
>> justified because UNIX is not popular or well known compared to Windows.
>
> jobs != number of users
>
> Windows may have 20x the number of users of Unix, but how many Windows
> users buy software licences that run to 4 digits or more (in USD or
> Euros)?
So what? You seem to like drifting topics. The question at hand is not how
many Objective-C jobs are available on job sites. The question is whether
the language is "virtually unknown". The number of jobs you can find on
traditionally C++ and Java job sites is irrelevant to the question.
> Well, I still simply do not see the point. I forsee no prospects of
> using Objective-C in a professional context. So that leaves dabbling at
> home. And since I mainly dabble at home on Solaris and Mac OS X (plus a
> small amount on FreeBSD, Linux and Windows), then it makes sense to me
> to stick to C++ and Qt, which covers all those platforms.
I and thousands of other people make a living using Objective-C in a
professional context. Maybe there is no future in it for you. This does
not mean that there is no future in it for anybody, or that the language
is obscure.
>> Overall, you seem to have some common misconceptions about Objective-C and
>> Cocoa. You seem to think that ObjC is a vast, complicated, C++-like
>> language, which simply isn't the case; you can learn enough to get started
>> in hours. You seem to think that ObjC is an all-or-nothing prospect,
>> requiring you to "port" code to it, when the reality is that ObjC will
>> talk to C with no problems, and ObjC++ lets you interface directly with
>> C++ code.
>
> I'm a bit of a perfectionist when it comes to learning programming
> languages (verging on being a language lawyer). The grammar may be
> straightforward, but what is difficult are the idioms.
Sure, but in this case basically all the idioms come from the library,
which I never said would take a day to learn. Objective-C does not really
have any idioms itself (I've worked with more than one Objective-C
application framework and I can tell you that they had little in common in
this respect), but it gives you the tools you need to build them.
Michael Ash
>>> cross platform business logic, it's going to be in C++. We're almost in
>>> 2008, and exceptions can't be passed easily from C++ to the Objective C
>>> UI code. That's a very big deal to me.
>>
>> You use Objective-C++ for the code that has to call into C++, and you wrap
>> the C++ calls with exception handlers, just like you would do if the GUI
>> code were C++. Seems no harder than it would be in something like Qt. Am I
>> wrong?
>
> No, I would imagine the Qt bindings are possible. PyQt has existed for a
> while, Python bindings to Qt (I've never used it though).
Huh? Seriously, I have no idea what this means or why you said this. You
asserted that exceptions can't be easily passed from C++ model code to
Objective-C GUI code. I stated that it seemed easy enough to me. You
countered by stating... something totally irrelevant about Qt bindings.
Did I totally miss something, or did you quote my text and then say
something completely unrelated?
Paul Floyd
The previous poster was complaining about C++ integration. I pointed out
that C++ Qt can be wrapped for Python. So I assume that it can also be
wrapped for Objective-C(++). It probably helps that Qt itself makes no
use of exceptions. So mixing Objective-C and Qt should be feasible, in
theory.
A bientot
Paul
Paul Floyd
[font dialog]
> - It's modal.
> - It has no search box.
> - It has no concept of collections, so I can't limit it to, say, Fixed
> Width fonts. This is kind of important when choosing the "Monospace font".
> - It does not display several of my Japanese fonts, for reasons I do not
> understand.
> - The Help button opens help in a new web page, behind the font chooser.
> Since the font chooser and the preferences panel which spawned it are both
> modal, hilarity ensues.
Yes, this is a bit of a clanger.
> - Its modality is not strongly enforced. If you switch to another
> application, then switch back by clicking on the Preferences window, the
> prefs window activates and the font panel deactivates. Since the prefs
> window is modal, I can't get the font chooser back. Well, unless I switch
> apps and then click it again. If I take the obvious course of action of
> clicking the font chooser button again, I get a *new* font chooser! This
> entire sequence of events is utterly ridiculous and would be avoided by
> using the standard Mac OS X font chooser and the standard idiom of a
> modeless preferences window.
> - The name of the Wingdings font is displayed in Wingdings, so I can't
> read it. But the sample is normal alphabetic lettering. WTF?
Curiously, Opera's font dialog is not the same as the QFontDialog in
either Qt 3 or 4 (at least, not in the online docs). Perhaps they rolled
their own? I'll try to see
> This is just stuff I found in a few minutes. You can hopefully see why I'm
> not eager to use it for any longer than that.
Still, I don't think that I'd ever refuse to use an app based on its
font dialog.
Which browser do you use on Mac OS X?
>> It seems quite functional to me. There are very many keyboard
>> shortcuts, most of which I've never used. Perhaps amongst them all there
>> is one that does what you want. If you really want to find out, ask in
>> the Opera fora on their web site.
>
> I don't want Opera-specific keyboard shortcuts, I want the same keyboard
> shortcuts I use everywhere else to work in Opera too.
It seems to have both its own and some Mac specfic ones. I'm not sure
what they do when there is a conflict between an Opera shortcut and a
Mac one.
[toolbar]
Well it seemed reasonably intuitive to me, and easy enough to perform
for a task that on average I perform perhaps once every few years.
> The question was not, "Is Qt adequate for building a good web browser?"
> The question was, "Is Qt adequate for building an application that looks
> and behaves like a real Mac app?" The answer as given by Opera is a
> resounding "No!"
...
> Once again, discussion of alternatives is irrelevant to the question at
> hand, which is whether Qt can be used to make an app that works like a Mac
> app.
For me this is an issue. Cross platform availability counts for more
than UI rule conformance.
>>> Yes, it is. It is literally about half a dozen keywords and a handful of
>>> syntax additions on top of C. Your C++ experience has probably colored
>>> your thinking in this regard. C++ is a language you can work with
>>> constantly for a decade and still find strange new corners. Objective-C is
>>
>> So is C!
>
> In my personal experience, the strange new corners in C stop after about
> half a decade of intensive use. Maybe I learn faster, or I'm better at
> avoiding new corners. In any case, C hasn't surprised me in quite a while.
> When I get bored and read comp.lang.c, there is always new stuff I hadn't
> seen there, but it's all language lawyering that doesn't affect how I
> actually use it.
In my experience, most C code out there is somewhere in the K&R to C90
spectrum. C99 added a lot, quite a bit of which is relevant to my work
(complex types, type generic maths).
> C++, on the other hand, looks like the kind of language you can use
> intensively forever and still have lots of new, important things to learn.
> (I do not consider this to be a good thing in any way, in case it wasn't
> obvious.) I haven't done this myself but I get that distinct impression
> from talking to people who have.
I've got mixed feelings about C++'s abilities. Sometimes it can do
interesting things which are just about impossible to comprehend under
the hood, and may have terrible run time and portability problems.
>> OK, show me a general IT job site that has over 3000:1 Objective-C:C++
>> job ads. Today I was browsing Dr Dobbs, and I clicked on their job site
>> link. C++ 600 odd, Objective-C, zero.
>
> Why do I have to show you a general IT job site with a particular ratio to
> prove that Objective-C is not obscure and virtually unknown?
OK, show me a metric that shows Objective-C in a non-obscure light. I'll
add another: usenet traffic.
comp.lang.c++ 4000-8000 posts a month
comp.lang.c++.moderated 500-3000 posts a month
comp.lang.objective-c 15-900 posts a month
[snip]
> I and thousands of other people make a living using Objective-C in a
> professional context. Maybe there is no future in it for you. This does
> not mean that there is no future in it for anybody, or that the language
> is obscure.
For the present, I count thousands of users and mono-platform obscure.
I'd say that the future of Objective-C depends on a) continued success
of Mac OS X and b) continued support from Apple.
A bientot
Paul
Doc O'Leary
Paul Floyd <ro...@127.0.0.1> wrote:
> Still, I don't think that I'd ever refuse to use an app based on its
> font dialog.
I think you're being disingenuous here. I don't see anybody saying
they'll flat out refuse to use a crappy port, especially if it only came
down to a single quirk like the font dialog. We are, however, calling a
spade a spade by pointing out exactly where the ports fall short
compared to a properly developed Mac OS X app. Unless you're actually
going to address that point, at least stop pretending you're interested
in doing Mac development at all.
> OK, show me a metric that shows Objective-C in a non-obscure light. I'll
> add another: usenet traffic.
>
> comp.lang.c++ 4000-8000 posts a month
> comp.lang.c++.moderated 500-3000 posts a month
> comp.lang.objective-c 15-900 posts a month
Very amusing. The OO extensions that ObjC layers on C are *trivial* to
understand compared to C++. The lack of newsgroup traffic points more
to that than any count of knowledgeable programmers. What's next,
pointing out how thin the Cox book is compared to Stroustrup's?
> I'd say that the future of Objective-C depends on a) continued success
> of Mac OS X and b) continued support from Apple.
I'd say you're wrong. ObjC built a devoted following long before Apple
was in the picture. As long as the "popular" alternatives are
technically wanting, an OO language like ObjC has a far better future
than the likes of C++.
Michael Ash
>> This is just stuff I found in a few minutes. You can hopefully see why I'm
>> not eager to use it for any longer than that.
>
> Still, I don't think that I'd ever refuse to use an app based on its
> font dialog.
As pointed out, I'm not saying why I wouldn't use it, but why it's not
Mac-like.
> Which browser do you use on Mac OS X?
I use Safari. Oddly enough Safari has similar issues with its toolbar. The
major difference here is that Opera would have to work to *get* the
standard OS X toolbar customization, but Safari has to work to *avoid* it.
I have no idea why Apple avoids it though.
> Well it seemed reasonably intuitive to me, and easy enough to perform
> for a task that on average I perform perhaps once every few years.
I notice that you didn't tell me how to remove an item. This still
mystifies me. How do you do it?
You're right that this isn't a big deal by itself. However, it still
illustrates my general point, that this application is not truly Mac-like.
Also, in my experience, an application which has problems in an area like
this will also have problems in areas which I touch more frequently. For
example, tabbing between controls is utterly broken, and I do that all the
time.
>> Once again, discussion of alternatives is irrelevant to the question at
>> hand, which is whether Qt can be used to make an app that works like a Mac
>> app.
>
> For me this is an issue. Cross platform availability counts for more
> than UI rule conformance.
As a user? You seemed to indicate that before as well. I simply can't
understand why this would matter. I occasionally use Windows, and I really
don't care about using Safari there. There's no compelling reason for me
to use the same browser on all platforms.
For the developer, this can be very important, but IMO it should be more
important to produce a good application.
>> In my personal experience, the strange new corners in C stop after about
>> half a decade of intensive use. Maybe I learn faster, or I'm better at
>> avoiding new corners. In any case, C hasn't surprised me in quite a while.
>> When I get bored and read comp.lang.c, there is always new stuff I hadn't
>> seen there, but it's all language lawyering that doesn't affect how I
>> actually use it.
>
> In my experience, most C code out there is somewhere in the K&R to C90
> spectrum. C99 added a lot, quite a bit of which is relevant to my work
> (complex types, type generic maths).
I find it extremely od that you say "added a lot" and then reference only
two extremely simple features:
- #include <complex.h> and you can use "complex" as a modifier for your
primitive number types, such as double complex x;. Complex number
constants can be written like 1 + 2*I. The pieces can be extracted using
the creal() and cimag() and variants. Various standard math functions are
provided in complex.h
- #include <tgmath.h> instead of <math.h> and you can use standard math
functions and the compiler will call the function with the right type
without having to use the f and l postfixes for float and long double.
>> C++, on the other hand, looks like the kind of language you can use
>> intensively forever and still have lots of new, important things to learn.
>> (I do not consider this to be a good thing in any way, in case it wasn't
>> obvious.) I haven't done this myself but I get that distinct impression
>> from talking to people who have.
>
> I've got mixed feelings about C++'s abilities. Sometimes it can do
> interesting things which are just about impossible to comprehend under
> the hood, and may have terrible run time and portability problems.
The way I see it, C++ is a pretty decent language, but with six thousand
useless and painful features added on for no good reason. C++ can be nice
if you restrict yourself to a very small subset of the full language. The
problem is that nobody else ever does this, so if you work in a team or
get code from other people, you lose.
>>> OK, show me a general IT job site that has over 3000:1 Objective-C:C++
>>> job ads. Today I was browsing Dr Dobbs, and I clicked on their job site
>>> link. C++ 600 odd, Objective-C, zero.
>>
>> Why do I have to show you a general IT job site with a particular ratio to
>> prove that Objective-C is not obscure and virtually unknown?
>
> OK, show me a metric that shows Objective-C in a non-obscure light. I'll
> add another: usenet traffic.
>
> comp.lang.c++ 4000-8000 posts a month
> comp.lang.c++.moderated 500-3000 posts a month
> comp.lang.objective-c 15-900 posts a month
C/C++ is basically the most popular and visible set of computer languages
ever created. Given how many languages are out there, I think that getting
a few percent of the traffic is pretty good. Especially when, as pointed
out in another post, Objective-C is so simple that people don't generally
*need* to talk about it.
>> I and thousands of other people make a living using Objective-C in a
>> professional context. Maybe there is no future in it for you. This does
>> not mean that there is no future in it for anybody, or that the language
>> is obscure.
>
> For the present, I count thousands of users and mono-platform obscure.
>
> I'd say that the future of Objective-C depends on a) continued success
> of Mac OS X and b) continued support from Apple.
I don't see why. The language is in gcc and has enough support outside
Apple to keep it maintained. Of course it's not going to get any
improvements without Apple but it's not going to disappear and become
useless.
Paul Floyd
> As a user? You seemed to indicate that before as well. I simply can't
> understand why this would matter. I occasionally use Windows, and I really
> don't care about using Safari there. There's no compelling reason for me
> to use the same browser on all platforms.
If your home directory is NFS mounted (a step that I haven't yet taken
at home, but may well happen) then it's nice to have all of your
settings available on all platforms.
A bientot
Paul
Ben Artin
Michael Ash <mi...@mikeash.com> wrote:
Objective-C++ is of questionable utility. At compile time, g++ 4 mode has bugs
that make some code that compiles when included from a .cpp file not compile
when included from a .mm file. At runtime, C++ exceptions and Objective-C
exception can't mix unless you require Objective-C 2.0, Leopard, and compile for
64 bits (if I recall correctly), which makes error handling in Objective-C++
tedious in the best case and extremely error prone in the worst case.
Honestly, a C++ library with a well-defined API is better off exposing that API
to Python (via boost::python). PyObjC and boost::python are much more robust
than Objective-C++ (and yes, I speak from first-hand experience).
Ben
--
If this message helped you, consider buying an item
from my wish list: <http://artins.org/ben/wishlist>
I changed my name: <http://periodic-kingdom.org/People/NameChange.php>
Paul Floyd
<drolear...@4q2007.subsume.com> wrote:
> In article <slrnfi0sl...@bourbiere.local>,
> Paul Floyd <ro...@127.0.0.1> wrote:
>
>> Still, I don't think that I'd ever refuse to use an app based on its
>> font dialog.
>
> I think you're being disingenuous here. I don't see anybody saying
> they'll flat out refuse to use a crappy port, especially if it only came
> down to a single quirk like the font dialog. We are, however, calling a
> spade a spade by pointing out exactly where the ports fall short
> compared to a properly developed Mac OS X app. Unless you're actually
I prefer function over form user. For instance, right now, I'm using vi.
vi doesn't score too highly in the 'Mac native UI' stakes.
(The Xcode editor is quite good though, and I find it very comfortable to
use.)
> going to address that point, at least stop pretending you're interested
> in doing Mac development at all.
What code I do write at home is mainly for my own use. I am interested
in Mac development, but I'll do it my way. This isn't Room 101.
A bientot
Paul
Simon Slavin
<slrnfhr8g...@bourbiere.local>:
> Is Objective-C really that trivial?
Took me 6 hours to add Objective-C to C.
Took me another 6 hours to understand Apple's frameworks (Cocoa) and how
they interact.
After about 10 years I /still/ can't write C++ code reliably. When I
write Cocoa it generally works. When I wrote C++ it generally failed in
ways that were difficult to debug.
Simon.
--
http://www.hearsay.demon.co.uk
Michael Ash
That makes sense. I don't use browsers on multiple OSes very much and even
if I did, I don't use things like bookmarks very much so it wouldn't
matter much to me personally, but I see where it would matter in certain
situations and usage patterns.
Michael Ash
According to the stereotypical C++ programmer, this is just because you're
a lazy programmer, or because Objective-C/Cocoa are busily biting you in
the ass but you're too incompetent to realize it.
I'm not accusing anyone in here of saying this, but I do occasionally run
into this attitude and it's odd to see.
Michael Ash
> In article <11931936...@nfs-db1.segnet.com>,
> Michael Ash <mi...@mikeash.com> wrote:
>
>> You use Objective-C++ for the code that has to call into C++, and you wrap
>> the C++ calls with exception handlers, just like you would do if the GUI
>> code were C++. Seems no harder than it would be in something like Qt. Am I
>> wrong?
>
> Objective-C++ is of questionable utility. At compile time, g++ 4 mode has bugs
> that make some code that compiles when included from a .cpp file not compile
> when included from a .mm file.
That's interesting. Do you have any specific examples?
> At runtime, C++ exceptions and Objective-C
> exception can't mix unless you require Objective-C 2.0, Leopard, and compile for
> 64 bits (if I recall correctly), which makes error handling in Objective-C++
> tedious in the best case and extremely error prone in the worst case.
You're correct that they are unified in the 64-bit runtime but not
otherwise. However I'm not sure how much this really matters. Exceptions
are so rarely used it Cocoa code that being unable to mix them never bit
me; most of the time, if an ObjC exception is being thrown then it's
either on your computer and should be caught by the debugger, or it's on
the user's computer and it's pretty much game over anyway.
I did work on a fairly sizable Objective-C++ project for a couple of years
and for the most part it went well, but I enforced a very strict
separation between the two with the exception of just a few places where
they met up to exchange information, and the C++ component was designed to
be portable to some very restricted platforms and so didn't use a lot of
advaced C++ features. I'm sure you have more experience with this than I
do.
Steven Fisher
Michael Ash <mi...@mikeash.com> wrote:
> I have no doubt that a sufficiently comprehensive cross-platform framework
> would allow a developer to implement Mac-like behavior, and that there are
> such frameworks out there. The real question is how feasible it is. Every
> time I put out such a request, the responses are terrible in many ways.
> I'm forced to conclude that either everyone who uses these frameworks just
> doesn't care enough to put in the requried effort, or that the amount of
> effort required to add all the expected Mac behavior is just too large.
Actually, it's a third explanation.
Most "Qt developers" are really "Windows developers." They use Qt
because it is easier to develop for than straight Win32. Further, if
they code to Qt instead of Win32, they think that one day they'll get
"completely free" porting to Mac OS X. If, you know, a Mac version is
ever worth the cross-compile it would take.
Now, they start out with a product with a fairly terrible interface.
They wouldn't be taking this "Win32 now, Mac maybe one day if it's free"
route to begin with if they had any sense of aesthetics! But what the
developer actually ends up with is having to remove a bunch of Win32
code they didn't realize they were using. And when they're done doing
that, they've spent more time than they planned and they still have
crappy product. On Windows the UI was tolerated but not loved. Now that
they're on Mac, and that horribly-behaving interface really sticks out
compared to the elegance of the other applications.
Plus the developer was just targeting Windows, so they didn't bother
setting the property that put Quit under the right menu and gave it the
right text, provided the adaptive hot keys so that the weird control key
shortcuts got mapped to the normal Mac OS X command key equivalents,
etc, etc.
> think it's the latter, because the number of complex behaviors that Cocoa
> (and to a somewhat lesser extent Carbon) provides is enormous, and I'd
> hate to think of having to do all that on my own. And the stuff that you
> don't get for free is often at odds with how other platforms work; for
> example, the Mac preference for sheets over modal dialogs whenever
> possible has large consequences for code flow.
>
> > The places Qt4 falls down are Mac only widgets rounded edit fields (i.e.
> > the search type) and progress animations (the "spinning arrows"). I've
> > seen solutions to the rounded edit fields, but they were inelegant for
> > developer and user alike.
>
> I personally don't care very much if your app is using square text fields
> instead of rounded ones.
Bad example to not care about, actually. Round text fields are for
entering search terms, so the appearance implies the behavior. Getting
this right is important.
> Visual defects don't bother me *that* much unless
> it looks like the entire app has just come out of the Ugly factory like
> Google Earth does.
I just checked: Google Earth is Qt3. According to wikipedia Qt4 was
released in 2005, if that helps you understand exactly how much
development has gone on since then.
Qt3 seems to be used more often by open source developers than Qt4,
probably because Qt3 is at the heart of the current version of KDE. Qt3
looks pretty decent there, but it looks terrible and behaves worse on
the Mac.
> What bothers me about text fields is stuff like missing support for
> standard keybindings, odd selection and dragging behavior, weird
> context menu items, and other such things. Behavior counts for much
> more than appearance.
I think this is where the scenario I outlined above comes into play.
> A minor nitpick: Xcode project files aren't XML, they're old-style
> OpenStep property lists. Doesn't make it any easier to edit with a text
> editor though.
Ah, yes, I guess it's been long enough that I've forgotten what the
inside of the pbproj looks like. :) The scarring has begun to heal!
Actually, OpenStep property lists are probably slightly worse because
there are fewer tools to operate on them.
> How tightly are the Qt build tools tied to Qt? Seems like you ought to be
> able to use them to build native apps too, if you like them that much.
Yes, I think I probably could use qmake to build Xcode project files
that didn't rely on Qt frameworks. If I'm going to code something for a
single platform I'd rather that Apple provide an alternate project type,
though. :)
> You use Objective-C++ for the code that has to call into C++, and you wrap
> the C++ calls with exception handlers, just like you would do if the GUI
> code were C++. Seems no harder than it would be in something like Qt. Am I
> wrong?
It sounds good. I'll have to check this out again. Maybe my info is
out-of-date.
Steven Fisher
Steven Fisher <st...@pyile.com> wrote:
> shortcuts got mapped to the normal Mac OS X command key equivalents,
> etc, etc.
One more comment: Reading that whole rant again, I'm sure I've nailed
it. And boy, is it depressing!
Gabriele Greco
> You're correct that they are unified in the 64-bit runtime but not
> otherwise. However I'm not sure how much this really matters. Exceptions
> are so rarely used it Cocoa code that being unable to mix them never bit
> me; most of the time, if an ObjC exception is being thrown then it's
> either on your computer and should be caught by the debugger, or it's on
> the user's computer and it's pretty much game over anyway.
You speak from the wrong point of view.
Image that you have a 1.500.000 code project and only 5% is the GUI
related code.
Your code uses exceptions, like many modern C++ projct do. Obviously
you'll need to pass exceptions to your GUI level if something is wrong.
You want to write a Mac version of your project and you really want to
make it a real mac app, but you cannot rewrote half of the project to do
so, so you'll end up using QT or wxWidgets...
This is a real world scenario.
> they met up to exchange information, and the C++ component was designed to
> be portable to some very restricted platforms and so didn't use a lot of
> advaced C++ features. I'm sure you have more experience with this than I
> do.
Actually you can write "advanced" c++ and be compatible with OSX, Win32,
Linux. Only the GUI level it's a problem and mostly on OSX cause on
win32 and linux the interfaces are so standardless that no one cares if
your application is slightly different from what they are used to :)
--
Bye,
Gabry
glenn andreas
Gabriele Greco <gabrie...@REMOVEUPPERCASETOMAILtin.it> wrote:
> Michael Ash wrote:
>
> > You're correct that they are unified in the 64-bit runtime but not
> > otherwise. However I'm not sure how much this really matters. Exceptions
> > are so rarely used it Cocoa code that being unable to mix them never bit
> > me; most of the time, if an ObjC exception is being thrown then it's
> > either on your computer and should be caught by the debugger, or it's on
> > the user's computer and it's pretty much game over anyway.
>
> You speak from the wrong point of view.
>
> Image that you have a 1.500.000 code project and only 5% is the GUI
> related code.
>
> Your code uses exceptions, like many modern C++ projct do. Obviously
> you'll need to pass exceptions to your GUI level if something is wrong.
You can't pass your exceptions through Carbon either - you need to wrap
and catch any exception so that it doesn't go through any of the
multitude of Carbon based callbacks (i.e., user clicks a button, Carbon
framework calls event handler for that, your event handler needs to call
your logic code, but must make sure no exceptions are raised that aren't
caught, because unwinding the stack through the GUI code will cause bad
things to happen).
The big restriction with Objective-C is that if you mix the two at the
logic level, you've got to be careful about exceptions - but if you
program has the logic layer entirely in C++, why would it matter what
wraps around it?
Michael Ash
> Michael Ash wrote:
>
>> You're correct that they are unified in the 64-bit runtime but not
>> otherwise. However I'm not sure how much this really matters. Exceptions
>> are so rarely used it Cocoa code that being unable to mix them never bit
>> me; most of the time, if an ObjC exception is being thrown then it's
>> either on your computer and should be caught by the debugger, or it's on
>> the user's computer and it's pretty much game over anyway.
>
> You speak from the wrong point of view.
>
> Image that you have a 1.500.000 code project and only 5% is the GUI
> related code.
>
> Your code uses exceptions, like many modern C++ projct do. Obviously
> you'll need to pass exceptions to your GUI level if something is wrong.
>
> You want to write a Mac version of your project and you really want to
> make it a real mac app, but you cannot rewrote half of the project to do
> so, so you'll end up using QT or wxWidgets...
>
> This is a real world scenario.
I have no idea why you think this is incompatible with the idea that you
lose if you throw an *Objective-C* exception. In fact it sounds like
you're in 100% violent agreement with me, all except for the part where
you say I'm wrong.
>> they met up to exchange information, and the C++ component was designed to
>> be portable to some very restricted platforms and so didn't use a lot of
>> advaced C++ features. I'm sure you have more experience with this than I
>> do.
>
> Actually you can write "advanced" c++ and be compatible with OSX, Win32,
> Linux. Only the GUI level it's a problem and mostly on OSX cause on
> win32 and linux the interfaces are so standardless that no one cares if
> your application is slightly different from what they are used to :)
Well of course. The "very restriction platforms" I'm talking about are, of
course, *not* among OS X, Win32, and Linux.
Michael Ash
> Michael Ash <mi...@mikeash.com> wrote:
>> I have no doubt that a sufficiently comprehensive cross-platform framework
>> would allow a developer to implement Mac-like behavior, and that there are
>> such frameworks out there. The real question is how feasible it is. Every
>> time I put out such a request, the responses are terrible in many ways.
>> I'm forced to conclude that either everyone who uses these frameworks just
>> doesn't care enough to put in the requried effort, or that the amount of
>> effort required to add all the expected Mac behavior is just too large.
>
> Actually, it's a third explanation.
>
> Most "Qt developers" are really "Windows developers." They use Qt
> because it is easier to develop for than straight Win32. Further, if
> they code to Qt instead of Win32, they think that one day they'll get
> "completely free" porting to Mac OS X. If, you know, a Mac version is
> ever worth the cross-compile it would take.
I'm pretty sure your explanation fits into "doesn't care enough to put in
the required effort".
>> > The places Qt4 falls down are Mac only widgets rounded edit fields (i.e.
>> > the search type) and progress animations (the "spinning arrows"). I've
>> > seen solutions to the rounded edit fields, but they were inelegant for
>> > developer and user alike.
>>
>> I personally don't care very much if your app is using square text fields
>> instead of rounded ones.
>
> Bad example to not care about, actually. Round text fields are for
> entering search terms, so the appearance implies the behavior. Getting
> this right is important.
I understand that but from a personal level there are enough other cues
that something is a search field that this particular one is not a big
deal. For general consumption, yes, it would be a very good idea to use
such things where appropriate.
>> Visual defects don't bother me *that* much unless
>> it looks like the entire app has just come out of the Ugly factory like
>> Google Earth does.
>
> I just checked: Google Earth is Qt3. According to wikipedia Qt4 was
> released in 2005, if that helps you understand exactly how much
> development has gone on since then.
Right, Qt4 is wonderful and great etc. So why can't anyone point me to a
Qt app that looks and acts like a Mac app? :)
>> A minor nitpick: Xcode project files aren't XML, they're old-style
>> OpenStep property lists. Doesn't make it any easier to edit with a text
>> editor though.
>
> Ah, yes, I guess it's been long enough that I've forgotten what the
> inside of the pbproj looks like. :) The scarring has begun to heal!
> Actually, OpenStep property lists are probably slightly worse because
> there are fewer tools to operate on them.
It's easy enough to transform them into XML plists using plutil, but this
does add an extra step. Personally I just try to stay out of there and
treat it like an opaque format.
Ben Artin
Michael Ash <mi...@mikeash.com> wrote:
> In comp.sys.mac.programmer.help Ben Artin <mac...@artins.org> wrote:
> > In article <11931936...@nfs-db1.segnet.com>, Michael Ash
> > <mi...@mikeash.com> wrote:
> >
> >> You use Objective-C++ for the code that has to call into C++, and you wrap
> >> the C++ calls with exception handlers, just like you would do if the GUI
> >> code were C++. Seems no harder than it would be in something like Qt. Am I
> >> wrong?
> >
> > Objective-C++ is of questionable utility. At compile time, g++ 4 mode has
> > bugs that make some code that compiles when included from a .cpp file not
> > compile when included from a .mm file.
>
> That's interesting. Do you have any specific examples?
I've long since stopped caring. I filed my Radar bugs, declared Obj-C++ not
worth my time, and moved on. I'm sure I could dig them up if I really cared, but
I don't.
> I did work on a fairly sizable Objective-C++ project for a couple of years
> and for the most part it went well, but I enforced a very strict separation
> between the two with the exception of just a few places where they met up to
> exchange information, and the C++ component was designed to be portable to
> some very restricted platforms and so didn't use a lot of advaced C++
> features. I'm sure you have more experience with this than I do.
If you treat C++ as better C, and ignore all the advanced... features... then
you can probably get pretty far with Objective-C++. It may very well be a useful
tool for a lot of people, I just think it bears mentioning that it's not exactly
a magic wand that you can wave over your C++ code to make a Cocoa app around it
(which is how it's often presented).
Steven Fisher
Michael Ash <mi...@mikeash.com> wrote:
> I'm pretty sure your explanation fits into "doesn't care enough to put in
> the required effort".
No, it's more like "isn't even aware they haven't put in the effort, and
wouldn't know what to actually do if they were willing to." Lack of
effort is only half the problem; the other half is lack of knowledge.
> I understand that but from a personal level there are enough other cues
> that something is a search field that this particular one is not a big
> deal. For general consumption, yes, it would be a very good idea to use
> such things where appropriate.
Granted.
> Right, Qt4 is wonderful and great etc. So why can't anyone point me to a
> Qt app that looks and acts like a Mac app? :)
Because I haven't shipped mine yet! :) The hold up hasn't been the
Qt-interface code. The hold up is the older business logic someone wrote.
And, actually, my tool probably wouldn't satisfy you. It isn't a full
document-based application, but more of a data synchronization tool. I
don't have first hand experience on how well sheets work when there's
another window the user can switch to. I'm sure you couldn't write Pages
or iPhoto in Qt, for instance.
> It's easy enough to transform them into XML plists using plutil, but this
> does add an extra step. Personally I just try to stay out of there and
> treat it like an opaque format.
Yeah. Back when I used Xcode projects as source instead of generating
them, I'd look at a diff before checking them into source control. But
it was just to see that nothing completely insane had happened.
Basically, at that point I either checked in the project or reverted it.
Chris Hanson
> Objective-C++ is of questionable utility. At compile time, g++ 4 mode has bugs
> that make some code that compiles when included from a .cpp file not compile
> when included from a .mm file.
I'm very curious about what those specific bugs are, and whether
they're addressed in the version of GCC 4.0.1 that's distributed with
Xcode 3.
Several years back -- in the GCC 3.1 days -- I did some consulting work
for a client with a huge (multi-million line) Objective-C++
application. It worked quite well for their them and they were using
modern C++ idioms at the time.
All they did was ensure that the layers were properly separated, i.e.
that they didn't pass exceptions across the Objective-C/C++ boundary.
By following that and a few other simple patterns, all of their logic
(and there was a ton of it) was in C++ as was most of their
"high-level" presentation code. That in turn talked to Objective-C
code which actually implemented the behavior for the high-level
presentation code.
Today it would be even easier because you can do things like have
constructors (zero-argument only, of course) and destructors invoked
for non-pointer C++ objects that happen to be instance variables of
Objective-C classes. Of course, in the 32-bit runtime you still can't
just throw exceptions across the C++/Objective-C boundary, but as
Michael Ash points out, you can't do that with callback-based C APIs
anyway.
-- Chris
Chris Hanson
> It's easy enough to transform them into XML plists using plutil, but this
> does add an extra step.
Don't do that, it will be good for neither you nor your project.
A significant amount of effort was put into making the Xcode project
file format diffable and mergeable by humans for Xcode 2.1. For
example, elements have comments next to them describing exactly what
they are, so you don't have to refer to their section and follow the
chains implied by references to their unique IDs. Everything is also
written in a stable order so as to minimize revision control diffs when
you're not actually changing a project's structure, and structural
elements are written one to a line as well for easy merging.
Thus you can easily see that a file reference within a group refers to
MyApplication_Prefix.pch, or (and this is the important part!) that a
conflict occurred because two developers were both trying to add a file
to the end of the Compile Sources or Copy Headers build phase in a
target. But if both you and a coworker edit different build settings
in the same configuration of a target, you won't get a conflict. Etc.
Yes, there are a lot of scary-looking hex numbers in there. They are
unique IDs, nothing else. There's no information hidden in them,
they're just used to reference an object elsewhere in the file. And
all of the objects should be in a section whose comments make it at
least somewhat clear what its role in the project is.
Few people are likely to be generating Xcode projects by hand any time
soon, but they're not really that opaque.
-- Chris
Ben Artin
> On 2007-10-25 13:29:53 -0700, Ben Artin <mac...@artins.org> said:
>
> > Objective-C++ is of questionable utility. At compile time, g++ 4 mode has
> > bugs that make some code that compiles when included from a .cpp file not
> > compile when included from a .mm file.
>
> I'm very curious about what those specific bugs are, and whether they're
> addressed in the version of GCC 4.0.1 that's distributed with Xcode 3.
I understand your curiosity; unfortunately, I didn't save the offending
preprocessed sources, and it's not worth my time to dig them out of version
control because the code in question has long since been replaced with
Python/PyObjC (mmmm, Python).
> Several years back -- in the GCC 3.1 days -- I did some consulting work for a
> client with a huge (multi-million line) Objective-C++ application. It worked
> quite well for their them and they were using modern C++ idioms at the time.
>
> All they did was ensure that the layers were properly separated, i.e. that
> they didn't pass exceptions across the Objective-C/C++ boundary. By
> following that and a few other simple patterns, all of their logic (and there
> was a ton of it) was in C++ as was most of their "high-level" presentation
> code. That in turn talked to Objective-C code which actually implemented the
> behavior for the high-level presentation code.
I really disagree with the characterization of "properly separated" for this; I
think it's "suitably crippled".
Given a language feature that is semantically equivalent in two languages (such
as exceptions), not being able to use that feature across the two languages has
nothing to do with proper separation and everything to do with running into a
limitation of the language bridge and sucking it up.
> Today it would be even easier because you can do things like have
> constructors (zero-argument only, of course) and destructors invoked for
> non-pointer C++ objects that happen to be instance variables of Objective-C
> classes. Of course, in the 32-bit runtime you still can't just throw
> exceptions across the C++/Objective-C boundary, but as Michael Ash points
> out, you can't do that with callback-based C APIs anyway.
"It works no worse than C" is not exactly high praise.
I guess what this really comes down to is that my expectations of developer
tools are rather high, and that usefulness of Obj-C++ falls short of them. I
recognize that this is in large part due to the slow-mo train wreck that is C++;
no need to remind me :-)
Michael Ash
> as exceptions), not being able to use that feature across the two languages has
> nothing to do with proper separation and everything to do with running into a
> limitation of the language bridge and sucking it up.
You could replace "exceptions" with "objects" in the above and still have
an accurate statement.
Of course this isn't really a defense of ObjC++, more like a proof that it
*must* suck, no matter how it's done.
glenn andreas
Ben Artin <mac...@artins.org> wrote:
> >
> > All they did was ensure that the layers were properly separated, i.e. that
> > they didn't pass exceptions across the Objective-C/C++ boundary. By
> > following that and a few other simple patterns, all of their logic (and
> > there
> > was a ton of it) was in C++ as was most of their "high-level" presentation
> > code. That in turn talked to Objective-C code which actually implemented
> > the
> > behavior for the high-level presentation code.
>
> I really disagree with the characterization of "properly separated" for this;
> I
> think it's "suitably crippled".
>
> Given a language feature that is semantically equivalent in two languages
> (such
> as exceptions), not being able to use that feature across the two languages
> has
> nothing to do with proper separation and everything to do with running into a
> limitation of the language bridge and sucking it up.
Except that they are not semantically equivalent - C++ exceptions call
dtors as the stack is unwound, while Objective-C exceptions don't (since
Objective-C is built on C which has no such notion, and was implemented
via setjmp/longjmp). They are two completely different models (stack
unwinding with compiler generated tables for stack layout vs
setjmp/longjmp) that share some similar concepts but important semantic
differences.
So when Objective-C++ came about, they could either use one exception
model or the other - they chose to use the Objective-C version (to avoid
breaking all existing Objective-C code, with the caveat that C++ needed
to be "partitioned"). With 64 bit Objective-C++, since there was no
existing Objective-C code to break, they could finally use the C++ style
exceptions.
Ben Artin
Michael Ash <mi...@mikeash.com> wrote:
Well, yes and no.
This line of reasoning ultimately leads you to realize that what you really need
is a common language runtime with well-defined semantics, and then you need all
the languages that you care about to work on top of that runtime. This is what
Microsoft did with CLR, and this is increasingly the direction that Apple is
going in by bridging the Obj-C runtime to Python, Perl, Ruby, etc.
Then you realize that C++ can't work on top of any sane runtime, at which point,
if you are Microsoft, you invent a modified version of C++ that can or, if you
are me, you realize that you are better off using a language (such as Python)
that works on top of a sane runtime.
Ben Artin
glenn andreas <gand...@mac.com> wrote:
> In article <macdev-267894....@news.teranews.com>,
> Ben Artin <mac...@artins.org> wrote:
>
> > Given a language feature that is semantically equivalent in two languages
> > (such as exceptions), not being able to use that feature across the two
> > languages has nothing to do with proper separation and everything to do
> > with running into a limitation of the language bridge and sucking it up.
>
> Except that they are not semantically equivalent - C++ exceptions call dtors
> as the stack is unwound, while Objective-C exceptions don't (since
> Objective-C is built on C which has no such notion, and was implemented via
> setjmp/longjmp). They are two completely different models (stack unwinding
> with compiler generated tables for stack layout vs setjmp/longjmp) that share
> some similar concepts but important semantic differences.
Good point!
Michael Ash
> In article <11945378...@nfs-db1.segnet.com>,
> Michael Ash <mi...@mikeash.com> wrote:
>
>> In comp.sys.mac.programmer.help Ben Artin <mac...@artins.org> wrote:
>> > Given a language feature that is semantically equivalent in two languages
>> > (such as exceptions), not being able to use that feature across the two
>> > languages has nothing to do with proper separation and everything to do
>> > with running into a limitation of the language bridge and sucking it up.
>>
>> You could replace "exceptions" with "objects" in the above and still have an
>> accurate statement.
>>
>> Of course this isn't really a defense of ObjC++, more like a proof that it
>> *must* suck, no matter how it's done.
>
> Well, yes and no.
You say this, but then you go on to say what appears to be "yes and yes".
:)
> This line of reasoning ultimately leads you to realize that what you really need
> is a common language runtime with well-defined semantics, and then you need all
> the languages that you care about to work on top of that runtime. This is what
> Microsoft did with CLR, and this is increasingly the direction that Apple is
> going in by bridging the Obj-C runtime to Python, Perl, Ruby, etc.
>
> Then you realize that C++ can't work on top of any sane runtime, at which point,
> if you are Microsoft, you invent a modified version of C++ that can or, if you
> are me, you realize that you are better off using a language (such as Python)
> that works on top of a sane runtime.
In other words, the only way for ObjC++ not to suck would be to do things
that result in no longer having C++ anymore. Ergo, ObjC++ must suck.
However, I wonder if this is really true. So much of C++ is in the
compiler by its very nature. I imagine you could host C++ on top of a more
dynamic runtime, and just have C++ ignore most of the dynamism. Virtual
function calls could be replaced with true dynamic dispatch, for example.
Static function calls could just be normal function calls, or they could
end up doing dynamic dispatch on some suitably uniqued name. Stack objects
could be replaced with heap objects with automatic refcounting or GC. Then
you expose all the C++ functions as methods in the runtime and other
languages would then be allowed to use duck typing and all the rest.
Of course a major consequence of this would be to suddenly make C++
*slower* than the others, due to all the extra indirection. That might be
enough to qualify as "suck", but I'm not sure.
This is all just a thought experiment anyway. I personally have no need
for such a thing, and I agree with you that you're better off switching
languages if it comes to that.
Ben Artin
Michael Ash <mi...@mikeash.com> wrote:
> In comp.sys.mac.programmer.help Ben Artin <mac...@artins.org> wrote:
> > In article <11945378...@nfs-db1.segnet.com>, Michael Ash
> > <mi...@mikeash.com> wrote:
> >
> >> In comp.sys.mac.programmer.help Ben Artin <mac...@artins.org> wrote:
> >> > Given a language feature that is semantically equivalent in two
> >> > languages (such as exceptions), not being able to use that feature
> >> > across the two languages has nothing to do with proper separation and
> >> > everything to do with running into a limitation of the language bridge
> >> > and sucking it up.
> >>
> >> You could replace "exceptions" with "objects" in the above and still have
> >> an accurate statement.
> >>
> >> Of course this isn't really a defense of ObjC++, more like a proof that it
> >> *must* suck, no matter how it's done.
> >
> > Well, yes and no.
>
> You say this, but then you go on to say what appears to be "yes and yes".
> :)
I guess you can look at it that way :-)
> > This line of reasoning ultimately leads you to realize that what you really
> > need is a common language runtime with well-defined semantics, and then you
> > need all the languages that you care about to work on top of that runtime.
> > This is what Microsoft did with CLR, and this is increasingly the direction
> > that Apple is going in by bridging the Obj-C runtime to Python, Perl, Ruby,
> > etc.
> >
> > Then you realize that C++ can't work on top of any sane runtime, at which
> > point, if you are Microsoft, you invent a modified version of C++ that can
> > or, if you are me, you realize that you are better off using a language
> > (such as Python) that works on top of a sane runtime.
>
> In other words, the only way for ObjC++ not to suck would be to do things
> that result in no longer having C++ anymore. Ergo, ObjC++ must suck.
What I am trying to say is that by its nature Obj-C++ must suck as much as C++
does, but it doesn't have to add suck of its own. Effectively prohibiting use of
exceptions in C++ APIs called by Obj-C is one case in which I think Obj-C++
added suck on top of the suck of C++ (and I was glad to see that's fixed in the
64-bit runtime).
Programming in C++ is already like being in a straightjacket. In some cases,
Obj-C++ also ties your shoelaces together.
[snip]
> Of course a major consequence of this would be to suddenly make C++ *slower*
> than the others, due to all the extra indirection. That might be enough to
> qualify as "suck", but I'm not sure.
Well, it would to C++ weenies. It cracks me up every time I see a discussion of
C++ libraries that goes along the lines of
"We should have a C++ Unicode string class"
"Yeah, but what encoding would it use?"
"Store the encoding in a private member, and convert to other encodings if
needed"
"That would be too slow"
"Never mind then."
Ben
Michael Ash
> What I am trying to say is that by its nature Obj-C++ must suck as much as C++
> does, but it doesn't have to add suck of its own. Effectively prohibiting use of
> exceptions in C++ APIs called by Obj-C is one case in which I think Obj-C++
> added suck on top of the suck of C++ (and I was glad to see that's fixed in the
> 64-bit runtime).
There's kind of two ways to look at that, though. There's the broader
question of whether ObjC and C++ can be theoretically integrated that way,
and obviously the answer is yes, given the changes for 64-bit. But then
there's the more specific question involving the actual 32-bit ObjC that
Apple had to work with at the time, and for that one the answer was that
this dis-integration is in fact inherent to that particular environment.
> Programming in C++ is already like being in a straightjacket. In some cases,
> Obj-C++ also ties your shoelaces together.
Or sneaks into your house while you're away, hides in your closet and then
jumps out and strangles you in your bed at night. I'd say it's the easiest
language to provoke that I've used personally.
>> Of course a major consequence of this would be to suddenly make C++ *slower*
>> than the others, due to all the extra indirection. That might be enough to
>> qualify as "suck", but I'm not sure.
>
> Well, it would to C++ weenies. It cracks me up every time I see a discussion of
> C++ libraries that goes along the lines of
>
> "We should have a C++ Unicode string class"
> "Yeah, but what encoding would it use?"
> "Store the encoding in a private member, and convert to other encodings if
> needed"
> "That would be too slow"
> "Never mind then."
C++ is a great example of why you should avoid premature optimization. For
whatever reason, the design of the language seems to encourage that sort
of thinking.