Qt 5.5.0 an Qt 5.5.1, QWebEngine, QtWebKit and ICU

Leave a comment

Notes about compiling QtWebEngine (instead of QtWebkit) together with Qt 5.5.1

Qt 5.5.0 configure switches for ICU:

configure \
    -icu \
    -I Q:\SharedLibraries\icu4c-51_1\icu\include \
    -L Q:\SharedLibraries\icu4c-51_1\icu\lib64

Starting with 5.5.1 it shouldn’t be necessary to compile and ship ICU libraries because ICU should be included in Qt package itself.

Compile QtWebkit

It’s necessary to compile it as standalone module.

cd Qt/qtwebkit
perl Tools\Scripts\build-webkit

Simpler solution

Much easier solution seem to be to use http://www.awesomium.com/  😉

Notes:

  • When changing configure settings, it’s sometimes necessary to perform complete clean rebuild. The  best way how to do that is download completely new source package.
  • nmake clean or nmake distclean unfortunately didn’t work for 100%
  • It’s necessary to have installed Ruby, Python and Perl

Source links:

Other info:

Crash in QTreeWidget / QTreeView index mapping on Mac OSX 10.10 part III

2 comments

So, one more attempt. Previous articles (part1, part2) mentioned possible solutions to fix crash insinde the QTreeWidget and QAccessibleTableCell.

Unfortunately, deselecting current item still doesn’t fix all issues. The problem with deselection is that it’s not handled correctly via QAccessibleTableCell:

If current index isn’t valid, QAccessible doesn’t correctly update currect QAccessibleTableCell object which caused all this evil crashes.

So there are two ways how to fix it. One is to manually set QAccessibleTableCell but I didn’t find a way how to do that. The second way is to disable QAccessible for Property editor. Unfortunately it’s not an easy task. In QAccessible exists method setActive:

QAccessible::setActive(false)

But this method works only with AccessibleObserver class but not with QPlatformAcessibility which handles real QAcessible::isActive result. Because of this it’s necessary to update setActive method in file qacessible.cpp inside the Qt.

Original method:

void QAccessible::setActive(bool active)
{
  for (int i = 0; i < qAccessibleActivationObservers()->count() ;++i)
    qAccessibleActivationObservers()->at(i)->accessibilityActiveChanged(active);
}

and updated version:

void QAccessible::setActive(bool active)
{
  #ifndef QT_NO_ACCESSIBILITY
    if ( QPlatformAccessibility *pfAccessibility = platformAccessibility() )
      pfAccessibility->setActive(active);
  #endif

  for (int i = 0; i < qAccessibleActivationObservers()->count() ;++i)
    qAccessibleActivationObservers()->at(i)->accessibilityActiveChanged(active);
}

In case you will find better way how to turn off accessibility, please let me know.

But there is still one more problem. Occasionally OS X decides to switch accessible back on:

And this is probably the reason why everything works ok on older OS X but not on 10.10. Because OS X 10.10 randomly turns accessible on which causes this crash. Accessible is usually turned on when opening some modal dialog.

This explains why opening an empty dialog increased the probability to crash the application. The only solution I have found is to disable QAccessible every time the PropertyEditor is cleared up.

Crash in QTreeWidget / QTreeView index mapping on Mac OSX 10.10 part II

One comment

As mentioned in the first part of this article, the workaround with focus unfortunately didn’t work. In some cases application is still crashing. So after next hours of debugging and unsuccessful consulting the problem on stack overflow I probably found a the core reason of this bug and the solution too.

2015-05-18_0850

 

The core of this problem doesn’t lie in the QTreeModel, but in Qt implementation of Cocoa Accessible. The problem is that although the PropertyTree is correctly cleared, there is object QAccessibleTableCell which isn’t correctly updated after

clear()

.

This means that although the PropertyTree and TreeWidget is empty, the QAccessibleTableCell object still holds m_index variable to invalid element. And when

 NSAcessibleEntryPointrAttributeNames

is executed, m_index is translated to QTreeWidget element pointer and accessed. And this means that application completely crashes.

The solution is pretty simple. Together with property editor clear set also current index and selected index to NULL.

	propertyBrowser->clear();
	propertyManagers->clear();
	propertyManagers->treeWidget()->setCurrentItem(NULL);
	propertyManagers->treeWidget()->setItemSelected(NULL, false);

And that is it. Thanks for this your application will not crash any more (on this bug 😉 ).

 

Crash in QTreeWidget / QTreeView index mapping on Mac OSX 10.10

One comment

This crash took me about 40hr+ to replicate and find a way how to eliminate it (unfortunately not to fix it). This crash occurred only on OS X 10.10, not 10.9, not Linux, not Windows.

2015-05-18_0850

Bug occurred in slightly modified QtTreePropertyBrowser where we have additional buttons for each property.

2015-05-18_0847

When any of these buttons caused property tree refresh, application randomly crashed. But when these actions were executed by buttons outside of the property tree, everything worked fine.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.qt-project.QtWidgets      	0x0000000103f49290 QTreeModel::index(QTreeWidgetItem const*, int) const + 176
1   org.qt-project.QtWidgets      	0x0000000103f4950b QTreeModel::parent(QModelIndex const&) const + 75
2   org.qt-project.QtWidgets      	0x0000000103f23bb7 QTreeView::isIndexHidden(QModelIndex const&) const + 71
3   org.qt-project.QtWidgets      	0x0000000103f17e0d QTreeView::visualRect(QModelIndex const&) const + 93
4   org.qt-project.QtWidgets      	0x0000000103ec490d QAccessibleTableCell::rect() const + 29
5   org.qt-project.QtWidgets      	0x0000000103ec46f2 QAccessibleTableCell::state() const + 146
6   libqcocoa.dylib               	0x00000001071913aa QCocoaAccessible::hasValueAttribute(QAccessibleInterface*) + 58
7   libqcocoa.dylib               	0x000000010718df7e -[QMacAccessibilityElement accessibilityAttributeNames] + 398
8   com.apple.AppKit              	0x00007fff95dea26e NSAccessibilityEntryPointAttributeNames + 115
9   com.apple.AppKit              	0x00007fff95e275af -[NSObject(NSAccessibilityInternal) _accessibilityAttributeNamesClientError:] + 56
10  com.apple.AppKit              	0x00007fff95e2a62a CopyAttributeNames + 216
11  com.apple.HIServices          	0x00007fff9768cbce _AXXMIGCopyAttributeNames + 252
12  com.apple.HIServices          	0x00007fff976950c6 _XCopyAttributeNames + 385
13  com.apple.HIServices          	0x00007fff97671109 mshMIGPerform + 199
14  com.apple.CoreFoundation      	0x00007fff99259c79 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
15  com.apple.CoreFoundation      	0x00007fff99259beb __CFRunLoopDoSource1 + 475
16  com.apple.CoreFoundation      	0x00007fff9924b767 __CFRunLoopRun + 2375
17  com.apple.CoreFoundation      	0x00007fff9924abd8 CFRunLoopRunSpecific + 296
18  com.apple.HIToolbox           	0x00007fff9695d56f RunCurrentEventLoopInMode + 235
19  com.apple.HIToolbox           	0x00007fff9695d2ea ReceiveNextEventCommon + 431
20  com.apple.HIToolbox           	0x00007fff9695d12b _BlockUntilNextEventMatchingListInModeWithFilter + 71
21  com.apple.AppKit              	0x00007fff95a489bb _DPSNextEvent + 978
22  com.apple.AppKit              	0x00007fff95a47f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
23  libqcocoa.dylib               	0x000000010717b29d QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2093
24  org.qt-project.QtCore         	0x0000000104b0337d QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 381
25  org.qt-project.QtWidgets      	0x0000000103e6c192 QDialog::exec() + 514

I updated methods from signals-slots mechanism to QEvent system. Unfortunately this didn’t help as well. Next attempt was QTimer usage instead of QEvent or signal-slot to simulate real click. But also without any success.

0   org.qt-project.QtWidgets      	0x000000011112f62e QTreeModel::data(QModelIndex const&, int) const + 46
1   org.qt-project.QtWidgets      	0x00000001110aa7bb QAccessibleTableCell::state() const + 347
2   libqcocoa.dylib               	0x00000001143913aa QCocoaAccessible::hasValueAttribute(QAccessibleInterface*) + 58
3   libqcocoa.dylib               	0x000000011438df7e -[QMacAccessibilityElement accessibilityAttributeNames] + 398
4   com.apple.AppKit              	0x00007fff95dea26e NSAccessibilityEntryPointAttributeNames + 115
5   com.apple.AppKit              	0x00007fff95e275af -[NSObject(NSAccessibilityInternal) _accessibilityAttributeNamesClientError:] + 56

With a lot of luck I finally found the reason for the crash. It’s caused by erasing a property tree (and inner QTreeWidget) together with an active focus on this widget. Unfortunately I’m not able to fix it in the QtCore because according to callstack there is only some QModelIndex manipulation without any sight of what’s going wrong.

2015-05-18_0853

The effective solution how to fix this wrong behaviour is to temporally set focus to another widget (or parent), clear the tree and set focus back to property tree. Unfortunately this solution doesn’t work. Check part II of this article for better solution

  QWidget* pObject = qobject_cast<QWidget*>(m_propertyBrowser->parent());
  if (pObject!=NULL);
    pObject->setFocus();
	m_propertyBrowser->clear();
  m_propertyBrowser->setFocus();

If anyone know how to fix that, I will be glad for any info.

WordPress upgrade

Leave a comment

Error message:

wordpress update Could not create directory
This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php

Solution:

#set persmissions for writing to all
find -type d -print0 | xargs -0 chmod 777
find -type f -print0 | xargs -0 chmod 666

#revert back
find -type d -print0 | xargs -0 sudo chown deploy
find -type f -print0 | xargs -0 sudo chown deploy

find -type d -print0 | xargs -0 chmod 755
find -type f -print0 | xargs -0 chmod 664

#set permissions to correct user
sudo chown deploy ./wp-includes/js/tinymce/plugins/wpemoji/*

Additional links

OS X codesign failed: bundle format is ambiguous (could be app or framework)

4 comments

This error can be caused by many things but I know about one more which I didn’t find anywhere else ;-).

In case you compile and deploy your app by using qtmacdeploy and sign your application immediately, everything will probably works fine. The problem occurs, when you need to copy your application to different location (for example during dmg building). In such cases, this error can occur:

bundle format is ambiguous (could be app or framework)

Althought codesign is executed as always, singing isn’t successful:

codesign --deep --force --verbose --sign "$SIGNNAME" ./Skipper.app
/path/Skipper.app/Contents/Frameworks/QtCore.framework: bundle format is ambiguous (could be app or framework)

The problem is, that during the copy it’s necessary to keep all symbolic links inside frameworks. Without this, singing will fail.

So instead of 

cp -r ./Source ./Destination

it’s necessary to use

cp -R ./Source ./Destination

QDialog::reject can be invoked multiple times

Leave a comment

When user use ESC to close the dialog and press it very quickly two or more times in a row, QDialog::reject can be invoked also multiple times.

This is very dangerous and unpredictable because in case your reject will contain some one-time-execute routine the application will start crashing.

The only solution I found is to add these routines to QDialog destructor instead of to reject/accept.

Keyboard and mouse recording tools

Leave a comment

OS X

How to update gcc to 4.8.1 on any ubuntu

Leave a comment

Everything is perfectly explained in this post:

http://ubuntuhandbook.org/index.php/2013/08/install-gcc-4-8-via-ppa-in-ubuntu-12-04-13-04/

 
List of commands

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update; sudo apt-get install gcc-4.8 g++-4.8
sudo update-alternatives --remove-all gcc 
sudo update-alternatives --remove-all g++
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 20
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 20
sudo update-alternatives --config gcc
sudo update-alternatives --config g++
gcc --version

 

Mac OS – app can’t be opened because the identity of the developer cannot be confirmed.

Leave a comment

Starting with OS X 10.10 existing code signing method doesn’t work. If you have application signed for 10.9 and application works without problems, with 10.10 you will get following error:

2015-02-05_1003

How to verify application sign status from command line:

codesign -dvvv /Applications/APP.app

Executable=/Applications/Skipper.app/Contents/MacOS/Skipper
Identifier=com.skipper.Skipper
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20100 size=239848 flags=0x0(none) hashes=11986+3 location=embedded
Hash type=sha1 size=20
CDHash=98839e7aa72de4105ac5ad8a2612682ba3bca53f
Signature size=4237
Authority=Developer ID Application: Inventic s.r.o. (6BYV46LH6T)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=03 Feb 2015 17:38:21
Info.plist entries=10
TeamIdentifier=not set
Sealed Resources version=1 rules=4 files=44
Internal requirements count=1 size=300

As it’s seems from the verification output, application is correctly signed but OSX doesn’t accept it. Another way how to verify application sign status is via spctl command:

spctl --assess --type execute --verbose Skipper.app/

Skipper.app/: rejected
source=obsolete resource envelope

We have some error at least. Now it’s necessary to find out what is wrong. We can try one more test:

codesign -v Skipper.app/
Skipper.app/: resource envelope is obsolete (version 1 signature)

where we dest little bit more details. All these errors we get only on 10.10 mac, not on 10.9 or older.

After another investigation I found following article. The most important part is:

“Important: For your apps to run on updated versions of OSX they must be signed on OS X version 10.9 or later and thus have a version 2 signature.”

Another post about this topic is in felix-schwarz.org blog.

So ,it’s bad. We need to update our build machine to 10.9 or at least create new “sign machine” and make sure that everything will work as expected.

Additional links