Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )

[John Hawkinson]

> Are you aware of systems where there are more values than 8 bits for the 
> alpha channel (for which we should prepare)?
> It wouldn't be a much bigger deal to go this road, but I think it shouldn't 
> be purely prophylactic without real needs in mind.

I'd be speaking out of school.

It appears to me that netpbm's pgm supports 16-bit alpha channels
http://netpbm.sourceforge.net/doc/pgm.html
and it looks to me like Photoshop supports them as well (in 16bpp file), and 
a cursory reading of the PDF 1.7 Reference suggests no limitation to 8 bits.

But I could definitely be misreading this.

--jh...@mit.edu
  John Hawkinson
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )

[Matthias Kuhn]

I'd say in the API we should be closer to the data and hence use 0-255, in the 
slider we convert it to 0-100%.
We could possibly have a slider that allows for 255 positions but prints 
numbers from 0%-100%?

Are you aware of systems where there are more values than 8 bits for the alpha 
channel (for which we should prepare)?
It wouldn't be a much bigger deal to go this road, but I think it shouldn't be 
purely prophylactic without real needs in mind.

Matthias

On 02/20/2017 03:19 PM, John Hawkinson wrote:
> > An outstanding question is what range we should allow? Behind the
> > scenes it's generally going to be converted to a 0-255 value, but for
> > users a 0-100% may be more explanatory. Opinions?
>
> The tools I use again express opacity in 0-100%, and I think that's
> the correct thing for the user interface. Why should users presume
> the internals are going to be 8-bit unsigned? Why shouldn't it be
> 0-65536? Or floating point?
>
> > The API is ALL OVER THE PLACE here, and should also be fixed. We have
> > a mix of transparency/opacity/alpha and ranges of 0-1, 0-100, 0-255.
> > It's confusing for developers too!
>
> So, I imagine at some point in the future someone is going to
> decide 8-bit alpha channels are too limiting. The API should
> probably be forward-looking with respect to that. I'm not
> sure exactly what that means, but to me it suggests
> not 0-255. Maybe 0-1 floating point. But I dunno.
>
> --jhawk
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )

[John Hawkinson]

> An outstanding question is what range we should allow? Behind the
> scenes it's generally going to be converted to a 0-255 value, but for
> users a 0-100% may be more explanatory. Opinions?

The tools I use again express opacity in 0-100%, and I think that's
the correct thing for the user interface. Why should users presume
the internals are going to be 8-bit unsigned? Why shouldn't it be
0-65536? Or floating point? 

> The API is ALL OVER THE PLACE here, and should also be fixed. We have
> a mix of transparency/opacity/alpha and ranges of 0-1, 0-100, 0-255.
> It's confusing for developers too!

So, I imagine at some point in the future someone is going to
decide 8-bit alpha channels are too limiting. The API should
probably be forward-looking with respect to that. I'm not
sure exactly what that means, but to me it suggests
not 0-255. Maybe 0-1 floating point. But I dunno.

--jhawk
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] What version of python for new plugin?

[Paolo Cavallini]

Il 20/02/2017 14:53, Magnus Homann ha scritto:
> Hi, what would be a good python version to use for a new plugin? 2.7 or 3?
> And is it QGIS 2.14 LTR that I should support for now?
> 
> Seems to be a lot of new stuff in the near future...

does this clarify a bit?
https://lists.osgeo.org/pipermail/qgis-developer/2017-February/047113.html
all the best
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] What version of python for new plugin?

[Magnus Homann]

Hi, what would be a good python version to use for a new plugin? 2.7 or 
3?

And is it QGIS 2.14 LTR that I should support for now?

Seems to be a lot of new stuff in the near future...

/Magnus
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3 configuration at first startup

[Nathan Woodrow]

Hey,

I was thinking about handling that case in my work as per QEP 82 (
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/82).

Regards,
Nathan

On Mon, Feb 20, 2017 at 9:42 PM, DelazJ  wrote:

> Hi,
>
> I've enabled QGIS 3 on a Windows machine where 2.18 and 2.14 are also
> installed.
> I was expecting to have some of my configurations kept but all was new
> (use of the system locale , use of epsg:4326, otf off, didn't keep my
> custom symbols... regardless my choices for 2.x release).
>
> While I understand that QGIS 3 picks user configuration from a new .qgis3
> folder, I wonder if this one shouldn't be populated with the current
> configs of the user (when compatible). I'm not sure that all end users will
> understand and could workaround these changes.
>
> Regards,
> Harrissou
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS 3 configuration at first startup

[DelazJ]

Hi,

I've enabled QGIS 3 on a Windows machine where 2.18 and 2.14 are also
installed.
I was expecting to have some of my configurations kept but all was new (use
of the system locale , use of epsg:4326, otf off, didn't keep my custom
symbols... regardless my choices for 2.x release).

While I understand that QGIS 3 picks user configuration from a new .qgis3
folder, I wonder if this one shouldn't be populated with the current
configs of the user (when compatible). I'm not sure that all end users will
understand and could workaround these changes.

Regards,
Harrissou
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plans for next QGIS releases

[Paolo Cavallini]

Hi,

Il 20/02/2017 11:59, DelazJ ha scritto:
> * retire 2.14 in June 2017
> * 2.18 becomes LTR from June 2017 to 2018
> * 3.0 feature freeze in July 2017
> * release 3.0 in Sept 2017
> * release 3.2 as next LTR in release 3.0 + 4 Months (eta June 2018).
> 
> You mean 3.2 released in january/february 2018, becomes LTR in june
> 2018, right?

sorry, I think this should be

* release 3.2 as next LTR in release 3.0 + 4 Months (eta Jan 2018).

all the best
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1160] Go2NextFeature approval notification.

[noreply]

Plugin Go2NextFeature approval by pcav.
The plugin version "[1160] Go2NextFeature 1.11" is now approved
Link: http://plugins.qgis.org/plugins/go2nextfeature/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1161] SmoothLine approval notification.

[noreply]

Plugin SmoothLine approval by pcav.
The plugin version "[1161] SmoothLine 1.11" is now approved
Link: http://plugins.qgis.org/plugins/smooth_line/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Netcdf4 problem in QGIS 64-bit under Windows

[Saber Razmjooei]

Hi all,

This is more of an issue with gdal/osgeo4w installer than QGIS. But there
is an inconsistency how netcdf4 files are being handled in Windows/Linux
from QGIS users' point of view.

Here is a ticket related to the issue:
https://trac.osgeo.org/osgeo4w/ticket/293

and SE discussion:
http://gis.stackexchange.com/questions/179132/gdal-nc-rasters-opened-as-netcdf-network-common-data-format-under-linux-an

I guess this will be resolved if a newer version of netcdf is shipped with
QGIS.

Regards
Saber



-- 
Saber Razmjooei
www.lutraconsulting.co.uk
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plans for next QGIS releases

[DelazJ]

Hi Paolo (and all)

2017-02-20 11:17 GMT+01:00 Paolo Cavallini :

> Hi all,
> during a fast and productive IRC meeting today we have come out with a
> proposal for the management of current and future versions of QGIS:
>
> Thanks to you


> * retire 2.14 in June 2017
> * 2.18 becomes LTR from June 2017 to 2018
> * 3.0 feature freeze in July 2017
> * release 3.0 in Sept 2017
> * release 3.2 as next LTR in release 3.0 + 4 Months (eta June 2018).
>
> You mean 3.2 released in january/february 2018, becomes LTR in june 2018,
right?

Harrissou


> Of course we know that some of you will have different preferences and
> constraints, but we believe this is the best compromise we can reach
> now. Please let us know if you have strong opposition to this, or good
> argument to change. Nothing is carved in stone, but it will be good to
> give our users and devs a perspective on what they can expect.
>
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )

[Stéphane Brunner]

+1 :-)

2017-02-20 11:43 GMT+01:00 Alexandre Neto :

> +1 for 0-100% Opacity in sliders.
>
> Paolo Cavallini  escreveu no dia segunda,
> 20/02/2017 às 08:32:
>
>> Il 20/02/2017 09:31, Nyall Dawson ha scritto:
>>
>> > An outstanding question is what range we should allow? Behind the
>> > scenes it's generally going to be converted to a 0-255 value, but for
>> > users a 0-100% may be more explanatory. Opinions?
>>
>> +1 for 0-100%
>> thanks
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
> Alexandre Neto
> -
> @AlexNetoGeo
> http://sigsemgrilhetas.wordpress.com
> http://gisunchained.wordpress.com
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
camptocamp.com
mapfish.org
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )

[Alexandre Neto]

+1 for 0-100% Opacity in sliders.

Paolo Cavallini  escreveu no dia segunda, 20/02/2017
às 08:32:

> Il 20/02/2017 09:31, Nyall Dawson ha scritto:
>
> > An outstanding question is what range we should allow? Behind the
> > scenes it's generally going to be converted to a 0-255 value, but for
> > users a 0-100% may be more explanatory. Opinions?
>
> +1 for 0-100%
> thanks
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Min Qt version

[Denis Rouzaud]

On 02/07/2017 11:59 AM, Radim Blazek wrote:
> On Tue, Feb 7, 2017 at 10:43 AM, Jürgen E. Fischer  wrote:
>> Hi Nyall,
>>
>> On Tue, 07. Feb 2017 at 09:11:25 +1000, Nyall Dawson wrote:
 INSTALL says in requirements Qt >= 5.3.0, Debian stable has 5.3.2.
>>> That's a mistake. AFAIK we are targeting 5.3 to cater for Debian.
>> Debian jessie (stable) has GDAL 1.10.1 - too old for us.
> I do compile all geo packages (gdal,proj,grass) myself but I would
> like to avoid Qt compilation.
> What others do on jessie? Do you compile Qt?
>
> Radim
Is there a decision here?
What min Qt version is the requirement: 5.3 or 5.7?
>
>> Debian stretch (testing) has Qt 5.7.1.
>>
>>
>> Jürgen
>>
>> --
>> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
>> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
>> Software Engineer   D-26506 Norden http://www.norbit.de
>> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plans for next QGIS releases

[Paolo Cavallini]

Hi all,
during a fast and productive IRC meeting today we have come out with a
proposal for the management of current and future versions of QGIS:

* retire 2.14 in June 2017
* 2.18 becomes LTR from June 2017 to 2018
* 3.0 feature freeze in July 2017
* release 3.0 in Sept 2017
* release 3.2 as next LTR in release 3.0 + 4 Months (eta June 2018).

Of course we know that some of you will have different preferences and
constraints, but we believe this is the best compromise we can reach
now. Please let us know if you have strong opposition to this, or good
argument to change. Nothing is carved in stone, but it will be good to
give our users and devs a perspective on what they can expect.

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Mathieu Pellerin]

I've never used the browser much, I can't say I would miss it if it's
retired.

The one thing I'd miss a bit is its capability at quickly previewing
datasets. I'm wondering if this could be somehow integrated into the QGIS'
browser dock (maybe now made possible following the major layer registry /
project refactoring which has taken place prior to 3.0?). Just like the
information panel, we could have a preview panel that renders a preview of
the vector/raster dataset.

Anyhow; +1 to see the standalone browser gone. :)

Math




On Mon, Feb 20, 2017 at 4:58 PM, Jorge Gustavo Rocha 
wrote:

> Hi,
>
> I never used it, and it is definitely a source of confusion in workshops.
>
> Regards,
>
> Jorge Gustavo
>
> Às 07:52 de 20-02-2017, Nathan Woodrow escreveu:
> > It's the same code, just in dock form.  I find the browser dock to be
> > super helpful but have never used the standalone version.
> >
> > On Mon, Feb 20, 2017 at 5:30 PM, Richard Duivenvoorde
> > > wrote:
> >
> > On 19-02-17 23:33, Nyall Dawson wrote:
> > > Hi all,
> > >
> > > Just wanted to raise the discussion about the future of the
> standalone
> > > QGIS browser.
> > ...
> > > So what should we do with the standalone browser in 3.0 and
> future? is
> > > there a future here, or should we just drop this functionality and
> > > save ourselves the maintenance burden? And if there IS interest in
> > > keeping the browser around, is anyone able to step up and sponsor
> some
> > > investment into making browser more useful and polished?
> >
> > Hi Nyall,
> >
> > I would be ok too to drop de browser (mainly because I've never used
> it
> > standalone, and seeing Tim's first point in practice too).
> > But what I'm wondering is what code is shared between the
> > Browser-panel-widget and the stand alone one.
> > Because some of your points are also valid for the widget? And I
> have a
> > troublesome relation with the widget too:
> > - eating cpu when you have a WMS-node or db node open when you
> > stop/start QGIS
> > - very silent failing of drag en drop behaviour (if it works it
> works,
> > but ...)
> > - missing datatypes/services too
> >
> > So same questions for the panel/widget?
> >
> > In general I'm in favour of making QGIS as lean as possible for 3.0,
> it
> > will gain weight in near future anyway. And this is the only time in
> > near future that we can do such a diet :-)
> >
> > Regards,
> >
> > Richard D
> >
> >
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org  osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > 
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > 
> >
> >
> >
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
> J. Gustavo
> --
> Jorge Gustavo Rocha
> Departamento de Informática
> Universidade do Minho
> 4710-057 Braga
> Tel: +351 253604480
> Fax: +351 253604471
> Móvel: +351 910333888
> skype: nabocudnosor
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Jorge Gustavo Rocha]

Hi,

I never used it, and it is definitely a source of confusion in workshops.

Regards,

Jorge Gustavo

Às 07:52 de 20-02-2017, Nathan Woodrow escreveu:
> It's the same code, just in dock form.  I find the browser dock to be
> super helpful but have never used the standalone version.
> 
> On Mon, Feb 20, 2017 at 5:30 PM, Richard Duivenvoorde
> > wrote:
> 
> On 19-02-17 23:33, Nyall Dawson wrote:
> > Hi all,
> >
> > Just wanted to raise the discussion about the future of the standalone
> > QGIS browser.
> ...
> > So what should we do with the standalone browser in 3.0 and future? is
> > there a future here, or should we just drop this functionality and
> > save ourselves the maintenance burden? And if there IS interest in
> > keeping the browser around, is anyone able to step up and sponsor some
> > investment into making browser more useful and polished?
> 
> Hi Nyall,
> 
> I would be ok too to drop de browser (mainly because I've never used it
> standalone, and seeing Tim's first point in practice too).
> But what I'm wondering is what code is shared between the
> Browser-panel-widget and the stand alone one.
> Because some of your points are also valid for the widget? And I have a
> troublesome relation with the widget too:
> - eating cpu when you have a WMS-node or db node open when you
> stop/start QGIS
> - very silent failing of drag en drop behaviour (if it works it works,
> but ...)
> - missing datatypes/services too
> 
> So same questions for the panel/widget?
> 
> In general I'm in favour of making QGIS as lean as possible for 3.0, it
> will gain weight in near future anyway. And this is the only time in
> near future that we can do such a diet :-)
> 
> Regards,
> 
> Richard D
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org 
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

J. Gustavo
-- 
Jorge Gustavo Rocha
Departamento de Informática
Universidade do Minho
4710-057 Braga
Tel: +351 253604480
Fax: +351 253604471
Móvel: +351 910333888
skype: nabocudnosor
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Moving Processing options?

[Victor Olaya]

+1. I like the idea, and I hnk that, if it is possible to add options
from plugins in the settings dialog, it should be mandatory for
plugins to do so, for the sake of homogeneity, instead of creating
their own.

2017-02-20 10:16 GMT+01:00 Matthias Kuhn :
> I once did that for vector layers (globe uses this) and Nathan reworked
> it a bit for the styling dock IIRC, it probably wouldn't be hard to copy
> this code.
>
> On 02/20/2017 09:57 AM, Paolo Cavallini wrote:
>> Il 20/02/2017 09:55, Nyall Dawson ha scritto:
>>> I've thought this too.
>>>
>>> We'd need a way for plugins to embed panels inside the general options
>>> first though. This would also allow us to move the python console
>>> options here too. In general it might help reduce UI clutter though
>>> plugins creating menu items just for a config dialog (i.e. the Win95
>>> style menus "Plugins - > Super Team Pty Ltd -> Super Team Awesome
>>> Plugin -> Super Team Awesome Plugin v1.0 settings" )
>>
>> Right, that always bothered me too.
>> How to proceed not to forget it?
>> All the best.
>>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Moving Processing options?

[Matthias Kuhn]

I once did that for vector layers (globe uses this) and Nathan reworked
it a bit for the styling dock IIRC, it probably wouldn't be hard to copy
this code.

On 02/20/2017 09:57 AM, Paolo Cavallini wrote:
> Il 20/02/2017 09:55, Nyall Dawson ha scritto:
>> I've thought this too.
>>
>> We'd need a way for plugins to embed panels inside the general options
>> first though. This would also allow us to move the python console
>> options here too. In general it might help reduce UI clutter though
>> plugins creating menu items just for a config dialog (i.e. the Win95
>> style menus "Plugins - > Super Team Pty Ltd -> Super Team Awesome
>> Plugin -> Super Team Awesome Plugin v1.0 settings" )
> 
> Right, that always bothered me too.
> How to proceed not to forget it?
> All the best.
> 
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Moving Processing options?

[Paolo Cavallini]

Il 20/02/2017 09:55, Nyall Dawson ha scritto:
> I've thought this too.
> 
> We'd need a way for plugins to embed panels inside the general options
> first though. This would also allow us to move the python console
> options here too. In general it might help reduce UI clutter though
> plugins creating menu items just for a config dialog (i.e. the Win95
> style menus "Plugins - > Super Team Pty Ltd -> Super Team Awesome
> Plugin -> Super Team Awesome Plugin v1.0 settings" )

Right, that always bothered me too.
How to proceed not to forget it?
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Moving Processing options?

[Nyall Dawson]

On 20 February 2017 at 18:38, Paolo Cavallini  wrote:
> Hi all,
> any special reason Procesing options should remain in the Processing
> menu, instead of being moved to the general options dialog?
> II think this will be easier and more understandable for the user.
> All the best.

I've thought this too.

We'd need a way for plugins to embed panels inside the general options
first though. This would also allow us to move the python console
options here too. In general it might help reduce UI clutter though
plugins creating menu items just for a config dialog (i.e. the Win95
style menus "Plugins - > Super Team Pty Ltd -> Super Team Awesome
Plugin -> Super Team Awesome Plugin v1.0 settings" )

Nyall




> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Nyall Dawson]

On 20 February 2017 at 18:38, Jürgen E. Fischer  wrote:
> Hi Nyall,
>
> On Mon, 20. Feb 2017 at 08:33:13 +1000, Nyall Dawson wrote:
>> - Ignoring a tiny change I made a couple of days ago (to make the
>> preview use a pan tool), the last commit to standalone browser
>> (besides general api fixes) was... adding a new icon in may 2015.
>
> Um, one minute you request a change and the other you want to have it killed.
> I should have better used the time to finish it ;)

Sorry - that commit comment just started me thinking about what it's
future is. I actually didn't expect that there would be such strong
consensus to remove it, and thought that this discussion was more
likely to result in suggestions for improving it and several people
saying "i can't live without it!". Apologies if your effort on that
commit wasn't required...

Nyall



>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Outline/border -> stroke?

[G. Allegri]

Opacity is more coherent with graphic softwares (and I generally talk about
opacity when designing maps) but IMHO transparency is more intuitive for
the lay users, and it's a quite conmon terminology in GIS softwares.

Maybe opacity could be used for styling and transaprency for the global
layer rendering (general layer properties, etc.), both for vectors and
rasters.

giovanni

Il 20 feb 2017 09:30, "Paolo Cavallini"  ha scritto:

> Il 20/02/2017 09:28, Nyall Dawson ha scritto:
>
> > Seems like a strong consensus here for "stroke". I'll try and make
> > this change sometime this week (should be mostly search and replace)
>
> great, thanks. how about Opacity vs Transparency?
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Martin Dobias]

Hi Nyall

we (Radim and me) have added it long time ago within a small contract where
people wanted a simple standalone app for preview of data files (with an
assortment of other functionality that was not yet available in qgis app at
the time). Personally I have never been too attached to the idea of a
standalone browser, but thats how they wanted it.

Nowadays, the browser dock integrated inside qgis has richer functionality
and in general much more potential, so I think it would be fine to get rid
of the standalone browser - obviously it is barely used and not really
developed by anyone...

Cheers
Martin


On 20 Feb 2017 06:33, "Nyall Dawson"  wrote:

> Hi all,
>
> Just wanted to raise the discussion about the future of the standalone
> QGIS browser.
>
> The current situation (as I see it)
>
> - Ignoring a tiny change I made a couple of days ago (to make the
> preview use a pan tool), the last commit to standalone browser
> (besides general api fixes) was... adding a new icon in may 2015.
>
> - The standalone browser is very limited. There's lots of
> functionality available in the browser panel in the main app which
> isn't available in the standalone browser, like the search filter and
> everything in the right click context menus.
>
> - The current state of the standalone browser is "schizophrenic" at
> best. It's predominantly a read-only display of data, but with some
> extra random functionality in a toolbar (add wms server (what about
> wfs/wcs/etc?), create shapefile (what about spatialite/geopackage?),
> set layer projection)
>
> - The UI is very unpolished - eg there's a "header" header over the
> browser tree (http://mappinggis.com/wp-content/uploads/2015/11/5.png)
>
> I'm guessing, given this, that there's not a lot of demand for the
> standalone browser. This may either be due to lack of interest in this
> functionality in general, or else just a reflection of the current
> limited functionality available in it.
>
> So what should we do with the standalone browser in 3.0 and future? is
> there a future here, or should we just drop this functionality and
> save ourselves the maintenance burden? And if there IS interest in
> keeping the browser around, is anyone able to step up and sponsor some
> investment into making browser more useful and polished?
>
> Nyall
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Moving Processing options?

[Paolo Cavallini]

Hi all,
any special reason Procesing options should remain in the Processing
menu, instead of being moved to the general options dialog?
II think this will be easier and more understandable for the user.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Jürgen E . Fischer]

Hi Nyall,

On Mon, 20. Feb 2017 at 08:33:13 +1000, Nyall Dawson wrote:
> - Ignoring a tiny change I made a couple of days ago (to make the
> preview use a pan tool), the last commit to standalone browser
> (besides general api fixes) was... adding a new icon in may 2015.

Um, one minute you request a change and the other you want to have it killed.
I should have better used the time to finish it ;)


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



pgpSmc2YfGtiQ.pgp
Description: PGP signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )

[Nyall Dawson]

On 19 February 2017 at 14:02, John Hawkinson  wrote:

> As for transparency vs. opacity, as I wrote in that email:
>
> * Why does QGIS use Transparency sliders instead of Opacity sliders?
>   Isn't Opacity much more common in graphics software?
>
> To expand a little more, both Photoshop and Illustrator use Opacity
> sliders -- far left is 0% opacity / full transparency. (Although
> curiously, Illustrator's is inside the Transparency window.)
>
> Are there prominent examples of software packages (in the GIS world?)
> that use Transparency instead of Opacity in sliders?
>
> For the tols I use, Opacity wins hands-down. I gather that's not true
> for everyone, but I wonder what the tools are that use Transparency
> sliders (far left is 100% opacity / no transparency).
>
> I would say, also, that Opacity is a little more intuitive, because
> it basically translates to Brightness. If you ask a user which way
> they turn the knob to make a line darker, they'll usually turn it in
> the positive director (err, s/knob/slider/).

My preference would be for opacity too.

An outstanding question is what range we should allow? Behind the
scenes it's generally going to be converted to a 0-255 value, but for
users a 0-100% may be more explanatory. Opinions?

> I would say, also, that the internal API is very different from the
> UI. What's the justification for changing the API on this? Confusion
> to API developers? Is that really worth it?

The API is ALL OVER THE PLACE here, and should also be fixed. We have
a mix of transparency/opacity/alpha and ranges of 0-1, 0-100, 0-255.
It's confusing for developers too!

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )

[Paolo Cavallini]

Il 20/02/2017 09:31, Nyall Dawson ha scritto:

> An outstanding question is what range we should allow? Behind the
> scenes it's generally going to be converted to a 0-255 value, but for
> users a 0-100% may be more explanatory. Opinions?

+1 for 0-100%
thanks

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Outline/border -> stroke?

[Paolo Cavallini]

Il 20/02/2017 09:28, Nyall Dawson ha scritto:

> Seems like a strong consensus here for "stroke". I'll try and make
> this change sometime this week (should be mostly search and replace)

great, thanks. how about Opacity vs Transparency?

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Outline/border -> stroke?

[Nyall Dawson]

On 18 February 2017 at 20:15, Raymond Nijssen  wrote:
> +1 for stroke
>

Seems like a strong consensus here for "stroke". I'll try and make
this change sometime this week (should be mostly search and replace)

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Nyall Dawson]

On 20 February 2017 at 18:17, Paolo Cavallini  wrote:
> Il 20/02/2017 09:11, Régis Haubourg ha scritto:
>> Agreed here,
>> never used it, and it sends a wrong message saying Esri UX choices are
>> good enough to be copied. Let's get rid of it :)
>
> Agreed with most people here:
> * never used it myself
> * never seen used by anyone
> * very confusing for the users (especially when it had the same desktop
> icon as main app).
> On the other hand, I find the docked version superuseful and intuitive,
> although I agree with Richard that it should be streamlined, hopefully
> replacing the (too) many "Add this and that" buttons.
> Thanks Nyall for raising the issue.

Yes - I should have stressed this more. I love the in-app browser dock
and think it's vital to using QGIS. It's not going anywhere!

Seems like quite a consensus that the standalone browser should go.
Does anyone know the history here? I'd like to hear from the original
developer as to whether this was a funded project which could cause
issues with removal or if it's no longer required by them either...

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[G. Allegri]

I agree for dropping it. Never used and many partecipants to our courses
were doubtful of its usefulness.

I guess it was meant to be similar to ESRI ArcCatalog but in that case a
lot more of functionalities should be implemented to give it a reason to
exist as a standalone sw.

giovanni

Il 20 feb 2017 09:12, "Régis Haubourg"  ha
scritto:

> Agreed here,
> never used it, and it sends a wrong message saying Esri UX choices are
> good enough to be copied. Let's get rid of it :)
> Régis
>
> 2017-02-20 8:52 GMT+01:00 Nathan Woodrow :
>
>> It's the same code, just in dock form.  I find the browser dock to be
>> super helpful but have never used the standalone version.
>>
>> On Mon, Feb 20, 2017 at 5:30 PM, Richard Duivenvoorde <
>> rdmaili...@duif.net> wrote:
>>
>>> On 19-02-17 23:33, Nyall Dawson wrote:
>>> > Hi all,
>>> >
>>> > Just wanted to raise the discussion about the future of the standalone
>>> > QGIS browser.
>>> ...
>>> > So what should we do with the standalone browser in 3.0 and future? is
>>> > there a future here, or should we just drop this functionality and
>>> > save ourselves the maintenance burden? And if there IS interest in
>>> > keeping the browser around, is anyone able to step up and sponsor some
>>> > investment into making browser more useful and polished?
>>>
>>> Hi Nyall,
>>>
>>> I would be ok too to drop de browser (mainly because I've never used it
>>> standalone, and seeing Tim's first point in practice too).
>>> But what I'm wondering is what code is shared between the
>>> Browser-panel-widget and the stand alone one.
>>> Because some of your points are also valid for the widget? And I have a
>>> troublesome relation with the widget too:
>>> - eating cpu when you have a WMS-node or db node open when you
>>> stop/start QGIS
>>> - very silent failing of drag en drop behaviour (if it works it works,
>>> but ...)
>>> - missing datatypes/services too
>>>
>>> So same questions for the panel/widget?
>>>
>>> In general I'm in favour of making QGIS as lean as possible for 3.0, it
>>> will gain weight in near future anyway. And this is the only time in
>>> near future that we can do such a diet :-)
>>>
>>> Regards,
>>>
>>> Richard D
>>>
>>>
>>>
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Paolo Cavallini]

Il 20/02/2017 09:11, Régis Haubourg ha scritto:
> Agreed here, 
> never used it, and it sends a wrong message saying Esri UX choices are
> good enough to be copied. Let's get rid of it :)

Agreed with most people here:
* never used it myself
* never seen used by anyone
* very confusing for the users (especially when it had the same desktop
icon as main app).
On the other hand, I find the docked version superuseful and intuitive,
although I agree with Richard that it should be streamlined, hopefully
replacing the (too) many "Add this and that" buttons.
Thanks Nyall for raising the issue.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Marco Bernasocchi]

On Sun, Feb 19, 2017 at 11:33 PM, Nyall Dawson 
wrote:

>Hi all,
>   Just wanted to raise the discussion about the future of the
>standalone QGIS browser.


Never used and never taught how to use it

ciaö
-- 
Marco Bernasocchi
OPENGIS.ch - berna.io - 27summits.ch



signature.asc
Description: OpenPGP digital signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of standalone browser?

[Régis Haubourg]

Agreed here,
never used it, and it sends a wrong message saying Esri UX choices are good
enough to be copied. Let's get rid of it :)
Régis

2017-02-20 8:52 GMT+01:00 Nathan Woodrow :

> It's the same code, just in dock form.  I find the browser dock to be
> super helpful but have never used the standalone version.
>
> On Mon, Feb 20, 2017 at 5:30 PM, Richard Duivenvoorde  > wrote:
>
>> On 19-02-17 23:33, Nyall Dawson wrote:
>> > Hi all,
>> >
>> > Just wanted to raise the discussion about the future of the standalone
>> > QGIS browser.
>> ...
>> > So what should we do with the standalone browser in 3.0 and future? is
>> > there a future here, or should we just drop this functionality and
>> > save ourselves the maintenance burden? And if there IS interest in
>> > keeping the browser around, is anyone able to step up and sponsor some
>> > investment into making browser more useful and polished?
>>
>> Hi Nyall,
>>
>> I would be ok too to drop de browser (mainly because I've never used it
>> standalone, and seeing Tim's first point in practice too).
>> But what I'm wondering is what code is shared between the
>> Browser-panel-widget and the stand alone one.
>> Because some of your points are also valid for the widget? And I have a
>> troublesome relation with the widget too:
>> - eating cpu when you have a WMS-node or db node open when you
>> stop/start QGIS
>> - very silent failing of drag en drop behaviour (if it works it works,
>> but ...)
>> - missing datatypes/services too
>>
>> So same questions for the panel/widget?
>>
>> In general I'm in favour of making QGIS as lean as possible for 3.0, it
>> will gain weight in near future anyway. And this is the only time in
>> near future that we can do such a diet :-)
>>
>> Regards,
>>
>> Richard D
>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer