Re: [Development] Qt 5 Mac losing window focus/active state

[jiang.jiang]

Hi,

On Sep 11, 2012, at 9:59 PM, ext Stephen Chu  wrote:
> I am having a lot of issue with window active state (or focus?) on Mac. 
> In addition to losing focus after clicking a combo box, I ran into this one:
> 
> 
> Basically after clicking at a empty window, clicking at the zoom button 
> and after the the window is maximized, the window title becomes inactive 
> although the window content is still getting clicks.
> 
> I tried to find out the cause of this but couldn't get anywhere. :(

I can confirmed that I can reproduce this with all the widgets. I haven't been 
able to find the cause either, but I suspect it could be a bug in event 
dispatching. (Mouse event causing the main window to resign key window status, 
to be specific.) Maybe Morten or Richard can help here.

- Jiang

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Plugin loading issue on Mac OS X

[jiang.jiang]

On Jul 10, 2012, at 11:39 AM, ext Thiago Macieira wrote:
> Are you sure that some plugins are only built in debug mode? That sounds 
> really weird. They should be built however they wish, but there should be at 
> least one file without the "_debug" image suffix.

I found it strange as well. The plugin resides in 
qtdeclarative/src/imports/qtquick2.

The generated Makefile does have both release and debug targets. But for
some reason I don't understand, it has "first: debug" at the beginning.
I found nothing suspicious in the qtquick2.pro file.

- Jiang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Plugin loading issue on Mac OS X

[jiang.jiang]

Hi,

Due to an autotest regression, I recently discovered that if plugins built
with both release and debug version (-debug-and-release) are loaded, it will
cause warning messages like:

   objc[26809]: Class QNSListener is implemented in both 
/Users/jjgod/qtbase/plugins/bearer/libqcorewlanbearer.dylib and 
/Users/jjgod/qtbase/plugins/bearer/libqcorewlanbearer_debug.dylib. One of the 
two will be used. Which one is undefined.

or even crashes.

However, simply blacklist _debug.dylib doesn't seem to be a good idea, because
certain plugins are only built with debug version, libqtquick2plugin_debug.dylib
for instance. Meanwhile, some others are only built with release version, like
libcocoa.dylib.

But we can't tell if a dylib should be loaded without loading it at present,
because qt_unix_query() only works for ELF binaries. Thus, we have to 
temporarily
load a dylib to tell if it is a plugin.

I guess the proper fix is to implement metadata query for Mach-O binaries, if
that's viable.

Any better idea?

- Jiang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Retina display

[jiang.jiang]

On Jun 13, 2012, at 3:35 PM, ext Jason Dictos wrote:
> Oh wait, I see, so I moved it out of the bundle and ran Designer, and wow 
> looks great.
> 
> I wonder how I can enable this mode in my application, since I'm using my own 
> bundle.

Try adding:

NSPrincipalClass
NSApplication

to the Info.plist of your app bundle.

See:

http://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW7

NSHighResolutionCapable sounds like something worth trying as well.

- Jiang

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QT5] System fonts are not loaded in ubuntu 12.04

[jiang.jiang]

On May 14, 2012, at 10:15 AM, ext Loaden wrote:
> The issue still exist.
> In Ubuntu 12.04, the 'fontconfig' package installed by default.
> loaden@qpsoft:~$ sudo apt-get install fontconfig
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> fontconfig is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

You need fontconfig-dev package, as I said in my first email.

> And the FontConfig value is 'auto'.
> FontConfig support . auto

We should probably make it more clear, but for now, if fontconfig
configure test succeeds, you will see 'fontconfig' in the
'Configuration ..' line.

- Jiang

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QT5] System fonts are not loaded in ubuntu 12.04

[jiang.jiang]

On May 5, 2012, at 8:16 AM, ext liang jian wrote:
>I have built Qt 5 in ubuntu 12.04, The simplified chinese
> character can't be displayed.
>I found that in QBaseFontDatabase::popluateFontDatabase() the font
> path returned by fontDir() is "/mnt/sda8/liang/qt5/qtbase/lib/fonts/"
> which is the path I built my Qt5, there are several fonts file in this
> directory but there are no chinese font files. As a result of this,
> the system font installed on my ubuntu 12.04 was not loaded and the
> simplified chinese character can't be displayed.
>In Qt5 Windows platform, there is a classe named
> QWindowsFontDatabase which is a subclass of QPlatformFontDatabase
> which will search Windows Font using Windows API, I there any way to
> search system fonts in XCB?

Build Qt with fontconfig development package installed (configure should show 
fontconfig enabled), then QFontconfigDatabase will be used instead of 
QBasicFontDatabase.

- Jiang

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Platform specific font matching in QPA

[jiang.jiang]

Hi folks,

Today I want to bring up the topic on font matching in QPA. In my opinion it's 
broken for certain very useful cases and beyond simple fix.

The first case is what Thiago brought up here [1]. Matching for aliases like 
"serif" and "monospace" is a commonly used feature in both desktop applications 
and WebKit. It allows us to specify an abstract font family name and have it 
configured in a platform specific format (fontconfig config file for instance). 
This is how things used to work in other toolkits and Qt 4.

The second one is when I tried to implement a separated Han script font 
matching in QUnicodeTables. As we know, Chinese, Japanese and Korean share a 
lot of code points in Unicode, without language tagging (lang="ja" in HTML), by 
simply checking the code points of a string, there is no way we can tell which 
font should be used. Should we use a Chinese font or Japanese font for the same 
"中" character? Such logic can only be found in a platform specific config file. 
It does not only happen to CJK fonts, whenever you have more than one fonts for 
the same script, how do we want to prioritize them will be platform dependent 
logic.

However, in QPA we can't do that. The current font matching logic in QPA works 
like this:

In the beginning, QFontDatabase will call populateFontDatabase() in a 
QPlatformFontDatabase and it will list all the fonts on the platform and use 
QPlatformFontDatabase::registerFont() to add these fonts into an internal 
structure defined in QFontDatabase. An important parameter of this 
registerFont() call is a void *handle. It's a unique representation of the font 
being added on the platform. For QFontconfigDatabase we use a combination of 
font path and index as the handle.

When QFontDatbase is asked to load a font request in a given script, it will go 
through all the fonts registered in its internal structure, evaluating the 
match() function to calculate a score for each font, the one with the lowest 
score gets selected.

After we find out the selected font, QPlatformFontDatabase::fontEngine() 
function will be called with the handle stored for that font, and 
QPlatformFontDatabase can just load the font with this handle.

In summary, QPlatformFontDatabase has no way to control the font matching order 
at all, all the font matching logic is fixed in QtGui. You can't simply write a 
QPA platform plugin to override this. As shown above, such logic is simply not 
flexible enough to handle a lot of use cases.

How is it handled in Qt 4.8 (non-QPA)? You may wonder. In Qt 4 each platform 
has its own QFontDatabase implementation in qfontdatabase_x11.cpp, 
qfontdatabase_mac.cpp, etc. In X11 for instance, QFont request (in QFontDef 
format) will be converted to a fontconfig query pattern (FcPattern *), 
fontconfig will do the match and return the matched font to us. Then we will 
create a QFontEngine (QFontEngineMultiX11 to be specific) out of it. So the 
platform specific font matching rules are perfectly executed. In Qt 5/QPA we 
lost that ability.

What's my proposal to fix it then? It's actually quite simple (no API change at 
all!), QFontDatabase will first try to get the matched QFontEngine by calling 
QPlatformFontDatabase::fontEngine() directly, with handle = 0, in that case the 
QPlatformFontDatabase::fontEngine() function will do a match in platform 
specific way, with the QFontDef and script given. If it fails to find a font or 
don't want to support this, simply return 0 and QFontDatabase will work just 
like how it's working now.

The WIP fix is here: http://codereview.qt-project.org/20590

- Jiang

[1] http://lists.qt-project.org/pipermail/development/2012-March/002736.html
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Removal of xlib plugin - a possible disaster.

[jiang.jiang]

On Mar 20, 2012, at 1:58 PM, ext Thiago Macieira wrote:
>> Font matching in QPA is pretty much broken for these cases, I have a WIP
>> patch to fix this: http://codereview.qt-project.org/20590 but it's not
>> complete yet. You can of course try and see if it helps.
> 
> Didn't see much of a difference...
> 
> I also don't see a "Monospace", "Sans" or "Serif" font in the Creator drop-
> down list.

Have you applied http://codereview.qt-project.org/20583? If so, can you see 
Monospace, Sans Serif and Serif in the QStringList returned by 
QFontDatabase::families()?

How does it look if you try to rendering something as simple as 
https://gist.github.com/2135911? It works for me here.

- Jiang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Removal of xlib plugin - a possible disaster.

[jiang.jiang]

Hi Thiago,

On Mar 20, 2012, at 8:31 AM, ext Thiago Macieira wrote:
> That's the point: I don't want it to convert. I want to configure my system 
> to 
> use "Monospace" and let fontconfig decide which font that is. If I were to 
> change my fontconfig settings, the applications should change too.
> 
> More importantly: I don't think the conversion is working properly. The 
> system 
> default is "Monospace", which is mapped to "DejaVu Mono", but on first start 
> Creator showed with a very different font and really hard to read.

Font matching in QPA is pretty much broken for these cases, I have a WIP patch
to fix this: http://codereview.qt-project.org/20590 but it's not complete yet.
You can of course try and see if it helps.

- Jiang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Removal of xlib plugin - a possible disaster.

[jiang.jiang]

Hi Thiago,

On Mar 19, 2012, at 9:50 PM, ext Thiago Macieira wrote:
>> That started happening sometime between 17 Feb. and now, FWIW; I
>> suspect it's quite recent.  At least the default font choice has
>> gotten better.
> 
> It's a horrible choice now. Creator uses by default the font "Monospace" in 
> Qt 
> 4.x. For whatever reason, in Qt 5 that font (an alias) is not present.

It should just work. In Qt 5 we do have the logic to use fontconfig to convert 
aliases like "Monospace" into actual fonts mapped into your system, like 
"Courier". I will try it with a recent xcb build now.

- Jiang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Something is wrong in QFontEngineFT::loadGlyph

[jiang.jiang]

Hi Mark,

On Feb 14, 2012, at 12:03 AM, ext Mark wrote:
> While using Qt's elidedText function 
> http://developer.qt.nokia.com/doc/qt-4.8/qfontmetricsf.html#elidedText i 
> noticed the function was dog slow. For just 1000 entries (each 250 chars) 
> eliding them to 200px took about 190ms on windows and 100ms on linux. Using 
> that for drawing is noticeable slow. I haven't actually tried that, but i 
> certainly would notice that and in the longer run that is my intention.
> 
> So, i started playing with it in an attempt to get it blazing fast. And i got 
> there. On windows i have a speedup of 39x (same job only takes 5ms) and on 
> Linux i got a speedup of 10x (same job takes 10ms, side effect is that linux 
> while 10x faster is now slower then windows.. odd), Those speedups are nice 
> but it tasted like more so i went on to profilling. I already knew the 
> QFontMetricsF::width was the function dragging everything down and a 
> kcachegrind seems to indicate the same.
> 
> Note for the speedups, i got them mostly by cashing the width of the used 
> character thus avoiding the width function as much as possible.
> 
> This is the path that width() takes till the point of calling the freetype 
> functions:
> QFontEngineFT::stringToCMap
> QFontEngineFT::recalcAdvances
> QFontEngineFT::loadGlyph
> 
> loadGlyph is where i think something odd is going on.
> http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontengine_ft.cpp#line812
> 
> Note the last parameter: "fetchMetricsOnly" ... The path it took had 
> fetchMetricsOnly set to true : 
> http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontengine_ft.cpp#line1611.
>  That leads me to think that this function is only going to fetch the metrics 
> of the glyph, not render it! The opposite is the case. It's rendering it and 
> that is the part that takes long.
> 
> So, am i right here? Is this function doing to much? Remember, we come from 
> the "width()" function. All we actually need is the width of the glyph, 
> that's it.
> 
> Actually, if you look in that function for the fetchMetricsOnly occurrence 
> you'll see that it's only used in one place and there it doesn't seem to do a 
> lot with metrics. It kinda looks like the original implementer of this has 
> some idea, but never finished implementing it. Or am i wrong here?

Your guess is mostly correct. This fetchMetricsOnly flag was added a while ago 
(Nov 5, 2008) to suppress a warning message but it's actually useful to avoid 
doing rendering in that case. I think we should change (set->outline_drawing && 
fetchMetricsOnly) to (set->outline_drawing || fetchMetricsOnly) if not 
regression is caused. How is that working for you?

- Jiang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use make before you push and stage

[jiang.jiang]

Hi,

On Jan 25, 2012, at 9:55 AM, ext lars.kn...@nokia.com wrote:
>> Yesterday was a bit of a frustrating day. I had to stage a simple
>> .pro-file change of mine 8, eight, times before it finally went in. All
>> of the breakages throughout the day where build breakages. Many of them
>> were in the autotests, but some where in the libraries themselves.
>> 
>> My request is simple: make sure you've configured with the
>> -developer-build, don't use -nomake if you're going to be pushing changes
>> to Gerrit for review, and don't forget to use your make tool before
>> pushing. You will save yourself and your fellow cuties alot of
>> frustration.
> 
> Another hint: configure with -no-pch if you can afford it, otherwise you
> might end up with missing includes causing breakage in the CI system. And
> if you do larger refactorings or touch headers in a bigger way also try to
> compile with -qtnamespace Foo (yes, I'm guilty of not doing this as well).

For somewhat big changes and refactor changes, it usually took many iterations
of compile/testing until they finally went in, because it's not always possible
for the developers to try all the different configurations on their development
machine. Would it make sense to setup a semi-final staging area to test that
kind of changes before we finally cherry-pick them to master? It should make
smaller changes integration smoother.

I have to apologize for broken integration several times myself, but I simply
don't have time/energy to maintain a Windows development machine. But I would
love to first cherry-pick my change into a testing area before trying to 
integrate
that into master.

- Jiang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development