In article <369e286b.0@news.povray.org> , par### [at] my-dejanewscom (Ron Parker)
wrote:

>I thought 
>the Mac UI had a more advanced way to specify these options anyway, so why 
>is it a big deal in the first place?

Well, there is no *clean* way to pass options to POV-Ray except through the command
line in some way when using altmain. What we do is rather simple: All options are
taken from the dialog, then stored in a resource which is (Mac-like) in the resource
fork of the file (the data fork contains the text file part). When building the
command line we use this resource's data and allocate a string with the proper
argument. After altmain we free this memory. The (currently) only other way would be
to directly manipulate "internal" data structures.

The way we use is to check if a filename etc. uses with characters the core code
cannot handle. Then we warn the user.

>If the Mac UI does allow you to specify 
>a command line, it seems like it's the UI's job to parse it into a format 
>that's acceptable to altmain.

No it does not offer a command line, but it offers full INI file support of course...

>Unfortunately, I don't have the source code handy at the moment, so I can't
>say for sure whether any of these assertions are grounded in fact, but I'm
>sure you'll correct me if I'm wrong. :)

I think (I am not sure) that the command line parser will even take several arguments
in one string, so the UI does not need to split it.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csicom
e-mail: fro### [at] charliecnsiitedu

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://www.povray.org

Post a reply to this message

> In article <369ceb04.0@news.povray.org> , "Johannes Hubert"
> <jhu### [at] algonetse> wrote:
> 
> >I don't know about this "bug" and it's fix, I am just curious:
> >
> >Regardless of if the OS allows a leading space or not: Why would anyone
> >in his right mind would want to use a leading space in a filename? 
[..]
Thorsten Froehlich <fro### [at] charliecnsiitedu> wrote:

> 
> Just a short technical explaination: Macs don't use pathes to find a
> unique file. And spaces are only the tip of the iceberg...Macs allow
> volumes with the same name...each volume has an unique ID, so it is no
> problems...and some users like spaces etc.  For example spaces in front
> move (if sorted) the filename to the top.
> 
> So the answer should be: As users are allowed to name their files this way
> programmers *have to* support it. Actually, this is no problem for Mac OS
> applications as long as they don't need path based standard C lib file IO.
> And there is no perfect solution for this :-(

As Thorsten said, there are all kinds of reasons for using a leading
space in a file name or volume name. 

We recently got a bug report [about our unofficial version] from a new
(I guess) POV-Ray user.
POV-Ray kept on complaning that the file 'xxx' could not be found. And
looking at this message you keep asking yourself why, why,.. if your eye
doesn't catch it you can look for a long time!
In this case the reason for the space was probably just because 
' Macintosh HD ' looks nicer on the desktop then 'Macintosh HD'.

I think that the space character is one of the most used ones in file
names on a Mac and especially this character is not handled right by
POV-Ray.

Anyway, the official version not only has a problem when the file name
has a leading space but also if the library paths have them. 
Our version only doesn't like a leading space in a volume name, but the
problem remains.

POV-Ray still attracts new users (yeh!) every day and those users should
be able to render the examples, even if there volume(s) have a leading
space.
And if I remember well, there have been some bug reports concerning this
to the Mac-Pov-Team-dudes in the past. So it *did* happen and it *still*
does happen!

Perhaps a warning in the message window is required if a leading space
is detected instead of 'could not find file' on platforms where it
matters.

Yvo Smellenbergh

-- e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh

Post a reply to this message

Nieminen Mika wrote in message <369e340b.0@news.povray.org>...
>Johannes Hubert <jhu### [at] algonetse> wrote:
>:>  And anyways, you don't have to guess anything if you have a proper
shell
>:>which supports file name completion
>: [snip]
>
>: That would have to be a *very* intelligent completion. Figure this:
>
>: Two filenames "    abc.txt", "   bcd.txt" (both have 3 leading spaces).
>: With a proportional font you can see that there are *some* leading spaces
>: but not how many. So you would have to guess, and completion won't help
you
>: either. Or am I missing some magic feature of completion?
>
>  No problem:
>  (pressing tab for file name completion is indicated as <tab>)
>
>talitiainen:~/temp>touch "    abc.txt"
>talitiainen:~/temp>ls \ <tab>
>talitiainen:~/temp>ls \ \ \ \ abc.txt
>    abc.txt

I think you missed my point: I wrote that there are *two* files, called "
abc.txt" and "   bcd.txt".
So when you enter

talitiainen:~/temp>ls \ <tab>

the shell would have to guess which one you mean. As I understand
completion, nothing happens when you press <tab> as long as it is not clear
from the uncomplete part, which of several possible options is meant. As
long as it is not clear you need to enter further charaters, until you
entered a "startstring" that is unique. Then you can press <tab> for
completion. Well, and this unique startstring would be hard to guess since
both filenames start with 3 spaces, but you only know *that* they start with
spaces, not with how many... (Note my other condition: Usage of a
proportinal font, which would make "counting" spaces hard.)

Johannes.

Post a reply to this message

Have to add a thing here..

in Sweden, and also is allowed by windoze 95... but, POV went off on those too...

//Spider

Johannes Hubert wrote:
> 
> [NOTE: Yvo posted his message in "povray.bugreports". I posted my reply
> here, because it is really off-topic for that group, and I didn't want to
> clutter the bug-reports with it...]
> 
> smellenbergh wrote in message
> <1dl### [at] dialup22leuvenskynetbe>...
> >Looks like file names are causing problems on Macintosh, and perhaps
> >other platforms too (all platforms allowing spaces as first character in
> >file names).
> >
> >We are aware that this is more an inconvenience than realy a bug but we
> >might have a solution.
> >
> >For example if your input file is ' scene.pov' (notice the space in
> >front) POV-Ray is unable to find that file because while parsing the
> >option 'Input_File= scene.pov', the space is thrown away.
> >
> >Why not not change the option parser in a way that options can be
> >enclosed like this:
> >Input_File=" scene.pov" and Version="3.1" ,......
> >
> >Or perhaps allowing it only for library paths, input files, output
> >files, ..... all options relating to file names.
> >If an option is enclosed, the parser should take *all* characters,
> >including spaces.
> >
> >Would it be hard to implement?
> >
> >Yvo Smellenbergh
> >
> 
> I don't know about this "bug" and it's fix, I am just curious:
> 
> Regardless of if the OS allows a leading space or not: Why would anyone in
> his right mind would want to use a leading space in a filename? This looks
> to me like inviting problems in more areas than only POV-ray - even if the
> OS handles the filenames correctly, humans will *very* easily make mistakes
> because it will be so easy to miss the leading space.
> Seems just as bad a practice to me as using *several* leading spaces
> (imagine, with a proportional font, the fun of "guessing" how many spaces
> you have to type to replicate a filename! ;-) or even worse: one or several
> *trailing* spaces (and no ".*" fileextension of course, which could spoil
> the fun of guessing the number of trailing spaces!)
> 
> Well, as said, I am curious. After all, there may be valid reasons... Any
> suggestions?
> 
> Johannes.

Post a reply to this message

Johannes Hubert <jhu### [at] algonetse> wrote:
: the shell would have to guess which one you mean. As I understand
: completion, nothing happens when you press <tab> as long as it is not clear
: from the uncomplete part, which of several possible options is meant.

  I quote myself:

>   zsh is even smarter (at least right configured): If there are many file
> names with leading spaces, then you can press tab twice and zsh will start
> to go through all them until you get the one you wanted (as 4dos does at the
> first tab press).

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Aarrgh!
Guess I should read postings more carefully... :-)

Johannes.

Post a reply to this message