Hi Etienne,
On Sun, May 27, 2012 at 11:37 PM, Etienne Tourigny
wrote:
> Can you look at this and if possible commit it before 1.8 is released?
I've just added a note to the pull request.
Regards.
>
> https://github.com/qgis/Quantum-GIS/pull/151
>
> Etienne
>
> On Fri, May 25, 2012 at 1:09 PM,
Guiseppe,
I have implemented this and sent a new pull request, along with other
small fixes for .vrt and .gz files.
Can you look at this and if possible commit it before 1.8 is released?
https://github.com/qgis/Quantum-GIS/pull/151
Etienne
On Fri, May 25, 2012 at 1:09 PM, Etienne Tourigny
wro
On Fri, May 25, 2012 at 12:41 PM, Giuseppe Sucameli
wrote:
> Hi Etienne,
>
> On Fri, May 25, 2012 at 5:08 PM, Etienne Tourigny
> wrote:
>>> BTW we need another method, right? Something like
>>> QgsLayerItem::layerName()
>>
>> This is the approach in my patches, only it is also supported in
>> Qgs
Hi Etienne,
On Fri, May 25, 2012 at 5:08 PM, Etienne Tourigny
wrote:
>> BTW we need another method, right? Something like
>> QgsLayerItem::layerName()
>
> This is the approach in my patches, only it is also supported in
> QgsDataItem (see below why).
IMHO it isn't.
In your patch the fileName me
On Fri, May 25, 2012 at 11:55 AM, Giuseppe Sucameli
wrote:
> Hi Radim,
>
> On Wed, May 23, 2012 at 6:45 PM, Radim Blazek wrote:
>>> and adding a QgsDataItem::fileName() member which the browser would
>>> use for layer items. It very simple to fix now.
>>
>> It should be possible to get the file n
On Wed, May 23, 2012 at 1:45 PM, Radim Blazek wrote:
> On Wed, May 23, 2012 at 1:35 PM, Etienne Tourigny
> wrote:
>> This can be solved in code by removing the extension in the
>> QgsDataItem name() member, this way it does not have to be stripped in
>> drop operations,
>> and adding a QgsDataIte
Hi Radim,
On Wed, May 23, 2012 at 6:45 PM, Radim Blazek wrote:
>> and adding a QgsDataItem::fileName() member which the browser would
>> use for layer items. It very simple to fix now.
>
> It should be possible to get the file name from QgsDataItem::uri().
if the layer is file-based get the name
I have added a patch for this and also for another browser issue in
this pull request
https://github.com/qgis/Quantum-GIS/pull/147
Regards,
Etienne
On Wed, May 23, 2012 at 10:07 AM, Andreas Neumann wrote:
> +1 for what Etienne suggests: no extension in the layer tree toc but
> extensions in the
On Wed, May 23, 2012 at 1:35 PM, Etienne Tourigny
wrote:
> This can be solved in code by removing the extension in the
> QgsDataItem name() member, this way it does not have to be stripped in
> drop operations,
> and adding a QgsDataItem::fileName() member which the browser would
> use for layer i
+1 for what Etienne suggests: no extension in the layer tree toc but
extensions in the browser.
Andreas
On Wed, 23 May 2012 08:35:41 -0300, Etienne Tourigny wrote:
Hi all,
I propose that a reasonable compromise would be the following (by
default) for 1.8:
- show extensions in browser (it is
Hi all,
On Wed, 2012-05-23 at 19:12 +1000, Nathan Woodrow wrote:
> I agree. Showing filetype in the legend is just ui noise that isn't needed.
> How
> often do you open the same layer from different sources with the same name.
> Even if people do I doubt it would be more then a couple and then t
Hi all,
I propose that a reasonable compromise would be the following (by
default) for 1.8:
- show extensions in browser (it is a "file browser" after all, and a
majority have shown support for it)
- no extension in legend nor anywhere else (ui noise, a minority support it)
This can be solved in
I agree. Showing filetype in the legend is just ui noise that isn't needed. How
often do you open the same layer from different sources with the same name.
Even if people do I doubt it would be more then a couple and then the tooltips
would do fine. Don't add something that adds UI noise for a 5%
Hi Etienne,
On Wed, May 23, 2012 at 1:07 AM, Etienne Tourigny
wrote:
> How about in the legend? I am 50/50 on that as there is always the
> option to change the layer names manually, and the tooltip does give a
> clue on the filetype.
IMHO no extensions should be displayed in the legend as well.
Hi all,
I often use tooltips to see some information on a layer, and do not find it
very helpful though :
* you have to stand still
* you cannot always read the whole line (e.g. for postgis layers / layers
with long WHERE filter on small screens), and it is not very "readable"
some times
* you can
On Tue, May 22, 2012 at 7:58 PM, Giuseppe Sucameli
wrote:
> Hi all,
>
> On Tue, May 22, 2012 at 10:10 PM, Martin Dobias wrote:
>> - extensions in legend widget are useless
>> - new column for layer type in legend widget is are also useless
>> (there is tooltip with data source / full path)
>
> I
Hi all,
On Tue, May 22, 2012 at 10:10 PM, Martin Dobias wrote:
> - extensions in legend widget are useless
> - new column for layer type in legend widget is are also useless
> (there is tooltip with data source / full path)
I agree.
I guess a layer is just a layer. Distinguishing them by extensi
On Tue, May 22, 2012 at 7:37 AM, Paolo Cavallini wrote:
> Hi all.
> 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?
IMHO:
- extensions in legend widget are useless
- new column for la
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
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 / "
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.
Attac
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
> On Tue, May 22, 2012 at 4:10 AM, Giovanni Manghi
> wrote:
> > Hi,
> >
> >> I think the discussion on http://hub.qgis.org/issues/5621 d
On Tue, May 22, 2012 at 4:10 AM, Giovanni Manghi
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 dis
Dear all,
This is a little beside the point you are discussing, but I think it would
be a nice addition to the File Browser to allow users to delete geographic
data (or only shapefiles). Managing geographic data with Windows Explorer
is quite annoying and I think it would make a lot of sense to ad
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 originally asked to avoid leave the extension while dragging and
dropping from the browser, mainly because when dropping into
Hi all.
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?
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
__
25 matches
Mail list logo
