[AD] [ alleg-Bugs-2758987 ] better way to display errors

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Bugs item #2758987, was opened at 2009-04-13 14:09
Message generated for change (Tracker Item Submitted) made by elias
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=2758987&group_id=5665

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core Library
Group: 4.9
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pschernig (elias)
Assigned to: Nobody/Anonymous (nobody)
Summary: better way to display errors

Initial Comment:
Right now, most example use TRACE() to display errors to the user. Which is of course pointless, as in debug mode they may or may not show up in some log file, and in release mode are directly sent to /dev/null. Previously, we used printf(), but if there is no console you cannot see the errors now either.

It seemed like a good idea to use al_show_native_message. But it depends on GTK and it may be annoying under Linux to have messages pop up when you actually prefer them on the console.

The GTK dependency could easily be solved by either having a core function which is implemented like in A4 (system("kdialog/xdialog")) - so no need to link the native dialogs addon. Or make the native dialogs addon not depend on anything (and fall back on the same A4 implementation).

The other problem could be solved with a config setting or environment variable where you force printf.

In any case, making this bug report so we won't forget to implement it at some point.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=2758987&group_id=5665




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/