Re: [Qgis-developer] Cannot add new GeoPackage connection to DB Manager

[Larry Shaffer]

Hi Stefan,

Confirmed here on Mac (same error after choosing file). Using master build
from yesterday.

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota

On Fri, Apr 22, 2016 at 4:34 AM, Stefan Ziegler  wrote:

> Hi
>
> When trying to add a new GeoPackage connection:
>
> - right mouse click on Spatialite/Geopackage
> - New Connection
> - Choose Geopackage by double-clicking
>
>
> I get the following error:
>
> TypeError: TreeItem.itemChanged[] signal has 0 argument(s) but 1 provided
>
> Traceback (most recent call last):
>   File
> "/usr/local/qgis_master/share/qgis/python/plugins/db_manager/db_tree.py",
> line 103, in newConnection
> self.mainWindow.invokeCallback(item.addConnectionActionSlot, index)
>   File
> "/usr/local/qgis_master/share/qgis/python/plugins/db_manager/db_manager.py",
> line 288, in invokeCallback
> callback(self.tree.currentItem(), self.sender(), self, *params)
>   File
> "/usr/local/qgis_master/share/qgis/python/plugins/db_manager/db_plugins/spatialite/plugin.py",
> line 102, in addConnectionActionSlot
> index.internalPointer().itemChanged.emit(index.internalPointer())
> TypeError: TreeItem.itemChanged[] signal has 0 argument(s) but 1 provided
>
> I'm on Ubuntu 14.04 and QGIS master. Can anyone confirm this? The
> Geopackage can be displayed in QGIS when using the standard vector file
> dialog.
>
> best regards
> Stefan
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Server] performance questions

[Jörg Habenicht]

Hello Marco.

Am 22.04.2016 um 17:44 schrieb Marco Hugentobler:
> Hi
> 
> Yes, rendering multithreaded in the server is possible (but needs some
> work of course).
> 
> What I said was that the effect is probably not that big, because the
> fcgi module already distributes concurrent requests to different
> processes.

we already got this technology, but in those cases described below the
work distribution does not help. Currently we got around 10
clicks/second at max, but the user has to wait an awful long time for
the map to update in his/her session.

We have measured the average response time which is around 1 second. But
using FCGI and parallel QGis-server processes does not help in this case.


> In the special case of very rare requests to the server, it
> might have a considerable effect. But even then it is very unlikely that
> a 20sec request will render in 1-2 sec (what you need for interactive
> web maps).

I'd estimate it to be nearly linear for painting the pictures (and maybe
also for calling the DB). On your server we can see one core to be fully
utilized calculating with low IO and all others idling around.

I'd like to give it a try in the below mentioned method. Do I have to
expect serious side effects? Do I have to consider something I forgot in
my design?


> 
> Regards,
> Marco

cu
Jörg

> 
[snip]
>>> Il 22 apr 2016 3:27 PM, "Jörg Habenicht" >> > ha scritto:
>>>
>>> Hi Andreas, dear list,
>>>
[snip]
>>>
>>> I have scanned the git-Qgis sources (commit
>>> 81744ecf90a8f6c1e2e94fdacb07e3dca6987dcc) for a suitable
>>> multithreading
>>> entry. Found QgsMapRenderer::render() because of the line "while (
>>> li.hasPrevious() )". It seems in this loop the layers are painted in
>>> serial onto the resulting picture.
>>> If I can build an auto parallel computing with QtConcurrent in this
>>> place there seems to be the most gain. I mean to parallelize the loop
>>> with concurrent DB requests, concurrent painting in separate pictures
>>> and in serial map the single pictures onto the result picture.
>>>
>>> Right now I don't know if I can do DB requests in parallel, or
>>> where the
>>> code for database requests is buried.
>>> And how about the calls inside the loop, are there side effects
>>> preventing multi threading?
>>>
>>>
>>> Do you got hints, flames or suggestions?
>>>
>>>
>>> cu
>>> Jörg
>>>
>>>
[snip]

-- 

mWerk GmbH
Dipl.-Ing. Jörg Habenicht
Landwehrstr. 76
30519 Hannover
(T) +49 511  8033
(F) +49 511  8041
(E) j...@mwerk.net
Amtsgericht Hannover HRB 206522
Geschäftsführer
Reiner Brachvogel
Dennis Kornehl
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Server] performance questions

[Jörg Habenicht]

Hi Matthias,

Am 22.04.2016 um 17:20 schrieb Matthias Kuhn:
> Hi,
> 
> I don't know the server code very well, so I may be wrong, but I think
> that making the server multithreaded rendering (MTR) capable should be
> possible. And while it is certainly often possible to increase the
> performance with filtering, rules and caching there are certainly also
> situations where MTR can help a server to generate quick responses (many
> layers, few requests).
> 
> As far as I can see, the main task would be porting the code from
> QgsMapRenderer to QgsMapRendererJob and QgsMapSettings. A first step
> into this direction can be found in a recently closed pull request [1],
> in particular this commit [2].

I'll have a look.
It seems to me I have to extract the code inside the loop (in
QgsMapRenderer::render(), "while ( li.hasPrevious() )") into a separate
method and call QtConcurrent on that.


> 
> Concerning parallel DB connection, there's no difference between server
> and desktop use. This code is already in production use and should be
> fairly robust already.
> 
> I hope I didn't base this message on wrong assumptions and hope someone
> of the server developers can shed more light onto this.

thanks

> 
> Regards
> Matthias
> 
> [1] https://github.com/qgis/QGIS/pull/2989/files
> [2]
> https://github.com/qgis/QGIS/pull/2989/commits/4cba6393544aeb23569d6c15f19e67f4ff8bf19c
> 
> 
[snip]


-- 

mWerk GmbH
Dipl.-Ing. Jörg Habenicht
Landwehrstr. 76
30519 Hannover
(T) +49 511  8033
(F) +49 511  8041
(E) j...@mwerk.net
Amtsgericht Hannover HRB 206522
Geschäftsführer
Reiner Brachvogel
Dennis Kornehl
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Server] performance questions

[Marco Hugentobler]

Hi

Yes, rendering multithreaded in the server is possible (but needs some 
work of course).


What I said was that the effect is probably not that big, because the 
fcgi module already distributes concurrent requests to different 
processes. In the special case of very rare requests to the server, it 
might have a considerable effect. But even then it is very unlikely that 
a 20sec request will render in 1-2 sec (what you need for interactive 
web maps).


Regards,
Marco

On 22.04.2016 17:20, Matthias Kuhn wrote:

Hi,

I don't know the server code very well, so I may be wrong, but I think 
that making the server multithreaded rendering (MTR) capable should be 
possible. And while it is certainly often possible to increase the 
performance with filtering, rules and caching there are certainly also 
situations where MTR can help a server to generate quick responses 
(many layers, few requests).


As far as I can see, the main task would be porting the code from 
QgsMapRenderer to QgsMapRendererJob and QgsMapSettings. A first step 
into this direction can be found in a recently closed pull request 
[1], in particular this commit [2].


Concerning parallel DB connection, there's no difference between 
server and desktop use. This code is already in production use and 
should be fairly robust already.


I hope I didn't base this message on wrong assumptions and hope 
someone of the server developers can shed more light onto this.


Regards
Matthias

[1] https://github.com/qgis/QGIS/pull/2989/files
[2] 
https://github.com/qgis/QGIS/pull/2989/commits/4cba6393544aeb23569d6c15f19e67f4ff8bf19c



On 22/04/16 17:00, Andrea Peri wrote:


I guess a more time consuming parameter is the number of vertex in 
the feature involved in the map rather than the layer numbers.


A.

Il 22 apr 2016 3:27 PM, "Jörg Habenicht" > ha scritto:


Hi Andreas, dear list,

sorry for the warm up of this old topic.

There is in deed a need to enable multi threading in Qgis-Server.

In our company we use around 60 different layer to lay some topics on
the map. This may be an extreme example to read, but quite common
in our
environment, i.e. we can not lower this number significantly.

A warmed up QGis-Server process which already read and cached the
Configuration file qgis-xy.conf still needs around 20 seconds to
calculate the complete resulting map picture.

During this calculation there is only one thread working, serializing
the DB-requests, calculation the layer picture and mapping the
picture
on the resulting picture.
The process is running on a multi core server. If we can utilize the
idle cores to do useful work, this can be an easy example to speed up
the process (significant).

I'd like to share my developing experience to do this change, but I
would need further information and some support to do some useful
patches.

I have scanned the git-Qgis sources (commit
81744ecf90a8f6c1e2e94fdacb07e3dca6987dcc) for a suitable
multithreading
entry. Found QgsMapRenderer::render() because of the line "while (
li.hasPrevious() )". It seems in this loop the layers are painted in
serial onto the resulting picture.
If I can build an auto parallel computing with QtConcurrent in this
place there seems to be the most gain. I mean to parallelize the loop
with concurrent DB requests, concurrent painting in separate pictures
and in serial map the single pictures onto the result picture.

Right now I don't know if I can do DB requests in parallel, or
where the
code for database requests is buried.
And how about the calls inside the loop, are there side effects
preventing multi threading?


Do you got hints, flames or suggestions?


cu
Jörg


Am 23.02.2016 um 16:39 schrieb Neumann, Andreas:
> Hi Régis,
>
> QGIS server is single-threaded. You can't simply turn on
multi-threaded
> rendering in QGIS server. The other issue is that each Apache FCGI
> process has it's own set of cache. So if you have 5-10 parallel
Apache
> threads or processes each thread/process has it's own cache. If
your
> client hits a thread that has the cache unititialized you will
have wait
> longer until this cache is fillled.
>
> I once asked Marco whether one could
>
> a) have a shared cache for all Apache threads or processes

There is no shared cache, because Apache spawns QGis-Processes
with its
own memory layout. these Processes know nothing about its
neighbor, and
you have a hard time to exchange data between all processes.
How about a scheduler, which assigns requests to warmed up
Qgis-processes?

>
> b) support multi-threaded rendering
>
> But he said it would be very complicated to implement a) and
b), if not
> impossible. Maybe other devs have other views. Note that 

[Qgis-developer] Moving the install instructions to a more sexy, visible, coherent and translatable page in qgis.org

[DelazJ]

 Hi,

Currently, when someone is looking for steps to compile a QGIS release,
he'll will find them in the QGIS repo [0]

I personally don't like that page and from a non-english speaker and
non-developer looking for a howto, I didn't like it not being translated.
And there are pages from the translated website that directly link to this
page (leaving a fully translated page to a specialized page totally in
english from within the QGIS project doesn't really sound good to me).

Then, reading the introduction of this notice, you'll find assertions such
as:
- "You can download this document as part of the QGIS 'User and
Installation Guide' in HTML and PDF format via http://qgis.org.;
- "Translations of this document can also be downloaded at the
documentation area of the QGIS project at http://qgis.org.;
AFAICS, this text is available nowhere in the manuals and there's no
translated version.

SO, does it make sense to move it to somewhere like
http://www.qgis.org/en/site/getinvolved/development/index.html?
It'll complete all other chapters on development matters, will be more
visible, sexy and translatable.

The issues I can't figure out how they can be solved are:
- what will be the status of the current page, in the QGIS repo?
- how will update be managed?

Comments are welcome. I'd have loved to show you this chapter in context
but I'm unable to build the website [1] so you may need to review the PR
#343 [2](I've RSTed the text)


Thanks,
Harrissou

[0]
http://htmlpreview.github.io/?https://github.com/qgis/QGIS/blob/master/doc/INSTALL.html
[1]
http://osgeo-org.1560.x6.nabble.com/Unable-to-build-QGIS-Website-with-Paver-td5262145.html
[2] https://github.com/qgis/QGIS-Website/pull/343
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Questions about QgsEditorWidgetWrapper value() / setValue()

[Matthias Kuhn]

Hi Even

On 22/04/16 16:32, Even Rouault wrote:

Thanks, that make sense. And it is actually implemented by
QgsRelationReferenceWidgetWrapper.

Arg, I meant QgsValueRelationWidgetFactory. It is *not* by
QgsRelationReferenceFactory, hence my question about the appropriatness of
doing so.

Yes, sounds reasonable to me. And I think it would also make sense to 
implement a shorthand QgsEditorWidgetWrapper::displayValue() for this 
functionality.
That's where one would expect such a method and it reduces boilerplate 
code, the best demonstration for this is this thread I guess.


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

Re: [Qgis-developer] [Server] performance questions

[Neumann, Andreas]

Hi Jörg, 

Unfortunately I am not the suitable person to ask. In only occasionally
develop Python and don't know C/C++. However, I am a long-time QGIS
server user. I have big projects as well (with 80/90 layers). They
usually render in 1-2 seconds, not 20 seconds like you cite. So maybe
there are other issues/bottlenecks? Do you have an exceptional number of
features in your layers? Do you use scale thresholds to filter features.
Typically it doesn't make any sense to render too many features at small
scales, because you can't depict them anyway if there are too many. 

I assume you use Postgis as a data source - since you talk about DB
queries. Do you have the proper spatial index and other indexes? Do you
have a recent version of QGIS server? I think version 2.10 and later
introduced filtering inside the DB (instead of filtering in QGIS), which
should come with a performance improvement. 

20 seconds is definitely too long a wait for a map rendering, but I
guess you can bring this down to 1-2 seconds if properly optimized (both
in DB and in QGIS). 

It may well be that there is room for improvements in rendering speed of
QGIS server, but multi-threading is probaby the most complicated way of
improving performance in QGIS server. When I asked Marco Hugentobler,
the main QGIS Server developer, he told me it would be almost impossible
to make QGIS server multi-threaded. 3LIZ is also into QGIS server
development since some time. So these are the guys to ask. 

And then - the other issue is that you want to reserve your other CPU
cores for parallel requests as well. You usually don't want to dedicate
all your CPU power to a single http request. 

But if there is a way to improve speed in QGIS server I am all for it
... 

Greetings, 

Andreas 

On 2016-04-22 15:20, Jörg Habenicht wrote:

> Hi Andreas, dear list,
> 
> sorry for the warm up of this old topic.
> 
> There is in deed a need to enable multi threading in Qgis-Server.
> 
> In our company we use around 60 different layer to lay some topics on
> the map. This may be an extreme example to read, but quite common in our
> environment, i.e. we can not lower this number significantly.
> 
> A warmed up QGis-Server process which already read and cached the
> Configuration file qgis-xy.conf still needs around 20 seconds to
> calculate the complete resulting map picture.
> 
> During this calculation there is only one thread working, serializing
> the DB-requests, calculation the layer picture and mapping the picture
> on the resulting picture.
> The process is running on a multi core server. If we can utilize the
> idle cores to do useful work, this can be an easy example to speed up
> the process (significant).
> 
> I'd like to share my developing experience to do this change, but I
> would need further information and some support to do some useful patches.
> 
> I have scanned the git-Qgis sources (commit
> 81744ecf90a8f6c1e2e94fdacb07e3dca6987dcc) for a suitable multithreading
> entry. Found QgsMapRenderer::render() because of the line "while (
> li.hasPrevious() )". It seems in this loop the layers are painted in
> serial onto the resulting picture.
> If I can build an auto parallel computing with QtConcurrent in this
> place there seems to be the most gain. I mean to parallelize the loop
> with concurrent DB requests, concurrent painting in separate pictures
> and in serial map the single pictures onto the result picture.
> 
> Right now I don't know if I can do DB requests in parallel, or where the
> code for database requests is buried.
> And how about the calls inside the loop, are there side effects
> preventing multi threading?
> 
> Do you got hints, flames or suggestions?
> 
> cu
> Jörg
> 
> Am 23.02.2016 um 16:39 schrieb Neumann, Andreas: 
> 
>> Hi Régis,
>> 
>> QGIS server is single-threaded. You can't simply turn on multi-threaded
>> rendering in QGIS server. The other issue is that each Apache FCGI
>> process has it's own set of cache. So if you have 5-10 parallel Apache
>> threads or processes each thread/process has it's own cache. If your
>> client hits a thread that has the cache unititialized you will have wait
>> longer until this cache is fillled.
>> 
>> I once asked Marco whether one could
>> 
>> a) have a shared cache for all Apache threads or processes
> 
> There is no shared cache, because Apache spawns QGis-Processes with its
> own memory layout. these Processes know nothing about its neighbor, and
> you have a hard time to exchange data between all processes.
> How about a scheduler, which assigns requests to warmed up Qgis-processes?
> 
>> b) support multi-threaded rendering
>> 
>> But he said it would be very complicated to implement a) and b), if not
>> impossible. Maybe other devs have other views. Note that was about 2
>> years ago, when I last discussed this with Marco.
>> 
>> -
>> 
>> Nevertheless I believe there would be room for performance improvements
>> in QGIS server - if interested parties share their 

Re: [Qgis-developer] Questions about QgsEditorWidgetWrapper value() / setValue()

[Even Rouault]

> Thanks, that make sense. And it is actually implemented by
> QgsRelationReferenceWidgetWrapper.

Arg, I meant QgsValueRelationWidgetFactory. It is *not* by 
QgsRelationReferenceFactory, hence my question about the appropriatness of 
doing so.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [678] Multi-distance buffer approval notification.

[noreply]

Plugin Multi-distance buffer approval by pcav.
The plugin version "[678] Multi-distance buffer 1.0" is now approved
Link: http://plugins.qgis.org/plugins/MultiDistanceBuffer/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Questions about QgsEditorWidgetWrapper value() / setValue()

[Matthias Kuhn]

Hi Even

On 22/04/16 14:38, Even Rouault wrote:

Hi,

I'm trying to understand the abstraction of QgsEditorWidgetWrapper.

1) Semantics question
Am I right that there's no guarantee (and that's actually intended) that the
following pseudo-code is true :
setValue(v)
assert value() == v
It should in theory either return the same value or an invalid QVariant 
which should be interpreted by the outside world as "no change". But I 
admit that I doubt that all widgets effectively follow this rule.



For example in the QgsValueRelationWidgetWrapper(), value() returns the value
of the value column of the referenced layer, which corresponds to the key
provided to setValue().
And that's value() that is used when displaying the attribute table in table
view mode.
So this value() method is more a displayValue(), right ? And setValue() would
be setRawValue() / setSourceValue() ?


value() should return the real/raw value. Returning the display value is 
wrong.



2) Implementation of QgsRelationReferenceWidgetWrapper.
The value() method in that case actually returns the foreign key set by
setValue(). Is that intended ? To have similar behaviour as
QgsValueRelationWidgetWrapper, one could rather expect value() to return the
evaluation of the display expression, no ?
If the current behaviour is intended, is there something in the abstraction of
QgsEditorWidgetWrapper that could return the evaluation of the display
expression for a QgsRelationReferenceWidgetWrapper ?


For this there is QgsEditorWidgetFactory::representString 
https://qgis.org/api/classQgsEditorWidgetFactory.html#a6805c62cc859478b4d4715b3819ce24f


Matthias

Thanks

Even



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

Re: [Qgis-developer] [Server] performance questions

[Jörg Habenicht]

Hi Andreas, dear list,

sorry for the warm up of this old topic.

There is in deed a need to enable multi threading in Qgis-Server.

In our company we use around 60 different layer to lay some topics on
the map. This may be an extreme example to read, but quite common in our
environment, i.e. we can not lower this number significantly.

A warmed up QGis-Server process which already read and cached the
Configuration file qgis-xy.conf still needs around 20 seconds to
calculate the complete resulting map picture.

During this calculation there is only one thread working, serializing
the DB-requests, calculation the layer picture and mapping the picture
on the resulting picture.
The process is running on a multi core server. If we can utilize the
idle cores to do useful work, this can be an easy example to speed up
the process (significant).

I'd like to share my developing experience to do this change, but I
would need further information and some support to do some useful patches.

I have scanned the git-Qgis sources (commit
81744ecf90a8f6c1e2e94fdacb07e3dca6987dcc) for a suitable multithreading
entry. Found QgsMapRenderer::render() because of the line "while (
li.hasPrevious() )". It seems in this loop the layers are painted in
serial onto the resulting picture.
If I can build an auto parallel computing with QtConcurrent in this
place there seems to be the most gain. I mean to parallelize the loop
with concurrent DB requests, concurrent painting in separate pictures
and in serial map the single pictures onto the result picture.

Right now I don't know if I can do DB requests in parallel, or where the
code for database requests is buried.
And how about the calls inside the loop, are there side effects
preventing multi threading?


Do you got hints, flames or suggestions?


cu
Jörg


Am 23.02.2016 um 16:39 schrieb Neumann, Andreas:
> Hi Régis,
> 
> QGIS server is single-threaded. You can't simply turn on multi-threaded
> rendering in QGIS server. The other issue is that each Apache FCGI
> process has it's own set of cache. So if you have 5-10 parallel Apache
> threads or processes each thread/process has it's own cache. If your
> client hits a thread that has the cache unititialized you will have wait
> longer until this cache is fillled.
> 
> I once asked Marco whether one could
> 
> a) have a shared cache for all Apache threads or processes

There is no shared cache, because Apache spawns QGis-Processes with its
own memory layout. these Processes know nothing about its neighbor, and
you have a hard time to exchange data between all processes.
How about a scheduler, which assigns requests to warmed up Qgis-processes?

> 
> b) support multi-threaded rendering
> 
> But he said it would be very complicated to implement a) and b), if not
> impossible. Maybe other devs have other views. Note that was about 2
> years ago, when I last discussed this with Marco.
> 
> -
> 
> Nevertheless I believe there would be room for performance improvements
> in QGIS server - if interested parties share their efforts (be it dev
> time or financial resources).
> 
[snip]
> 
> Andreas
> 
[snip]
> 
>  
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

-- 

mWerk GmbH
Dipl.-Ing. Jörg Habenicht
Landwehrstr. 76
30519 Hannover
(T) +49 511  8033
(F) +49 511  8041
(E) j...@mwerk.net
Amtsgericht Hannover HRB 206522
Geschäftsführer
Reiner Brachvogel
Dennis Kornehl
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [981] DIVI QGIS Plugin approval notification.

[noreply]

Plugin DIVI QGIS Plugin approval by pcav.
The plugin version "[981] DIVI QGIS Plugin 0.9 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/DiviPlugin/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Questions about QgsEditorWidgetWrapper value() / setValue()

[Even Rouault]

Hi,

I'm trying to understand the abstraction of QgsEditorWidgetWrapper.

1) Semantics question
Am I right that there's no guarantee (and that's actually intended) that the 
following pseudo-code is true :
setValue(v)
assert value() == v 

For example in the QgsValueRelationWidgetWrapper(), value() returns the value 
of the value column of the referenced layer, which corresponds to the key 
provided to setValue().
And that's value() that is used when displaying the attribute table in table 
view mode.
So this value() method is more a displayValue(), right ? And setValue() would 
be setRawValue() / setSourceValue() ?

2) Implementation of QgsRelationReferenceWidgetWrapper.
The value() method in that case actually returns the foreign key set by 
setValue(). Is that intended ? To have similar behaviour as 
QgsValueRelationWidgetWrapper, one could rather expect value() to return the 
evaluation of the display expression, no ?
If the current behaviour is intended, is there something in the abstraction of 
QgsEditorWidgetWrapper that could return the evaluation of the display 
expression for a QgsRelationReferenceWidgetWrapper ?

Thanks

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Cannot add new GeoPackage connection to DB Manager

[Stefan Ziegler]

Hi

When trying to add a new GeoPackage connection:

- right mouse click on Spatialite/Geopackage
- New Connection
- Choose Geopackage by double-clicking


I get the following error:

TypeError: TreeItem.itemChanged[] signal has 0 argument(s) but 1 provided

Traceback (most recent call last):
  File
"/usr/local/qgis_master/share/qgis/python/plugins/db_manager/db_tree.py",
line 103, in newConnection
self.mainWindow.invokeCallback(item.addConnectionActionSlot, index)
  File
"/usr/local/qgis_master/share/qgis/python/plugins/db_manager/db_manager.py",
line 288, in invokeCallback
callback(self.tree.currentItem(), self.sender(), self, *params)
  File
"/usr/local/qgis_master/share/qgis/python/plugins/db_manager/db_plugins/spatialite/plugin.py",
line 102, in addConnectionActionSlot
index.internalPointer().itemChanged.emit(index.internalPointer())
TypeError: TreeItem.itemChanged[] signal has 0 argument(s) but 1 provided

I'm on Ubuntu 14.04 and QGIS master. Can anyone confirm this? The
Geopackage can be displayed in QGIS when using the standard vector file
dialog.

best regards
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer