> -----Original Message-----
> From: development-bounces+kai.koehne=digia....@qt-project.org
> [...]
> On the contrary, the end-user on Windows expects the application logs to be
> in a file somewhere near the executable if it's not a system service. So in my
> opinion the logs shouldn't write into system unless explicitly asked to.

I think logging to a file is a useful option. But I disagree that it should be 
the default, at least for Windows.
First, you've the problem to find a file 'somewhere near the executable' that 
you can write to. For end-users, you don't necessarily have write permissions 
to Program Files, and even if you have it, you don't want data to be put there, 
either. The only place that should always work would probably be %localappdata%.

But even if you manage to do that: You need to take care of concurrent accesses 
(multiple instances of your application might run). Then someone comes along 
and complains about his user directory hitting the quota, so you've to 
implement some cleanup/rotation ... It gets quite a big task.

Then there's the IDE side: You can adapt Qt Creator, but Visual Studio etc 
won't know a thing about your log file.

Despite all its limits (one global buffer, only plain string logging, only one 
debugger/viewer can attach ...), the Windows system log is the recommended way 
to log debugging information for GUI applications. I'm not arguing against 
adding such a file based backend, but it should be the default. 

> Moreover afaik not every enterprise user has access to System Logs on
> Windows.

First time I hear this  (and I don't think we have had a lot complains about it 
so far?). Anyway, this is one of the things where I'd rather tell people to fix 
their policies ( I know, I know, it's a hard fight ...). Also, you can just run 
your application in the debugger (as long as you've the rights to do this ;), 
or implement a simple log-to-file in 10 lines of code yourself.


Development mailing list

Reply via email to