I think the first order here is to decide what are “critical” error
messages.Sorry no. You, nor anyone else, gets to decide what is critical. That
is
up to the programmers using the library and the developers of the
library. It is up to the individuals and is not subject to any sort
of
group decision or policy. The rest of your legalistic discussion is
seriously off topic.I’m afraid one or both of us are responsible for a miscommunication
here, Bob. Deciding what constitutes a “critical error” was merely an
endeavor to create operational terminology for the purpose of this
discussion. The word “critical” indicates “necessary severity.” In this
thread, the necessary severity for an SDL application to be unable to
communicate with the user is generally going to be a segmentation
fault, or corrupt and/or missing resource files. Why is this where the
distinction is drawn? Because if you can find your resources, and you
haven’t crashed, then you are still able to report the error to the
user.On the other hand, if you wanted a more “casual” GUI dialog interface,
I think you are in the minority here. There are several GUI libraries,
and if utilizing the native environment’s “message box” interface is
that important to you, I recommend finding a library to accomplish this
for you, or writing it yourself separately from SDL.
Donny, considering the sehar volume of misinformation you have posted
since you started on this list it is very hard to take anything you say
the least bit seriously. AFAIK, I am the only person in the world
actively working on adding multi-window support to SDL. I believe that
working on that project has given me a moderate level of understanding
of the issues you are talking about. Something you have demonstrated
that you clearly do not have. Well, all I can say is that it is time for
you to take a deep breath and spend some time thinking about what you
are saying. You appear to be much more interested in getting your own
way and “winning” the argument than in coming to a solution that will
work.
Seriously, take a deep breath, let it out slowly, and then spend a few
minutes trying to see the issue from all sides. Not just from yours.
Bob Pendleton
P.S.
Seriously Folks, this whole thread has turned into an exercise in
futility. Although it has been hilarious watching the people who
actually know what they are talking about poking holes in the self
important blowhards. It is just too painful to watch when the people who
are being made fun of don’t even seem to understand they are being egged
on for the shear humor of watching their blustering and strutting
reactions.On Sat, 2005-03-19 at 02:00 -0500, Donny Viszneki wrote:
On Mar 18, 2005, at 1:30 PM, Bob Pendleton wrote:
On Mar 18, 2005, at 7:56 AM, Brian Barrett wrote:
B) The average X (Linux, BSD, etc.) user will be >smartenough to
check stdout / stderr themselves.Do you not think that’s just a bit misinformed. i used linux and
before learniing SDL i would have no reason to assume apps printed
errors to some obscure file when they crashed.Some obscure file? On Linux (which you say you were using) you would
either have run the application from the command line (no problems
seeing the error output in this case, I assume,) or you would have run
it from your desktop environment (most likely scenario.) In the latter
case, there is no “obscure” file. Typically, your X session will send
the non-graphical of a graphical application to a log, the system
console (or another similar “console” file) or sometimes nowhere.
However, most Unix users know this. I’m sorry you did not. The fact
that you didn’t is probably a good indication that I am better than you
to say what the typical Unix user is likely to know. (Read: most Unix
users are not newbs, and know how to retrieve the non-graphical output
of their graphical applications.)
On Mar 18, 2005, at 7:56 AM, Brian Barrett wrote:
The way i see it is
- SDL can make windows on many platforms
- SDL has built in surfaces
so instead of printing SDL_Parachute deployed , after the window
closes, open a different window and import an error surface… at the
very least you could set the title of the window to SDL_ERROR #4 so
users could report errors back to the developers…Software of every origin and purpose for decades has found a message
box a perfectly acceptable method of reporting critical errors. Why
don’t you?In a small project, why not use a message box to inform the user the
program has crashed, and where (and if) to report the crash. For a
large project, I recommend writing a crash reporter, or finding one
that’s right for you. You’ll also find that it’s not something to
implement in a cross-platform fashion… or, more accurately, most
effective when left platform segregated.
One thing I didn’t really cover in my last post were crashes resultant
of segmentation faults, and similar conditions. Would anyone like the
suggestion of allowing the parachute to execute another program, or
perhaps a function in the current program? I think this is both the
most flexible, and the lightest solution possible. A cross-platform
message-box would still be more appropriate for errors such as the
typical “cannot find resources” error that I covered thoroughly in my
previous post. Perhaps both of these features together can cover all
the bases for everyone?I do realize you can turn the parachute off, however I think telling
the parachute to execute your own program or function allows you to
retain the benefit of SDL already knowing how to hook into the varying
signal handling interface of each platform. I hope everyone will agree
that these two solutions cover everything adequately.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
