QGIS » QGIS Application

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
 1. 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
 1. save it as a style, then cancel the symbol
 1. edit the symbol again
 1. select the saved style
 1. 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...

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

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.

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.

I think I'll leave it at 3ebf1bcf (SVN r15377). 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()?

duplicate of #2746 (closing that one).

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

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 3ebf1bcf (SVN r15377) 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.

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.

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
 1. color ramp type dialog
 1. gradient color ramp - after the color ramp type dialog is removed
 1. color picker

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 3e74c57f (SVN r15856) so that stops can be added by Mac users.

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.

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.

In testing 2b9c8377 (SVN r15857) 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.

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.

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?

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.

QGIS 1.6.0-2 for Snow Leopard

QGIS 1.7 171bed79 (SVN r15815) 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.

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-171bed79 (SVN r15815) 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).

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.

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.

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.

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.plis_t 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.

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.

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

Tom Elwertowski wrote:

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?

Hello ! This is my first time here, I'm not english native speaker but I'm willing to enter this QGIS comunity.

I have the same problem with Mac and the symbology. I've been trying many things to solve this bug (I'm absolutely not a hacker) by puting Tom's code everywhere I can !! Could you please specify where does the fix for Qt must go ??? Thanke you.

I am having this same problem. It seems to be part of a larger issue in which any changes to the symbology of a layer will crash QGIS on OS X. It makes QGIS essentially unusable on OS X. Is there any progress on this ticket? Why would this be low priority if it causes the application to crash?

I would like to use QGIS on OS X, and currently it is useless due to the underlying issue, of not being able to change symbology on OS X. What can I do to help?

is this confirmed on Mac?

With changes to use qt dialogs rather than native cocoa dialogs, the problem seems to be gone. I am going to try and revert the changes to use native dialogs and see if the bug has been squashed in qt code. I'm using qt-4.8.2, so maybe it has been fixed in their code. I will report back if I can successfully use native cocoa dialogs as they would be much preferable to the qt dialogs in terms of UI consistency.

was this patch applied? can the ticket be closed?

If was not applied I suggest to make a pull request on github, this way it has more chances to be reviwed and applied.

please leave feedback.

what is the status of this issue on the latest master?

Looks like the symbology overhaul for 2.0 includes native OS X color pickers with Cancel/OK buttons. All seems to work - the layer properties dialog only has 1 level of dialogs now, so that won't cause trouble, and adding color stops to a gradient didn't freeze QGIS.

I'd say this bug is squashed.