QGIS » QGIS Application

Hi Andreas,

Can not confirm on Mac.

Does this happen consistently for the projects that do crash?

Try this: in Options->General set the 'Open project on launch' to 'Most recent' and apply settings; then, open the problem project manually. On next launch (just launching app, not from file) QGIS should auto-open the most recent project. Please let me know if it crashes then.

You can also just set the 'Open project on launch' to 'Specific' and directly specify the project's path.

If it continues to crash (in either setup), subsequent launches should show a red (critical) message bar indicating that the auto-opening project could not be previously opened, and the Options->General set the 'Open project on launch' will be reset to 'New'.

This will help be determine if it the problem stems from the code I introduced there, or possibly something wrong in the new Composer GUI updates.

Also, do you already have 'Open project on launch' set to something other than New, then loading a project from the command line?

Larry, the code crashing is not being compiled on Mac.

lines 4790 to 4793 in qgisapp.cpp

#ifndef Q_OS_MACX
composer->setWindowState( Qt::WindowMinimized );
composer->show();
#endif

Matthias Kuhn wrote:

Larry, the code crashing is not being compiled on Mac.

lines 4790 to 4793 in qgisapp.cpp

#ifndef Q_OS_MACX
composer->setWindowState( Qt::WindowMinimized );
composer->show();
#endif

Ok, I updated that code and tested on Ubuntu and Win 7, but maybe my test composers wern't complicated enough (or something like that). Could you try "reverting that change in the commit":commit:160a5c47273a8052c7155e451961be379f63264e#src/app/qgisapp.cpp, and see if that helps?

No. Still crashes...

Matthias Kuhn wrote:

No. Still crashes...

And when you comment those lines out?

No crash for me here on KDE / Kubuntu 12.04

The problem is related to svg symbol loading ( 34f3d50099c7e90e614fc68a5ebe37c9bd04cae0 )
details have been discussed on #qgis and Larry is currently working on a patch

No need for further investigation. Sorry for not updating this topic.

Ok, I think this may work (I can't get anything to crash on launch with project from command line, so... ):

https://github.com/dakcarto/Quantum-GIS/tree/fix_7458_2

Please test. It's not ideal. The repetitive loading of the same SVG previews for every composer picture is what is slowing things down (and the need for the busy indicator), especially on Mac. The SVG preview list widget should be moved to model-view setup or a shared cache. (Don't have time to do that this week, myself.)

This fix works here (just gave it a short test and no crash).

Well, I could but it is not a good solution, more a band-aid, loading all SVG previews for all composer picture items (can be very slow if there are a lot) before the composer is shown.

Recently I pulled the SVG selector for symbology out into its own class to use in the label background settings, which, if edited further will offer a much better and basically permanent fix.

Here is what needs done to the class:

• Allow passing in already constructed QgsSvgSelectorListModel and QgsSvgSelectorGroupsModel. This will allow a base SVG and groups model that can be constructed in QgisApp or QgsComposer, independent of the views.

• Add a get/setter for retrieving/adding SVG search paths. This way, any instance of the views can offer the ability to edit the search paths.

• Add a parameter for construction that builds the widget in code instead (currently a .ui file), offering the option for horizontal (side-by-side) or vertical (groups above SVG listing) generation of the layout. This way the widget can be dropped in and easily configured for horizontal- or vertical-aspect-prominent dialogs.

Shouldn't take too long, and could possibly be done under the concept of fixing this bad bug. Unfortunately, I don't have the time prior to 2.0.

Then, here's what can be done in the Print Composer:

• Add the widget to composer's picture item panel, setting its orientation to vertical (groups above SVG listing).

• On construction of the composer, the SVG selector widget for each composer picture item added to the QGraphicsScene does not need to load all of the SVG previews, just reference the existing model. This should be a much better model-view approach and not take long to load.

• Composer uses a set of special SVG paths in addition to the base search paths. This could be continued by utilizing the get/setter for the search paths. However, I think it is odd that there are search paths only available in the composer, and that the functionality be dropped in favor of only the paths that can be defined in the Options dialog, or added to the base search paths, if it is not.

Additionally, the SVG selector widget could have simple + and - buttons (or just one that says 'search paths', etc.) that pops up the SVG paths editor. All of this could be tied into remote repositories for SVGs as well, etc. like gradients in symbology.

Also, the SVG selector widget needs 'backported' to the symbology code, which I did not edit, so changes to the selector are available there as well. And, if the models are part of QgisApp, then the new label backgrounds SVG selector can be quickly adapted to use them as well.

Here is a dump-file from a crash when loading one of my projects by double-clicking the file in Windows explorer.

Hi Andreas,

In the labeling gui redesign branch I'm about to finish (today or tomorrow), I have reworked QgsSvgSelectorWidget to be a standalone SVG selector dialog. This aided in getting a data defined SVG setup for label backgrounds.

While this doesn't implement the better 'base SVG and groups model' idea noted above, it does offer a solid solution for this issue for 2.0. However, it does mean that the SVG previews will not be shown as they are now. There will be a line edit for SVG file path (already there), then a button to pop up the SVG selector. This essentially bypasses the issue, since the SVG previews are only ever loaded on user's interactive choice.

The SVG selector dialog does have signals available, so it is still possible to have a live update of the picture on the Composer canvas upon just selecting an SVG preview in the detached dialog. It does introduce an initial extra click to open the dialog and another to close it.

Hi Larry,

This sounds fine. I think it is not problem that there is an extra step for selecting the SVG symbol. Selecting an SVG for a symbol definition or composer is not a step that is done very often.

Would this also mean that the project loading would be a bit faster? I see that a lot of time is spent going through the SVG symbol library after the project loaded.

Thank you a lot for your work! Looking forward to see this fixed.

Andreas

I tried with the current master (which should have your revision you mention above, Larry?) and QGIS still crashes on program load.

Hi Andreas,

The fix is not pushed to master yet. I should be able to do that sometime this week. Sorry for the delay.

Hi Larry,

This looks very good.

I tested around 10 projects and do not get crashes anymore. The projects also load faster as the SVG preview generation is now postponed until the symbols are really needed.

And the annoying blinking in the SVG preview panel of the print composer is now gone.

Very nice - thank you for your work!

From my point of view we can close this bug.

Andreas