Re: [Qgis-developer] Discussion on the QGIS grant proposals

[Vincent Picavet (ml)]

Hello,

Thanks Andreas for raising this topic and clearing up facts and giving
your position.
I agree 100% with what you stated, and I do think this is something
which should be emphasized much more, if not even constrained.

Some more notes below.

On 22/09/2016 08:14, Neumann, Andreas wrote:
> [..] Now comes my personal position/opinion - note that this is not
> the official opinion of the QGIS.ORG board.
Same here

> I would personally welcome, if this round of the QGIS grants program 
> could focus on the QGIS 3.0 release.

This is indeed the main challenge for QGIS in the coming months.
Focusing on all aspects of making QGIS3 a real thing should be our top
priority when confronted to choices.

> I personally also think that the QGIS grants program, at least at
> the current time, should not pay for development of new features (at
> least not features visible in the GUI for the users). These features
> can be "relatively easy" funded by companies and government
> organizations out there. So our limited QGIS.ORG funds should be
> rather spent a) to community work or b) infrastructure work or c)
> development work in the core of QGIS, such as API modifications, code
> redesign - stuff that isn't really visible to the users, but
> essential for the success of the project.

From a developer's company point of view, I can only applause to this.
We have numerous demands for new features with paid contract, and the
global pace of feature development in QGIS is really fast. The very
large majority of them are funded by clients.
Meanwhile, all tasks like refactoring, code cleaning, bug triaging,
infrastructure and long term core development efforts are really
difficult to get funded. Public sector organization generally can't pay
for this due to public tender bid constraints, and generally end-users
do not realize that this kind of work is at the same time necessary and
time consuming.
In my opinion, the role of QGIS organization, hence the QGIS Grant
program, is to compensate for this disequilibrium.

> Documentation and PyQT documentation work is already budgeted in our 
> annual budget. The money for 2016 hasn't even been spent for both
> items. So I think we should first use the budgeted money for such
> work. I think that user and developer documentation should be an
> ongoing effort and should be supported every year, und budgeted every
> year as such. We can increase the documentation budget positions next
> year, should it be necessary. In reality, it was more a lack of
> people willing to do the work, rather than a lack of funding. So, I
> am happy to see some proposals around documentation and developer
> documentation - so it seems that we have some volunteers. I just
> suggest that we consider documentation work separately and do it
> anyway - regardless of the outcome of the voting on these items.

Documentation is crucial, and I am also fully in favor of having a
dedicated yearly budget to improve it. It should be stated in the QGIS
grant application call too.

> Several proposals have a very limited local focus, only useful to
> one single country, or a very limited subset of our users. I suggest
> that such proposals could best be financed by local user groups or
> interest groups. It can't be the purpose of the QGIS grants program
> to finance such projects.

+1 also

Since I have more or less the same priority list as Andreas, I will also
add a few comments below.

> ---
> 
> Here is my own personal list of priorities:

In my own priority order :

> ​11)​ Introduce everything necessary for QGIS3 to OSGeo4W
> 
> The majority of our users are on Windows (like it or not). This is
> the platform that matters most in our user base. The introduction of
> QGIS 3.0 means porting everything to newer libraries and means a lot
> of work. This should be one of our main priorities. Jürgen does it
> works silently in the background many days of work each year that go
> unnoticed. Jürgen usually only hears complaints if something fails -
> maybe not so much praise. Having Windows nightly builds and releases
> early on in the life cycle of QGIS 3.x means that it can be well
> tested. So - also really important to our project.

This is to me the most important item for QGIS3. Jef does a huge work,
something difficult and not the most passionating thing to work on. We
do need to have the platform stable and ready as soon as possible to
have feedback on QGIS 3 very early in the release process.

> ​18)​ QGIS 3 ticket handling and API refactoring
> 
> This is really time critical, and past discussions around QGIS 3.0
> has shown that there is a lack of project management work and
> coordination. I regard this proposal as very useful for the QGIS 3.0
> release.

Disclaimer : This proposal is by Oslandia
We proposed this item exactly because we observed that we were lacking
project management efforts, and especially regarding the QGIS3 release.
Having time 

[Qgis-developer] Discussion on the QGIS grant proposals

[Neumann, Andreas]

Dear QGIS users, developers, voting members and user group
representatives, 

As you may have noticed, there is a first round of a QGIS grant program,
fueled by the donations and sponsorship money we received in the past
months. Tim Sutton, chair of the QGIS project, has publicized this
program repeatedly on several channels. 

The good thing is that we got some very good proposals. In total 18
proposals, adding up to a total grant sum of 101 k EUR. You can see all
proposals at
https://drive.google.com/file/d/0B__vDnQXCKiwYTIyWmRSbi1hMWM/view?usp%3Dsharing=D=1474526025402000=AFQjCNFhp43Lkxw3aBCed9-9luJpnR0oWg


Please note that we can only spend 20k EUR in this first round. So there
are tough decisions to make. Note that proposals that can't make it in
the first round, can be kept in a waiting list and may apply again in
the next round of a grants program. If a proposal can't be accepted in
the first round, this doesn't mean it isn't valuable and useful to the
QGIS.ORG project. 

The QGIS PSC will honor the opinion of the voting members, the OSGEO
representative and the user group representatives on how to spend this
limited money wisely. Alltogether a group of currently 27 people (13
qgis user group represenatives, 13 community voting members, 1 OSGEO
representative). This is kind of the "parliament" of the QGIS project
when it comes to such decisions. 

-- 

Now comes my personal position/opinion - note that this is not the
official opinion of the QGIS.ORG board. 

I would personally welcome, if this round of the QGIS grants program
could focus on the QGIS 3.0 release. 

I personally also think that the QGIS grants program, at least at the
current time, should not pay for development of new features (at least
not features visible in the GUI for the users). These features can be
"relatively easy" funded by companies and government organizations out
there. So our limited QGIS.ORG funds should be rather spent a) to
community work or b) infrastructure work or c) development work in the
core of QGIS, such as API modifications, code redesign - stuff that
isn't really visible to the users, but essential for the success of the
project.  

Documentation and PyQT documentation work is already budgeted in our
annual budget. The money for 2016 hasn't even been spent for both items.
So I think we should first use the budgeted money for such work. I think
that user and developer documentation should be an ongoing effort and
should be supported every year, und budgeted every year as such. We can
increase the documentation budget positions next year, should it be
necessary. In reality, it was more a lack of people willing to do the
work, rather than a lack of funding. So, I am happy to see some
proposals around documentation and developer documentation - so it seems
that we have some volunteers. I just suggest that we consider
documentation work separately and do it anyway - regardless of the
outcome of the voting on these items. 

Several proposals have a very limited local focus, only useful to one
single country, or a very limited subset of our users. I suggest that
such proposals could best be financed by local user groups or interest
groups. It can't be the purpose of the QGIS grants program to finance
such projects. 

--- 

Here is my own personal list of priorities: 

​18)​ QGIS 3 ticket handling and API refactoring 

This is really time critical, and past discussions around QGIS 3.0 has
shown that there is a lack of project management work and coordination.
I regard this proposal as very useful for the QGIS 3.0 release. 

​11)​ Introduce everything necessary for QGIS3 to OSGeo4W 

The majority of our users are on Windows (like it or not). This is the
platform that matters most in our user base. The introduction of QGIS
3.0 means porting everything to newer libraries and means a lot of work.
This should be one of our main priorities. Jürgen does it works silently
in the background many days of work each year that go unnoticed. Jürgen
usually only hears complaints if something fails - maybe not so much
praise. Having Windows nightly builds and releases early on in the life
cycle of QGIS 3.x means that it can be well tested. So - also really
important to our project. 

​2)​ Implement a flexible properties framework in QGIS 

This is the kind of under-the-hood API changes and improvements I
mentioned above. Stuff that brings our project forward, but under the
hood - not visible for the user. This is the basis that later follow-up
work can than build upon and benefit from. Stuff that later can also be
funded by organizations/companies. Also time critical, to be done as
soon as possible. Early in the 3.x life cycle when API changes are still
possible. 

​14)​ Project / Map layer registry refactoring 

Similar reasoning like item 2) above. Under the hood, necessary API
improvements. Also time critical, to be 

[Qgis-developer] Code complexity survey

[Vard Antinyan]

Dear qgis developers,



We have undertaken a task to assess code complexity triggers and generate 
recommendations for developing understandable code. Our intension is to share 
the results with you, developers, so everyone can learn the triggers behind 
complex software.



We need your help for rigorous results. My request to you is - if you get 5-10 
min. time, would you please consider to answer the questions of this survey on 
code complexity?

https://goo.gl/forms/h9WXZ8VSEw7BUyHg1



You are welcome to learn preliminary results through this link:

https://www.facebook.com/SoftwareCodeQuality/photos/?tab=album_id=1639816749664288



The results will be shared in a public webpage and everyone possible will be 
invited to learn and discuss them.



Your knowledge and experience is vital for achieving substantial and 
generalizable results, and your effort is much appreciated!



Sincerely

Vard Antinyan

PhD candidate in University of Gothenburg, Sweden

Tel: 0046317725707

___
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] Renaming QML to QSL

[Matthias Kuhn]

On 09/22/2016 12:31 PM, Andreas Neumann wrote:
> And would the .qsl files than concentrate on styling and labeling and
> strip away the Field/Widget part, as well as other non-styling
> properties/settings?

Then we would need yet another file format that also includes also field
widget configuration... And I'm not sure that's of wider benefit, so I
would just leave it all the same and rename.

In the future we can possibly offer more control when saving/loading
with some checkboxes what to save.

Matthias

> 
> .qsl (QGIS styling language ;-) )?
> 
> @Nyall: any relations with your new properties framework project?
> 
> Greetings,
> 
> 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] Renaming QML to QSL

[Luigi Pirelli]

I almost agree for the reasons exposed...

almost because I'm not really convinced to mixup style with other
stuffs as exposed by Andreas. But I understand the problem to add more
and more file and style types.
In this moment we have a IMHO a serious interoperability problem
creating a defacto standard (with sld and their dialects) without a
lexical definition that allow style interchange abaount Arc$,
mapserver, geoserver and so on.
Sincerely I can't see a convergence in this moment... btw this is
another thread!


cheers
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 22 September 2016 at 12:02, Matthias Kuhn  wrote:
> Developers,
>
> We all know and appreciate .qml files. Some of us for shipping QGIS
> styles some of us for writing QtQuick applications [1].
>
> The second one become more important with Qt5 and so increase the risk
> of confusing the two file types. We already have technical collisions of
> the two file endings now [2]
>
> To avoid this, I propose to rename .qml files to .qsl for QGIS 3.
>
> Regards
> Matthias
>
> [1] https://en.wikipedia.org/wiki/QML
> [2] https://github.com/qgis/QGIS/pull/3266
> ___
> 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] Renaming QML to QSL

[Nyall Dawson]

On 22 Sep 2016 8:16 PM, "Matthias Kuhn"  wrote:
>
> On 09/22/2016 12:14 PM, Nyall Dawson wrote:
> > On 22 Sep 2016 8:02 PM, "Matthias Kuhn"  > > wrote:
> >>
> >> Developers,
> >>
> >> We all know and appreciate .qml files. Some of us for shipping QGIS
> >> styles some of us for writing QtQuick applications [1].
> >>
> >> The second one become more important with Qt5 and so increase the risk
> >> of confusing the two file types. We already have technical collisions
of
> >> the two file endings now [2]
> >>
> >> To avoid this, I propose to rename .qml files to .qsl for QGIS 3.
> >
> > Just to clarify - this would mean qgis 3 saves styles as "qsl", but
> > would be able to open both qsl and qml named files?

I'm in favour in pricing principle, the reasoning is sound.

But what's qsl stand for?

Nyall

>
> Yes.
>
> Matthias
>
> >
> > Nyall
> >
> >>
> >> Regards
> >> Matthias
> >>
> >> [1] https://en.wikipedia.org/wiki/QML
> >> [2] https://github.com/qgis/QGIS/pull/3266
> >> ___
> >> 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] Renaming QML to QSL

[Nyall Dawson]

On 22 Sep 2016 8:28 PM, "Nyall Dawson"  wrote:
>
> On 22 Sep 2016 8:16 PM, "Matthias Kuhn"  wrote:
> >
> > On 09/22/2016 12:14 PM, Nyall Dawson wrote:
> > > On 22 Sep 2016 8:02 PM, "Matthias Kuhn"  > > > wrote:
> > >>
> > >> Developers,
> > >>
> > >> We all know and appreciate .qml files. Some of us for shipping QGIS
> > >> styles some of us for writing QtQuick applications [1].
> > >>
> > >> The second one become more important with Qt5 and so increase the
risk
> > >> of confusing the two file types. We already have technical
collisions of
> > >> the two file endings now [2]
> > >>
> > >> To avoid this, I propose to rename .qml files to .qsl for QGIS 3.
> > >
> > > Just to clarify - this would mean qgis 3 saves styles as "qsl", but
> > > would be able to open both qsl and qml named files?
>
> I'm in favour in pricing principle, the reasoning is sound.

Oops - "In principal"

>
> But what's qsl stand for?
>
> Nyall
>
> >
> > Yes.
> >
> > Matthias
> >
> > >
> > > Nyall
> > >
> > >>
> > >> Regards
> > >> Matthias
> > >>
> > >> [1] https://en.wikipedia.org/wiki/QML
> > >> [2] https://github.com/qgis/QGIS/pull/3266
> > >> ___
> > >> 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] Discussion on the QGIS grant proposals

[Nyall Dawson]

>> 2) Implement a flexible properties framework in QGIS
>>
>> This is the kind of under-the-hood API changes and improvements I
>> mentioned above. Stuff that brings our project forward, but under
>> the hood - not visible for the user. This is the basis that later
>> follow-up work can than build upon and benefit from. Stuff that later
>> can also be funded by organizations/companies. Also time critical, to
>> be done as soon as possible. Early in the 3.x life cycle when API
>> changes are still possible.
>
> I also consider this one important, but it may be introduced later on.

Just to clarify (since I'm not sure if it was explicitly noted in the
proposal) - this is more or less a happens-during-api-break or doesn't
happen at all type change. To do it and maintain existing api would
result in 1.5-2x the work required, and a horrible mixed api with many
deprecated methods for the lifecycle of 3.x.

Nyall
___
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-user] Discussion on the QGIS grant proposals

[Paolo Cavallini]

Il 22/09/2016 11:39, Matthias Kuhn ha scritto:

> In particular I think we should pay attention to not attract individuals
> that only pop up when there's money to be spent from the project and
> then disappear again.

Agreed totally.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
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 Server cascaded GetFeatureInfo doesn't work

[G. Allegri]

for me :)

Hi devs,
I thought it should have worked, given that Server delegates to each
layer's respective provider.
I haven't digged into the code and I couldn't setup a debug session yet,
but I wanted to know if it's working or not for others of you.

giovanni
___
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] Renaming QML to QSL

[Nyall Dawson]

On 22 Sep 2016 8:02 PM, "Matthias Kuhn"  wrote:
>
> Developers,
>
> We all know and appreciate .qml files. Some of us for shipping QGIS
> styles some of us for writing QtQuick applications [1].
>
> The second one become more important with Qt5 and so increase the risk
> of confusing the two file types. We already have technical collisions of
> the two file endings now [2]
>
> To avoid this, I propose to rename .qml files to .qsl for QGIS 3.

Just to clarify - this would mean qgis 3 saves styles as "qsl", but would
be able to open both qsl and qml named files?

Nyall

>
> Regards
> Matthias
>
> [1] https://en.wikipedia.org/wiki/QML
> [2] https://github.com/qgis/QGIS/pull/3266
> ___
> 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] [Qgis-user] Discussion on the QGIS grant proposals

[Matthias Kuhn]

Thank you for raising this Andreas,

What I wonder is to which degree the people/companies behind a proposal
should be considered. In particular about:

 * Their history within the project *

how much they did before for the project. I think that a grant can not
only have a direct impact by making a particular project happen but also
an indirect multiplier effect by keeping people motivated to stay on the
project.

 * Volunteer time *

Grant money could compensate for volunteer time spent by
some people. And foster the multiplier effect again.

 * Their suitability for a particular job *
How much they did in this area before and therefore can be expected to
successfully accomplish the job.

In particular I think we should pay attention to not attract individuals
that only pop up when there's money to be spent from the project and
then disappear again.

Regards
Matthias

On 09/22/2016 08:14 AM, Neumann, Andreas wrote:
> Dear QGIS users, developers, voting members and user group representatives,
> 
> As you may have noticed, there is a first round of a QGIS grant program,
> fueled by the donations and sponsorship money we received in the past
> months. Tim Sutton, chair of the QGIS project, has publicized this
> program repeatedly on several channels.
> 
> The good thing is that we got some very good proposals. In total 18
> proposals, adding up to a total grant sum of 101 k €. You can see all
> proposals
> at 
> https://drive.google.com/file/d/0B__vDnQXCKiwYTIyWmRSbi1hMWM/view?usp%3Dsharing=D=1474526025402000=AFQjCNFhp43Lkxw3aBCed9-9luJpnR0oWg
> 
> Please note that we can only spend 20k € in this first round. So there
> are tough decisions to make. Note that proposals that can't make it in
> the first round, can be kept in a waiting list and may apply again in
> the next round of a grants program. If a proposal can't be accepted in
> the first round, this doesn't mean it isn't valuable and useful to the
> QGIS.ORG project.
> 
> The QGIS PSC will honor the opinion of the voting members, the OSGEO
> representative and the user group representatives on how to spend this
> limited money wisely. Alltogether a group of currently 27 people (13
> qgis user group represenatives, 13 community voting members, 1 OSGEO
> representative). This is kind of the "parliament" of the QGIS project
> when it comes to such decisions.
> 
> --
> 
> Now comes my personal position/opinion - note that this is not the
> official opinion of the QGIS.ORG board.
> 
> I would personally welcome, if this round of the QGIS grants program
> could focus on the QGIS 3.0 release.
> 
> I personally also think that the QGIS grants program, at least at the
> current time, should not pay for development of new features (at least
> not features visible in the GUI for the users). These features can
> be "relatively easy" funded by companies and government organizations
> out there. So our limited QGIS.ORG funds should be rather spent a) to
> community work or b) infrastructure work or c) development work in the
> core of QGIS, such as API modifications, code redesign - stuff that
> isn't really visible to the users, but essential for the success of the
> project. 
> 
>  
> 
> Documentation and PyQT documentation work is already budgeted in our
> annual budget. The money for 2016 hasn't even been spent for both items.
> So I think we should first use the budgeted money for such work. I think
> that user and developer documentation should be an ongoing effort and
> should be supported every year, und budgeted every year as such. We can
> increase the documentation budget positions next year, should it be
> necessary. In reality, it was more a lack of people willing to do the
> work, rather than a lack of funding. So, I am happy to see some
> proposals around documentation and developer documentation - so it seems
> that we have some volunteers. I just suggest that we consider
> documentation work separately and do it anyway - regardless of the
> outcome of the voting on these items.
> 
> Several proposals have a very limited local focus, only useful to one
> single country, or a very limited subset of our users. I suggest that
> such proposals could best be financed by local user groups or interest
> groups. It can't be the purpose of the QGIS grants program to finance
> such projects.
> 
> ---
> 
> Here is my own personal list of priorities:
> 
> ​18)​ QGIS 3 ticket handling and API refactoring
> 
> This is really time critical, and past discussions around QGIS 3.0 has
> shown that there is a lack of project management work and coordination.
> I regard this proposal as very useful for the QGIS 3.0 release.
> 
> ​11)​ Introduce everything necessary for QGIS3 to OSGeo4W
> 
> The majority of our users are on Windows (like it or not). This is the
> platform that matters most in our user base. The introduction of QGIS
> 3.0 means porting everything 

Re: [Qgis-developer] Renaming QML to QSL

[Andreas Neumann]

And would the .qsl files than concentrate on styling and labeling and 
strip away the Field/Widget part, as well as other non-styling 
properties/settings?


.qsl (QGIS styling language ;-) )?

@Nyall: any relations with your new properties framework project?

Greetings,

Andreas


Am 22.09.2016 um 12:02 schrieb Matthias Kuhn:

Developers,

We all know and appreciate .qml files. Some of us for shipping QGIS
styles some of us for writing QtQuick applications [1].

The second one become more important with Qt5 and so increase the risk
of confusing the two file types. We already have technical collisions of
the two file endings now [2]

To avoid this, I propose to rename .qml files to .qsl for QGIS 3.

Regards
Matthias

[1] https://en.wikipedia.org/wiki/QML
[2] https://github.com/qgis/QGIS/pull/3266
___
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] Renaming QML to QSL

[Andreas Neumann]

Ah sorry. Mixed up things. It would be a simple rename - nothing else. 
To not collide with the other usage (the qt qml files).


I always thought it would be useful if the .qml export and import would 
be more modular - giving the user the option what parts of the 
information should be exported or loaded.


Currently, it is a wild mixture of different properties relating to a 
layer. Styling and non-styling stuff.


Andreas

Am 22.09.2016 um 12:31 schrieb Andreas Neumann:
And would the .qsl files than concentrate on styling and labeling and 
strip away the Field/Widget part, as well as other non-styling 
properties/sAh ettings?


.qsl (QGIS styling language ;-) )?

@Nyall: any relations with your new properties framework project?

Greetings,

Andreas


Am 22.09.2016 um 12:02 schrieb Matthias Kuhn:

Developers,

We all know and appreciate .qml files. Some of us for shipping QGIS
styles some of us for writing QtQuick applications [1].

The second one become more important with Qt5 and so increase the risk
of confusing the two file types. We already have technical collisions of
the two file endings now [2]

To avoid this, I propose to rename .qml files to .qsl for QGIS 3.

Regards
Matthias

[1] https://en.wikipedia.org/wiki/QML
[2] https://github.com/qgis/QGIS/pull/3266
___
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] Renaming QML to QSL

[Matthias Kuhn]

Developers,

We all know and appreciate .qml files. Some of us for shipping QGIS
styles some of us for writing QtQuick applications [1].

The second one become more important with Qt5 and so increase the risk
of confusing the two file types. We already have technical collisions of
the two file endings now [2]

To avoid this, I propose to rename .qml files to .qsl for QGIS 3.

Regards
Matthias

[1] https://en.wikipedia.org/wiki/QML
[2] https://github.com/qgis/QGIS/pull/3266
___
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] Discussion on the QGIS grant proposals

[Paolo Cavallini]

Hi Andreas,
thanks again for raising these important points.
My notes (also personal opinion, not to be intended as a PSC position)
below:

Il 22/09/2016 08:14, Neumann, Andreas ha scritto:

> --
> 
> Now comes my personal position/opinion - note that this is not the
> official opinion of the QGIS.ORG board.
> 
> I would personally welcome, if this round of the QGIS grants program
> could focus on the QGIS 3.0 release.

Agreed, a critical point for QGIS future.

> I personally also think that the QGIS grants program, at least at the
> current time, should not pay for development of new features (at least
> not features visible in the GUI for the users). These features can
> be "relatively easy" funded by companies and government organizations
> out there. So our limited QGIS.ORG funds should be rather spent a) to
> community work or b) infrastructure work or c) development work in the
> core of QGIS, such as API modifications, code redesign - stuff that
> isn't really visible to the users, but essential for the success of the
> project.

Agreed, that's one of the reasons we started this program.

> Documentation and PyQT documentation work is already budgeted in our
> annual budget. The money for 2016 hasn't even been spent for both items.
> So I think we should first use the budgeted money for such work. I think
> that user and developer documentation should be an ongoing effort and
> should be supported every year, und budgeted every year as such. We can
> increase the documentation budget positions next year, should it be
> necessary. In reality, it was more a lack of people willing to do the
> work, rather than a lack of funding. So, I am happy to see some
> proposals around documentation and developer documentation - so it seems
> that we have some volunteers. I just suggest that we consider
> documentation work separately and do it anyway - regardless of the
> outcome of the voting on these items.

It makes sense to me.

> Several proposals have a very limited local focus, only useful to one
> single country, or a very limited subset of our users. I suggest that
> such proposals could best be financed by local user groups or interest
> groups. It can't be the purpose of the QGIS grants program to finance
> such projects.

Fully agreed.

One other important point: the reason I originally proposed the grant
programme was to recognize the huge volunteer work several people are
donating to the project, and to help keeping their motivation high.

My suggestion is therefore to prioritize the projects by the people you
feel/know have contributed most to the project until now.

All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
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] Renaming QML to QSL

[Matthias Kuhn]

On 09/22/2016 12:14 PM, Nyall Dawson wrote:
> On 22 Sep 2016 8:02 PM, "Matthias Kuhn"  > wrote:
>>
>> Developers,
>>
>> We all know and appreciate .qml files. Some of us for shipping QGIS
>> styles some of us for writing QtQuick applications [1].
>>
>> The second one become more important with Qt5 and so increase the risk
>> of confusing the two file types. We already have technical collisions of
>> the two file endings now [2]
>>
>> To avoid this, I propose to rename .qml files to .qsl for QGIS 3.
> 
> Just to clarify - this would mean qgis 3 saves styles as "qsl", but
> would be able to open both qsl and qml named files?

Yes.

Matthias

> 
> Nyall
> 
>>
>> Regards
>> Matthias
>>
>> [1] https://en.wikipedia.org/wiki/QML
>> [2] https://github.com/qgis/QGIS/pull/3266
>> ___
>> 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] standard way for custom plugin python dependencies

[Tom Kralidis]

Jachym: fwiw request is included in master and release-2_16 branches 
respectively [1].

Having said this, a more streamlined approach to plugin management in QGIS
would make things much easier for long term support across distributions.

..Tom

[1] https://github.com/qgis/QGIS/tree/master/python/ext-libs

On Thu, 22 Sep 2016, Luigi Pirelli wrote:


Date: Thu, 22 Sep 2016 17:01:51 +0200
From: Luigi Pirelli 
To: Jachym Cepicky 
Cc: "qgis-developer@lists.osgeo.org" 
Subject: Re: [Qgis-developer] standard way for custom plugin python
dependencies

why not package critical/missing dep with the plugin itself? import
from local egg only if not present in the installation.
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 22 September 2016 at 14:08, Jachym Cepicky  wrote:

Hi all,

we've developed an (python) plugin for QGIS, which is somehow using (among
others) nice "requests" python library. We use it the standard way

import requests

But when we distributed the plugin to other computers, it turned out, they
do not have it installed.

Is there any standard way, how to distribute dependencies along with python
plugin? Something in metadata.txt? Some requirements file?

Thanks

Jachym

___
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] standard way for custom plugin python dependencies

[Jachym Cepicky]

Hi all,

we've developed an (python) plugin for QGIS, which is somehow using (among
others) nice "requests" python library. We use it the standard way

import requests

But when we distributed the plugin to other computers, it turned out, they
do not have it installed.

Is there any standard way, how to distribute dependencies along with python
plugin? Something in metadata.txt? Some requirements file?

Thanks

Jachym
___
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] standard way for custom plugin python dependencies

[Matthias Kuhn]

Hi Jachym,

Unfortunately not. This has been discussed and is something that will
certainly be added at some point but so far nobody implemented it
(basically because of its cross-platform nature I think).

Your possibilities are:

 * Document and print nice warnings
 * Ship the dependency packaged with your plugin
 * Fix it by adding dependency management in QGIS

Cheers
Matthias

On 09/22/2016 02:08 PM, Jachym Cepicky wrote:
> Hi all,
> 
> we've developed an (python) plugin for QGIS, which is somehow using
> (among others) nice "requests" python library. We use it the standard way
> 
> import requests
> 
> But when we distributed the plugin to other computers, it turned out,
> they do not have it installed. 
> 
> Is there any standard way, how to distribute dependencies along with
> python plugin? Something in metadata.txt? Some requirements file?
> 
> Thanks
> 
> Jachym
> 
> 
> ___
> 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] Table Manager discontinuation and missing French translator

[Bernd Vogelgesang]

Just a note on usability:
Though even the Table Manager was not the obvious tool to manipulate  
attribute tables, cause it wasn't even installed by default, now the  
Refactor Fields function in Processing is even less visible to people.


It would be great if this function could be kind of hard-wired to the  
attribute table with a button (like the field calculator, formatting  
etc.). I think especially ArcMap-users (but not only) will struggle to  
find that function.


Cheers
Bernd



Am 22.09.2016, 14:16 Uhr, schrieb Borys Jurgiel :


Hi folks!

I'm going to discontinue the Table Manager. It was always a dirty  
workaround,
and nowadays (with recent QGIS versions and GDAL 2) numerous data  
corruptions
are reported. As QGIS finally contains the Refactor Fields tool and  
doesn't

need any external plugins, I believe it's the high time to kill the Table
Manager. I'm going to release the final version that displays a farewell
message pointing users to the Refactor Fields (and still works, beside  
that
message). Of course if someone is willing to take the development and  
keep it

up to date with the changing GDAL‚ I can abstain :)

Table Manager was translated into French, Russian and Ukrainian, so I'd  
like
to ask the translators for help with that message. However... I can't  
remember
who was the original translator. A massive shame on me, as it seems I  
didn't

put any credentials anywhere! I don't know how could I overlook it :(( I
apologize and promise to fix it as soon as we find the right persons.

I believe it was Maxim for Russian and Alex for Ukrainian, were you? But  
who
made the French translation? Régis, maybe it was you or do you have any  
ideas?


Best regards

Borys

___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] Table Manager discontinuation and missing French translator

[Borys Jurgiel]

Hi folks!

I'm going to discontinue the Table Manager. It was always a dirty workaround, 
and nowadays (with recent QGIS versions and GDAL 2) numerous data corruptions 
are reported. As QGIS finally contains the Refactor Fields tool and doesn't 
need any external plugins, I believe it's the high time to kill the Table 
Manager. I'm going to release the final version that displays a farewell 
message pointing users to the Refactor Fields (and still works, beside that 
message). Of course if someone is willing to take the development and keep it 
up to date with the changing GDAL‚ I can abstain :)

Table Manager was translated into French, Russian and Ukrainian, so I'd like 
to ask the translators for help with that message. However... I can't remember 
who was the original translator. A massive shame on me, as it seems I didn't 
put any credentials anywhere! I don't know how could I overlook it :(( I 
apologize and promise to fix it as soon as we find the right persons.

I believe it was Maxim for Russian and Alex for Ukrainian, were you? But who 
made the French translation? Régis, maybe it was you or do you have any ideas?

Best regards

Borys

___
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] standard way for custom plugin python dependencies

[Akbar Gumbira]

Hi Matthias,

Is there any pointer to the discussion? If it's possible for me to help, I
could may be make a proposal for next year GSoC on this :)

@Jachym: AFAIK, most plugins now just ship the needed libraries along with
it or ask the users to install them. There are some libraries that are
already shipped into QGIS from the core python plugins (e.g jinja), you
might want to check if what you need is there already.

On Sep 22, 2016 19:14, "Matthias Kuhn"  wrote:

> Hi Jachym,
>
> Unfortunately not. This has been discussed and is something that will
> certainly be added at some point but so far nobody implemented it
> (basically because of its cross-platform nature I think).
>
> Your possibilities are:
>
>  * Document and print nice warnings
>  * Ship the dependency packaged with your plugin
>  * Fix it by adding dependency management in QGIS
>
> Cheers
> Matthias
>
> On 09/22/2016 02:08 PM, Jachym Cepicky wrote:
> > Hi all,
> >
> > we've developed an (python) plugin for QGIS, which is somehow using
> > (among others) nice "requests" python library. We use it the standard way
> >
> > import requests
> >
> > But when we distributed the plugin to other computers, it turned out,
> > they do not have it installed.
> >
> > Is there any standard way, how to distribute dependencies along with
> > python plugin? Something in metadata.txt? Some requirements file?
> >
> > Thanks
> >
> > Jachym
> >
> >
> > ___
> > 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] standard way for custom plugin python dependencies

[Alessandro Pasotti]

On Thu, Sep 22, 2016 at 2:37 PM, Akbar Gumbira 
wrote:

> Hi Matthias,
>
> Is there any pointer to the discussion? If it's possible for me to help, I
> could may be make a proposal for next year GSoC on this :)
>
>
Nice idea!

Please go ahead :)


> @Jachym: AFAIK, most plugins now just ship the needed libraries along with
> it or ask the users to install them. There are some libraries that are
> already shipped into QGIS from the core python plugins (e.g jinja), you
> might want to check if what you need is there already.
>
>
A new metadata (external_deps: text) field was introduced for this purpose
but there is nothing implemented inside QGIS for now:
https://github.com/qgis/QGIS-Django/commit/6546a2ab54fd01b6e94b921b610c31b619e99979#diff-536e872043014a84818f87dc640b2d4d

A common pattern seems shipping dependencies with the plugin as Python eggs.



> On Sep 22, 2016 19:14, "Matthias Kuhn"  wrote:
>
>> Hi Jachym,
>>
>> Unfortunately not. This has been discussed and is something that will
>> certainly be added at some point but so far nobody implemented it
>> (basically because of its cross-platform nature I think).
>>
>> Your possibilities are:
>>
>>  * Document and print nice warnings
>>  * Ship the dependency packaged with your plugin
>>  * Fix it by adding dependency management in QGIS
>>
>> Cheers
>> Matthias
>>
>> On 09/22/2016 02:08 PM, Jachym Cepicky wrote:
>> > Hi all,
>> >
>> > we've developed an (python) plugin for QGIS, which is somehow using
>> > (among others) nice "requests" python library. We use it the standard
>> way
>> >
>> > import requests
>> >
>> > But when we distributed the plugin to other computers, it turned out,
>> > they do not have it installed.
>> >
>> > Is there any standard way, how to distribute dependencies along with
>> > python plugin? Something in metadata.txt? Some requirements file?
>> >
>> > Thanks
>> >
>> > Jachym
>> >
>> >
>> > ___
>> > 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
>



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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] Multiple Fields in R-Processing

[matteo]

Hi guys,

I have a small problem with the integration of the MultipleField
parameter in the R-Processing script.

The trial script is super simple:

##[R-Geostatistics]=group
##l=vector
##X=multiple Field l

>X

So I just want to understand how can I extract the single fields of the
parameter.

Doing so the script runs, but I always get the same error:



Source: "/tmp/processing510ec5d19fc74c0582fbe8983bd85e66", layer:
"1474548069.5615"
with 102 features
It has 6 fields
multiple Field l="Gruppo;SN"
Error: unexpected symbol in "multiple Field"
Execution halted


I tried several other combinations but I'm running out of fantasy.

With the selection parameter it is simpler:


##type=selection point;lines;point

>type


and the output is 0 (so the first chosen).


The parameter can be accessed here:

import processing
from processing.core.parameters import ParameterTableMultipleFiel



Thanks guys

Matteo
___
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] Table Manager discontinuation and missing French translator

[Borys Jurgiel]

Good idea.
What about adding a shorcut to the Vector menu, like it's now with the 
algorithms formerly available in fTools?

Borys


 
Dnia czwartek, 22 września 2016 14:32:07 Bernd Vogelgesang pisze:
> Just a note on usability:
> Though even the Table Manager was not the obvious tool to manipulate
> attribute tables, cause it wasn't even installed by default, now the
> Refactor Fields function in Processing is even less visible to people.
> 
> It would be great if this function could be kind of hard-wired to the
> attribute table with a button (like the field calculator, formatting
> etc.). I think especially ArcMap-users (but not only) will struggle to
> find that function.
> 
> Cheers
> Bernd

___
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] Table Manager discontinuation and missing French translator

[Borys Jurgiel]

Ah it was you, Jean Roc, weren't you?  :)

Dnia czwartek, 22 września 2016 14:16:25 Borys Jurgiel pisze:
> Hi folks!
> 
> I'm going to discontinue the Table Manager. It was always a dirty
> workaround, and nowadays (with recent QGIS versions and GDAL 2) numerous
> data corruptions are reported. As QGIS finally contains the Refactor Fields
> tool and doesn't need any external plugins, I believe it's the high time to
> kill the Table Manager. I'm going to release the final version that
> displays a farewell message pointing users to the Refactor Fields (and
> still works, beside that message). Of course if someone is willing to take
> the development and keep it up to date with the changing GDAL‚ I can
> abstain :)
> 
> Table Manager was translated into French, Russian and Ukrainian, so I'd like
> to ask the translators for help with that message. However... I can't
> remember who was the original translator. A massive shame on me, as it
> seems I didn't put any credentials anywhere! I don't know how could I
> overlook it :(( I apologize and promise to fix it as soon as we find the
> right persons.
> 
> I believe it was Maxim for Russian and Alex for Ukrainian, were you? But who
> made the French translation? Régis, maybe it was you or do you have any
> ideas?
> 
> Best regards
> 
> Borys
> 
> ___
> 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] standard way for custom plugin python dependencies

[Luigi Pirelli]

why not package critical/missing dep with the plugin itself? import
from local egg only if not present in the installation.
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 22 September 2016 at 14:08, Jachym Cepicky  wrote:
> Hi all,
>
> we've developed an (python) plugin for QGIS, which is somehow using (among
> others) nice "requests" python library. We use it the standard way
>
> import requests
>
> But when we distributed the plugin to other computers, it turned out, they
> do not have it installed.
>
> Is there any standard way, how to distribute dependencies along with python
> plugin? Something in metadata.txt? Some requirements file?
>
> Thanks
>
> Jachym
>
> ___
> 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] Multiple Fields in R-Processing

[matteo]

Victor,

thanks for the super quick reply.

I still don't get how can I select the different single fields from the
output.

I mean, with the selection parameter all is straightforward.

In the example I wrote in the previous mail, how can I access the first
field of the multiple fields parameter?

Thank Victor for your time, if I manage how to do it, I will also
improve the documentation

Cheers

Matteo
___
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] standard way for custom plugin python dependencies

[Vincent Picavet (ml)]

Hi,


On 22/09/2016 14:43, Alessandro Pasotti wrote:
> On Thu, Sep 22, 2016 at 2:37 PM, Akbar Gumbira  > wrote:
[..]
> @Jachym: AFAIK, most plugins now just ship the needed libraries
> along with it or ask the users to install them. There are some
> libraries that are already shipped into QGIS from the core python
> plugins (e.g jinja), you might want to check if what you need is
> there already.
> 
> A new metadata (external_deps: text) field was introduced for this
> purpose but there is nothing implemented inside QGIS for now:
> https://github.com/qgis/QGIS-Django/commit/6546a2ab54fd01b6e94b921b610c31b619e99979#diff-536e872043014a84818f87dc640b2d4d
> 
> A common pattern seems shipping dependencies with the plugin as Python eggs.

New Python Wheels and Pypi now support binary packages. This becomes a
really useful and convenient tool to install dependencies, with
multi-platform support, without even having a compiler installed.

Making QGIS Python plugins as Python modules would allow to use all pip
and pypi insfrastructure really easily.

The proposed osgeo4w grant application by Jef could include the low
level required changes necessary to introduce this behaviour. Right now
pip is distributed by default in OSGeo4w, but since not all OSGeo4w
python modules are installed through pip (but through specific exe
installers), this may lead to installation problems ( names conflicts e.g.).

If this work is done, there still will be some work on the QGIS python
plugin interface, but _not_ reimplementing a package management system
in QGIS and use pip instead could be a good option.

Regards,
Vincent
> 
>  
> 
> On Sep 22, 2016 19:14, "Matthias Kuhn"  > wrote:
> 
> Hi Jachym,
> 
> Unfortunately not. This has been discussed and is something that
> will
> certainly be added at some point but so far nobody implemented it
> (basically because of its cross-platform nature I think).
> 
> Your possibilities are:
> 
>  * Document and print nice warnings
>  * Ship the dependency packaged with your plugin
>  * Fix it by adding dependency management in QGIS
> 
> Cheers
> Matthias
> 
> On 09/22/2016 02:08 PM, Jachym Cepicky wrote:
> > Hi all,
> >
> > we've developed an (python) plugin for QGIS, which is somehow
> using
> > (among others) nice "requests" python library. We use it the
> standard way
> >
> > import requests
> >
> > But when we distributed the plugin to other computers, it
> turned out,
> > they do not have it installed.
> >
> > Is there any standard way, how to distribute dependencies
> along with
> > python plugin? Something in metadata.txt? Some requirements file?
> >
> > Thanks
> >
> > Jachym
> >
> >
> > ___
> > 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
> 
> 
> 
> 
> 
> -- 
> Alessandro Pasotti
> w3:   www.itopen.it 
> 
> 
> ___
> 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: 

Re: [Qgis-developer] standard way for custom plugin python dependencies

[Alessandro Pasotti]

On Thu, Sep 22, 2016 at 3:22 PM, Vincent Picavet (ml) <
vincent...@oslandia.com> wrote:

> Hi,
>
>
> On 22/09/2016 14:43, Alessandro Pasotti wrote:
> > On Thu, Sep 22, 2016 at 2:37 PM, Akbar Gumbira  > > wrote:
> [..]
> > @Jachym: AFAIK, most plugins now just ship the needed libraries
> > along with it or ask the users to install them. There are some
> > libraries that are already shipped into QGIS from the core python
> > plugins (e.g jinja), you might want to check if what you need is
> > there already.
> >
> > A new metadata (external_deps: text) field was introduced for this
> > purpose but there is nothing implemented inside QGIS for now:
> > https://github.com/qgis/QGIS-Django/commit/
> 6546a2ab54fd01b6e94b921b610c31b619e99979#diff-
> 536e872043014a84818f87dc640b2d4d
> >
> > A common pattern seems shipping dependencies with the plugin as Python
> eggs.
>
> New Python Wheels and Pypi now support binary packages. This becomes a
> really useful and convenient tool to install dependencies, with
> multi-platform support, without even having a compiler installed.
>
> Making QGIS Python plugins as Python modules would allow to use all pip
> and pypi insfrastructure really easily.
>
> The proposed osgeo4w grant application by Jef could include the low
> level required changes necessary to introduce this behaviour. Right now
> pip is distributed by default in OSGeo4w, but since not all OSGeo4w
> python modules are installed through pip (but through specific exe
> installers), this may lead to installation problems ( names conflicts
> e.g.).
>
> If this work is done, there still will be some work on the QGIS python
> plugin interface, but _not_ reimplementing a package management system
> in QGIS and use pip instead could be a good option.
>


I could't agree more!

We definitely don't want to re-invent the (PyPi) wheel ;)

Go for pip, but still the external_deps field in metadata could be useful
to hold the content of REQUIREMENTS.txt, or a path to it.

-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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] Multiple Fields in R-Processing

[Victor Olaya]

Matteo

For the multiple field you dont supply the fields or options. It takes
them from the parent layer and you can select several, instead of one,
as the PArameterTableField does

Hope this helps

2016-09-22 14:48 GMT+02:00 matteo :
> Hi guys,
>
> I have a small problem with the integration of the MultipleField
> parameter in the R-Processing script.
>
> The trial script is super simple:
>
> ##[R-Geostatistics]=group
> ##l=vector
> ##X=multiple Field l
>
>>X
>
> So I just want to understand how can I extract the single fields of the
> parameter.
>
> Doing so the script runs, but I always get the same error:
>
>
>
> Source: "/tmp/processing510ec5d19fc74c0582fbe8983bd85e66", layer:
> "1474548069.5615"
> with 102 features
> It has 6 fields
> multiple Field l="Gruppo;SN"
> Error: unexpected symbol in "multiple Field"
> Execution halted
>
>
> I tried several other combinations but I'm running out of fantasy.
>
> With the selection parameter it is simpler:
>
>
> ##type=selection point;lines;point
>
>>type
>
>
> and the output is 0 (so the first chosen).
>
>
> The parameter can be accessed here:
>
> import processing
> from processing.core.parameters import ParameterTableMultipleFiel
>
>
>
> Thanks guys
>
> Matteo
> ___
> 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