> On 08/07/2014 11:13 AM, Tom Breton (Tehom) wrote:
>> Ted, I noticed you changed the debug printing to go to std::cerr.
>
> Yeah, I couldn't think of anything better.
>
>> Is there some way we can handle what you need thru the RG_DEBUG idiom?
>> Or
>> perhaps some way to have the best of both?
>
> I like to have two things:
>
> 1. Debug output that is present while I'm debugging, but always
> committed turned off so it doesn't get in anyone else's way. For this,
> I went with RG_DEBUG and RG_NO_DEBUG_PRINT to turn it off when I commit.
Yes, that's important and that's the clean way to do it.
> I saw in other places #ifdef being used, but that's pretty cumbersome.
Yes, it is very cumbersome.
> 2. Debug output for error situations to help users troubleshoot.
> This would always be enabled, for a debug build anyway. For this, I
> went with std::cerr since RG_NO_DEBUG_PRINT would have no effect on it.
OK, to help myself understand and/or be clear, let me list the levels of
debug/error output there would be as I understand them:
* Pop-up messages. Intended for in-the-users-face issues. Always on.
* What you're proposing: Debug output for error situations to help users
troubleshoot, should they choose to. Turned on in the debug build.
* What RG_DEBUG is doing now: Very detailed error messages intended for
maintainers. On short-term during intense development, per developer.
> (Neither would a release build for that matter. So, it's a bit
> extreme.) It would be nice to have an RG_ERROR that acts like RG_DEBUG,
> but isn't affected by RG_NO_DEBUG_PRINT. I didn't notice anything like
> that in Debug.h. (Qt has qDebug() and qWarning() which I think roughly
> correspond to what I would use.)
Right and right.
I suspect with cerr or another ostream, you would run into the annoyance
that most operator<< overloads are defined for QT and are thus unavailable
to ostreams. (Though an important one for Event is just for ostream)
RG_ERROR seems promising. It looks easy enough to write. We'd want to
ensure that future developments understood which to use when.
Since these aren't fatal conditions, RG_WARNING might be a more
appropriate name. An alias like RG_NOTIFY might be wanted for level-2
messages that aren't warnings, such as "RG Translations loaded
successfully." or successfully loading the user's config file.
That's what makes sense to me.
> But this is just the way I work. I wouldn't impose this on anyone
> else. Though I will admit that the deluge of RG_DEBUG output during a
> run does make it more difficult for me to get my work done. I would
> love to have a "Please don't commit live RG_DEBUG statements" rule. But
> I've mentioned it in the past, and the idea met with some resistance.
I have no problem with such a rule. I have not always followed it 100% in
the past; no excuses. I have no problem with following it in the future,
but I'd like to hear from others.
The deluge of output is a longstanding thing. Nobody loves it AFAICT. I
*suspect* that nobody would object if most of it went away.
It might make sense to keep a few major messages like major phases of
initialization. If I understand what you proposed, those would be
appropriate for the level-2 output.
Anybody else want to voice an opinion?
Tom Breton (Tehom)
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
