In article <1193193656.328993@[EMAIL PROTECTED]
>,
Michael Ash <mike@[EMAIL PROTECTED]
> 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" ****ting 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 im****tant.
> 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 sup****t 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.
|
