Re: [Qgis-developer] Feedback re future of core c++ plugins in QGIS 3.0

On 06-12-16 23:00, Nyall Dawson wrote: On 8 November 2016 at 11:24, Nyall Dawson wrote: Hi all, Discussion is currently underway concerning the future of a number of the plugins which come preinstalled with QGIS. This concerns the plugins: - coordinate capture - evis

Re: [Qgis-developer] QGIS Custom Widget in Qt Designer

Hi Matteo, Having the error on master sounds correct, since QgsColorButtonV2 really doesn't exist anymore (replaced by QgscolorButton [0]). As I wrote already in the topic, issues seem to arise when using uic.loadUi. Are you using this approach? Personally, I use pyuic without any issue (you

Re: [Qgis-developer] Feedback re future of core c++ plugins in QGIS 3.0

Il 6 dicembre 2016 23:00:50 CET, Nyall Dawson ha scritto: >On 8 November 2016 at 11:24, Nyall Dawson >wrote: >> Hi all, >> >> Discussion is currently underway concerning the future of a number of >> the plugins which come preinstalled with QGIS.

Re: [Qgis-developer] Feedback re future of core c++ plugins in QGIS 3.0

On 8 November 2016 at 11:24, Nyall Dawson wrote: > Hi all, > > Discussion is currently underway concerning the future of a number of > the plugins which come preinstalled with QGIS. > > This concerns the plugins: > > - coordinate capture > - evis > - geometry_checker > -

[Qgis-developer] QGIS Custom Widget in Qt Designer

Hi all, I'm currently compiling both master and release_2_18 on a linux machine (with make, not debian rules, and I run them directly from the output folder, thanks Matthias for the advice ;)) I set the WITH-CUSTOMWIDGET ON for both qgis2_18 and master (not sure if this is needed) To have the

[Qgis-developer] Plugin [1035] Lat Lon Tools approval notification.

Plugin Lat Lon Tools approval by pcav. The plugin version "[1035] Lat Lon Tools 0.6" is now approved Link: http://plugins.qgis.org/plugins/latlontools/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info:

[Qgis-developer] Plugin [995] dzetsaka : Classification tool approval notification.

Plugin dzetsaka : Classification tool approval by pcav. The plugin version "[995] dzetsaka : Classification tool 2.1.1" is now approved Link: http://plugins.qgis.org/plugins/dzetsaka/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

>> This would have some advantages. Providers would be better organized, > > Can you elaborate on this? Is it just better organised because they > would be in separate repos? > Yes, mainly because of that, since all provider would be treated equal. Now the providers that are in core seem to be

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

>> Slightly off topic, but I'm not sure (yet) if we should port the >> actual algorithms themselves to c++. For my purposes (Matthias might >> disagree here) it would be sufficient to allow algorithms to be fully >> created in c++ only if required. Otherwise, I quite like having the >> algorithms

Re: [Qgis-developer] Processing NG/V2 - brainstorming

Hi Richard, On 12/06/2016 11:56 AM, Richard Duivenvoorde wrote: > On 05-12-16 10:03, Nyall Dawson wrote: >> Hi all, > > Hi Nyall et al. Good thinking, just wondering... what is NG/V2? :-) Next Generation, Version 2 Add to that: X / 2.0 / reloaded ;) > >> So here we go... a bunch of random

Re: [Qgis-developer] Processing NG/V2 - brainstorming

On 05-12-16 10:03, Nyall Dawson wrote: Hi all, Hi Nyall et al. Good thinking, just wondering... what is NG/V2? :-) So here we go... a bunch of random ideas on future processing enhancements: 1. Rework native algorithms to avoid layer input/outputs I have seen some people creating huge FME

Re: [Qgis-developer] Status of Q3 migration?

2016-12-06 10:47 GMT+01:00 Paolo Cavallini : > Il 06/12/2016 09:20, Régis Haubourg ha scritto: > > > @Paolo, I think we are not yet in polishing step, some really low level > > things still need to be broken and rebuilt. See > > there:

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

Hi On 12/06/2016 10:14 AM, Nyall Dawson wrote: > On 6 December 2016 at 18:25, Victor Olaya wrote: > > Slightly off topic, but I'm not sure (yet) if we should port the > actual algorithms themselves to c++. For my purposes (Matthias might > disagree here) it would be

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

On 6 December 2016 at 18:25, Victor Olaya wrote: > >> It might be a way full of caveats probably. Also, does that fit with the >> idea from Matthias and Nyall of having core processing capabilities to have >> them enabled in Android (or any python unfriendly platform) ?. >> >

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

On 6 December 2016 at 16:33, Victor Olaya wrote: > > This would have some advantages. Providers would be better organized, Can you elaborate on this? Is it just better organised because they would be in separate repos? > and they could be updated and managed independently. In

Re: [Qgis-developer] Status of Q3 migration?

* -1 for QGIS development to go back to the "wait until ready" mode which delayed QGIS 2.0 way too long * +0.5 to have a serious discussion around a possible (fixed in time) extension :) Let's not forget that while of us on the dev mailing list run on home-made or nightly builds, which tents to

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

> Hi Victor, > about this, we need to think of upgrading process so that a user raising > QGIS version will have no choice but to also upgrade the locally installed > stuff (providers, algs, ..) to avoid version conflicts. We should probably > then have some metadata with min and max processing

Re: [Qgis-developer] Status of Q3 migration?

Hi all, I propose I add this as a discussion topic at the end of the Lyon Code Sprint next week. We'll maybe have a clearer view of how much work is remaining. @Paolo, I think we are not yet in polishing step, some really low level things still need to be broken and rebuilt. See there:

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

Hi Victor, about this, we need to think of upgrading process so that a user raising QGIS version will have no choice but to also upgrade the locally installed stuff (providers, algs, ..) to avoid version conflicts. We should probably then have some metadata with min and max processing version for

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

+1 for this idea. Small offtopic note: IMHO for Processing should not install providers/scripts/models/etc. Better to use Resource Sharing plugin for this to unify user experience. -- Alexander Bruy ___ Qgis-developer mailing list