Re: [DVBCUT-user] Changes in r71
Hi! Ralph Glasstetter wrote: >>Windows users should try out my experimental MSI installer package. >>You can download it from http://www.mr511.de/dvbcut/dvbcut.msi > > Hmmm,... the mplayer.exe is not running on my AMD! > Is this the executable from Raouls older MSI package (which was only for > Intel > CPUs)? Uh... maybe. I'm not sure where it's from, and I only tested it on my Core Duo notebook which I'm also using for compiling. My AMD system is playing file server and DVB recorder, so rebooting is not an option ;-) > And the default installation path was "C:\Programme\DVBcut\DVBcut"... > maybe one DVBcut to much...? ;-) Sorry, that's the default path: C:\Programme\\. Once I become more familiar with the MSI packager, I may be able to change that. For now, I just wanted to see if it works at all. -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user
Re: [DVBCUT-user] Changes in r71
hi, Am Donnerstag, 13. September 2007 18:54 schrieb Michael Riepe: > Hi! > > This time I probably got the encoding thing right. :-) > Yepp,... > Windows users should try out my experimental MSI installer package. > You can download it from http://www.mr511.de/dvbcut/dvbcut.msi Hmmm,... the mplayer.exe is not running on my AMD! Is this the executable from Raouls older MSI package (which was only for Intel CPUs)? And the default installation path was "C:\Programme\DVBcut\DVBcut"... maybe one DVBcut to much...? ;-) ciao Ralph - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user
[DVBCUT-user] Changes in r71
Hi! This time I probably got the encoding thing right. :-) Windows users should try out my experimental MSI installer package. You can download it from http://www.mr511.de/dvbcut/dvbcut.msi -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user
Re: [DVBCUT-user] Wrong handling of unicode filenames
Hi! Ralph Glasstetter wrote: > The important thing is obviously to specify the stream encoding explicitely > (no matter which type), since under Windows and Linux different default > encodings are used otherwise... At least if you want a particular output format. If you don't specify an encoding, the resulting file will use your locale's encoding. > probably the locale set by $LANG, which is > not there under Windows and therefore using none at all... > This could also explain your observation with (implicite) Latin-15 and > toCSring... Exactly. toCString() produced UTF-8, and QTextStream ran that through an additional Latin1->Latin15 conversion step (which, of course, is plain nonsense). Setting the target encoding to Latin1 as well turns off the extra conversion (Latin1->Latin1 is a no-op). -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user
Re: [DVBCUT-user] Wrong handling of unicode filenames
Hi, Am Donnerstag, 13. September 2007 08:46 schrieb Michael Riepe: > Since we also use "<<" with a "const char*" argument, which has the same > properties, the cleanest solution is to do it this way: > > stream.setEncoding(QTextStream::Latin1); > stream << "\n"; > stream << doc.toCString(); > > If we ever replace the QTextStream with a std::ostream or another "byte > transparent" kind of stream, this variant will continue to work, while > the other one won't. > > On my system, this creates a correctly encoded project file in both > Latin-15 and UTF-8 based locales. I'll check the Windows part this evening. > Yepp,... this version also works on my OpenSuse-Linux... as expected... and I expect it also to work under Windows! ;-) The important thing is obviously to specify the stream encoding explicitely (no matter which type), since under Windows and Linux different default encodings are used otherwise... probably the locale set by $LANG, which is not there under Windows and therefore using none at all... This could also explain your observation with (implicite) Latin-15 and toCSring... ciao Ralph - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user