After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 504936 - Logging warnings/errors
Logging warnings/errors
Status: RESOLVED WONTFIX
Product: ekiga
Classification: Applications
Component: Engine
unspecified
Other All
: High enhancement
: ---
Assigned To: Snark
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2007-12-21 20:56 UTC by Snark
Modified: 2014-03-04 18:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Snark 2007-12-21 20:56:06 UTC
It would be nice if the engine had some way to log warnings and errors.

I was wondering if objects couldn't have chains of responsibility for that, like the following :
1. a plain function has a std::cout << message ;
2. it is connected as handler on a chain of responsibility of (for example) Ekiga::ContactCore ;
3. said core knows about sources, and is connected as handler on chains of responsibility for them ;
4. said sources know about books, and are connected as handler on chains of responsibility for them ;
5. said contacts have chain of responsibilities for messages.

This could allow displaying warnings like :
*WARNING* Ekiga::ContactCore->Evolution::Source->Evolution::Book("Personal")->Evolution::Contact("Foo"):  something very wrong happened.
Comment 1 Snark 2008-10-17 05:00:37 UTC
I see three uses for such logging :

(-) we get a successful registration : a flashing message in the status line is enough ;

(-) we get a failed registration : a flashing message is definitely not enough, we need something that sticks! Another example of such situation is the number of unread messages attached to an *opal* account (it doesn't make sense for a generic account).

(-) we get a developer-oriented error : all the FIXMEs about bad forms come to mind.

I'd really like to see a good system come up fast : we need it pretty badly.
Comment 2 Snark 2014-03-04 18:48:10 UTC
We already have glib's functions to handle such things : we should just use it more.

In retrospect, we didn't need that this fast or this badly...