Crash when changing font and color in Style manager on OS X

[rcline]

I am trying to use a font as a marker symbol in Style manager. Set Symbol layer type to Font marker. QGIS often crash with a bus error. Sometimes it will crash when I click on a font symbol in the scroll area and then select a different symbol. Sometimes it will crash when I click the font popup. It is rather inconsistent in what triggers the crash, but if i make several changes it will crash. When the program is re-lanched after a crash it is more likely to crash again when trying to set a font symbol.

This is using both 1.6 and 1.7 r1508m from the KyngChaos site. I tested on windows and I do not have the problem.

[kyngchaos]

This may be related to another font symbol issue I'm seeing - changing some properties of a symbol cause the main layer properties dialog to beep at me when I try to click OK button. ie:

1. edit symbol color in symbol selector, OK
2. back in the layer properties, try to click OK - beep

If I edit the color and save a style, then OK the symbol, then the layer properties OK will work, but QGIS crashes.

If I:

1. edit the symbol color
2. save it as a style, then cancel the symbol
3. edit the symbol again
4. select the saved style
5. OK the symbol, OK the layer properties

no crash, and my symbol is set.

I wonder if it has something to do with Cocoa native widgets, like the color picker. Since I figured out that Qt 4.7.1 fixes the ignore native dialog bug for font selection, so it works as well as it can now with the Qt font selector (#1752), maybe the color widget has a similar ignore flag...

[kyngchaos]

Yep, that got the color picker crash fixed (QColorDialog::DontUseNativeDialog). Partial fix in r15376. I'll get the rest in the morning.

[jctull]

This works, but the sacrifice in losing what the native color brings to the application is not small. The same is true for the font tool. Are these qt bugs or QGIS bugs? Thanks for finding a workaround, although all this qt-ness and lack of OS compliance is bothersome.

[kyngchaos]

I think it's an acceptable sacrifice to get it working. I found a few Qt bugs reported about this in 4.6, but the devs can't reproduce it.

[kyngchaos]

I think I'll leave it at r15376. I tried some of the other places where the color picker is used and the Mac color picker didn't cause any crashes. Even the old symbology doesn't crash with the Mac color picker (I changed that, but I'll leave since I think old symbology will be dropped soon?).

Maybe there is something wrong in how the new symbology is calling getcolor()?

[kyngchaos]

duplicate of #2746 (closing that one).

I didn't try a color ramp. I'll check it out and do the workaround if needed.

[kyngchaos]

OK, went through all the color pickers in the map view (skipped the composer for now), and what I found is that generally the native Mac color picker works in the old symbology and not the new symbology. Though there are a couple places in the new symbology where it does work. It also works in layer properties other than symbology, project properties and QGIS preferences.

Specifically, in the new (ignoring the r15376 workarounds):

• The color picker directly off the layer properties window to set fill/line color works, and the color 1 and color 2 pickers in the gradient dialog work.

• Any color pickers that are one jump away from the layer properties window (like symbol properties -> color) or another dialog window (like layer properties for point layer ->change symbol -> color), will cause the previous dialog to refuse clicks on the OK/Cancel buttons (it beeps at me), though ESC works to cancel (return/enter does not do OK though).

• The add color stop picker locks up the color ramp dialog, and the processor is running full speed. The only way to get out of this one is to force quit QGIS.

[telwertowski]

I think this is a qt bug and it has something to do with how qt chains windows together. The Cocoa qt implementation is hiding and keeping the color picker for reuse rather than deleting and creating it anew for each use. The beeping unresponsive dialog is probably due to the invisible color picker retaining control and confusing the chain of command.

I tried setting parent to both null and actual parent for the full chain. Both fail when the color picker is more than one dialog away. Is there somewhere in the old symbology where a working picker is deeper than window > dialog > picker?

If there is a workaround, I suspect it involves understanding the Cocoa qt internal window chaining code so that something can be reset (if it's publicly accessible) after each call. The non-native picker works because it gets deleted and the command chain is appropriately updated upon deletion.

[kyngchaos]

Good explanation, makes sense.

I couldn't find a place in the old symbology deeper than 1 level.

On the new symbology side, the gradient color ramp dialog is a couple levels deep. The color 1 and color 2 pickers work, though the add stop picker causes a hang (instead of the OK/cancel problem). This looks different as far as the "chain" goes:

1. layer properties window
2. color ramp type dialog
3. gradient color ramp - after the color ramp type dialog is removed
4. color picker

[telwertowski]

The hang is caused by QColorDialog::getColor doing something that QInputDialog::getInt doesn't expect. Reversed the call order (Mac Cocoa only, works in Carbon) as a workaround in r15855 so that stops can be added by Mac users.

[telwertowski]

A Qt bug report ​QTBUG-14889 has already been filed on the nested QColorDialog problem. I added a vote for this bug and attached an example to reproduce it. The bug was submitted 10/31/10 and has not been worked on.

[kyngchaos]

So does this mean we absolutely need to use the Qt color picker workaround? (And in the future, tweak the qt version test when they fix it.)

Then, I was thinking we should wrap the color picker call so there will be only 1 block of #ifdefs to manage. Something like a qgisColorDialog() function.

[rcline]

In testing r15856 the ability to add stops is fixed. However, it introduces a new problem on OS X when editing an existing color ramp. When the program returns to the Style Manager dialog, none of the buttons work when clicked. It just beeps like one is not clicking in the active dialog. The escape key will close the Style Manager dialog and the changes are preserved. This occurs when editing color1, color2, or modifying stops.

I had modified the color ramp routine to use the Qt color ramp using Williams other changes as a template and both the Add and Edit worked.

[kyngchaos]

My guess is that while the freeze is fixed when adding color stops, it still has the problem of color pickers being one too many levels deep in dialogs.

[telwertowski]

Further investigation reveals that the Cocoa implementation of QColorDialog::getColor is unstable because the Mac Cocoa color picker does not have OK and Cancel buttons and Qt is hacking the dialog to add them. The Cocoa color picker is intended to be used with a color well where the well changes color as the picker is clicked. Buttons therefore aren't needed.

Qt provides a NoButtons option which will use an unhacked dialog. It works but it may be unintuitive that closing the dialog sets the color. A better long term fix may be to implement a QgsColorWell which changes as the color dialog is clicked. However the following variant will show a native buttonless Mac color picker and not block other dialogs.

#ifdef QT_MAC_USE_COCOA

QColorDialog colorDialog( this ); colorDialog.setOption( QColorDialog::NoButtons ); colorDialog.exec(); QColor color = colorDialog.currentColor();

#else

QColor color = QColorDialog::getColor( QColor(), this );

#endif

Is a buttonless native dialog preferable to the Qt color dialog?

[jctull]

Good sleuthing, Tom. I would answer "yes" to you question in your last comment. This will be consistent with its use, generally, across OS X.

[marsofearth]

QGIS 1.6.0-2 for Snow Leopard
QGIS 1.7 r15814 for Snow Leopard (64bit Intel Qt 4.7 Cocoa)

Same issue. Any change to the symbology of a layer hard crashes QGIS on Apply/OK.

No current version available for our Macs that will allow symbology changes.

[kyngchaos]

What exactly are you doing? There are a few known crashes and lockups, as mentioned in this bug report. 1.6 does have random crashes changing symbology, but they've been dealt with or are being worked on. 1.7-r15814 should work in many cases.

With the latest workaround for the gradient color stops, the latest development source (I haven't packaged a new dev build yet) doesn't have any problems so far (limited testing).

[marsofearth]

I do not believe I am doing anything special (from any other GIS I use).

I import a shapefile (any shapefile on my local Mac system). open up the Layers Properties, "click" the Style 'tab' Change the color/options and then click Apply OR OK

Hard drive works a bit then QGIS hard crashes<<

I have never been able to use Symbology on QGIS 1.6 and up on any of our Macs with exception of one r#build that I seem to have miss placed or updated.

The crashing has never been random for us, seems to work like clockwork.

[marsofearth]

So I decided to try building QGIS from trunk and give that a try. Installed Qt 4.7.3 and all the other dependancies listed here on the QGIS Wiki: ​http://is.gd/AdHLiT

Ended up building the latest version of QGIS in trunk: 1.7.0 (1.7.0-Wroclaw (15870)) Build went fine.

No problems opening shapefiles, spatiallite, postgis, etc.

However, same issue when changing symbology of a layer. QGIS hard crashes.

Sometimes it crashes on the first time setting symbology, sometimes on the 3rd or 4th time, but early enough.

This issue is actually a little depressing for me because I love using QGIS, but with out symbology I do find it rather limiting.

[kyngchaos]

I got a crash once. But later attempts failed to crash after 10+ symbology changes.

Note, SVN is frozen. The rest of the color picker workarounds are in the new GIT repository.

Can you reproduce the crashing on a simple public data set? Natural Earth is a good one.

[kyngchaos]

A recent crash - after 4 changes (returning to layout each time)

[marsofearth]

Sure!

I loaded up the Natural Earth 1:10m Culture Vectors - ​http://is.gd/3hBddi Tested "10m_admin_0_scale_ranks.shp".

First Symbol change of only the fill worked no crash. Second symbol change to remove outline stroke crashed QGIS.

I did find that deleting qgis.plist helped prevent crashing sometimes for a few more symbol changes.

Okay now to figure out GIT I suppose... I have tested variations of saving symbols and loading symbols. Sometimes that worked, usually a 50/50 chance of Hard Crashing.

[marsofearth]

Latest QGIS Symbol change crash using Natural Earth 1:10m Cultural Vectors, 10m_admin_0_scale_ranks.shp

[kyngchaos]

I see from your crash report that you are not bundling Qt. I've had crashing problems in the past when QGIS runs with external Qt frameworks because of Qt plugin issues.

Add to your cmake configure:

-D QGIS_MACAPP_BUNDLE=1

It's part of my standard build, so I didn't think to check on this for recent Qt versions, but I should probably make this the default.

[marsofearth]

Downloaded qgis-Quantum-GIS-c724ce5.tar.gz from QGIS Git Hub

Added to cmake configure

-D QGIS_MACAPP_BUNDLE=1

Used Natural Earth polygon layers to test. Managed 3 symbology changes (fill, outline, fill) On the 4th symbology change (outline) QGIS crashed

[marsofearth]

Latest QGIS Crash (Natural Earth)