Hi Nyall,
> So again, I'm +1 to the policy, but only if it's enforced
> automatically on Travis by an appropriate meta unit test.
yep! we should find a way to make life easier for both teams without
loosing quality and features
> I think we could do this by some rules like:
> - if a commit
Hi all
On 16/01/19 23:42, Nyall Dawson wrote:
> So again, I'm +1 to the policy, but only if it's enforced
> automatically on Travis by an appropriate meta unit test.
agreed
> I think we could do this by some rules like:
> - if a commit message has [feature] or [needs-docs], then the body of
>
Did you check if a plugin with the same name already exists?
On Wed, Jan 16, 2019 at 11:21 PM Alessandro Cristofori
wrote:
> Hello,
> I have just uploaded to the QGIS plugin repository my first plug-in.
>
> After having read all the documentation, provided a LICENSE a README and
> having
On Wed, 16 Jan 2019 at 00:08, Raymond Nijssen wrote:
>
> Since 2 months there's a new function called leftOfLine() which
> calculates if a point is left or right from a line(segment). While using
> it I wondered why:
>
> It returns
> -1 if point is on left side
> 1 if point is on right side
>
>
On Thu, 17 Jan 2019 at 02:49, Matteo Ghetta wrote:
>
> Fully agreed with all the comments.
>
> What are devs thoughts? ;)
I'm +1 to the policy, BUT...
in reality this is just moving part of the workload from the
(overworked) documentation team to the (overworked) PR review team.
Instead of just
Hello,
I have just uploaded to the QGIS plugin repository my first plug-in.
After having read all the documentation, provided a LICENSE a README and
having filled the metadata.txt file I zipped it and uploaded via the upload
page.
As a confirmation I get a white page that says "You cannot modify
Hi
Its weird - it works fine here on my Mac but wasn’t working on a course
participant’s windows QGIS 3.4.3 yesterday. I will try again tomorrow. Thanks
for the notes!
Regards
Tim
> On 16 Jan 2019, at 21:05, Denis Rouzaud wrote:
>
> Advanced digitizing are available for points!
>
> Select
Advanced digitizing are available for points!
Select the layer
Enable editing
Select add feature tool or vertex tool
Enable advanced digitizing tools
Enter X and/or Y coordinates, press enter.
Let me know if you have any issue!
Le mer. 16 janv. 2019 à 13:49, Tim Sutton a écrit :
> Ah thanks!
Ah thanks!
Tim Sutton
Co-founder of Kartoza
Ex-QGIS project chairman
> On 16 Jan 2019, at 20:40, Etienne Trimaille
> wrote:
>
> With the vertex tool enabled, right click on a vertex and then you can enter
> X and Y.
>
>
>> Le mer. 16 janv. 2019 à 14:25, Tim Sutton a écrit :
>> Hi
>>
With the vertex tool enabled, right click on a vertex and then you can
enter X and Y.
Le mer. 16 janv. 2019 à 14:25, Tim Sutton a écrit :
> Hi
>
> In QGIS 3.x we have the nice integration with the advanced digitising
> panel for lines and polygons. Do we have any capability to capture a point
The Lat Lon Tools plugin does this. Select a point layer that is editable
and then you use "Lat Lon Digitize"
Calvin
On Wed, Jan 16, 2019 at 1:25 PM Tim Sutton wrote:
> Hi
>
> In QGIS 3.x we have the nice integration with the advanced digitising
> panel for lines and polygons. Do we have any
+1 on all.
Thanks Alessandro.
On 16/01/19 18:28, Alessandro Pasotti wrote:
> My 2 quick cents:
>
> 1 - new features or significant changes to existing features *must*
> provide a description of the feature/changes or a link to it in some
> form (a QEP, the PR text, a blog post an extensive
Hi
In QGIS 3.x we have the nice integration with the advanced digitising panel for
lines and polygons. Do we have any capability to capture a point by entering
coordinates? In 2.x we had the numerical vertex editor plugin but that isn’t
available in 3.x yet.
Regards
Tim
—
Tim
My 2 quick cents:
1 - new features or significant changes to existing features *must* provide
a description of the feature/changes or a link to it in some form (a QEP,
the PR text, a blog post an extensive commit message etc., suitable for
copy-paste into the documentation)
2 - little
Fully agreed with all the comments.
What are devs thoughts? ;)
Cheers
Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:
Hi Marco,
On Wed, 16. Jan 2019 at 15:55:31 +0100, Marco Bernasocchi wrote:
> On 16.01.19 13:08, Jorge Gustavo Rocha wrote:
> > If you agree to discuss this again, may I open a "Move to GitLab" stream
> > in the Coruña meeting wiki
> well nobody agreed that "Move to GitLab" is what the plan
Plugin Local Dominance Visualisation approval by pcav.
The plugin version "[1605] Local Dominance Visualisation 0.1 Experimental" is
now approved
Link: http://plugins.qgis.org/plugins/local_dominance/
___
QGIS-Developer mailing list
Yes - it is actually an example where the feature is already quite
documented. Just not in the manual.
It is one of the better cases, when it comes to documentation.
Andreas
Am 16.01.19 um 16:07 schrieb Marco Bernasocchi:
Well to be fair, in this (and many) other cases, the "Naughty Dev"
Well to be fair, in this (and many) other cases, the "Naughty Dev"
provided an amazingly well written description of the feature. That can
just be copy pasted to the docs.
But yes, I think minimal docs, or maybe a changelog entry or a link to a
blogpost would be good
Cheers
Marco
On 16.01.19
Hi Gustavo,
On 16.01.19 13:08, Jorge Gustavo Rocha wrote:
> If you agree to discuss this again, may I open a "Move to GitLab" stream
> in the Coruña meeting wiki
well nobody agreed that "Move to GitLab" is what the plan should be. You
can open an "issue infrastructure" stream if you want.
+1
No more "the naughty developer didn't provide a description" messages,
please.
Best regards,
Alexandre Neto
Paolo Cavallini escreveu no dia quarta, 16/01/2019
às 09:02:
> Totally agreed:
> * pushing at least a minimal documentation has to be a requirement, just
> like unit tests
> * an
Hi Marco,
Glad to know that you are taking the lead of this discussion to move
issues away from redmine.
Last year, in Madeira, we have (another) discussing about the subject.
Vincent strongly support the move to GitLab. As I remember, he already
did something on GitLab and was quite confident
Since most seem to agree with the bot implementation, can we do it in a way
that:
- the PR owner (and other watchers) receive a message warning that the PR
is going to be closed with some time to act;
- Not automatically merging PRs, but warn the owner (and watchers) that the
owner (if with commit
Totally agreed:
* pushing at least a minimal documentation has to be a requirement, just
like unit tests
* an automatic system is far preferable to a manual one.
Topic added to the TODO for the HF:
https://github.com/qgis/QGIS/wiki/22nd-Developer-Meeting-in-A-Coru%C3%B1a,-Spain
Thanks.
On
+1
In case nobody objects, I'd suggest implementing this soon, during HF at
latest, better before.
All the best.
On 16/01/19 08:44, Andreas Neumann wrote:
> Hi Matteo,
>
> Your suggestion sounds good to me.
>
> Andreas
>
> Am 16.01.19 um 08:42 schrieb matteo:
>> Hi Anita,
>>
>>> I am not
Hi Carlo,
unfortunately (personal opinion) the issue tracker is not on github but
on a redmine instance so we can't use the api stats nor the integrated
pulse dash board like in https://github.com/opengisch/QField/pulse
There have been endless discussion in that sense without ever reaching a
Hi Richard,
It is something to consider - I agree that we have a documentation crisis.
On the other hand - I never see any QGIS user reading/consulting that
manual we provide (because it is hard to read a manual) - that's why I
sometimes - if a question from a user about feature x is raised -
On Wed, 16 Jan 2019 at 17:42, Richard Duivenvoorde wrote:
> I do not want to be a PITA, but can we maybe add a mandatory requirement
> for a pull request that in case of a new feature the dev adds some
> mandatory Text and Images about the feature IN the PR?
Random idea: could we code up a test
28 matches
Mail list logo
