[FFmpeg-cvslog] r22946 - trunk/libavutil/log.c

James Darnley james.darnley
Fri Apr 23 00:29:06 CEST 2010

2010/4/22 M?ns Rullg?rd <mans at mansr.com>:
> Michael Niedermayer <michaelni at gmx.at> writes:
>> On Thu, Apr 22, 2010 at 10:01:22PM +0100, M?ns Rullg?rd wrote:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>> > On Thu, Apr 22, 2010 at 09:32:24PM +0100, M?ns Rullg?rd wrote:
>>> >> Please revert or disable this code while you figure out something that
>>> >> works.
>>> >
>>> > ok
>>> > does anyone know how we can cleanly detect if the used terminal supports
>>> > ANSI codes?
>>> That's what termcap/terminfo is for. ?This means either using ncurses
>>> or doing a lot of dirty work ourselves, neither of which is very
>>> thrilling.
>> :/
>> what about getenv("TERM") and an array of terms that support ANSI?
> That's the wrong solution. ?Using curses would also make it work on
> non-ANSI terminals with colour information in terminfo. ?Let's see how
> hard it is to do this with curses before embarking on further hack
> trails.
>>> On windows ANSI codes work only if the ansi.sys driver is loaded. ?I
>>> don't know if that can be detected. ?I also don't know about other
>>> systems.
>> on dos there was the mem command that listed things (like ps)
>> it should list ansi.sys too
> Smells like a hack.

Then use a hack-free solution like attached.  Granted, some works
still needs to be done.  Perhaps the Windows functions should only be
called if the colour will be changed.  Perhaps a cleaner way of
getting the windows colours.

Michael, something for you to consider:
can be replaced by:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: colours.diff
Type: application/octet-stream
Size: 1690 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20100423/8c761af2/attachment.obj>

More information about the ffmpeg-cvslog mailing list