Bug report #7039

Use message bar for handling bad layers

Added by Nathan Woodrow over 6 years ago. Updated over 5 years ago.

Status:Closed
Priority:High
Assignee:-
Category:GUI
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:16129

Description

The handle bad layers dialog is quite intrusive for users it would be be good to have a message like "Project opened but some layers failed" shown in the message bar. We can still use the dialog to resolve the issues if the user clicks a resolve button on the message bar.

The issue I do see which might need some cleaner handling is the loading of the failed layer. At the current time the project loading process is halted until the user has fixed or removed the layer. To handle this better I think we could show failed layers in a light red with a X for there geometry type icon in the layer list. Once the layers are fixed we can save and reload the project, or even better just reload those layers.

dialog.png (104 KB) Nathan Woodrow, 2014-06-07 07:58 PM

Associated revisions

Revision 15320484
Added by Jürgen Fischer over 5 years ago

improve bad layer handling: make all datasource editable (fixes #7039)

History

#1 Updated by Olivier Dalang over 5 years ago

I very much agree !

The fact that layers which are currently unavailable are deleted upon opening a project is a big annoyance : what if the layer is on a (currently) unavailable network drive ?

Correcting this would also be the perfect occasion to add a "relink" action to the context menu and the layer properties, which would allow to change the source of a layer without changing anything else.

#2 Updated by marisn - over 5 years ago

Oliver, you are talking about #8718
It's a different issue and it isn't strictly dependant on this one (although both of them could be solved by a redesign of bad layer handling).
Olivier Dalang wrote:

I very much agree !

The fact that layers which are currently unavailable are deleted upon opening a project is a big annoyance : what if the layer is on a (currently) unavailable network drive ?

Correcting this would also be the perfect occasion to add a "relink" action to the context menu and the layer properties, which would allow to change the source of a layer without changing anything else.

#3 Updated by Olivier Dalang over 5 years ago

Hi !

It seems this has been done for 2.2 already...

But IMO, the current behavior is not satisfying, and even DANGEROUS !

Simple scenario : I open a huge project, and go take a nap while it loads. I come back, and don't see the message in the bar, which not only is quite subtle, but also vanishes after a few seconds. I work happily on my project, and save. BAM ! I just lost some layers with no way to recover them !

Currently, I would flag this as blocker, since it leads easily to data corruption.

Either we must move back to previous solution, or implement #8718

#4 Updated by Olivier Dalang over 5 years ago

Can we flag this as a blocker ? (I almost lost some layers again)
Or is it happening only to me ?

#5 Updated by Regis Haubourg over 5 years ago

Agreed with Olivier, we should mark this as a blocker until we have a behaviour that do not allow layer destruction unless user really wants it.
I suggest we keep bad layers in layer registry, with a flag for it like ESRI does (refactoring is under work, why not add this to the list). We should be able to correct bad layers on project opening OR a posterio in layer properties.
Cheers,
R2gis

#6 Updated by Michael Douchin over 5 years ago

+1 for flagging this as a blocker.

#7 Updated by Matthias Kuhn over 5 years ago

  • Priority changed from Normal to Severe/Regression

+1

I'd rather have an intrusive dialog for something heavy as this than a tiny message. The timeout does really not make sense here (probably seldom makes sense for warnings and almost never for errors).
Bad layers is something the user needs to care about. As long as it's not possible to fix a layer a posterio (#8718), the user should be forced to make a decision about what to do.

#8 Updated by Nathan Woodrow over 5 years ago

I'm confused, the dialog is still there

Is your data in PostGIS by any chance?

#9 Updated by Martin Dobias over 5 years ago

  • Priority changed from Severe/Regression to High

I don't think there is a scope to get this into 2.4 - I would classify this as a new feature since it would require non-trivial changes to the code. I agree the current behaviour is not nice, but I can't see a reason why it should be suddenly a blocker (the loading worked liked this for ages).

#10 Updated by Olivier Dalang over 5 years ago

Nathan Woodrow wrote:

Is your data in PostGIS by any chance?

Hi ! Yes it seems to happen with PostGIS layers, not with shapefiles... I didn't test with other providers yet.

Martin wrote:

I don't think there is a scope to get this into 2.4 - I would classify this as a new feature since it would require non-trivial changes to the code. I agree the current behaviour is not nice, but I can't see a reason why it should be suddenly a blocker (the loading worked liked this for ages).

Getting a good solution to this problem (ie be able to load bad layer) is indeed not trivial, and there's already a feature request for this : #8718
But displaying the handle bad layer dialog instead of having the temporary message in the message bar shouldn't be hard ?

About the blocker flag, it's up to you, but I thought bugs leading to potential data loss (here : loss of layers) should be flagged as blockers.

#11 Updated by Martin Dobias over 5 years ago

Olivier Dalang wrote:

Nathan Woodrow wrote:

Is your data in PostGIS by any chance?

Hi ! Yes it seems to happen with PostGIS layers, not with shapefiles... I didn't test with other providers yet.

Ok now I understand what is going on - the "handle bad layers" dialog is available only for OGR, spatialite and delimitedtext layers. Other data sources are considered as "not fixable" because the dialog is only able to handle file-based sources.

We could at least easily remove the timeout of the message in the message bar, so it does not happen that you miss that information.

#12 Updated by Nathan Woodrow over 5 years ago

I was just going to change it so that non file based layers could just be hand edited. A lot of times it's just the connection string that needs to be updated. Shouldn't be too hard to do if you want me to take a look.

#13 Updated by Jürgen Fischer over 5 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF