In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

>> That is not true, you just don't know what you are talking about!
>
> It is true. The official version with GUI has the problem, the command
> line version and MacMegaPOV do not. The problem is definitely not in the
> core code, I don't see how you can seriously claim otherwise.

It is the priority setting of the OS for GUI applications.  Grap too much
and you see a beachball.  Command-line versions don't have a user interface
to serve, thus their priorities are handled very differently.  The only
working way around the beachball is to use MP threads *and* pure Carbon
Events.  Sadly that is easier said than done because Carbon Events replace
WaitNextEvent in a manner that isn't in every respect compatible with object
oriented applications:

Due to the need of "timers" and their callback functions which can end up
being called while your object is half-destroyed.  To be precise, you have
to install and remove timer callbacks in the highest derived class because
otherwise (that is in the lowest common base class that needs the timer,
i.e. a "window" base class) while being in a destructor the timer can fire
and the high-level object parts (i.e. "textwindow") are already destroyed
but the timer has not been disabled in the base class yet (because the
destructor function of "window" hasn't been called yet).  This makes using
Carbon Events a bit more tricky than they should be, and that is why many
applications don't use them (the Finder doesn't fully use them as well, it
seems)...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3e60b2f7$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Well, you could also say Mac OS X breaks all GUI conventions intelligent
> people at Apple spend decades to refine. 

You could. I don't.


> You should not only look at the CPU time wasting effects Mac OS X 
> brings, but also the millions of bugs and things it breaks. 

My CPU is idle most of the time. *That* is wasted CPU time. And yes it 
has bugs, the old Mac OS had plenty of bugs too. Considering its age, it 
is doing quite well.


> From the useless window layering to the dock.  Nothing
> works.  Hardly better than Windos in the end.  And it needs more memory than
> Windos already <sigh>  But of course, under the current leadership at Apple
> a consistent and easy to use user interface is no longer a topic at all.

Everything works. I find it far better than Windows. I've got enough 
memory. The current leadership gave me this, and I'm happy about it.


> Just look at Safari's non-standard appearance...

Yes, annoyingly inconsistent look, but still easy to use. I like the way 
it handles bookmarks.


> Sure, except that the interface is non-standard in every other respect.  The
> Quit menu belongs into the file menu, period. 

No it doesn't, it goes in the application menu.


> And the stupid application menu is just one big usability madness: 
> Maybe you did not notice, but with the application name being the 
> leftmost item the whole menu moves around in every application.

So? It's never been a problem for me. The application menu is bold, it 
makes a nice visual target to offset from. The ordering does not change, 
and the movement is not much.

All this is irrelevant anyway...point is that the official Mac version 
of POV-Ray does not work properly under Mac OS X. That is a simple fact, 
and has nothing to do with your opinions of the Mac OS X GUI. MacMegaPOV 
may have its own inconsistencies, but overall it has been much more 
reliable and it actually works right, so I am going to recommend it over 
the official version.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

>> Just look at Safari's non-standard appearance...
>
> Yes, annoyingly inconsistent look, but still easy to use. I like the way
> it handles bookmarks.

I like that too.  And I think it wouldn't be a problem at all to switch the
window theme, just a bit hacking of resources should do.  But that would not
fix several other non-standard interfaces, like the background in the
download window...

>> Sure, except that the interface is non-standard in every other respect.  The
>> Quit menu belongs into the file menu, period.
>
> No it doesn't, it goes in the application menu.

There shouldn't be an application menu of the kind that currently exists.
The same goes for preferences.  Remember that menus convey actions, not
concepts.  Do you "application" preferences or do you "edit" preferences for
example?  Sure, by concept preferences are an application property, but by
action you edit them.  hence they belong into the Edit menu.

The Quit menu item is a bit more tricky.  You may recall the OpenDoc days
when Apple tried to leave the concept of "application" behind (which would
have been a quantum leap had it been adopted by developers).  In that design
there was no "Quit" menu item at all.  Now, in Mac OS X by changing the
window layering Apple on the one hand tries to weaken the concept of
application regarding windows, but on the other hand strengthens it by
adding an additional menu for it.  And _that_ is inconsistent and the root
of all the problems :-(

>> And the stupid application menu is just one big usability madness:
>> Maybe you did not notice, but with the application name being the
>> leftmost item the whole menu moves around in every application.
>
> So? It's never been a problem for me. The application menu is bold, it
> makes a nice visual target to offset from. The ordering does not change,
> and the movement is not much.

The position moves.  If you tape users you will notice menu selection takes
much longer compared to Mac OS.  On average, the same tasks performed in a
usability test (that didn't seek to test Mac OS vs Mac OS X usability, it
just happened that one system in one location had 9.2.1 and the other at
another location 10.2.3 installed) showed, and which was very surprising,
for tasks that they took Mac OS 9 users 33 minutes and Mac OS X users 37
minutes to complete on average (7 and 12 users respectively).  That is a
"only" 12% difference, but on a full 8 hour workday is almost one hour of
lost productivity!  The test involved a website used with IE (because it was
available on both systems) and viewing downloaded data in Excel and
Acrobat...

> All this is irrelevant anyway...point is that the official Mac version
> of POV-Ray does not work properly under Mac OS X.

There is only a (very specific) problem with 10.2, which, as you may recall,
was released *after* the official POV-Ray 3.5.  MacMegaPOV on the other hand
was released much later...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3e60dc90@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> There shouldn't be an application menu of the kind that currently exists.
> The same goes for preferences.  Remember that menus convey actions, not
> concepts.  Do you "application" preferences or do you "edit" preferences for
> example?  Sure, by concept preferences are an application property, but by
> action you edit them.  hence they belong into the Edit menu.

File. Special. Apple. Window. Web browsers often have things like 
History and Bookmarks.
Menu *commands* convey actions, and even that is a general rule, with 
exceptions (such as the Window menu...but you probably don't like that 
either). Preferences belong in the Application menu, putting them in the 
menu containing document editing commands never made sense to me.


> for tasks that they took Mac OS 9 users 33 minutes and Mac OS X users 37
> minutes to complete on average (7 and 12 users respectively).  That is a
> "only" 12% difference, but on a full 8 hour workday is almost one hour of

7 OS 9 users and 12 OS X users, at completely different locations? 4 
minutes difference? That study doesn't show anything about the usability 
differences.


> lost productivity!  The test involved a website used with IE (because it was
> available on both systems) and viewing downloaded data in Excel and
> Acrobat...

Ugh...IE under OS X is a slow piece of crap.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff's furious key-hammering produced this:
> Ugh...IE under OS X is a slow piece of crap.

Agreed.  Sadly, though, the Windows version still isn't as good as the Mac OS
release when it comes to CSS...

Of course, when the IE:Mac for OS 9.2 behaves in a similar fashion to running
IE:Win under Win9X, it's definitely something to avoid (I had two total crashes
under OS 9.2 last night because of IE:Mac).  At least IE for OS X is a bit more
stable.

-- 
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

>> for tasks that they took Mac OS 9 users 33 minutes and Mac OS X users 37
>> minutes to complete on average (7 and 12 users respectively).  That is a
>> "only" 12% difference, but on a full 8 hour workday is almost one hour of
>
> 7 OS 9 users and 12 OS X users, at completely different locations? 4
> minutes difference? That study doesn't show anything about the usability
> differences.

No, it just shows that you don't know how usability is tested.  And the
location does matter at all for a usability study (well, it would if the
locations where seriously different in setup, i.e. one indoors and one
outdoors during a snowstorm for example).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

>> lost productivity!  The test involved a website used with IE (because it was
>> available on both systems) and viewing downloaded data in Excel and
>> Acrobat...
>
> Ugh...IE under OS X is a slow piece of crap.

The speed of the browser has absolutely nothing to do with this.  Nobody
measures speed differences of rendering pages in sub-second times.  It is
only relevant that the pages render in one to two seconds (more isn't
possible over intranets these days).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> Well, you could also say Mac OS X breaks all GUI conventions intelligent
> people at Apple spend decades to refine.  You should not only look at the
> CPU time wasting effects Mac OS X brings, but also the millions of bugs and
> things it breaks.  From the useless window layering to the dock.  Nothing
> works.  Hardly better than Windos in the end.  And it needs more memory than
> Windos already <sigh>  But of course, under the current leadership at Apple
> a consistent and easy to use user interface is no longer a topic at all.
> Just look at Safari's non-standard appearance...
> 

I have to (mostly) agree with Thorsten here. Whether you like OS X's 
interface or not, it and the iApps break many of the guidelines 
originally set out by the Apple Human Interface group. While Steve Jobs 
has undeniably done many good things for Apple since his return, 
sometimes, it seems he wants to emphasize "style" over "substance" too 
much. It's true, some people just want to whine because OS X is 
different than what they've been used to, but many people have also 
raised a lot of legitimate concerns with the direction the Mac gui is 
taking.

RJay

"There is a fantasy in Redmond that Microsoft products are innovative, 
but this is based entirely on a peculiar confusion of the words 
"innovative" and "successful." Microsoft products are successful -- they 
make a lot of money -- but that doesn't make them innovative, or even 
particularly good."
-- Robert X. Cringley

Post a reply to this message

In article <3e646194@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> No, it just shows that you don't know how usability is tested.  And the
> location does matter at all for a usability study (well, it would if the
> locations where seriously different in setup, i.e. one indoors and one
> outdoors during a snowstorm for example).

It appears you know little about setting up experiments. You need to 
eliminate as many extraneous variables as possible, geographic location 
could make a big difference, and this sample size is pretty small. This 
study could easily have shown Windows had the best interface.


> The speed of the browser has absolutely nothing to do with this.  Nobody
> measures speed differences of rendering pages in sub-second times.  It is
> only relevant that the pages render in one to two seconds (more isn't
> possible over intranets these days).

And the sub-second time it takes to access a menu does? And the 
milliseconds difference between fixed and slightly moving menus? It 
takes me far longer to find an item in a menu than to find the menu 
itself, and I spend very little time doing that.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

RJay's furious key-hammering produced this:
> I have to (mostly) agree with Thorsten here. Whether you like OS X's 
> interface or not, it and the iApps break many of the guidelines 
> originally set out by the Apple Human Interface group.

Personally, I find the application menus in OS X to make more sense overall.
For instance, you don't quit the file -- you quit the application.  You're not
setting the preferences for "edit", you're setting the preferences for the
application.  Et cetera, et cetera...

There are a few things that I don't like about OS X, though, mainly file
sorting and little things like that.  I like being able to sort by type and
date -- not just by name (I don't know if this was changed in Jaguar -- I only
have 10.1.5).  The dock could be a pain at times as well (I wish maximized
applications would not go under the dock).

-- 
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"

Post a reply to this message