 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c72a1cc@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trf de> wrote:
> The menu item "Quit POV-Ray" is put there by Mac OS X itself and can neither
> be disabled nor removed by an application. Compliments for this "feature"
> should be directed to Apple...
But it shouldn't be disabled or removed. It should quit the program.
Isn't this possible while still allowing the same binary to run under
both Mac OS X and Mac OS 9?
(BTW, has CodeWarrior finally fixed their debugger problems?)
BTW, I had to do some hacking of the application bundle to get it to
run...it doesn't seem to have a Contents folder, Info.plist, *.app
extension, or any of the normal application bundle stuff...why?
After renaming the bundle with the *.app extension, adding the missing
contents, and moving stuff around a bit, it seems to work fine under Mac
OS X (aside from a few interface anomalies), though I haven't tested it
under OS 9.2.
Also, it seems like the standard include folder would fit better inside
the bundle. The user can add their own include folders, and if they
really need to get to the standard includes they can still do so, but I
don't think they need to be a separate folder.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chr### [at] netplexaussieorg> , Christopher
James Huff <chr### [at] maccom> wrote:
> But it shouldn't be disabled or removed. It should quit the program.
> Isn't this possible while still allowing the same binary to run under
> both Mac OS X and Mac OS 9?
Oh, sure, if I bloat the code to inifinity all problems of the Mac OS X UI can
be fixed by the application code. For example it is about 50 lines of code
just to move the damn menus around to match Job's idiotic ideas of how Mac OS
X should look like :-(
> (BTW, has CodeWarrior finally fixed their debugger problems?)
Well, if you call a one to two minute startup of the debugger a fix...
at least it works and they promised to get rid of the slow gdb based crap and
return to the reliable and fast sym format possibly with their own debugger
again in CW Pro 8. I really hope they will!
> BTW, I had to do some hacking of the application bundle to get it to
> run...it doesn't seem to have a Contents folder, Info.plist, *.app
> extension, or any of the normal application bundle stuff...why?
According to the Apple documentation, the plist should be in the application
resource fork, and that is where it is. There does not have to be a Contents
folder according to the documentation either (not even for Mach-O applications
- note that POV-Ray is of course a CFM application). And it does not need an
extension according to any specification either. In fact, POV-Ray is a
application package created with Apple's own tool. Why it does not work as
expected under Mac OS X is something Apple has to decide, but I don't want to
waste one of my ADC support incidents on such a trivial problem. Especially
because Apple promised to provide adequate and complete documentation for the
whole packe/bundle things a long time ago in the Package TechNote (don't
remeber the TN number). Right now the doc parts are scattered all over and as
you see, mac OS X knowns nothing about the docs.
> After renaming the bundle with the *.app extension, adding the missing
> contents, and moving stuff around a bit, it seems to work fine under Mac
> OS X (aside from a few interface anomalies), though I haven't tested it
> under OS 9.2.
because all documentation and Apple tools creating the packge say it is
neither required nor recommended, but optional. Make of that what you want...
> Also, it seems like the standard include folder would fit better inside
> the bundle.
this would just make it more difficult to access, which is a bad idea. And it
would make it next rto impossible to open files in the include folder because
packages and bundles appear as one item that cannot be opened in the open file
dialog.
Of course I am aware how annoying the Mac OS X application start system bugs
are. For this reason, the next beta will be a plain application again and I
will change the templates folder format so it is user-readable.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Oh, sure, if I bloat the code to inifinity all problems of the Mac OS X UI
can
> be fixed by the application code. For example it is about 50 lines of
code
> just to move the damn menus around to match Job's idiotic ideas of how Mac
OS
> X should look like :-(
50 lines?
Well, the Quit item should work as soon as the Quit Apple Event is handled
properly, which it should anyway (since System 7.0).
And removing the Quit item on MacOS X should be just a matter of two or
three lines (if you already know you're on MacOS X... add another five lines
for a call to Gestalt if you don't know yet).
At least it works that way in my programs, and I happen to _like_ the idea
of a quit item in the application menu... what exactly did "Quit" have to do
with "File" in the first place (and why did Microsoft copy it)?
> According to the Apple documentation, [...]
> [...] There does not have to be a Contents folder [...]
The problem seems to be that MacOS X does not properly support the MacOS 9
package format, which I have almost never seen used anyway. Instead, it
supports a much stricter format (.app, Contents folder, plist as a file,
etc.). This format is documented somewhere, only I don't remember where
exactly (there was something in the MacOS X System Overview, IIRC).
If the app is in a package, it must be a MacOS X package and the plist needs
to be in a separate file in the Contents folder - if its a simple CFM
application file, it should be in the resource fork.
> [...] For this reason, the next beta will be a plain application again
[...]
That seems like a good idea - especially as POVRay also runs on MacOS 8.x.
Yours sincerely,
Wolfgang Thaller
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c7ca6bc$1@news.povray.org> , "Wolfgang Thaller"
<wol### [at] gmxnet> wrote:
>> Oh, sure, if I bloat the code to inifinity all problems of the Mac OS X UI
>> can be fixed by the application code. For example it is about 50 lines of
>> code just to move the damn menus around to match Job's idiotic ideas of how
>> Mac OS X should look like :-(
>
> 50 lines?
> Well, the Quit item should work as soon as the Quit Apple Event is handled
> properly, which it should anyway (since System 7.0).
POV-Ray handles apple events correctly. As Mac OS X does not allow me to
disable the Quit menu item in the application menu the only way to prevent
this nonsense menu to cause damage is to add code to prevent POV-Ray from
receiving the Quit apple event from the application menu (two lines of code).
I would rather remove it, but as that isn't an option...
> And removing the Quit item on MacOS X should be just a matter of two or
> three lines
What about the other menu items? The Preference menu item which I am
supposed to move? The Window menu which I am supposed to let the OS screw up
for me? As i said, I would have to make massive changes to the whole menu
handling as a special case for Mac OS X just to support the stupid ideas of
zero usability.
> At least it works that way in my programs, and I happen to _like_ the idea
> of a quit item in the application menu... what exactly did "Quit" have to do
> with "File" in the first place (and why did Microsoft copy it)?
You "Quit" working with the documents of that particular type. And what is
the point to fix something that wasn't broken for nearly 20 years - just
because M$ copied it?
>> According to the Apple documentation, [...]
>> [...] There does not have to be a Contents folder [...]
>
> The problem seems to be that MacOS X does not properly support the MacOS 9
> package format, which I have almost never seen used anyway.
Well, Apple says it would support it and when introducing packages actually
claimed they would be a step towards Mac OS X. Of course, with the left hand
ignoring what the right hand was doing is nice it it all happens on the back
of developers...
> Instead, it
> supports a much stricter format (.app, Contents folder, plist as a file,
> etc.). This format is documented somewhere, only I don't remember where
> exactly (there was something in the MacOS X System Overview, IIRC).
Yes, it is. The "much stricter format" is a nearly one to one copy of the old
NextStep appliction directory format...
> If the app is in a package, it must be a MacOS X package and the plist needs
No, then it is a bundle, not a package...
>> [...] For this reason, the next beta will be a plain application again
> [...]
> That seems like a good idea - especially as POVRay also runs on MacOS 8.x.
In case you don't know, packages appear as simple folders in Mac OS versions
that don't support packages, so they work transparently. Of course, this
doesn't fix the broken Mac OS X handling of packages...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> As Mac OS X does not allow me to
> disable the Quit menu item
Rightly so, IMHO. A program that refuses to quit when I want it to usually
ends up being forced to quit. Preventing damage could be done by a dialog
box asking for confirmation.
> [...] this nonsense menu [...]
> [...] just to support the stupid ideas of
> zero usability.
You seem to have strong opinions here that are just about the opposite of my
own, so I won't try to force you to add what you obviously consider
"pointless bloat" to your code - if these problems keep bugging me, I can
still do it myself _if_ it's really worth the time.
> In case you don't know, packages appear as simple folders in Mac OS
versions
> that don't support packages, so they work transparently. [...]+
I do know. But they don't look nice as folders.
... and sorry for assuming that you didn't know how to make the quit item
work "properly" (according to my definition of "properly") when in fact you
just have different preferences..
Yours sincerely,
Wolfgang Thaller
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c7cb62e@news.povray.org> , "Wolfgang Thaller"
<wol### [at] gmxnet> wrote:
> A program that refuses to quit when I want it to usually
> ends up being forced to quit.
Well, there are times when you don't want POV-Ray to "Quit" immediately, i.e.
only proper termination will allow compressed Pict images or QT movie files to
work. Sure, you can still "break" it in Mac OS X by sending a Quit apple
event from an external application at this time, but doing so is much harder
than just hitting the "wrong" Quit menu item...
>> [...] this nonsense menu [...]
>> [...] just to support the stupid ideas of
>> zero usability.
>
> You seem to have strong opinions here that are just about the opposite of my
> own, so I won't try to force you to add what you obviously consider
> "pointless bloat" to your code - if these problems keep bugging me, I can
> still do it myself _if_ it's really worth the time.
I am still counting on the user interface of Mac OS X to be fixed in the
future once it is noticed how the user base and satisfaction starts to
decline...
>> In case you don't know, packages appear as simple folders in Mac OS
>> versions that don't support packages, so they work transparently.
>
> I do know. But they don't look nice as folders.
They really don't, but at least they work :-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> POV-Ray handles apple events correctly. As Mac OS X does not allow me to
> disable the Quit menu item in the application menu the only way to prevent
> this nonsense menu to cause damage is to add code to prevent POV-Ray from
> receiving the Quit apple event from the application menu (two lines of code).
> I would rather remove it, but as that isn't an option...
You can disable the quit menu item like this:
first:
Are we running os X? (more than one way of doing this)
SInt32 result;
Boolean HostIsMacOSX=false;
Gestalt( gestaltMenuMgrAttr, &result);
if (result & gestaltMenuMgrAquaLayoutMask)
HostIsMacOSX=true;
And now only one line, simplicity of os X ;-) :-)
if ( HostIsMacOSX )
DisableMenuCommand(NULL, 'quit');
Yvo
--
e-mail:sme### [at] skynetbe
http://users.skynet.be/smellenbergh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1f89yb5.1mbrmmv1tweq3yN%smellenbergh@skynet.be> ,
sme### [at] skynetbe (Rene) wrote:
> DisableMenuCommand(NULL, 'quit');
Actually DisableMenuCommand is a CarbonLib function and no checking is
necessary, not even a check if running on Mac OS X because on Mac OS the call
will simply have no effect as long as there isn't a 'quit'. However,
DisableMenuCommand is not documented (only mentioned once in some 1999 doc)
and neither is the ability to disable system provided menus this way because
'quit' is not defined as a menu item constant. Thus, this is a hack that may
work right now, but later could simply have no effect anymore...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well, there are times when you don't want POV-Ray to "Quit" immediately, i.e.
> only proper termination will allow compressed Pict images or QT movie files to
> work. Sure, you can still "break" it in Mac OS X by sending a Quit apple
> event from an external application at this time, but doing so is much harder
> than just hitting the "wrong" Quit menu item...
Pardon me if I am asking something stupid, but does this mean that POV-Ray
currently reacts to a quit apple event differently than to a user selecting
the "right" Quit menu item? If so, why this? As far as I know the quit apple
event does not mean "quit immediately", but is meant to allow programs to
ask about saving documents before quitting etc. At least that's my
experience with other programs.
-Christian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <B8A3C8B8.2FD5%cwa### [at] gmxch> , Christian Walther
<cwa### [at] gmxch> wrote:
> Pardon me if I am asking something stupid, but does this mean that POV-Ray
> currently reacts to a quit apple event differently than to a user selecting
> the "right" Quit menu item? If so, why this? As far as I know the quit apple
> event does not mean "quit immediately", but is meant to allow programs to
> ask about saving documents before quitting etc. At least that's my
> experience with other programs.
No, what the quit event allows is not the problem is this case. It is all a
bit more complex! The point is that there is no clean way of knowing whether
the render thread is currently saving. With an external apple event in Mac OS
X the application thread can receive a quit event even while it was actually
busy. However, with its own menus the application can be sure this never
happens because it is living in a cooperative multitasking environment and
thus won't be able to process menu events of its own quit menu item until the
render thread gives it time.
As pointed out, in Mac OS X even Carbon applications, also they are living in
a cooperative thread model can receive apple events at times they could
technically not receive them in Mac OS because there the whole system uses
cooperative threads and all menus (not only the application's own menus) are
processed in the same way.
As for the application-owned quit menu item, it of course also sends quit
apple events. Just, as explained above, it simply won't do so (because in the
cooperative thread model it can't run at the same time) while the render
thread is working. The system-owned quit menu item on the other hand does
work at this time...
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
|
|
| |
| |
|
|
|
|
| |
|
|
