Re: [Development] Qt5 can't show some Chinese character?
This is not a correct way the bugs should be reported ;)
Plz check if this bug is still reproducible with Qt 5.1 sources ("stable"
branch) and fill a bug report at bugreports.qt-project.org/ if so.
Also plz specify if this is a regression since 4.8.
Attaching some minimal code sample that shows the issue is also very
helpful. However, in you (specific) case, attaching a sample string + used
font name + "correct result" and "current result" images would be quite
enough.
BTW, I can't reproduce this issue with Qt 5.1 on windows with "Kozuka
Mincho Pro" font (see attachment)
Regards,
Konstantin
2013/3/28 Yuchen Deng
> Hi, there!
> I wan't show some Chinese character in QTableView, like this:
>
> [image: 内嵌图片 1]
>
> It's should display '霍映心', but it not. why?
> And seems the fonts is not clear?
> Am I missing something?
> I build Qt 5.0.2 with myself on Ubuntu 12.04 64bit.
> Any comments?
>
> --
> Best Regards
> Yuchen
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
<>___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 can't show some Chinese character?
2013/3/28 Konstantin Ritt > Attaching some minimal code sample that shows the issue is also very > helpful. However, in you (specific) case, attaching a sample string + used > font name + "correct result" and "current result" images would be quite > enough. > It's only Ubuntu (Linux) bug, I found it for a long long time since Qt5 did not out. I am installed libfontconfig1-dev before build Qt from the source. And I tried to use Application::setFont(...), then the UI font changed, but the issue still there. > BTW, I can't reproduce this issue with Qt 5.1 on windows with "Kozuka > Mincho Pro" font (see attachment) > Sorry I can't test Qt 5.1 for now. -- Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 can't show some Chinese character?
2013/3/28 Yuchen Deng : > > 2013/3/28 Konstantin Ritt >> >> Attaching some minimal code sample that shows the issue is also very >> helpful. However, in you (specific) case, attaching a sample string + used >> font name + "correct result" and "current result" images would be quite >> enough. > > It's only Ubuntu (Linux) bug, I found it for a long long time since Qt5 did > not out. > I am installed libfontconfig1-dev before build Qt from the source. > And I tried to use Application::setFont(...), then the UI font changed, but > the issue still there. > >> >> BTW, I can't reproduce this issue with Qt 5.1 on windows with "Kozuka >> Mincho Pro" font (see attachment) > > Sorry I can't test Qt 5.1 for now. I can :) Plz report a bug. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 can't show some Chinese character?
Reported here: https://bugreports.qt-project.org/browse/QTBUG-30415 2013/3/28 Konstantin Ritt > 2013/3/28 Yuchen Deng : > > > > 2013/3/28 Konstantin Ritt > >> > >> Attaching some minimal code sample that shows the issue is also very > >> helpful. However, in you (specific) case, attaching a sample string + > used > >> font name + "correct result" and "current result" images would be quite > >> enough. > > > > It's only Ubuntu (Linux) bug, I found it for a long long time since Qt5 > did > > not out. > > I am installed libfontconfig1-dev before build Qt from the source. > > And I tried to use Application::setFont(...), then the UI font changed, > but > > the issue still there. > > > >> > >> BTW, I can't reproduce this issue with Qt 5.1 on windows with "Kozuka > >> Mincho Pro" font (see attachment) > > > > Sorry I can't test Qt 5.1 for now. > > I can :) > Plz report a bug. > -- Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] include
Hi, I'm just trying to build against a yocto based sysroot. - it doesn't contain X11 libs/headers - it contains libwayland ... and in the end I want to build QtWayland against it => so I need xkbcommon => installing is no problem, because although it's a X11 package, it has no deps on X11 what so ever => when installed I get: /home/tsenyk/qt5/qt5/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.cpp:54:24: fatal error: X11/keysym.h: No such file or directory ... which IMO shouldn't be included there. Looking at X11/keysym.h and X11/keysymdef.h if my desktop, I contains a lot of defines, all defines beginning with 'XK_' but if I do: tsenyk@rudolf:~/qt5/qt5/qtbase/src/plugins/platforminputcontexts/ grep -r XK_ I get nothing. I get some XKB_, but those are defined in xkbcommon/xkbcommon.h ... maybe the defines are different on older systems? ... maybe it's just a left over include? So my question: is there something wrong with my logic or my conclusions? If not: I assume I can push a change like: http://pastebin.com/NjBZpfAz I've tested this on my desktop (archlinux 64bit) and for the target (yocto based sysroot, imx6 (arm)), both build without problems. Question on the side: This is a commit for stable, right? ... It can be considered a "build-bug-fix"... or not? Greets Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] include
On quinta-feira, 28 de março de 2013 13.35.22, Thomas Senyk wrote: > Question on the side: This is a commit for stable, right? > ... It can be considered a "build-bug-fix"... or not? Stable, it's a build fix. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
On 27 March 2013 20:11, John Layt wrote: > On 26 March 2013 18:15, Thiago Macieira wrote: >> On terça-feira, 26 de março de 2013 14.07.56, Sergio Ahumada wrote: >>> As far as I understand, the CI is all in Finland, so GMT +2. >> >> In other words, the tests are effectively disabled. > > Yeap, and on all platforms too. I assume changing the CI machines to > CET is out of the question. I'd say to run the tests with TZ set to > the right region, but on Windows that fails as while the C library > respects the setting the Win32 api doesn't so it just breaks the tests > in other interesting ways. So I guess we're left with modifying the > tests to Finnish time, even though it just perpetuates the problem. > > All work up a patch once I've fixed the bug in Windows. > > John. FYi, the bug is in the tests, or more exactly Microsoft's poor handing of time zones. CET in the Olsen database doesn't apply Daylight Time before 1980, but Windows does. Up to now all the dates auto-tested before 1980 have purely by chance always fallen in Standard Time, but the new min test for qint64 in 5.0 falls into Daylight time thus exposing the difference. I'll amend the tests to expect Daylight time from Windows. John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtSDK size difference between mingw and msvc version
Hi, sorry if this is a boring/stupid/old question (I have not found any related discussion): Why is the installed mingw version of the (5.0.1) SDK more than 3 times the size (>3.5GB) of the msvc version? It obviously boils down to the question why especially the debug dlls are so much bigger (like Qt5Guid.dll: 131MB vs 5MB). Somewhat related is the question: why is is necessary to have all those (huge) dlls both in the bin and lib directory? Not having them duplicated would cut down the above number by about 1.4 GB. - Axel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtSDK size difference between mingw and msvc version
On quinta-feira, 28 de março de 2013 18.31.50, Axel Waggershauser wrote: > Hi, > > sorry if this is a boring/stupid/old question (I have not found any > related discussion): Why is the installed mingw version of the (5.0.1) > SDK more than 3 times the size (>3.5GB) of the msvc version? Besides the point below, remember that the actual MinGW is shipped inside the installer. That adds another 300 MB. > It obviously boils down to the question why especially the debug dlls > are so much bigger (like Qt5Guid.dll: 131MB vs 5MB). Debugging symbols are much bigger and extremely space-inefficient with DWARF2. GCC is switching to DWARF4 and that should help. > Somewhat related is the question: why is is necessary to have all > those (huge) dlls both in the bin and lib directory? Not having them > duplicated would cut down the above number by about 1.4 GB. That's a mistake. The installed package should not have DLLs in the lib directory. I think Ossi has already pointed this out to the packaging team. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] include
It is a leftover, I have submitted a change: https://codereview.qt-project.org/#change,52599 From: development-bounces+gatis.paeglis=digia@qt-project.org [development-bounces+gatis.paeglis=digia@qt-project.org] on behalf of Thiago Macieira [thiago.macie...@intel.com] Sent: Thursday, March 28, 2013 4:02 PM To: development@qt-project.org Subject: Re: [Development] include On quinta-feira, 28 de março de 2013 13.35.22, Thomas Senyk wrote: > Question on the side: This is a commit for stable, right? > ... It can be considered a "build-bug-fix"... or not? Stable, it's a build fix. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating third-parties
On Wed, Mar 20, 2013 at 5:50 PM, Thiago Macieira wrote: > qtbase: > ANGLE (*) If I followed this thread sufficiently, it seems as if no one has yet made a statement about the update of ANGLE. I just remembered that a couple of weeks ago I came across this warning message when running some simple fragment shader of mine: warning X3206: implicit truncation of vector type Some googeling revealed that others have seen the same: http://qt-project.org/forums/viewthread/23563 Some more revealed that it is actually an ANGLE bug that has been fixed since last November: http://code.google.com/p/angleproject/source/detail?r=1557 According to http://qt.gitorious.org/qt/qtbase/blobs/stable/src/3rdparty/angle/src/common/version.h, the currently shipped version in qt is 1318, while the latest upstream version of their trunk is 2040: http://code.google.com/p/angleproject/source/list. I'd suggest to upgrade ANGLE to something after the mentioned fix, but since I don't see any 'proper' released upstream version other than a very old 'v1.0' branch, I would not know which version would be suited best. How has the currently used version been chosen at the time? - Axel P.S. this is not necessarily an offer to do the upgrade myself (I don't even have enough space to build qt on my windows partition right now) but I might be convinced to do so if no one else feels 'responsible' for ANGLE. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating third-parties
On Thu, Mar 28, 2013 at 08:44:13PM +0100, Axel Waggershauser wrote: > P.S. this is not necessarily an offer to do the upgrade myself (I > don't even have enough space to build qt on my windows partition right > now) but I might be convinced to do so if no one else feels > 'responsible' for ANGLE. > the wip/winrt branch is currently preparing an angle upgrade - but that is for 5.2. the change certainly could be re-targeted for stable ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating third-parties
On Thu, Mar 28, 2013 at 9:09 PM, Oswald Buddenhagen wrote: > On Thu, Mar 28, 2013 at 08:44:13PM +0100, Axel Waggershauser wrote: >> P.S. this is not necessarily an offer to do the upgrade myself (I >> don't even have enough space to build qt on my windows partition right >> now) but I might be convinced to do so if no one else feels >> 'responsible' for ANGLE. >> > the wip/winrt branch is currently preparing an angle upgrade - but that > is for 5.2. the change certainly could be re-targeted for stable ... You mean the ANGLE change that fixed this particular warning or the whole ANGLE upgrade from the wip/winrt branch? Which upstream revision is going to be in this ANGLE upgrade (and why)? (I went ahead and posted a question on the ANGLE ML asking which 'stable' revision they would suggest to ship with Qt 5.1.) - Axel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] File Selectors API, still for 5.1?
The renamed, private, dynamic selector supporting version is now on gerrit against stable: https://codereview.qt-project.org/#change,52605 for those following this change. On Tue, Mar 26, 2013 at 1:43 PM, Alan Alpert <4163654...@gmail.com> wrote: > On Tue, Mar 26, 2013 at 11:04 AM, Thiago Macieira > wrote: >> On segunda-feira, 25 de março de 2013 10.42.27, Alan Alpert wrote: >>> > This is not good enough a reason. Any new feature can only be accepted in >>> > *dev* once it's complete: that is, it is there, works, unit-tested, >>> > documented, with examples if necessary, and an initial API review has been >>> > done. If your feature is still discussing the class name, it indicates >>> > that >>> > the initial API review is not concluded. >>> >>> I got the impression that the initial API review was done. Then >>> someone brought up that they didn't like the name... >> >> Ok, that sounds more like nitpicking. We can always rename a class before >> it's >> released. That doesn't stop the integration, though, if everything else is >> fine. >> >> Unfortunately, the rest of the email thread doesn't lead me to believe that >> it >> is. >> >>> >> 2) What to call it? >>> >> Oswald suggested "QPathSelector. or QPathSwitch[er]. or >>> >> QPathMultiplexer." I'm still leaning towards QFileSelectors, but I'd >>> >> also be happy with Q[File|Path]Switcher or QPathMultiplexer. I know >>> >> that everyone has an opinion on naming matters, is there something >>> >> even better that we haven't thought of yet? >>> > >>> > Explain here in a few words what the class is meant to do and how it does >>> > that. That's two things I'm asking for: what and how. The name should come >>> > from one or both. >>> >>> Applies selectors to file paths. Hence QFileSelectors (QPathSelectors >>> maybe). >> >> What is a selector? Maybe I should just read the documentation... >> >> "QFileSelectors provides a convenient way of selecting file variants >> based >> on platform or device characteristics." >> >> (BTW, the docs are missing the \brief) >> >> "Multiplexer" is too complex a term. "Switcher" gives the impression that you >> can switch it -- as in switching from Android to iOS to QNX. That doesn't >> look >> right to me. So "Selector" is better -- singular since it's what the class >> does, not that it applies "selectors" to the name. > > Okay, maybe I'm too close to the issue. I'll rename it QFileSelector > (and add the \brief). > > -- > Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
