[Qgis-developer] making QgsMapToolIdentify available to plugins

[Radim Blazek]

On Fri, Feb 8, 2013 at 4:47 PM, Etienne Tourigny
<etourigny.dev at gmail.com> wrote:
> I haven't really followed this, but I assume this does not affect
> existing plugins which use  QgsRasterDataProvider::identify() such as
> e.g. the value tool plugin?

No. Not yet. I am still thinking about some class for identify results
instead of QVariant but I  want to keep it KISS at the same time.
Unfortunately the results may be really varied: double value, list of
feature lists, html, text.

Radim

> regards,
> Etienne
>
> On Thu, Feb 7, 2013 at 6:38 PM, Radim Blazek <radim.blazek at gmail.com> wrote:
>> Hi Denis,
>>
>> On Thu, Feb 7, 2013 at 11:30 AM, Denis Rouzaud <denis.rouzaud at gmail.com> wrote:
>>> Hi Radim,
>>>
>>> I just finished the work thanks to Jef's debugging ability!
>>>
>>> Here is the pull request
>>> https://github.com/qgis/Quantum-GIS/pull/421
>>
>> pushed to master in 4e64d72.
>>
>> Thanks
>> Radim
>>
>>> The identify method now returns directly the IdentifyResults instead of
>>> using a private attribute.
>>> Also, IdentifyResult is now a single struct (no RasterResult and
>>> VectorResult)
>>>
>>> Everything compiles fine and I tested it.
>>> However, could you check that everything is ok regarding to the
>>> rasterChanged?
>>>
>>> Also, could you take care of accepting the pull request?
>>>
>>> Thanks,
>>>
>>> Denis
>>>
>>>
>>>
>>> On 02/07/2013 11:24 AM, Radim Blazek wrote:
>>>
>>> Hi,
>>> sorry, I do not use IRC usually.
>>>
>>> I would like to return to work in identify tool areas next week:
>>>   - copy feature from context menu
>>>   - better tree hierarchy for rasters
>>>   - propagate errors to user - probably just error messages as texts in tree
>>>   - instead of all that signals on format change just listen in action
>>> and then call QgsMapToolIdentify and dialog functions
>>>
>>> Please let me know when you finish your work in identify tool so that
>>> we avoid conflicts.
>>>
>>> Radim
>>>
>>> On Thu, Feb 7, 2013 at 10:04 AM, Denis Rouzaud <denis.rouzaud at gmail.com>
>>> wrote:
>>>
>>> Hi Radim,
>>>
>>> I have already merged the changes to return directly the results.
>>>
>>> I am currently making a single struct for the results. I have a problem with
>>> python files, an error in compilation I am trying to solve for some time now
>>> without any success...
>>> Would you have some time to give me hand?
>>>
>>> Are you on IRC?
>>>
>>> Thanks
>>>
>>> Denis
>>>
>>>
>>>
>>> On 02/06/2013 05:07 PM, Radim Blazek wrote:
>>>
>>> Also, your changes to the raster result structure made me think that we
>>> could use a single struct for both vector and raster result.
>>> It might be easier to look into the results.
>>> Any opinion on this? Nathan?
>>>
>>> I believe, that It would be better to pass results to the dialog in
>>> the original hierarchical structure instead of splitting them to
>>> individual results and then reconstruct the tree searching for the
>>> layer it should go into. For rasters the logical structure may vary
>>> form one level for raster values (I would prefer to put band values
>>> directly into layer item instead of adding additional level "feature")
>>> to four levels for WMS with layer-sublayer-featuretype-feature.
>>>
>>> Maybe some parts of QgsMapToolIdentify::identifyVectorLayer and
>>> QgsMapToolIdentify::identifyRasterLayer, those related to creation the
>>> tree in dialog should better be moved to QgsIdentifyResultsDialog?
>>> I'll possibly add QgsRasterIdentifyResult and the dialog could work
>>> directly with that or to use current QList<QVariant> returned from
>>> raster identify().
>>>
>>> yes,
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer