[Qgis-developer] QtCreator and QGIS on ubuntu

[CABO]

Hello,

I am trying to follow Tim's blog post[1] on how to build QGIS using QtCreator 
on linux. The blog post is a couple of years old now and I have found a couple 
of replaced/extra packages I needed to install to get to the error below. I am 
at the step where I am using the CMake Wizard to run CMake and create the "cbp" 
file. It seems like it cannot find the QCA library:

CMake Error at cmake/FindQCA.cmake:64 (message):
  Could not find QCA
Call Stack (most recent call first):
  CMakeLists.txt:322 (FIND_PACKAGE)

If I haven't already got the QCA dependency, which library should I install?


Regards, Casper

1: http://kartoza.com/how-to-build-and-debug-qgis-with-qtcreator/

___
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] Decoupling core/data and GUI part of widgets in 3.0

[Patrick Valsecchi]

On Wed, Aug 31, 2016 at 4:38 PM, Matthias Kuhn  wrote:

> On 08/31/2016 04:12 PM, Patrick Valsecchi wrote:
> > That would force the plugin writters to provide two plugins:
>
> Not really, you can add two register calls in one plugin.
>
> Then the plugin woud only work for QGIS desktop and not for QGIS server...
___
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] Decoupling core/data and GUI part of widgets in 3.0

[Nyall Dawson]

On 31 August 2016 at 21:20, Matthias Kuhn  wrote:
> Hi,
>
> On 08/31/2016 12:41 PM, Nyall Dawson wrote:
>> On 31 August 2016 at 16:56, Matthias Kuhn  wrote:
>>> Hi,
>>>
>>> I've already got some ideas because it affects QField (where I'm about
>>> to drop the whole gui lib) as well.
>>>
>>> Implementing this in QGIS instead of QField is much preferred.
>>>
>>> From a technical perspective, I would propose to use a tree-like
>>> structure based on QVariants.
>>> They've got all it takes for this:
>>>
>>> QVariantMap can handle tree structures of key value pairs (for XML child
>>> nodes), a key "__attributes__" can be added to save the XML element
>>> attributes into.
>>>
>>> This way, the information can be read without knowledge about a
>>> particular widget's implementation details and is available directly
>>> from core. The widgets (or whatever part) can add the semantics on top
>>> in their own library.
>>
>> Just to clarify - are you proposing that only a map of widget
>> configuration is moved to core? I'd say the representValue function
>> for each widget should also should be moved across, otherwise we'll
>> end up with multiple code paths reimplementing the logic from each
>> widget + plugins having to redo this themselves.
>
> Good point,
>
> that will also be nice to have in core.
>
> In this case we'll end up with two registries and two factories
> (although only a few widgets will need core functionality).
> Or did you have a different idea in mind?

This is what I was thinking - I can't think of a nice way around this.

Nyall


>
> 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] Decoupling core/data and GUI part of widgets in 3.0

[Richard Duivenvoorde]

On 31-08-16 13:38, Denis Rouzaud wrote:

>>> >> So that's the inoffical QEP, I'd say we skip the official part.
>> > Fine by me - a QEP would have just been a way to get yourself and
>> > Denis to approve a design for this :)
> Let's go like this, but don't disappoint me ;)

Mmm, I think a QEP is not only to discuss but also to give some
background/context. To be honest I understand  'decoupling' between
model/view gui/core, but you lost me when you talked " to use a
tree-like structure based on QVariants".

Would it not be a good idea (also for future reference) to write a short
QEP, with
- the problem we have
- some context + link to your backgroud info
- maybe some more layman description of the used solution?
- some examples (Python/cpp?)

I really like the way Python uses it PEP-documents: you get an idea WHY
in history something is done.

I'm even happy to try to write it, IF I could follow the discussion :-(

Regards,

Richard Duivenvoorde
___
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] No plugins today?

[Richard Duivenvoorde]

On 31-08-16 15:02, Kari Salovaara wrote:
> Hi,
> 
> On win64 latest Master version gives me error:
> Error reading repository: QGIS Virallinen Liitännäisten Etäkirjasto
> 
> Server response is 200 OK, but doesn't contain plugin metatada. This is
> most likely caused by a proxy or a wrong repository URL. You can
> configure proxy settings in QGIS options.
> 
> Annoying 
> Boundless repo OK so probably not program error.

Hi Kari,

is it still a problem? Because for master the url that is used is:

https://plugins.qgis.org/plugins/plugins.xml?qgis=2.17
(for master_2)
https://plugins.qgis.org/plugins/plugins.xml?qgis=2.99
(for real master)
which now work both

(could be a timeout? Because if I'm correct the master ones are not cached)

Regards,

Richard

___
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] Qgis resource sharing VS processing for script sharing

[Akbar Gumbira]

Hi Michaël,

To be honest, when I implemented it to support sharing python processing
scripts (https://github.com/akbargumbira/qgis_resources_sharing/issues/11),
I didn't really think much about this concern that you raise. The one in
processing toolbox is very nice and focused only on the processing scripts.
The only thing missing from the one in the toolbox is to search the script
itself (?) If the number of the scripts is getting bigger, users would
probably find it hard to search for scripts they are looking for. The idea
itself is from Ale and Victor, so perhaps they can share their vision?

Cheers


On Thu, Sep 1, 2016 at 1:17 AM, kimaidou  wrote:

> Hi QGIS folks,
>
> Since the release of the great plugin "Qgis resource sharing" (1) (2) & (3)
> we can share many resources, and processing scripts are among them.
>
> We have also another Processing dedicated github repo for sharing Python
> scripts, R scripts and models (4)
>
> Regarding this current situation, what should we tell users and
> developpers who want to share Processing scripts ? What shoud they use to
> share their scripts ?
>
> Once the new plugin will be able to let users share R scripts and
> processing models, could we get rid of the historical Processing sharing
> tool ?
>
> Thanks in advance for your ideas about this topic.
>
> Cheers
> Michaël
>
>
> (1) https://github.com/akbargumbira/qgis_resources_
> sharing/releases/tag/v0.5.1
> (2) http://www.akbargumbira.com/qgis_resources_sharing/
> (3) https://github.com/qgis/QGIS-Resources
>
> (4) https://github.com/qgis/QGIS-Processing
>
> ___
> 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
>



-- 

*---*
*Akbar Gumbira *
*www.akbargumbira.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] Inconsistent usage of field aliases

[Spencer Gardner]

I recently worked with a map where another user had defined aliases on a
couple of fields. While trying to build expressions in the field calculator
and other contexts I became confused because the alias names that I saw in
the attribute table were not available in the expression builder. After
some searching (and panic over the thought that the shapefile was
corrupted) I realized that the expression builder refers to fields by their
actual name without any reference to the alias. Since I wasn't aware that
aliases had been set it didn't occur to me to check there.

It is highly confusing to use column aliases in some contexts and actual
names in other contexts. To improve user experience this should be unified.
There was a mailing list conversation in 2014

about this issue but as far as I can tell nothing was done about it.

There seem to be good arguments for using actual names and for using
aliases so I think the best solution will need to accommodate both usage
patterns. What is clear is that using aliases in some contexts and not in
others is not an intuitive design.

Has this been discussed more recently than my 2014 reference? If not, the
API changes to 3.0 might be a good opportunity to tackle this usability
issue.

Regards,
Spencer Gardner
___
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] Qgis resource sharing VS processing for script sharing

[kimaidou]

Hi QGIS folks,

Since the release of the great plugin "Qgis resource sharing" (1) (2) & (3)
we can share many resources, and processing scripts are among them.

We have also another Processing dedicated github repo for sharing Python
scripts, R scripts and models (4)

Regarding this current situation, what should we tell users and developpers
who want to share Processing scripts ? What shoud they use to share their
scripts ?

Once the new plugin will be able to let users share R scripts and
processing models, could we get rid of the historical Processing sharing
tool ?

Thanks in advance for your ideas about this topic.

Cheers
Michaël


(1)
https://github.com/akbargumbira/qgis_resources_sharing/releases/tag/v0.5.1
(2) http://www.akbargumbira.com/qgis_resources_sharing/
(3) https://github.com/qgis/QGIS-Resources

(4) https://github.com/qgis/QGIS-Processing
___
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] Plugin repository wiki page

[Anita Graser]

On Tue, Aug 30, 2016 at 9:26 PM, Paolo Cavallini 
wrote:

> Il 30/08/2016 18:58, Anita Graser ha scritto:
> > Hi,
> >
> > Is there anything on the plugin repo wiki page that we still need? I
> > reviewed it and it seems pretty much outdated:
> > http://hub.qgis.org/projects/quantum-gis/wiki/PluginRepository
> >
> > It also mentions "trusted" users, which causes confusion with our
> > current effort to establish trusted plugin authors. (See comment
> > in http://gis.stackexchange.com/questions/203116/what-does-
> the-trusted-flag-mean-for-qgis-plugins)
> >
> > I suggest deleting the wiki page.
>
> +1
> Thanks Anita for raising this.
>


​I'll move on and delete it. Bellow, you find the content for future
reference:​​

​---​

​This is the entry point for those interested in working on the plugin
repository. The plugin repository is a django application. The source code
for the application is hosted on github:

https://github.com/qgis/qgis-django

If you would like write access to the above repository, please contact Tim
Sutton (t...@linfiniti.com).

Note the repository was changed from a personal repository to a community
one - please note the new url above.


h2. The pieces

* http://plugins.qgis.org - the upload and download app
* http://hub.qgis.org the bugtracker for the plugins
* http://hub.qgis.org/projects/qgis-django/issues the bugtracker for the
webapp


h2. Version 1.0

This section lists wanted features for the first version of the plugin
repository. Once everything is on its place, we can probably switch from
the original repository now hosted at pyqgis.org and require all the plugin
developers to upload the plugins to the new repository. From that time, no
more public 3rd party repositories will be encouraged - everyone should be
happy to use the official repository :-)

For easy usage of the repository, a command line tool (supposedly a python
module) should be provided with qgis that will upload new plugin version,
given just the package file, changelog and username/password. Later we
could even create a plugin for convenience with simple GUI for instant
publishing.

List of views and actions in the plugin repository application:
* views for registered users:
** list my plugins
** plugin details with editing (remove incorrect upload, delete plugin, add
owner etc.)
* actions for registered users:
** add plugin / edit plugin
** upload new plugin version
* views for all users:
** list plugins (main page)
*** show either featured (default) or all plugins
*** show plugins of a particular user
*** sorting: recently added/updated, most downloaded
** show plugin details
** repository xml compatible with original repository

Notes:
* user authentication - osgeo LDAP should be used (no more new logins
please!), using HTTPS so that the passwords are not visible (see
http://packages.python.org/django-auth-ldap/)
* there is always one or more owners for a plugin, any owner of a plugin
can add new people as co-owners. Only owners are allowed to upload new
versions, edit or completely remove a plugin. If the owner of a plugin
disappears, a new owner could be assigned for the plugin by the admins
* download counts
** downloading of plugin packages should be redirected in order to
calculate download count directly (without accessing web server stats)
* featured plugins
** admins might want to mark interesting (and well behaving) general
purpose plugins as featured to make them more visible from the less
interesting ones
* trusted users
** a simple protection from malicious users: everyone is at the beginning
marked as untrusted, the uploaded plugins are not visible until an admin
doesn't review the code and mark the user as trusted. Plugins uploaded by
trusted users are immediately visible - this still leaves some space for
malicious users (first upload something good, get trusted, then upload
something bad), however we don't have resources to check all the updated
plugins. Malicious users - once detected - get blocked forever.
* plugin uploading: user should only select a file for upload and provide a
changelog - the rest should be handled on the server
* plugin versioning: for each plugin, the entire release history will be
kept. By default users will see only the last version. For plugins that
make distinction between development (experimental?) and stable versions,
there should be an option when uploading the plugin whether that is a
development version. The owner should be able to mark also manually which
version is the last stable and last development (experimental) version.
* upload checks
** check that the uploaded file has an acceptable size (e.g. < 1MB)
** check that the uploaded file is valid zip archive
** check that the plugin exists, user is owner of the plugin, this version
does not exist yet, ...
** parse plugin metadata and update the plugin details from it: nowadays
the plugins store metadata in __init__.py file, but it has been sugg

Re: [Qgis-developer] Decoupling core/data and GUI part of widgets in 3.0

[Matthias Kuhn]

Hi

On 08/31/2016 04:12 PM, Patrick Valsecchi wrote:
> Hi,
> 
> On Wed, Aug 31, 2016 at 1:20 PM, Matthias Kuhn  > wrote:
> 
> On 08/31/2016 12:41 PM, Nyall Dawson wrote:
> > Just to clarify - are you proposing that only a map of widget
> > configuration is moved to core? I'd say the representValue function
> > for each widget should also should be moved across, otherwise we'll
> > end up with multiple code paths reimplementing the logic from each
> > widget + plugins having to redo this themselves.
> 
> Good point,
> 
> that will also be nice to have in core.
> 
> In this case we'll end up with two registries and two factories
> (although only a few widgets will need core functionality).
> Or did you have a different idea in mind?
> 
> 
> 
> That would force the plugin writters to provide two plugins:

Not really, you can add two register calls in one plugin.

> I do agree that representValue would be useful in core, but that has
> some cost to split the thing in two. Or maybe reprensent value is
> something totally different from the widgets for editing the fields and
> they don't have to be in 1-1 relation.

As long as there is no representValue() method (most of the widgets
actually) I don't think the core part is required and just some generic
default module can handle this.

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] Decoupling core/data and GUI part of widgets in 3.0

[Patrick Valsecchi]

Hi,

On Wed, Aug 31, 2016 at 1:20 PM, Matthias Kuhn  wrote:

> On 08/31/2016 12:41 PM, Nyall Dawson wrote:
> > Just to clarify - are you proposing that only a map of widget
> > configuration is moved to core? I'd say the representValue function
> > for each widget should also should be moved across, otherwise we'll
> > end up with multiple code paths reimplementing the logic from each
> > widget + plugins having to redo this themselves.
>
> Good point,
>
> that will also be nice to have in core.
>
> In this case we'll end up with two registries and two factories
> (although only a few widgets will need core functionality).
> Or did you have a different idea in mind?
>
>

That would force the plugin writters to provide two plugins: one for core
that could be used for qgis server as well and one for gui. Then how do we
make sure the user install the two plugins at the same version? I guess the
GUI plugin will depend on the core one...

I do agree that representValue would be useful in core, but that has some
cost to split the thing in two. Or maybe reprensent value is something
totally different from the widgets for editing the fields and they don't
have to be in 1-1 relation.

CU
___
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] No plugins today?

[Kari Salovaara]

Hi,

On win64 latest Master version gives me error:
Error reading repository: QGIS Virallinen Liitännäisten Etäkirjasto

Server response is 200 OK, but doesn't contain plugin metatada. This is
most likely caused by a proxy or a wrong repository URL. You can
configure proxy settings in QGIS options.

Annoying 
Boundless repo OK so probably not program error.

Cheers,
Kari

___
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 [1094] Gban approval notification.

[noreply]

Plugin Gban approval by pcav.
The plugin version "[1094] Gban 1.0 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/gban/
___
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 [1095] AnnotationManager approval notification.

[noreply]

Plugin AnnotationManager approval by pcav.
The plugin version "[1095] AnnotationManager 0.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/annotationManager/
___
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 [1000] Qdraw approval notification.

[noreply]

Plugin Qdraw approval by pcav.
The plugin version "[1000] Qdraw 1.5 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/qdraw/
___
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 [999] Qgeric approval notification.

[noreply]

Plugin Qgeric approval by pcav.
The plugin version "[999] Qgeric 1.6 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/qgeric/
___
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] Decoupling core/data and GUI part of widgets in 3.0

[Denis Rouzaud]

On 08/31/2016 12:41 PM, Nyall Dawson wrote:
> On 31 August 2016 at 16:56, Matthias Kuhn  wrote:
>> Hi,
>>
>> I've already got some ideas because it affects QField (where I'm about
>> to drop the whole gui lib) as well.
>>
>> Implementing this in QGIS instead of QField is much preferred.
>>
>> From a technical perspective, I would propose to use a tree-like
>> structure based on QVariants.
>> They've got all it takes for this:
>>
>> QVariantMap can handle tree structures of key value pairs (for XML child
>> nodes), a key "__attributes__" can be added to save the XML element
>> attributes into.
>>
>> This way, the information can be read without knowledge about a
>> particular widget's implementation details and is available directly
>> from core. The widgets (or whatever part) can add the semantics on top
>> in their own library.
> Just to clarify - are you proposing that only a map of widget
> configuration is moved to core? I'd say the representValue function
> for each widget should also should be moved across, otherwise we'll
> end up with multiple code paths reimplementing the logic from each
> widget + plugins having to redo this themselves.
>
>> So that's the inoffical QEP, I'd say we skip the official part.
> Fine by me - a QEP would have just been a way to get yourself and
> Denis to approve a design for this :)

Let's go like this, but don't disappoint me ;)
___
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] Decoupling core/data and GUI part of widgets in 3.0

[Matthias Kuhn]

Hi,

On 08/31/2016 12:41 PM, Nyall Dawson wrote:
> On 31 August 2016 at 16:56, Matthias Kuhn  wrote:
>> Hi,
>>
>> I've already got some ideas because it affects QField (where I'm about
>> to drop the whole gui lib) as well.
>>
>> Implementing this in QGIS instead of QField is much preferred.
>>
>> From a technical perspective, I would propose to use a tree-like
>> structure based on QVariants.
>> They've got all it takes for this:
>>
>> QVariantMap can handle tree structures of key value pairs (for XML child
>> nodes), a key "__attributes__" can be added to save the XML element
>> attributes into.
>>
>> This way, the information can be read without knowledge about a
>> particular widget's implementation details and is available directly
>> from core. The widgets (or whatever part) can add the semantics on top
>> in their own library.
> 
> Just to clarify - are you proposing that only a map of widget
> configuration is moved to core? I'd say the representValue function
> for each widget should also should be moved across, otherwise we'll
> end up with multiple code paths reimplementing the logic from each
> widget + plugins having to redo this themselves.

Good point,

that will also be nice to have in core.

In this case we'll end up with two registries and two factories
(although only a few widgets will need core functionality).
Or did you have a different idea in mind?

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] Adding buttons to the attribute table toolbar

[Hugo Mercier]

Ah indeed :)
I see. I don't know very well this part of the code, but I don't think
there is a direct way to add a button in the attribute table.

You could always use QT introspection to look for the QToolBar and add
your own button ... but it's quite hacky.

Or we could extend a bit the concept of action to allow the action to be
called with a list of features, rather than with only one feature. By
default it would call the action for each selected feature. If needed,
we could add a way for the user to add its own "multiple feature"
version of the action.

On 31/08/2016 11:40, Neumann, Andreas wrote:
> Hi Hugo,
> 
> Yes - I know (we paid for that ;-) ). But this is more for "per-feature"
> actions - whereas I am after actions on a set of features (the selected
> features) - so in my case the custom buttons should be only once in the
> toolbar of the attribute table - not for every feature.
> 
> Thanks,
> 
> Andreas
> 
> On 2016-08-31 11:33, Hugo Mercier wrote:
> 
>> Hi Andreas,
>>
>> I think you can create Python-based actions and use the new option "show
>> them in the attribute table"
>>
>> On 31/08/2016 09:27, Neumann, Andreas wrote:
>>> Hi,
>>>
>>> Is it possible to add my own buttons to the toolbar of the attribute
>>> table window?
>>>
>>> If yes - do you have some sample code how to do this?
>>>
>>> My goal is to trigger some Python code that would process the currently
>>> selected features of the attribute table.
>>>
>>> Thanks,
>>>
>>> Andreas
>>>
>>>  
>>>
>>>
>>> ___
>>> 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
> 
>  
> 
>  
___
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] Decoupling core/data and GUI part of widgets in 3.0

[Nyall Dawson]

On 31 August 2016 at 16:56, Matthias Kuhn  wrote:
> Hi,
>
> I've already got some ideas because it affects QField (where I'm about
> to drop the whole gui lib) as well.
>
> Implementing this in QGIS instead of QField is much preferred.
>
> From a technical perspective, I would propose to use a tree-like
> structure based on QVariants.
> They've got all it takes for this:
>
> QVariantMap can handle tree structures of key value pairs (for XML child
> nodes), a key "__attributes__" can be added to save the XML element
> attributes into.
>
> This way, the information can be read without knowledge about a
> particular widget's implementation details and is available directly
> from core. The widgets (or whatever part) can add the semantics on top
> in their own library.

Just to clarify - are you proposing that only a map of widget
configuration is moved to core? I'd say the representValue function
for each widget should also should be moved across, otherwise we'll
end up with multiple code paths reimplementing the logic from each
widget + plugins having to redo this themselves.

>
> So that's the inoffical QEP, I'd say we skip the official part.

Fine by me - a QEP would have just been a way to get yourself and
Denis to approve a design for this :)

Nyall


>
> Matthias
>
> On 08/31/2016 08:48 AM, Richard Duivenvoorde wrote:
>>
>> +1 from me too
>>
>> As a project we should really take the opportunity of a 3.0 branch to
>> review this kind of architectural cleanups and focus on a healthy code
>> base more then on new features for the .0 version, in my opinion.
>>
>> best off course if core dev's take the lead in this
>>
>> Regards,
>>
>> Richard
>>
>>
>>
>> On 31-08-16 08:37, Nathan Woodrow wrote:
>>> I'm a big +1 on that.  I will add my notes on a QEP if one is opened
>>>
>>> (Hopefully I can be a bit more active in the project after a bit of a break)
>>>
>>> - Nathan
>>>
>>> On Wed, Aug 31, 2016 at 4:29 PM, Neumann, Andreas >> > wrote:
>>>
>>> Hi all, Hi Nyall, Matthias and Denis,
>>>
>>> After some discussion with Nyall we stumbled again over the
>>> inconvenience that widgets in QGIS mix data (core) and GUI part.
>>> This effects many places in QGIS where you want to address the
>>> display value of a widget instead of the raw value: QGIS Server
>>> (e.g. GetFeatureInfo Requests), Print Composer, Labels, Save to
>>> Spreadsheet with human readable values, and many more.
>>>
>>> So before people are introducing more and more widgets (which is
>>> nice) I would suggest to first improve our widget infrastructure for
>>> QGIS 3.0 to decouple the Core/data part from the GUI part, which
>>> would allow code to access all widget configuration and
>>> properties without having to deal with the GUI part of the widget.
>>> Nyall mentioned that the symbology rendering separates this nicely,
>>> but the attribute widgets do not.
>>>
>>> Nyall suggested to do a QEP for that to discuss the implications and
>>> how this can be cleanly designed.
>>>
>>> Matthias - since you are "the widget guy" - do you want to take a
>>> lead on this QEP? Or should I ask Nyall?
>>>
>>> Thanks,
>>>
>>> Andreas
>>>
>>>
>>>
>>> ___
>>> 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
>>>
>>
>> ___
>> 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
___
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] Adding buttons to the attribute table toolbar

[Hugo Mercier]

Hi Andreas,

I think you can create Python-based actions and use the new option "show
them in the attribute table"

On 31/08/2016 09:27, Neumann, Andreas wrote:
> Hi,
> 
> Is it possible to add my own buttons to the toolbar of the attribute
> table window?
> 
> If yes - do you have some sample code how to do this?
> 
> My goal is to trigger some Python code that would process the currently
> selected features of the attribute table.
> 
> Thanks,
> 
> Andreas
> 
>  
> 
> 
> ___
> 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

[Qgis-developer] pyqgis

[Ioan Ferencik]

Hello There,
ia'd like to know how can I get programatically
in pyqgis all project properties stored inside the properties section of a
project file

I know i can read them using QDomDocument or lxml but I want to retrieve
them from the QgsProject object






  
  



false


  



  false







  2
  true
  MU



false


false

  WGS84

8

  
  
  


  0
  255
  255
  255
  255
  255
  255


  2
  current_layer
  off
  0


  


  

None


  false


  +proj=merc +lon_0=0 +k=1 +x_0=0
+y_0=0 +datum=WGS84 +units=m +no_defs
  EPSG:3395
  1353
  1


  
  
  
  true
  255
  

conditions unknown
90

  meters
  m2


  
  


Thanks in advance
___
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] Adding buttons to the attribute table toolbar

[Neumann, Andreas]

Hi, 

Is it possible to add my own buttons to the toolbar of the attribute
table window? 

If yes - do you have some sample code how to do this? 

My goal is to trigger some Python code that would process the currently
selected features of the attribute table. 

Thanks, 

Andreas

  ___
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] Python and strange results using layer(.dataProvider()).getFeatures(...)

[CABO]

Hi Matthias and Nyall,

Thanks for your comments. 

I've created the issue: http://hub.qgis.org/issues/15505

Regards, Casper

-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Nyall Dawson
Sent: 31. august 2016 01:09
To: Matthias Kuhn
Cc: qgis-developer
Subject: Re: [Qgis-developer] Python and strange results using 
layer(.dataProvider()).getFeatures(...)

On 30 August 2016 at 23:52, Matthias Kuhn  wrote:
> Hi Casper
>
> On 08/30/2016 02:59 PM, Casper Børgesen (CABO) wrote:
>> Hi Nathan
>>
>>
>>
>> Thanks for clarifying that, I’ll try to put my faith in the layer. My 
>> question is then, why does the layer only respond with 2 features 
>> when I ask it for max 3 features, since 4 – 1 = 3?
>>
>
> I guess (no verification done) that in the background the limit is 
> forwarded to the dataprovider which returns 3 features from which 1 is 
> filtered out by the layer so only 2 remain.
>
> Please report this as a bug. I'm not sure if an action will be taken, 
> most of the "fixes" to this which I can think of defeat the purpose of 
> sending as few requests as possible to the database, but on the other 
> hand, this situation here can really lead to confusion.

I'd say something like this could work. In QgsVectorLayerFeatureIterator:
- take the feature request limit for mProviderRequest
- if deleted features are present in the edit buffer, add the number of deleted 
features to the limit in mProviderRequest
- if changed feature attributes are present, and the request is an expression 
based request, add the number of changed features to the limit (could be 
smarter here and check which attributes are required by the filter + which have 
changed)
- if geometry changes are present and a filter rect is in place then add the 
number of geometry changes to the limit

That would still gain us most of the benefits of feature limits + handle this 
case, and the only penalty is present when the bug would otherwise show itself.

Nyall



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