[Qgis-developer] Using app MessageBar from providers ?

Even Rouault even.rouault at spatialys.com
Mon Apr 11 01:51:36 PDT 2016 

Le lundi 11 avril 2016 07:19:17, Denis Rouzaud a écrit :
> Hi,
> 
> That sounds a bit weird to me.
> 
> Shouldn't it be the application which decide (filter) what to show from
> core log messages?
> Couldn't we use some error levels or tags to achieve this?

QgsMessageLog has the following error levels : INFO, WARNING, CRITICAL. (I couldn't really find a description of the semantics behind by the way)
QgsMessageBar has the same + SUCCESS.
The default level of QgsMessageLog::logMessage() is WARNING, and greping in the source shows that in most cases, it is let to the default.

Tags (as defined in QgsMessageLog) indicate the component from which the messages comes from, so I don't think they can be used for redirect to message bar.

CRITICAL is very rarely used, as shown by the following grep in src/ , so if we don't want
to have an explicit displayMessage argument, potentially the app could decide to redirect only CRITICAL messages to the MessageBar ?

$ grep -r QgsMessageLog::CRITICAL ../src/ | grep -v "src/server"
../src/core/qgsproject.cpp:      QgsMessageLog::logMessage( errorString, QString::null, QgsMessageLog::CRITICAL );
../src/core/qgsgml.cpp:        QgsMessageLog::CRITICAL
../src/core/qgsgml.cpp:      QgsMessageLog::CRITICAL
../src/providers/ogr/qgsogrprovider.cpp:      QgsMessageLog::logMessage( tr( "Possible corruption after REPACK detected. %1 still exists. This may point to a permission or locking problem of the original 
DBF." ).arg( packedDbf ), tr( "OGR" ), QgsMessageLog::CRITICAL );
../src/providers/ogr/qgsogrprovider.cpp:          QgsMessageLog::logMessage( tr( "Original layer could not be reopened." ), tr( "OGR" ), QgsMessageLog::CRITICAL );
../src/providers/ogr/qgsogrprovider.cpp:        QgsMessageLog::logMessage( tr( "Original datasource could not be reopened." ), tr( "OGR" ), QgsMessageLog::CRITICAL );

> 
> That just doesn't sound like a good API to have core function with
> displayMessage as argument.
> 
> But maybe I'm missing a part of the picture.

The precise use case is when the download of a WFS layer fails for some reason (network timeout, invalid server response),
it is not always obvious for the user to realize so. A prominent message saying that
the layer content is truncated would be helpful so he can decide for example to reload
the layer, etc...

> 
> Denis
> 
> On 04/11/2016 01:33 AM, Nathan Woodrow wrote:
> > Hey Even,
> > 
> > I think this solution is fine. The other option I thought of in the
> > past was to have some kind of signal on the provider that gets passed
> > up and connected at a higher level.
> > Using QgsMessageLog is a good idea as it's generic and can be used by
> > everyone.
> > 
> > Regards,
> > 
> > On Sun, Apr 10, 2016 at 11:25 PM, Even Rouault
> > 
> > <even.rouault at spatialys.com <mailto:even.rouault at spatialys.com>> wrote:
> >     Le dimanche 10 avril 2016 15:21:14, Luigi Pirelli a écrit :
> >     > a provider does not need necessarily an iface where to send GUI
> >     > messages (e.g pyqgis scripts).... IMHO is one reason.
> >     
> >     Yes I know. Hence my proposal. The provider would continue using
> >     the message
> >     log interface, so with its current behaviour still preserved, but
> >     with an
> >     extra hint when the message is also aimed at being prominently
> >     displayed, if
> >     possible. In the case qgis_app is started it would listen for that
> >     and redirect the message to the message bar too.
> >     
> >     > regards
> >     > Luigi Pirelli
> >     
> >     *********************************************************************
> >     ******
> >     
> >     > *********************** * Boundless QGIS Support/Development:
> >     lpirelli AT
> >     
> >     > boundlessgeo DOT com * LinkedIn:
> >     https://www.linkedin.com/in/luigipirelli
> >     
> >     > * Stackexchange:
> >     http://gis.stackexchange.com/users/19667/luigi-pirelli
> >     
> >     > * GitHub: https://github.com/luipir
> >     > * Mastering QGIS:
> >     > https://www.packtpub.com/application-development/mastering-qgis
> >     
> >     *********************************************************************
> >     ******
> >     
> >     > ***********************
> >     > 
> >     > On 10 April 2016 at 15:12, Even Rouault
> >     
> >     <even.rouault at spatialys.com <mailto:even.rouault at spatialys.com>>
> >     
> >     wrote:
> >     > > Hi,
> >     > > 
> >     > > For the WFS provider, I'd like some messages, like a partial
> >     
> >     feature
> >     
> >     > > download, to be emitted in a more prominent way than just in
> >     
> >     the message
> >     
> >     > > log. The MessageBar would be appropriate for that, but from
> >     
> >     what I can
> >     
> >     > > see, it is not currently possible for a provider to use it. A
> >     
> >     search in
> >     
> >     > > src/providers shows that the same need was at least
> >     
> >     encountered once in
> >     
> >     > > the GRASS provider but the code is commented out as the
> >     
> >     provider doesn't
> >     
> >     > > link against qgis_app.
> >     > > 
> >     > > So unless there's a good reason for a provider not to be able
> >     
> >     to use the
> >     
> >     > > message bar, I was thinking to the following mechanism to
> >     
> >     implement it :
> >     > > - QgsMessageLog would be extended to have 2 extra arguments bool
> >     > > displayInMessagerBar = false, int duration = 0 in logMessage() /
> >     > > messageReceived()
> >     > > - QgisApp would connect on messageReceived() and when the
> >     
> >     boolean is set,
> >     
> >     > > it would push the message to the main message bar.
> >     > > 
> >     > > Any thoughts ?
> >     > > 
> >     > > Even
> >     > > 
> >     > > --
> >     > > Spatialys - Geospatial professional services
> >     > > http://www.spatialys.com
> >     > > _______________________________________________
> >     > > Qgis-developer mailing list
> >     > > Qgis-developer at lists.osgeo.org
> >     
> >     <mailto:Qgis-developer at lists.osgeo.org>
> >     
> >     > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >     
> >     > > Unsubscribe:
> >     http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >     
> >     --
> >     Spatialys - Geospatial professional services
> >     http://www.spatialys.com
> >     _______________________________________________
> >     Qgis-developer mailing list
> >     Qgis-developer at lists.osgeo.org
> >     <mailto:Qgis-developer at lists.osgeo.org> List info:
> >     http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe:
> >     http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > 
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com

More information about the Qgis-developer mailing list