[Qgis-developer] Discussion on browser and file extensions

[Etienne Tourigny]

Attached the file in the relevant ticket:
http://hub.qgis.org/attachments/4473/mock1.jpg

On Tue, May 22, 2012 at 3:15 PM, Etienne Tourigny
<etourigny.dev at gmail.com> wrote:
> What should an additional column include, in the case of physical files?
>
> 1) extension (e.g. tiff / shp)
> 2) gdal/ogr driver name (e.g. GTiff / "ESRI Shapefile")
> 3) just the provider key? (.e.g. gdal / ogr)
>
> For others the provider key (postgres, spatialite, etc) should be
> sufficient I think.
>
> Attaching a propotype with this idea, using 2) with (V) or (R)  /
> (ogr) or (gdal) to differentiate vector or raster
>
> Etienne
>
> On Tue, May 22, 2012 at 1:23 PM, kimaidou <kimaidou at gmail.com> wrote:
>> Hi all
>>
>> +1 for optionnal additionnal column, as it will be consistent for all use
>> cases, and leave the choice to the user.
>>
>> Michael
>>
>>
>> 2012/5/22 Etienne Tourigny <etourigny.dev at gmail.com>
>>>
>>> On Tue, May 22, 2012 at 4:10 AM, Giovanni Manghi
>>> <giovanni.manghi at faunalia.pt> wrote:
>>> > Hi,
>>> >
>>> >> I think the discussion on http://hub.qgis.org/issues/5621 deserves more
>>> >> general
>>> >> discussion on this ML. Opinions? Could reporters make a short resume
>>> >> for us?
>>> >
>>>
>>> I guess the consesus in the issue is that the browser should display
>>> extension names, and that there should be an *optional* indication in
>>> the legends layer as to the provenance.
>>>
>>> However, any other display/tool (drop to DB manager and PG/spatialite
>>> in browser) should not use the extension.
>>>
>>> It was also mentioned that drop from browser should be consistent with
>>> "Add Layers" dialog (and also from the commandline). It is not
>>> currently in the case of vector layers.
>>>
>>> These alternatives have been presented, perhaps needing a user option:
>>>
>>> 1) Always adding the extension and stripping it where necessary
>>> 2) Never adding the extension and adding it in the legend
>>> 3) Never adding the extension
>>> 4) the legend could have an optional (for experts) additional column
>>> with data source format.
>>>
>>> 1) and 2) deal more with a technical aspect in that the display name
>>> is set in QgsDataItem (by the QgsDirectoryItem in the browser case),
>>> so selectively changing that name based on the destination requires
>>> some consideration on the source (probably the uri + provider would be
>>> sufficient).
>>>
>>> Consensus on having the extension in the browser means that the
>>> QgsDataItem name must have the extension, but this must be removed
>>> when doing most D&D operations, which means more complexity.
>>> The alternative is to add the extension in the Browser (and possibly
>>> legend) based on the URI or perhaps a new member variable.
>>>
>>> Radim's solution to have an additional column specifying the
>>> datasource format (TIF, SHP, PG, etc.) is interesting, but might add
>>> clutter?
>>>
>>>
>>>
>>> >
>>> > I originally asked to avoid leave the extension while dragging and
>>> > dropping from the browser, mainly because when dropping into DB Manager
>>> > it is annoying to have to manually remove that ".shp" (example) from the
>>> > suggested table name.
>>> >
>>> > On the other hand seeing the datatype in the TOC is useful and a thing
>>> > that many users have asked in the past.
>>> >
>>> > Real life projects tend to be large, with many layers from many
>>> > datasources/types. Vectors are not just vectors, and rasters are not
>>> > just rasters: there are vectors that cannot be edited (lack of
>>> > permission or because gdal does not allow it), layers that cannot be
>>> > used as input by standard qgis tools (GRASS rasters), etc.
>>> >
>>> > Sometimes the users have even layers with the same name but of different
>>> > type.
>>> >
>>> > So, seeing the format in the TOC is a step forward in usability, and in
>>> > the ticket were suggested a few ways to get it.
>>> >
>>> > cheers!
>>> >
>>> > -- Giovanni --
>>> >
>>> >
>>> > _______________________________________________
>>> > Qgis-developer mailing list
>>> > Qgis-developer at lists.osgeo.org
>>> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>