Sorry for my vague statements :) Actually I wasn't talking about logging to file as a default for Windows. On the contrary I think this has to be done by each application individually -- someone needs as you rightly say 10 lines of code just to make sure everything went okay, others need a large logging facility with rotation, archiving, severity of messages and maybe even mirroring some messages to a database. There's no universal solution here, the former would complain about dependencies, the latter would extend the existing logger or invent their own.
What I'm trying to say is that logging to file seems to be more common approach on Windows than logging to Event Log accessed from the Control Panel -> Administrative unless it is a service or application produced by Microsoft :) Access to Event Log by end-user can really be restricted by Domain Policies which affects mostly enterprise users, though I totally agree that those who are affected should do something about it. Cheers 2014-07-10 12:46 GMT+06:00 Koehne Kai <kai.koe...@digia.com>: > > >> -----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. > > Regards > > Kai _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
