#Mac/Win crosspltform Dev
24 messages in this thread
>>This is really surprising. Why does the Win API make it easier? Normally,
>>Windows development takes around 50% longer than the equivalent Mac
>>development.
Windows provides me with hooks for customization and allows me to keep
a specified non-modal window on top the desktop at all times —
regardless of what application is currenly interacting with the user.
Apparently, I have to "patch traps" on the Mac (something for which I
am still searching for documenation on) to make this happen. From
what I've gathered from a few discussions on the C and Pascal Forum,
my goal might not even be possible.
In Windows, I can achieve this goal with a single API call. In OS/2, I
can do it with a hook. In Unix/X-Windows, I can do it through window
manager customization. On the Mac…. well, I just don't know….
The reason that Windows programming takes so much longer than Mac
development is because there are so many little "ins and outs" that
you have to know that take forever to get through. That's the
feedback that I've heard at least.
Neil,
I recently compared notes with a friend who started developing software for the
Macintosh and Windows. He said most of the programming techniques were
identical, i.e. Windows API were duplicates of the Macintosh. And then there
were the "gotchas" which slowed him down to a crawl on Windows….
for what it's worth…
malam
Malam,
>> And then there were the "gotchas" which slowed him down to a crawl on
Windows….
That's exactly the type of thing that I've been hearing.
Thanks,
Neil
Neil,
Please, enlighten us with the "things you've been hearing" with regards to
Windows "gotchas".
David
David,
>> Please, enlighten us with the "things you've been hearing" with regards to
Windows "gotchas".
I am not able to give you specifics. What I can tell you is that the Windows
API is counter intuitive ENOUGH that experienced programmers read through
documentation, run into a problem and then have to spend time struggling
through little problems. Once they figure things out, things make sense.
Nothing is earth shattering, they are just time consuming.
Since you have *no* problems writing code for Wiindows, you must be a superior
programmer that knows everything in the world about Windows and never runs into
these little problems.
The rest of the world simply must not be as experienced as you are.
Neil
Mehboob,
Mind elaborating on the "gotchas" of Windows programming? Sometimes I think
you guys have been brain washed by Apple. Take an objective look at the
situation and you might see things very differently. I've looked at
programming from both sides now, from up and down, and still somehow it's
Apple's illusions I recall…I really don't know Macintosh programming at all!
David
David,
We develop an application for both Mac and Windows at my company. On the Mac, I
use TCL, and the Windows dudes use MFC. It usually takes 1.3 times longer to
implement the same features than I do. A lot of it has to do with TCL being
more robust than MFC (I know, I know, some would argue with this statement) in
that I can easily implement our features. I use TCL's CTable class, for
example, and it provides a good foundation for building on. MFC doesn't really
have an equivalent. Doing simple things like changing the cell color or bolding
text within a cell/row just aint that simple in MFC.
For us, this is no illusion. It takes longer to build the same functionality
into the Windows app as it does our Mac app. The 1.3 number comes from
evaluating actual development time.
> Mark
Neil,
Tell you what. You sit down at your Macintosh and write the code to handle a
single closeable, resizeable, zoomable window on the Macintosh all with a
standard Apple menu and a minimal File menu. Then I'll sit down at my PC and
do the same thing in Windows. Guess what? You're code will be _much_ _much_
longer and significantly more complex than my Windows code.
If that doesn't convince you, then lets add multiple document windows. You
see, you're problem gets exponetially difficult whilst I just ride on the
Multiple Document Interface.
I've programmed Macintosh. I've programmed Windows. Windows is noticeably
_and_ significantly easier to program than Macintosh. I've done both…I know.
David
David:
>>>
Tell you what. You sit down at your Macintosh and write the code to handle a
single closeable, resizeable, zoomable window on the Macintosh all with a
standard Apple menu and a minimal File menu. Then I'll sit down at my PC and
do the same thing in Windows. Guess what? You're code will be _much_ _much_
longer and significantly more complex than my Windows code.
<<<
So which one takes more code to zoom to more than one screen?
Steve
Steve,
"So which one takes more code to zoom to more than one screen?"
What's your point? I know of no one who has multiple monitors under Windows
(though, I hear, it is possible). Zooming is therefore a freebe, though
Windows could benefit from the Macintosh "zoom only as much as you need" trend.
David
David,
I hate to give ammunition to the enemy <g>, but why don't you use my favorite
example — Print Preview?
On the project I'm doing now, the 1st cut at the user interface was done by the
Windows guy — then we hashed it out. He automatically included Print Preview
because it is a freebie with MFC. I eliminated it from the design.
Reede
David,
Not only do I know why people do not have multiple monitors with Windows
(because it does not support them in the way that the Mac does – I have 2 Mac
monitors, and know plenty of Mac folk who find very good use for them), but I
also know of some folk who are saddled with using 2 monitors under Windows. And
it is *horrible*! They might as well be separate machines, not just monitors…
Howard.
I would ask you why you seem to want to keep a specified window on top
at all times, regardless of what app is currently interacting with
the user?
Surely, if the user is working in another app, he *does not want* your
window to be on top of all others. Otherwise, he will be interacting
with a window which is not the top window, which is hardly good
interface design, is it?
Simply being able to do something is not the point of the Mac OS –
which tends to support things which are in the HIG, rather than
'anything which you could ever want to do with windows'. You may
criticise Apple for working this way, but it is precisely this that
has made the Mac interface so successful. Supporting total
customisation is a great way to reduce the legendary consistency of
the Mac interface to the near-anarchy of the past (and, from my
experience, its current competitors).
I do not criticize Apple for designing their API to support their GUI
conventions.
It just so happens that GUI conventions can change (in this case, the user
*does* want my window on top all of the time. No they don't want to interact
with
the window all of the time, but they want ot *see* it on top all of the time).
The
window only takes up a small portion of the screen and it provides the user
with information that s/he needs as s/he uses the other applications on the
desktop. If they really don't want to see it, they can dismiss it.
In Windows, this is easy. In System 7, this is near impossible. Again,
I am critizing anyone, just noting that Windows gives me the flexibility to
implement requirements which improve upon (my opinion) existing GUI
standards.
–Jim
Jim,
I'm sorry, but I know of no circumstance in which I would ever wish to be
interacting with a proper window which was not the front window. I have used
systems which allowed this, and they were a disaster in human interface terms –
you simply lose track of which window you are actually working in. The
convention that the window with which you are interacting is the top window is
a very good one, proven, and not a potential victim of "changing conventions"
any more than putting the menu bar at the top of the screen.
Howard.
Howard,
Have you ever used Hypercard, SuperPaint, Excel, Lotus 1-2-3, MS Word, or many
others that use this funny thing called a floating window?
Sorry, couldn't resist. 🙂
> Mark
Mark:
>>>
Have you ever used Hypercard, SuperPaint, Excel, Lotus 1-2-3, MS Word, or many
others that use this funny thing called a floating window?
<<<
As far as I can recall, those generally have floaters only when you ask for
them. And the floaters invariably disappear when you switch applications.
Steve
Steve,
True enough. I was _attempting_ to have a bit of fun. Oh well.
Actually though, Quickeys recording window kind of falls into the category of a
window that stays open at all times while recording, even across layer
switches.
> Mark
Mark,
Steve has already answered most of your question.
I would add that many HI folk reserve judgement on floating windows. They are
fine if you happen to have a large monitor and lots of screen estate in which
you can place them, or (if you have a Mac <g>) multiple monitors, but if you
have a single smaller monitor (as most average users have), then they can be an
obstruction to the interface. Try running XPress on a Classic-line model (or
even with a single 14 inch monitor)!
The situation to which I was alluding was actually more like SigmaPlot's
bizarre use of a movable modal dialog window in front of its spreadsheet, when
you are selecting data columns. Jandel *just* about get away with it, because
it is such a limited scenario and the interaction very simple. However, trying
running an app like that for any time, and you quickly decide that there are
alternatives which all of a sudden look much more attractive.
Howard.
Howard,
I agree completely. I was just trying to have a little fun. Oh well. 🙂
> Mark
Howard,
"Surely, if the user is working in another app, he *does not want* your window
to be on top of all others. Otherwise, he will be interacting with a window
which is not the top window, which is hardly good interface design, is it?"
There are programs, like First Things First by Andrew Welch, which go through
lots of loops to implement what would be so very simple under Windows.
The Macintosh has strengths and weakenesses, as does Windows. This is a case
where Windows wins.
"Simply being able to do something is not the point of the Mac OS – which tends
to support things which are in the HIG, rather than 'anything which you could
ever want to do with windows'. You may criticise Apple for working this way,
but it is precisely this that has made the Mac interface so successful.
Supporting total customisation is a great way to reduce the legendary
consistency of the Mac interface to the near-anarchy of the past (and, from my
experience, its current competitors)."
I'll bet when Windows starts running native on the PowerPC you'll see how
critical Apple's HIG are. Apple has made it because they've had total control
over the hardware and the system software. They're about to lose control of
the hardware (PowerPC will be in _other_ machines _not_ from Apple) and the
system software (Windows is coming).
David
>> rather than 'anything which you could ever want to do with windows'
David,
I cannot elaborate on the "gotchas", since I wasn't doing the programming… in
relation to the above comments (which came from someone else), I remember a
former room-mate bragging about how MS-Write had the ability to italicize text
to any arbitraty angle. That feature seemed whizzy enough, but I didn't grasp
it's importance…
malam
David,
You make the tacit assumption that this model for the human interface is
better. Do you have any objective evidence to support this? Because I can cite
papers in which the Apple model has been validated.
Please do not misunderstand me – I am not defending this model because it is
Apple's; I am defending it because I believe it to have been demonstrated to be
better. I therefore see this as a strength and not a weakness, just as I see
menubars at the top of the screen as a strength.
Howard.