[Qgis-developer] Discussion on browser and file extensions

[Etienne Tourigny]

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
>
>