[QGIS-Developer] startup.py not working outside %APPDATA%\QGIS\QGIS3

2020-02-17 Thread Thomas Baumann
Hi QGIS-devs,
It looks like QGIS3 (tested with 3.10.2) does not make use of a startup.py
if it is saved outside
%APPDATA%\QGIS\QGIS3 (OS: Windows 10).

I opened QGIS with a custom "--profiles-path"  which works fine as QGIS
creates this profiles folder. But if you put a startup.py into this folder
(for example %APPDATA%\QGIS\qgis3_tests) it is not executed.

Only the startup.py saved in %APPDATA%\QGIS\QGIS3 is executed.

I guess this is a bug, isn't it?

Otherwise it would be not possible to have different startup.py files for
different profile folders (testing/production).

regards,
Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 3.10.2 start issue

2020-02-17 Thread Thomas Baumann
Hi Martin,

did you use the standalone installer or the OSGEO4W-Installer?

You can have a look if in your C:\Program Files\QGIS_3_10_2_Coruna\bin
folder if there exists a qgis.bat.tmpl file as template for the qgis.bat.

If so you can copy the file and rename it to qgis.bat. If not you can
create a qgis.bat with a content similar to this:
https://gist.githubusercontent.com/thbaumann/1550ba276b5c17f36edf9f91379dd81d/raw/795a657d10dcc9189f1d9331cec35382a2815db2/qgis.bat_template
(this bat file content is one for an OSGEO4W-Installation)

Afterwards you can open your cmd commandline("Eingabeaufforderung"),
navigate to C:\Program Files\QGIS_3_10_2_Coruna\bin and call "qgis.bat
--postinstall" to create the env file.

regards,
Thomas


Am Fr., 14. Feb. 2020 um 14:03 Uhr schrieb Martin Steiger <
martin.stei...@zg.ch>:

> Hello,
>
>
>
> I hope I write to the correct address with my request.
>
>
>
> In the "Kantonsverwaltung Zug" we use QGIS since version 2.16 in the
> department of geoinformation. We always used the following command to start
> QGIS:
>
>
>
> "C:\Program Files\QGIS_3_8_ZANZIBAR\bin\nircmd.exe" exec hide C:\Program
> Files\QGIS_3_8_ZANZIBAR\bin\qgis.bat
>
> (Yes, we install it in a custom named folder)
>
>
>
> It always worked out fine and QGIS started without any issues. However, in
> version 3.10.2 this does not work out, because the file qgis.bat does not
> exist. I found the file "C:\Program
> Files\QGIS_3_10_2_Coruna\bin\qgis-bin.exe" and tried to start it.
>
> Unfortunately I get an error message (see attachment). If I start the file 
> "C:\Program
> Files\QGIS_3_10_2_Coruna\bin\qgis-bin-g7.exe" I get the same behaviour. I
> think it’s a little bit odd that the mentioned file "C:\Program
> Files\QGIS_3_10_2_Coruna\bin\qgis-bin.env" doesn’t even exist in the file
> system…
>
>
>
> Can you help me out with this issue? Or is there a way you would recommend
> to correctly start QGIS?
>
>
>
> We use Windows 10 Build 1809 with the newest windows updates.
>
>
>
> Best Regards
>
> Martin Steiger
>
>
>
>
>
> Finanzdirektion Kanton Zug
>
> Amt für Informatik und Organisation (AIO) des Kantons Zug
>
> Martin Steiger
>
> Computer scientist in apprenticeship
>
> Aabachstrasse 1
>
> 6300 Zug
>
> Switzerland
>
> T +41 41 728 51 29
>
> martin.stei...@zg.ch
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] saving username in QGIS projectfile for tracking changes

2019-12-20 Thread Thomas Baumann
Hi QGIS-Devs,

I set up a cronjob to track changes in one QGIS projectfile which is used
as template for a bunch of users.

Apart from knowing which parts of the project file changed it would be nice
to know who saved these changes.

So i inserted the following snippet in the "writeProjectFile"- function of
my qgsproject.cpp:

  QDomElement userNode = doc->createElement(QStringLiteral("lastUser"));
  QDomText lastUser = doc->createTextNode(QgsApplication::userFullName());
  userNode.appendChild(lastUser);
  qgisNode.appendChild(userNode);

which works so I get one XML tag with the username who saved the project
file:

...

  
  Baumann Thomas
  
...

This was as first try. Perhaps it would make more sense to put this
information somewhere into the metadata node.

What do you think about the idea of adding this functionality into QGIS?

regards,
Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS Onboarding Day?

2019-12-09 Thread Thomas Baumann
Hi Raymond,
I won't be at the hackfest this time but I could record a screencast before
the HF so users can try to get the development setup running even before
they arrive.

If I would attend an onboarding session for me it would be very interesting
to watch how an experienced QGIS developer would debug a bug.

regards,
Thomas





Raymond Nijssen  schrieb am Fr., 6. Dez. 2019, 16:37:

> Hi Thomas,
>
> Good idea to also explain this for Windows. However we will need someone
> to teach that since I don't know how to compile on Windows. Could you do
> it? You seem to have managed setting it up and you could prevent other
> people to having the same frustrations you met.
>
> Recording the workshops is also a great idea. I will try to get the
> equipment for that. The workshops might be too long though, resulting in
> long and boring videos, so maybe creating short(er) instruction videos
> would me more efficient.
>
> Thanks for your input, hoping to see you at the hackfest!
> Raymond
>
>
>
>
> On 06-12-2019 14:42, Thomas Baumann wrote:
> > Hi Raymond,
> > I think especially getting QtCreator or Visual Studio under Windows OS
> > up and running would be a good topic if the are windows users as newbies
> > at your hackfest.
> >
> > On Linux and Windows I got the debug setup with QtCreator running with
> > the help of our paid QGIS support but the setup on windows with Visual
> > Studio which i tried on my own was just a nightmare.
> >
> > I'm still not sure if there are essential parts missing in the docs at
> > the moment (adding Version.lib dependency, manually creating qgis.env)
> > which were necessary for me to be able to debug in Visual studio:
> > https://gis.stackexchange.com/q/340984/67477
> >
> >
> > I can imagine that a "debug"-boarding directly from the QGIS devs would
> > be helpful for many users... So I was wondering if you plan to record
> > the boarding?
> >
> > If I wouldn't have needed the debug environment for my work I would have
> > just given up after some frustrating hours and dismissed the idea of
> > helping bugfixing QGIS.
> >
> >
> > regards,
> > Thomas
> >
> > Raymond Nijssen mailto:r.nijs...@terglobo.nl>>
> > schrieb am Do., 5. Dez. 2019, 13:19:
> >
> > Dear Devs,
> >
> > Making plans for the next hackfest (13-15 March 2020, The
> Netherlands)
> > we are thinking of a way to attract new people to the project. Quite
> > some Dutch people are interested to come over and "see" us, but of
> > course we need to help them getting up and running.
> >
> > So we are thinking on doing an "Onboarding Day" the day prior to the
> HF
> > (Thursday March 12) with workshops teaching:
> >
> > - How to translate?
> > - How to write documentation?
> > - How to compile?
> > etc...
> >
> > We already noticed Alessandro's offer to do a Mentor Stream on "my
> > first
> > pull request" which would also fit this idea.
> >
> > Just curious, what are your thoughts on this? And would you like to
> > arrive one day earlier in the lovely Netherland to warmly welcome new
> > contributors?
> >
> > Thanks,
> > Raymond (and Rosa and Aron)
> >
> >
> https://github.com/qgis/QGIS/wiki/24th-Contributor-Meeting-in-'s-Hertogenbosch
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org  QGIS-Developer@lists.osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS Onboarding Day?

2019-12-06 Thread Thomas Baumann
Hi Raymond,
I think especially getting QtCreator or Visual Studio under Windows OS up
and running would be a good topic if the are windows users as newbies at
your hackfest.

On Linux and Windows I got the debug setup with QtCreator running with the
help of our paid QGIS support but the setup on windows with Visual Studio
which i tried on my own was just a nightmare.

I'm still not sure if there are essential parts missing in the docs at the
moment (adding Version.lib dependency, manually creating qgis.env) which
were necessary for me to be able to debug in Visual studio:
https://gis.stackexchange.com/q/340984/67477


I can imagine that a "debug"-boarding directly from the QGIS devs would be
helpful for many users... So I was wondering if you plan to record the
boarding?

If I wouldn't have needed the debug environment for my work I would have
just given up after some frustrating hours and dismissed the idea of
helping bugfixing QGIS.


regards,
Thomas

Raymond Nijssen  schrieb am Do., 5. Dez. 2019, 13:19:

> Dear Devs,
>
> Making plans for the next hackfest (13-15 March 2020, The Netherlands)
> we are thinking of a way to attract new people to the project. Quite
> some Dutch people are interested to come over and "see" us, but of
> course we need to help them getting up and running.
>
> So we are thinking on doing an "Onboarding Day" the day prior to the HF
> (Thursday March 12) with workshops teaching:
>
> - How to translate?
> - How to write documentation?
> - How to compile?
> etc...
>
> We already noticed Alessandro's offer to do a Mentor Stream on "my first
> pull request" which would also fit this idea.
>
> Just curious, what are your thoughts on this? And would you like to
> arrive one day earlier in the lovely Netherland to warmly welcome new
> contributors?
>
> Thanks,
> Raymond (and Rosa and Aron)
>
>
> https://github.com/qgis/QGIS/wiki/24th-Contributor-Meeting-in-'s-Hertogenbosch
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] BWTA2017 grid support in QGIS >= 3.10

2019-12-03 Thread Thomas Baumann
@Even Rounault: thanks for this info. Then I guess we'll see the BWTA2017
support in 3.10.3 in the mid of january... keeping fingers crossed :-)

Am Di., 3. Dez. 2019 um 15:06 Uhr schrieb Even Rouault <
even.roua...@spatialys.com>:

> > @Jürgen Fischer: is there a change that you could "cherry-pick" the
> > corresponding pull requests and patch them into the existing PROJ release
> > used by osgeo4w for the upcoming pointrelease?
>
> Just wants to note that a PROJ 6.3.0 release, with the
> accompanying proj-datumgrid- backages, is scheduled for the beginning
> of
> January.
>
> Even
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] BWTA2017 grid support in QGIS >= 3.10

2019-12-03 Thread Thomas Baumann
Hello QGIS-devs,

in QGIS2 and QGIS-3 versions with proj<6 there was a support for the
BWTA2017.gsb-gridfile which is needed in the state Baden-Württemberg (
https://en.wikipedia.org/wiki/Baden-W%C3%BCrttemberg ) in southwest germany
to transform between the former official crs EPSG31467 and the new one
EPSG25832:

https://github.com/qgis/QGIS/pull/6980


For some time there was an issue about including the BWTA in the
proj-datumgrid.

https://github.com/OSGeo/proj-datumgrid/issues/22

The main reason why QGIS 3.10/proj6 cannot use the BWTA2017.gsb is that it
is not referenced in the EPSG registry so far but I will get in contact
with the LGL (www.lgl-bw.de) to ask them if they can make a changerequest
on http://www.epsg.org/EPSGDataset/Makechangerequest.aspx

For the meantime there are two pull requests which have been merged today:

https://github.com/OSGeo/proj-datumgrid/pull/65
and
https://github.com/OSGeo/PROJ/pull/1759 ( Even Rouault:"...As EPSG has no
entry for it, we create a grid_transformation, as well as a dedicated area
of use based on the extent of the grid, under the PROJ authority. With the
hope to be able to remove it once EPSG has an entry...")

@Jürgen Fischer: is there a change that you could "cherry-pick" the
corresponding pull requests and patch them into the existing PROJ release
used by osgeo4w for the upcoming pointrelease?

regards,
Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] crssync.exe crash during QGIS build

2019-11-25 Thread Thomas Baumann
Hi Devs,
I managed to build QGIS under linux and windows with QTCreator.
What still doesn't work is building QGIS with visual developer.

I followed instructions like
https://github.com/qgis/QGIS/blob/master/INSTALL#L423
https://www.shaeffer.co/compiling-qgis-with-visual-studio/
https://www.cursosgis.com/compilar-y-debuggear-qgis-en-windows/

but everytime I try to build QGIS within Visual Developer crssync.exe
crashes and when I try to start the debugger I get the error message that
qgis_app.dll is missing even if the file is in the folder where qgis.exe is
also located:
C:\Projects\QGIS\ms-windows\osgeo4w\build-qgis-test-x86_64\output\bin\RelWithDebInfo


Does someone know how to find out what is causing the problem?

I rebuilt qgis_app, qgis_core and crssync separately within visual
developer. All of them succeeded but the ALL_Build/Debugging still doesn't
work.

---
Problemsignatur:
  Problemereignisname: APPCRASH
  Anwendungsname: crssync.exe
  Anwendungsversion: 0.0.0.0
  Anwendungszeitstempel: 5ddb8f23
  Fehlermodulname: qgis_core.dll
  Fehlermodulversion: 6.3.9600.19464
  Fehlermodulzeitstempel: 5d6727f2
  Ausnahmecode: c135
  Ausnahmeoffset: 000ecf30
  Betriebsystemversion: 6.3.9600.2.0.0.272.7

regards,
Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] how to make sure QGIS3 is always started by calling qgis.bat and not qgis.exe?

2019-05-06 Thread Thomas Baumann
Hello QGIS-Devs,

I recently asked a question on gis.stackexchange about how to make sure
that QGIS3 is always started by calling the qgis.bat file:
https://gis.stackexchange.com/questions/321108/check-whether-qgis3-was-started-by-qgis-bat-or-qgis-exe

( The reason why I want to make sure that qgis.bat is used is that I have
added a md5-check which checks the startup.py in the users profile path
against the current startup.py I want to rollout on all clients.)

One idea which was posted on stackexchange was to intentially break the
connection between qgis.exe and the *.env/*.var files qgis expects to find
in order to make sure QGIS can obly be started by calling the qgis.bat file.

I am just wondering if it is safe to use QGIS3 without the information in
the *.env and *.var files or is this rather a bad idea?

Any other ideas how to make sure everyone uses the current startup.py?


regards,

Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Crashes on closing QGIS

2019-04-11 Thread Thomas Baumann
Hi Nathan,
is this a configuration issue? Can I do something to get the correct
symbols in the stacktrace?

regards,
Thomas


Am Do., 11. Apr. 2019 um 12:52 Uhr schrieb Nathan Woodrow <
madman...@gmail.com>:

> Nyall has hopefully fixed that bug already.  The one with proj_lpz_dist in
> the stack trace.  That isn't the real crash as that stack trace has no
> symbols so it's giving you the wrong info.  I got a stack trace the other
> day with correct symbols loaded and hopefully, it will be fixed now.
>
> - Nathan
>
> On Thu, Apr 11, 2019 at 5:06 PM Jürgen E. Fischer  wrote:
>
>> Hi Thomas,
>>
>> On Wed, 10. Apr 2019 at 23:04:50 +0200, Thomas Baumann wrote:
>> > proj_lpz_dist :
>> > QgsCoordinateTransform::transformPolygon :
>>
>> > Does someone know what "proj_lpz_dist" stands for?
>>
>> It's a function from PROJ:
>>
>>
>> https://proj4.org/development/reference/functions.html?highlight=deg#c.proj_lpz_dist
>>
>>
>> Jürgen
>>
>> --
>> Jürgen E. Fischer   norBIT GmbH Tel.
>> +49-4931-918175-31
>> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
>> +49-4931-918175-50
>> Software Engineer   D-26506 Norden
>> https://www.norbit.de
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Crashes on closing QGIS

2019-04-10 Thread Thomas Baumann
Hi there,

@Alessandro Pasotti; thanks for pointing out that there are several persons
affected by bugs which cause QGIS3 to crash on exit.
I know that my stacktrace is different from Andreas' one. when I said "same
here" I was refering to Andreas'  statement  "We always have crashes on
closing QGIS (on Windows)".

@Jürgen Fischer: ok. here is the long story about the stacktrace ;-) :
Yesterday I created some layers (mostly memory layers )with the processing
toolbar (reproject, union and so on). Then I did not touch the opened
project until today when I wanted to close QGIS and it warned me that there
are unsaved memory layers. So I canceled the closing and saved the layer.
After that I tried to close QGIS and it crashed.

@Matthias Kuhn: I can understand that the priority is not as high as if
would be if data would be corrupted but if I have a look at
https://issues.qgis.org/issues/20283 I see nearly 70 tickets linked to this
one where it was reported that QGIS crashes while closing so I think it's
obvious that is is a nasty bug that affects a lot of people.
Doing a quick google search for the term " proj_lpz_dist"  shows a lot of
cases where the coordinate transformation of a polygonlayer seems to cause
problems:

proj_lpz_dist :
QgsCoordinateTransform::transformPolygon :


Does someone know what "proj_lpz_dist" stands for?

If I would have been able to reproduce the error I would have contacted our
QGIS support provider to let them fix the bug but until now it was not
possible to reproduce the crash.

Is there something else that can be done to help fixing this bug?
This bug is one of the reasons why QGIS3 cannot be rolled out for
productiuon use at my workplace. Even if QGIS3 has very nice new features
QGIS2.18 is still way more stable at the moment, so we postpone the QGIS3
rollout from week to week.

regards,
Thomas




Am Mi., 10. Apr. 2019 um 17:30 Uhr schrieb Jürgen E. Fischer :
>
> Hi,
>
> On Wed, 10. Apr 2019 at 16:14:50 +0200, Alessandro Pasotti wrote:
> > @thomas : there are already dozen of issue reports with your stacktrace,
> > which is very different from Andrea's.
>
> namely https://issues.qgis.org/issues/20283, but a clue how to reproduce
the
> issue.   People tend to just post the crash report, but most of the time
no
> information how to reproduce the issue - this is not one of the issue
where the
> pure stacktrace is conclusive.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel.
+49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
+49-4931-918175-50
> Software Engineer   D-26506 Norden
https://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on
FreeNode
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Crashes on closing QGIS

2019-04-10 Thread Thomas Baumann
Hi there,

same situation here: QGIS 3.6 crashed several times when trying to close it.

regards,
Thomas

PS: attached is one crash report:


h2. User Feedback

QGIS Crashed when I tried to close QGIS

h2. Report Details

*Crash ID*: 62f1fcd2045780cb9f127836e6b579b8665f3e63


*Stack Trace*

proj_lpz_dist :
proj_lpz_dist :
QgsCoordinateTransform::transformPolygon :
QgsCoordinateTransform::transformPolygon :
QgsCoordinateTransform::QgsCoordinateTransform :
QHashData::free_helper :
QgsCoordinateTransform::addToCache :
QgsCoordinateTransform::invalidateCache :
QgsApplication::exitQgis :
QgisApp::~QgisApp :
CPLStringList::operator[] :
main :
BaseThreadInitThunk :
RtlUserThreadStart :



*QGIS Info*
QGIS Version: 3.6.0-Noosa
QGIS code revision: commit:58734527ab
Compiled against Qt: 5.11.2
Running against Qt: 5.11.2
Compiled against GDAL: 2.4.0
Running against GDAL: 2.4.0



*System Info*
CPU Type: x86_64
Kernel Type: winnt
Kernel Version: 10.0.14393


Am Mo., 8. Apr. 2019 um 11:22 Uhr schrieb Andreas Neumann <
a.neum...@carto.net>:

> Hi,
>
> We always have crashes on closing QGIS (on Windows) - regardless of
> version - it happens on 3.4, 3.6 and master.
>
> Seems to be related to the authentication manager. Is this a known issue?
> Are there ideas how to fix the issue?
>
> Here is the crashlog:
>
> Crash ID: 0f25782d491a42462ec5c96af91c45b3e9859bd3
>
> Stack Trace
>
>
> QMutex::lock :
> QMutexLocker::QMutexLocker :
> ::operator() qgsauthmanager.cpp:145
> QtPrivate::FunctorCall,QtPrivate::List,void, >::call qobjectdefs_impl.h:128
> QtPrivate::Functor,0>::call,void> qobjectdefs_impl.h:239
> QtPrivate::QFunctorSlotObject,0,QtPrivate::List,void>::impl 
> qobjectdefs_impl.h:427
> QMetaObject::activate :
> QThread::finished :
> QThread::currentThreadId :
> QThread::start :
> BaseThreadInitThunk :
> RtlUserThreadStart :
>
>
>
>
> QGIS Info
> QGIS Version: 3.7.0-Master
> QGIS code revision: 5a85e206f6
> Compiled against Qt: 5.11.2
> Running against Qt: 5.11.2
> Compiled against GDAL: 2.4.1
> Running against GDAL: 2.4.1
>
>
>
> System Info
> CPU Type: x86_64
> Kernel Type: winnt
> Kernel Version: 6.1.7601
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Red '__MACOSX' in plugin layer list

2019-03-12 Thread Thomas Baumann
Hi Richard,

yes for QGIS3 the OSMDownloader is one of the plugins with macosx folder:

check for QGIS 3.4:
-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
MapsPrinter.0.5.zip
AzimuthDistanceCalculator.2.0.zip
OSMDownloader.1.0.zip
MongoConnector.1.2.0.zip
Socrata.2.0.zip
natusferaqgis3.1.0.zip
FS3.1.0.1.zip
geohey_toolbox.0.4.zip
qgisgbifapi.0.3.0.zip
HotspotAnalysis.1.0.2.zip
SleuthInputs.3.0.zip
ecovaluator.2.0.zip
Hqgis.0.4.1.zip
-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

I adapted my script so it works for walking through the filesystem instead
of crawling through the parsed repository xml:
It walks recursive through your main repository folder and checks each zip
file for the macosx folder:
https://gist.github.com/rdbath/7f617d4d3b3417fdb50ae9048e2056cc

Listing the emails of the authors is something I can't do at the moment as
they are not part of the repository xml, so I have no access to the email
adresses.

I guess it's better to directly contact the authors instead of opening one
issue for each plugin, especially as a part of the tracker-url's in the
repository is not up to date.
I will write a seperate email about this topic in a second.

regards,
Thomas



Am Di., 12. März 2019 um 10:23 Uhr schrieb Richard Duivenvoorde <
rdmaili...@duif.net>:

> On 12/03/2019 09.21, Thomas Baumann wrote:
>
> > In order to cause less traffic and have a better performance it would be
> > much better to run the script on the server where the plugin zipfiles
> > are located.
>
> Hi Thomas,
>
> If you provide me the script I will run it.
>
> With me the OSMDownlader plugin added it. You can see it by going into
> the folder on your disk. The folder contains all kind of file data (not
> sure if it sensitive or not).
>
> I created an issue:
> https://github.com/qgis/QGIS-Django/issues/62
>
> Maybe you can upload your script there?
> ANd maybe a feature request :-)
> Also list the email of the author so we can mass mail the current
> __MACOSX uploaders :-)
>
> Thanks for idea and work
>
> Regards,
>
> Richard Duivenvoorde
>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Red '__MACOSX' in plugin layer list

2019-03-12 Thread Thomas Baumann
Hi Paolo,

i wrote a python script to check the qgis 2.18 repository and found 28
plugins which contain a __macosx folder:

AzimuthDistanceCalculator.1.1.2.zip
GeoHealth.1.0.1.zip
irods_qgis.3.2.zip
QgisGeoJSONExportPlugin.0.2.0.zip
vTool.0.2.zip
GridZoneGenerator.1.3.zip
qgis-mongodb-loader.1.4.0.zip
qgis-amigocloud-plugin.0.6.2.zip
pandora.2.0.1.zip
Submission.0.4.zip
mole.0.998k.zip
EmergencyMapper.0.0.1.zip
JapanElevation.1.0.zip
ZebToolbox.0.3.1.zip
PointToPolygon.1.0.zip
pgChainage.1.1.0.zip
geohey_toolbox.0.3.zip
pdokbaggeocoder.0.6.4.zip
pyarchinit.0.1.6.1.zip
geobricks_qgis_plugin_trmm.0.2.zip
geobricks_qgis_plugin_world_bank.0.1.zip
geobricks_qgis_plugin_faostat.0.5.zip
qgisgbifapi.0.2.0.zip
HotspotAnalysis.0.5.zip
SleuthInputs.0.3.zip
PointToPolygon.0.6.zip
EasyTemplatePrint.0.1.zip
envifate.0.1.zip

In order to cause less traffic and have a better performance it would be
much better to run the script on the server where the plugin zipfiles are
located.

regards,
Thomas



Am Di., 12. März 2019 um 02:21 Uhr schrieb Paolo Cavallini <
cavall...@faunalia.it>:

> Hi all,
> this would be welcomed. I check the git repo and ask to delete them when I
> spot them, but checking every zip manually it's a pain.
> Anyone could take this? Better open a ticket and add a note to the how-to
> page for plugin uploaders.
> Thanks.
>
> Il 11 marzo 2019 22:34:31 CET, Nyall Dawson  ha
> scritto:
>>
>> On Tue, 12 Mar 2019 at 05:08, Richard Duivenvoorde  
>> wrote:
>> >
>>
>>>  It says (see screenie): "This plugin is broken"
>>>
>>>  I'll go over my plugins to see if I see it somewhere, I think it is part
>>>  of one the zips...
>>>
>>>  Maybe check for it in our Django app?
>>>
>>
>> This sounds sensible - those folders are so prevalent amongst mac
>> users that I think any one-off fixes will be very short term.
>>
>> Nyall
>>
>> >
>>
>>>  Richard
>>>
>>>  On 11/03/2019 19.53, Tim Sutton wrote:
>>>
  What do you see in the description if you click that entry?

  Regards

  Tim

  On 11 Mar 2019, at 20:42, Richard Duivenvoorde   > wrote:
>
>  Hi,
>
>  In top of my layerlist in my current profile, I have a this red __MACOSX
>  item (see screenshot). FYI I do not own/run a mac :-)
>
>  So I think that this comes with some other plugin when I install it?
>
>  Though I also thought: but this only the list based on the xml so had a
>  look too:
>
>  https://plugins.qgis.org/plugins/plugins.xml?qgis=3.7
>
>  But that one does not show it. So I think that one or more of the
>  plugins 'install' it?
>  Do others also have this?
>
>  Another solution could be I add a __DEBIAN on top :-)
>
>  Regards,
>
>  Richard Duivenvoorde
>  
> ___
>  QGIS-Developer mailing list
>  QGIS-Developer@lists.osgeo.org
>  List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>  Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
  —







  *Tim Sutton*

  *Co-founder:* Kartoza
  *Ex Project chair:* QGIS.org 

  Visit http://kartoza.com  to find out about open
  source:

  Desktop GIS programming services
  Geospatial web development
  GIS Training
  Consulting Services

  *Skype*: timlinux
  *IRC:* timlinux on #qgis at freenode.net 
 --
  QGIS-Developer mailing list
  QGIS-Developer@lists.osgeo.org
  List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
  Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

 --
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>> --
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
> --
> Sorry for being short
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Red '__MACOSX' in plugin layer list

2019-03-11 Thread Thomas Baumann
Hi,
I have had this __MACOSX folder in the plugin for several times in the
past. It came from plugin zip files which contained this folder.
It seems that this (in MacOS hidden) folder gets included in the zipfile
when you use the MacOS Finder to zip folders:
https://apple.stackexchange.com/q/288568
I always just deleted the folder and restarted qgis.

regards,
Thomas

Richard Duivenvoorde  schrieb am Mo., 11. März 2019,
19:42:

> Hi,
>
> In top of my layerlist in my current profile, I have a this red __MACOSX
> item (see screenshot). FYI I do not own/run a mac :-)
>
> So I think that this comes with some other plugin when I install it?
>
> Though I also thought: but this only the list based on the xml so had a
> look too:
>
> https://plugins.qgis.org/plugins/plugins.xml?qgis=3.7
>
> But that one does not show it. So I think that one or more of the
> plugins 'install' it?
> Do others also have this?
>
> Another solution could be I add a __DEBIAN on top :-)
>
> Regards,
>
> Richard Duivenvoorde
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3

2019-02-20 Thread Thomas Baumann
Hi Nyall,

thanks for your feedback.
You are right that some of my examples were not ideal to explain what I
meant, so I try to explain it a bit better this time ;-)

Some of the following pyqgis-examples may be outdated as things can be done
easier in qgis3 now but they should just be an example
for some functions that were written by users to make life easier during
the development of QGIS plugins.


Example1: QgsVectorlayer:

Am Mi., 20. Feb. 2019 um 10:29 Uhr schrieb Nyall Dawson <
nyall.daw...@gmail.com>:

>
> This is a single line via the existing API :
>
> vl = QgsVectorLayer( '/home/me/my.shp' , 'my_layer' )
>
> I'm curious to hear how this could be improved?
>

I wrote "load a vectorlayer" but meant "create a vectorlayer"

Something like:

https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L24


Example2: For loading layer I meant something like

https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L7
:


def load_layer(filename, name = None):
'''
Tries to load a layer from the given file
:param filename: the path to the file to load.
:param name: the name to use for adding the layer to the current project.
If not passed or None, it will use the filename basename
'''
name = name or os.path.splitext(os.path.basename(filename))[0]
qgslayer = QgsVectorLayer(filename, name, 'ogr')
if not qgslayer.isValid():
qgslayer = QgsRasterLayer(filename, name)
if not qgslayer.isValid():
raise RuntimeError('Could not load layer: ' + unicode(filename))

return qgslayer

-

Example3: Iterate through layers:


> # all layers
> layers = [l.layer() for l in
> QgsProject.instance().layerTreeRoot().findLayers()]
>


> # visible layers
> visible_layers = [l.layer() for l in
> QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]
>
> Ok, not super-obvious in this case, but still quite concise ;)
>

For the example of  visible_layers = [l.layer() for l in
QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]  :
I would probably have needed some minutes to search in one of my plugins if
I have used such a code snippet before or google gis.stackexchange ;-)
Probably I also wouldn't have written such a fancy nice one-liner to get
these layers.

So if there would be a pyqgis-commons library where I would know that I
just have to call a function "get_visible_layers" instead of  using
[l.layer() for l in
QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]  I
probably could use this in my next plugin without having to search/google
how to do this.


Example4: show messages / log messages:

>
> > - show a message with different levels (info, warning, critical)
>
> iface.messageBar().pushWarning('blah','some message')
> iface.messageBar().pushInfo('blah','some message')
> iface.messageBar().pushCritical('blah','some message')
>
> > - log messages
> QgsMessageLog.logMessage('my plugin','something', Qgis.Critical)



I had something in mind like the MessageManager of Germán Carrillo:

https://github.com/gacarrillor/AutoFields/blob/master/MessageManager.py

I like the MessageManager because I can easily switch between the
message-modes 'production' or 'debug.

One other example would be the function "display_warning_message_bar" from
the inasafe-utilities where I can show a short message and also provide a
button to show more details about a warning:
https://github.com/inasafe/inasafe/blob/bd00bfeac510722b427544b186bfa10861749e51/safe/utilities/qgis_utilities.py#L132



 Example5: Settings:

>
> > - reading setting, writing settings
>
> The QgsSettings class should make this straightforward
>

Here I hat something in mind like the qgis-settingsmanager of opengis (
https://github.com/opengisch/qgissettingmanager ).
I know it is not only a collection of python-/pyqt-functions but a whole
python module but I still it is an example of how functionalities are
provided to make the development of plugins easier.


So it is always about providing some helper functions that I could also
write by myself but which will save time during development and can help me
to do the things in a consistent way in all of my plugins.



> I'm not saying we can't improve the PyQGIS experience, but I don't
> personally see these as good candidates.
>
> I think we have a LOT of work to do with things like:
> - throwing proper exceptions instead of crashing/returning "None"
> values/returning "invalid" objects (e.g. QgsGeometry.fromWkt should
> ideally raise an exception for invalid wkt instead of returning a null
> geometry)
> - providing Python-esque things like __repr__ methods, __len__, []
> operators (which behave in a python style, e.g. with -1 returning the
> last item), iterators, etc
> - providing more "context managers" (e.g. with  : #something )
>

I don't have such a deep insight in the QGIS-codebase but I guess this
would probably have to be done in the C++-part of QGIS, wouldn't it?


 

[QGIS-Developer] Common PyQGIS functions for QGIS 3

2019-02-20 Thread Thomas Baumann
Hi qgis-devs,

I recently updated 15 QGIS-plugins to be QGIS3-ready. Most of them were
self written (in house) plugins but four of them were also plugins from the
official repository which were written by someone else.

I noticed that there are severals tasks that have many plugins in common
like:
- load a vectorlayer
- add a layer to the layertree
- iterate through all (visible?) layers of the layertree
- show a message with different levels (info, warning, critical)
- log messages
- reading setting, writing settings
- ...

It seems a bit ineffective that every developer writes these common task
'from scratch'.

There already were some ideas to collect common functions that could be
re-used by plugin-developers:

-some older functions (GIS2) like

https://github.com/NathanW2/parfait

https://github.com/qgis/pyqgis_wrappers

and something newer like

https://github.com/boundlessgeo/lib-qgis-commons
https://pypi.org/project/qgiscommons/


One nice example for utilities collected for a (huge) plugin is:

https://github.com/inasafe/inasafe/tree/master/safe/utilities


Wouldn't it be possible to provide such a collection not only from privat
persons/projects but from the QGIS-project itself so users could add common
functions?
I think the chances would be higher that such a "official" collection would
be used in the long run and constantly extended.

Apart from the fact that developers could save time while writing their
plugins this could perhaps also help to improve the overall quality of the
qgis-plugins as there would probably be several persons who could/would
countercheck these common functions to make sure they are well written.

regards,
Thomas

PS: I asked something similar also on gis.stackexchange recently:

https://gis.stackexchange.com/questions/311755/looking-for-common-pyqgis-functions-for-qgis-3
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Plugin idea for Editing multiple layers

2019-02-16 Thread Thomas Baumann
Hello Alexandre,
for editing/selecting multiple layers I have used the QAD Plugin before.
For just selecting features from multiple layers there is the MultipleLayer
Selection-plugin:
 https://plugins.qgis.org/plugins/MultipleLayerSelection/

I think such a tool is indeed very useful.

Regards,
Thomas

Am Sa., 16. Feb. 2019, 14:54 hat Alexandre Neto 
geschrieben:

> Hi,
>
> I don't do much editing, but recently I needed to edit several layers at
> the same time. Although I find the digitizing capabilities of QGIS great,
> the bigger bottleneck I found in terms of productivity was in the selecting
> tools, because it forces the user to first make the layer active before he
> can select a feature in it. Editing multiple layers at the same time forces
> you to repeat that over and over again.
>
> So I though it would be nice to create a multi layer selection tool. It
> would work like the identify tool, selecting the first feature from top to
> bottom, then it would make the respective layer active, therefore ready for
> editing.
>
> Other options could be added later, like selecting the next and previous
> feature, or selecting all features from all layer. There could be options
> to determine which layers can be selected.
>
> Two questions:
> - for users: Anyone finds this useful?
> - for developers: Being done as a python plugin, will this be to slow if
> one uses too many layers/features?
>
> Thanks,
>
> Alexandre Neto
>
>
> --
> Alexandre Neto
> -
> @AlexNetoGeo
> http://sigsemgrilhetas.wordpress.com
> http://gisunchained.wordpress.com
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Find unmaintained plugins

2019-02-04 Thread Thomas Baumann
Hi Paolo,
I opened a ticket now:

https://issues.qgis.org/issues/21164

Regards,
Thomas



Am Sa., 2. Feb. 2019, 08:30 hat Paolo Cavallini 
geschrieben:

> Thanks for your offer of help. I agree that the mail should be sent only
> for plugins not updated in the last (3? 6? 9?) months.
> Could you please start filling up a ticket on
> https://issues.qgis.org/issues
> so we can define specs resulting from this thread and start implementing
> it?
> Cheers.
>
> On 01/02/19 22:40, Thomas Baumann wrote:
> > Hi Paolo,
> >
> > sounds like a good idea to send a reminder once a year to the maintainer
> > and mark plugins as unmaintained if no feedback is received.
> >
> > I am available to help implementing it.
> >
> > Regards,
> > Thomas
> >
> >
> > Am Fr., 1. Feb. 2019, 19:01 hat Paolo Cavallini  > <mailto:cavall...@faunalia.it>> geschrieben:
> >
> > Hi Thomas,
> >
> > On 01/02/19 13:53, Thomas Baumann wrote:
> >
> > > I made the experience that there are QGIS-plugins which are not
> > > maintained anymore.
> > > Example:
> > >
> >
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Rectangles-Ovals-Digitizing-plugin-deprecated-td5366686.html
> > >
> > > Recently I asked some maintainers if they have plans to update
> their
> > > plugins to be QGIS3-ready because I was willing to update them if
> the
> > > maintainer wouldn't do it... but again I got the impression that
> some
> > > plugins are not maintained anymore.
> > > Example:
> > > https://github.com/NathanW2/selection-sets/issues/5
> > >
> > > Now that there is the change from QGIS2 to QGIS3 some unmaintained
> > > plugins will just dissapear like through a "natural selection".
> But in
> > > one or two years there could again be lots of unmaintained plugins
> > which
> > > could have bugs that slow down qgis or make them unstable like it
> > > happened with the Rectangles-Ovals-Digitizing-plugin (
> > > https://github.com/vinayan/RectOvalDigitPlugin/issues/6 ).
> > >
> > > Wouldn't it make sense to check once a year if all plugins are
> still
> > > maintained?
> > >
> > > You could for example use something like LimeSurvey (
> > > https://www.limesurvey.org/community ) and ask every maintainer to
> > > respond if they still feel responsible for the plugin. In the
> > backend of
> > > Limesurvey you have a database with the responses so it should be
> > quite
> > > easy to automatically synchronize the results with your
> > repository-items.
> > > This way the unmaintained plugins could be marked as deprecated if
> no
> > > response is sent back.
> >
> > thanks a lot for your suggestion. I agree that the move to QGIS 3
> > automatically purges old unmaintained code, but this does not solve
> > entirely the issue.
> > In short do you suggest we should run a survey once a year, sending
> it
> > to the list of plugin maintainers, and marking as deprecated all
> plugins
> > for which we do not receive a positive response?
> > I would be a bit skeptical, as many plugins are still useful even if
> not
> > actively maintained. An alternative would be to add to our Django
> app an
> > automatic reminder to be sent to maintainer, asking to confirm they
> > maintenance; in absence of a feedback, we could mark it as
> unmaintained,
> > and make this visible to users, so they have the options of adopting
> it,
> > supporting it, or stopping using it before it actually stops working.
> > How does it sound? in case you agree on this or a modified version of
> > it, would you be available to help implementing this?
> > All the best.
> > --
> > Paolo Cavallini - www.faunalia.eu <http://www.faunalia.eu>
> > QGIS.ORG <http://QGIS.ORG> Chair:
> > http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org  QGIS-Developer@lists.osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Find unmaintained plugins

2019-02-04 Thread Thomas Baumann
Hi,
I can understand concerns about not wanting to discourage maintainers.

But at the same time you have to see that buggy unmaintained plugins can
cause a lot of frustration to users.
I have made the experience that problems caused by such plugins are also
actually very bad for the reputation of qgis.
(Because most of the users (and the deciders in a company) won't
differentiate between qgis "core" and the plugins which are distributed
over the official(!) repository. From their point of view qgis is just
buggy.)

I think it's just fair to inform the user if a plugin is still maintained
or not and to be honest I don't quite understand why it should be too hard
to click on a confirmation-link once a year to prove that you still
maintain a plugin.

If the maintainer does not want to respond or does not find the time to
click the link than I guess it just reflects the fact that the plugin isn't
maintained by this person anymore.


For qgis 2.18 there were more than 800 plugins in the official repository
and I guess that in some years there could be even more plugins available
for qgis 3.

I think it will be hard to keep qgis3 stable and performant if buggy
unmaintained plugins won't be sorted out or at least marked as unmaintained.

Regards,
Thomas








Am Mo., 4. Feb. 2019, 15:25 hat Tim Sutton  geschrieben:

> Hi
>
>
> On 04 Feb 2019, at 00:30, Nyall Dawson  wrote:
>
> On Mon, 4 Feb 2019 at 00:57, Matthias Kuhn  wrote:
>
>
> Hi Paolo
>
> On 2/3/19 1:39 PM, Paolo Cavallini wrote:
>
> Hi Matthias,
>
> On 03/02/19 10:17, Matthias Kuhn wrote:
>
> Marking a plugin as "unmaintained" or "deprecated" is a heavy action which
> may discourage developers and make even useful plugins disappear.
>
>
> deprecated yes, unmaintained not necessarily. We could just let the user
> know, perhaps suggesting a way to solve this, without removing them for
> the list of available plugins (just like the Featured tag).
>
>
> Then I misunderstood the goal of this proposal, sorry.
>
> I was imagining myself looking through a plugin list of a software of
> which I am an ordinary user and seeing a plugin tagged as
> "unmaintained". This would make me think it's unreliable, outdated and
> unstable and hence not recommended.
>
>
> I think this actually IS the intention here.
>
> But, as you've pointed out, no activity =/= unmaintained, as sometimes
> no activity just means bug free and feature complete. In this case I
> think it's fine to require developers to respond to a quick "is this
> still maintained" survey in order to avoid the flag.
>
>
> And sometimes even if the plugin is unmaintained it is still useful to
> lots of people (even if it has a few known bugs)…..
>
> I’m not sure if flagging plugins as unmaintained is always so nice.. I
> would favour an approach where we could just list plugins in the plugin
> manager based on the date of their last release, most recent first so that
> you can see old versus new
>
> Definitely -1 here on removing plugins that are orphaned unless they are
> part of a security / data integrity risk. Many people may have built up
> specific workflows around the existence of a particular plugin or two and
> there is no need to break this for people even if the plugin is orphaned…
>
> Regards
>
> Tim
>
>
>
> —
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Find unmaintained plugins

2019-02-01 Thread Thomas Baumann
Hi Calvin,
I have opened issues on GitHub for several plugins or sent pullrequest with
no reaction at all what's pretty frustrating.
I don't think that it's a good idea to wait several years until it's clear
that a plugin is not maintained anymore.
Answering one email per year (and plugin) doesn't seem to be too much
effort to me.

Regards,
Thomas


Am Fr., 1. Feb. 2019, 22:47 hat C Hamilton 
geschrieben:

> I would only send a reminder to the maintainer if there has not been a
> recent update and for some plugins they may not need to be updated for
> several years - with the exception of a major release i.e. 2 to 3.
>
> Regards,
> Calvin
>
> On Fri, Feb 1, 2019 at 4:41 PM Thomas Baumann 
> wrote:
>
>> Hi Paolo,
>>
>> sounds like a good idea to send a reminder once a year to the maintainer
>> and mark plugins as unmaintained if no feedback is received.
>>
>> I am available to help implementing it.
>>
>> Regards,
>> Thomas
>>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Find unmaintained plugins

2019-02-01 Thread Thomas Baumann
Hi Paolo,

sounds like a good idea to send a reminder once a year to the maintainer
and mark plugins as unmaintained if no feedback is received.

I am available to help implementing it.

Regards,
Thomas


Am Fr., 1. Feb. 2019, 19:01 hat Paolo Cavallini 
geschrieben:

> Hi Thomas,
>
> On 01/02/19 13:53, Thomas Baumann wrote:
>
> > I made the experience that there are QGIS-plugins which are not
> > maintained anymore.
> > Example:
> >
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Rectangles-Ovals-Digitizing-plugin-deprecated-td5366686.html
> >
> > Recently I asked some maintainers if they have plans to update their
> > plugins to be QGIS3-ready because I was willing to update them if the
> > maintainer wouldn't do it... but again I got the impression that some
> > plugins are not maintained anymore.
> > Example:
> > https://github.com/NathanW2/selection-sets/issues/5
> >
> > Now that there is the change from QGIS2 to QGIS3 some unmaintained
> > plugins will just dissapear like through a "natural selection". But in
> > one or two years there could again be lots of unmaintained plugins which
> > could have bugs that slow down qgis or make them unstable like it
> > happened with the Rectangles-Ovals-Digitizing-plugin (
> > https://github.com/vinayan/RectOvalDigitPlugin/issues/6 ).
> >
> > Wouldn't it make sense to check once a year if all plugins are still
> > maintained?
> >
> > You could for example use something like LimeSurvey (
> > https://www.limesurvey.org/community ) and ask every maintainer to
> > respond if they still feel responsible for the plugin. In the backend of
> > Limesurvey you have a database with the responses so it should be quite
> > easy to automatically synchronize the results with your repository-items.
> > This way the unmaintained plugins could be marked as deprecated if no
> > response is sent back.
>
> thanks a lot for your suggestion. I agree that the move to QGIS 3
> automatically purges old unmaintained code, but this does not solve
> entirely the issue.
> In short do you suggest we should run a survey once a year, sending it
> to the list of plugin maintainers, and marking as deprecated all plugins
> for which we do not receive a positive response?
> I would be a bit skeptical, as many plugins are still useful even if not
> actively maintained. An alternative would be to add to our Django app an
> automatic reminder to be sent to maintainer, asking to confirm they
> maintenance; in absence of a feedback, we could mark it as unmaintained,
> and make this visible to users, so they have the options of adopting it,
> supporting it, or stopping using it before it actually stops working.
> How does it sound? in case you agree on this or a modified version of
> it, would you be available to help implementing this?
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Find unmaintained plugins

2019-02-01 Thread Thomas Baumann
Hello qgis-devs,

I made the experience that there are QGIS-plugins which are not maintained
anymore.
Example:
http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Rectangles-Ovals-Digitizing-plugin-deprecated-td5366686.html

Recently I asked some maintainers if they have plans to update their
plugins to be QGIS3-ready because I was willing to update them if the
maintainer wouldn't do it... but again I got the impression that some
plugins are not maintained anymore.
Example:
https://github.com/NathanW2/selection-sets/issues/5

Now that there is the change from QGIS2 to QGIS3 some unmaintained plugins
will just dissapear like through a "natural selection". But in one or two
years there could again be lots of unmaintained plugins which could have
bugs that slow down qgis or make them unstable like it happened with the
Rectangles-Ovals-Digitizing-plugin (
https://github.com/vinayan/RectOvalDigitPlugin/issues/6 ).

Wouldn't it make sense to check once a year if all plugins are still
maintained?

You could for example use something like LimeSurvey (
https://www.limesurvey.org/community ) and ask every maintainer to respond
if they still feel responsible for the plugin. In the backend of Limesurvey
you have a database with the responses so it should be quite easy to
automatically synchronize the results with your repository-items.
This way the unmaintained plugins could be marked as deprecated if no
response is sent back.

Just my two cents...

regards,
Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Ribbon-like UI for QGIS

2018-09-13 Thread Thomas Baumann
Hi,
I think you mean Kadas-Albireo:

https://github.com/sourcepole/kadas-albireo

greetings,
Thomas


Am Do., 13. Sep. 2018 um 13:04 Uhr schrieb Tim Sutton :

> Hi Idan
>
> Sourcepole already did a very nice ribbon implementation for QGIS for
> their fork of QGIS for the Swiss military. It was on GitHub somewhere
>
> https://github.com/sourcepole?utf8=✓=qgis==
>
> But I can’t see where in their repos it is any more. There are no active
> plans to port this work to the official QGIS builds though.
>
>
> Regards
>
> Tim
>
> On 13 Sep 2018, at 12:47, Idan Miara  wrote:
>
> Hi,
>
> How complicated would it be to implement (or sponsor) a Ribbon-like UI to
> QGIS?
> (i.e. MS-office 2007+)
> Do you think people would like that kind of UI for QGIS?
>
> Regards,
> Idan.
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> —
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] reload attribute table does not work for attribute changed by dataProvider

2018-06-14 Thread Thomas Baumann
Hello,
isnt it "QgsEditError" instead of "QgsEditException"?

regards,
Thomas


Am Do., 14. Juni 2018 um 03:26 Uhr schrieb Zhang Qun :

> Hi Matthias
>
> I follow the steps in the link you posted and get the following errors
> when trying to import
>
> ImportError: cannot import name QgsEditException
>
> Do I have to install some modules? Didn't find any luck on google.
>
> Best regards,
> Zhang Qun
>
> On Wed, Jun 13, 2018 at 6:16 PM, Matthias Kuhn 
> wrote:
>
>> Glad you like it :)
>>
>> Forwading this answer also to the mailing list for future reference,
>> Ethan, you need to use "reply to all" in your mail application or other
>> are not able to follow our conversation (which would be a pity ;) ).
>>
>> Best regards
>> Matthias
>>
>> On 06/13/2018 12:13 PM, Zhang Qun wrote:
>> > Wow, i was about to look into the with() statement. It looks much
>> > better.  Many thanks for the link.
>> >
>> > Regards,
>> > Ethan
>> >
>> >
>> > On Wed, Jun 13, 2018, 6:03 PM Matthias Kuhn > > > wrote:
>> >
>> > Hi Ethan,
>> >
>> > there are of course advantages and disadvantages of both methods,
>> but in
>> > most cases the QgsVectorLayer ones just "do the right thing",
>> especially
>> > when used with a `with` block, see also this post:
>> >
>> > http://www.opengis.ch/2015/08/12/with-edit-layer/
>> >
>> > Cheers
>> > Matthias
>> >
>> > On 06/13/2018 11:59 AM, Zhang Qun wrote:
>> > > Hi Matthias,
>> > >
>> > > Thanks very much for the instruction. I will try it out. The
>> > > dataProvider method seems simpler to me and it can set attributes
>> in
>> > > batch as it takes a list as input. The layer method seems only
>> > takes one
>> > > input. If i want to change 10 attributes of a feature, i have to
>> issue
>> > > 10 commands.
>> > >
>> > > Best regards,
>> > > Ethan
>> > >
>> > >
>> > > On Wed, Jun 13, 2018, 5:45 PM Matthias Kuhn > > 
>> > > >> wrote:
>> > >
>> > > Hi Ethan
>> > >
>> > > On 06/13/2018 11:18 AM, Zhang Qun wrote:
>> > > > Hi everyone, i"m using QGIS2.18, and trying to change
>> feature
>> > > attributes
>> > > > using the following two methods:
>> > > >
>> > > > *dataProvider:*
>> > > >
>> > > > |attrs
>> > >
>>  ={0:"hello",1:123}layer.dataProvider().changeAttributeValues({fid
>> > > > :attrs })|
>> > > >
>> > > > *layer object:*
>> > > >
>> > > >
>> > >
>> >
>>   
>> |layer.startEditing()layer.changeAttributeValue(fid,fieldIndex,value)layer.commitChanges()|
>> > > >
>> > > > I keep the attribute table open, and monitor the changes.
>> > The first
>> > > > method dataProvider is not able to update the attribute
>> > table on the
>> > > > fly, even the "reload table" button on the top menu of the
>> > table does
>> > > > not work. I have to re-open the table to see the changes.
>> > The second
>> > > > method is working, the attribute table gets instantly
>> updated.
>> > > >
>> > > > I would like to stay with the dataProvider method but not
>> > sure how to
>> > > > get instantly updated attribute table?
>> > >
>> > > The provider's dataChanged() signal needs to be emitted, I
>> > think you can
>> > > directly emit that or call `dataProvider().forceReload()`.
>> > >
>> > > Out of curiosity, why would you like to stay with the
>> > dataProvider
>> > > method?
>> > >
>> > > Bests
>> > > Matthias
>> > >
>> > >
>> > > >
>> > > > Thanks.
>> > > >
>> > > > Best regards,
>> > > > Ethan
>> > > >
>> > > >
>> > > > ___
>> > > > QGIS-Developer mailing list
>> > > > QGIS-Developer@lists.osgeo.org
>> > 
>> > > > >
>> > > > List info:
>> > https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > > > Unsubscribe:
>> > https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > > >
>> > > ___
>> > > QGIS-Developer mailing list
>> > > QGIS-Developer@lists.osgeo.org
>> > 
>> > > > >
>> > > List info:
>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > > Unsubscribe:
>> > https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > >
>> >
>>
>
> ___
> 

Re: [QGIS-Developer] Rectangles-Ovals-Digitizing plugin deprecated

2018-06-06 Thread Thomas Baumann
@ Richard Duivenvoorde :

I am talking about the Rectangles Ovals Digitizing plugin (
https://plugins.qgis.org/plugins/rectovalDigit/  )
Current version is 1.1.2

The code is currently available at
https://github.com/vinayan/RectOvalDigitPlugin

The author itself ( Pavol Kapusta ) is ok with the idea of deprecating the
plugin.

I emailed the current maintainer Vinayan Parameswaran ( vinayan...@gmail.com)
to find out if he still maintains the plugin but did not get an answer.

If someone else knows how to get in contact with him feel free to do so.

My fork of the plugin with the bugfix is available at

https://github.com/rdbath/RectOvalDigitPlugin/

as version 1.1.3.

Thomas







Am Mi., 6. Juni 2018 um 10:48 Uhr schrieb Richard Duivenvoorde <
rdmaili...@duif.net>:

> On 2018-06-06 10:34, Thomas Baumann wrote:
> > Am Di., 5. Juni 2018 um 19:08 Uhr schrieb Loïc Bartoletti
> > :
> >
> >> Hi,
> >>
> >> I forked it some years ago since it wasn't maintained, see
> >> https://plugins.qgis.org/plugins/CADDigitize/
> >>
> >> FYI, it's integrated into QGIS 3.
> >>
> >> Regards
> >>
> >> Loïc
>
> >
> > NOW I TRIED TO UPLOAD A NEW VERSION OF THE PLUGIN WITH THE BUGFIX AT
> > HTTPS://PLUGINS.QGIS.ORG/PLUGINS/ADD/ BUT I GET FOLLOWING
> > ERROR-MESSAGE:
> >
> >  "You cannot modifiy this plugin. "
> >
> > How should I proceed?
> >
> > Thomas
>
> I'm happy to move owner/maintainership to Thomas or Loïc, if needed.
>
> But it is not fully clear to me about which plugin (version) you
> (Thomas) are talking?
>
> So please:
> - make sure you have consent from the old maintainer to take over
> - sent me your username
> - the name of the plugin that you want ownership of
> - fix metadata of your new version so you credit yourself AND old
> maintainer
> - fix metadata so it points to your new maintained repo/docs/plugin
> site.
>
> Then we can move maintainership (and/or remove deprecated flag)
>
> Regards,
>
> Richard Duivenvoorde
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Rectangles-Ovals-Digitizing plugin deprecated

2018-06-06 Thread Thomas Baumann
In the fixed version of the plugin I have written in the about section:
"about=THIS PLUGIN IS NO LONGER ACTIVELY MAINTAINED. PLEASE USE CADDIGITIZE
INSTEAD: https://plugins.qgis.org/plugins/CADDigitize/;

So the idea behind the update is just to fix the problem for the users who
have installed the plugin and point them to an alternative.
I think that these users won't find out that they should get rid of the
plugin if it's just flagged as deprecated or does the user get a message
for already installed plugins if they get flagged as deprecated?


Am Mi., 6. Juni 2018 um 11:22 Uhr schrieb DelazJ :

> Hi,
> Should we not take the occasion to get rid of this plugin
>
> 2018-06-06 11:13 GMT+02:00 L.Bartoletti :
>
>>
>>
>> No offense to my question, but why use this plugin again, since
>> CADDigitize or QAD (and maybe others) do the same job (better) and more?
>>
>> Agreed  with Loïc. We often claim and try (Paolo?) to avoid redundant
> plugins. If in this case there are (better?) alternatives, we should not
> revive the plugin imho.
> I'd be in favor of fixing the current issue of freeze while deprecating it
> with a message in its description (in Plugin Manager) inviting potential
> users to migrate to the alternatives.
>
> Regards,
> Harrissou
>
> Regards
>>
>> Loïc
>>
>>
>> On 06.06.2018 10:48, Richard Duivenvoorde wrote:
>> > On 2018-06-06 10:34, Thomas Baumann wrote:
>> >> Am Di., 5. Juni 2018 um 19:08 Uhr schrieb Loïc Bartoletti
>> >> :
>> >>
>> >>> Hi,
>> >>>
>> >>> I forked it some years ago since it wasn't maintained, see
>> >>> https://plugins.qgis.org/plugins/CADDigitize/
>> >>>
>> >>> FYI, it's integrated into QGIS 3.
>> >>>
>> >>> Regards
>> >>>
>> >>> Loïc
>> >
>> >>
>> >> NOW I TRIED TO UPLOAD A NEW VERSION OF THE PLUGIN WITH THE BUGFIX AT
>> >> HTTPS://PLUGINS.QGIS.ORG/PLUGINS/ADD/ BUT I GET FOLLOWING
>> >> ERROR-MESSAGE:
>> >>
>> >>  "You cannot modifiy this plugin. "
>> >>
>> >> How should I proceed?
>> >>
>> >> Thomas
>> >
>> > I'm happy to move owner/maintainership to Thomas or Loïc, if needed.
>> >
>> > But it is not fully clear to me about which plugin (version) you
>> > (Thomas) are talking?
>> >
>> > So please:
>> > - make sure you have consent from the old maintainer to take over
>> > - sent me your username
>> > - the name of the plugin that you want ownership of
>> > - fix metadata of your new version so you credit yourself AND old
>> > maintainer
>> > - fix metadata so it points to your new maintained repo/docs/plugin
>> site.
>> >
>> > Then we can move maintainership (and/or remove deprecated flag)
>> >
>> > Regards,
>> >
>> > Richard Duivenvoorde
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Rectangles-Ovals-Digitizing plugin deprecated

2018-06-06 Thread Thomas Baumann
Am Di., 5. Juni 2018 um 19:08 Uhr schrieb Loïc Bartoletti <
lbartole...@tuxfamily.org>:

> Hi,
>
> I forked it some years ago since it wasn't maintained, see
> https://plugins.qgis.org/plugins/CADDigitize/
>
> FYI, it's integrated into QGIS 3.
>
> Regards
>
> Loïc
>

Hi,

good to know that there is a acitvely maintained alternative to the old
plugin.

I agree with Matthias that a patch should be shipped.

( "



*From my point of view, this patch should be shipped even without a general
overhaul.  The plugin in use and probably causing data loss, reducing
productivity and giving bad reputation for QGIS (I guess many are not aware
that it's actually a plugin which is responsible for the situation, that
their QGIS is slowing down).* " )

The current version of the plugin has more than 7 Downloads so probably
there are a lot of people affected by the bug.

What's really nasty about the plugin is the fact that is slows down QGIS
even if you don't use it's functionality. As soon as it is installed it
listenes to the currentLayerChanged signal and connects the editingStarted
and editingStopped signal again and again to the toggle function.

At the company I'm working for this bug had caused a lot of frustration
until I found out what caused QGIS to slow down, freeze and crash.
Indeed the users (of course) did not differentiate between the core QGIS
and plugins   and their feedback just was that their QGIS is slow and
unstable.


*Now I tried to upload a new version of the plugin with the bugfix at
https://plugins.qgis.org/plugins/add/
 but I get following error-message:*

"You cannot modifiy this plugin. "

How should I proceed?


Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Rectangles-Ovals-Digitizing plugin deprecated

2018-06-05 Thread Thomas Baumann
Am Di., 5. Juni 2018 um 14:29 Uhr schrieb Matthias Kuhn :

>
>
> On 06/05/2018 02:12 PM, Nyall Dawson wrote:
> > On 5 June 2018 at 21:51, Matthias Kuhn  wrote:
> >> I have never used the plugin but repeatedly seen its name mentioned, so
> >> I assume it's widely used?
> >>
> >> In this case, it would be great if someone could volunteer as a new
> >> maintainer for the plugin. I think the minimal amount of work would be
> >> to merge pull requests and upload patched releases to the plugin
> repository.
> >
> > It's not needed anymore - 3.0 has the built in rectangles and ovals
> > digitising tools.
>
> That's good news, but for the current LTR and as general question on
> deprecating plugins I think it's still a valid request ;-)
>
> Matthias
>
>
>

Are the build in rectangles and ovals tools in QGIS 3 maptools to digitize
objects in a polygon-layer or 'just' an algorithm of the processing toolbox?

A fixed version of the plugin is available at
https://github.com/rdbath/RectOvalDigitPlugin for people who would still
like to use the plugin.
I was just thinking about if I should volunteer as a maintainer but I think
the code of the plugin is in general a bit "stale" and would need an
overhaul for which I just don't have the time to do that.
So I am not sure if it's a good idea to make a new version of the plugin
available even if the major problem of the plugin is fixed.

Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Rectangles-Ovals-Digitizing plugin deprecated

2018-06-05 Thread Thomas Baumann
Hello,

the Rectangles-Ovals-Digitizing plugin (
https://plugins.qgis.org/plugins/rectovalDigit ) has an issue that causes
QGIS to slow down and get unstable:
https://github.com/vinayan/RectOvalDigitPlugin/issues/6

I sent a pullrequest with a fix for the problem (
https://github.com/vinayan/RectOvalDigitPlugin/pull/7  ) but the plugin
does not seem to be maintained any more.


In 2013 there was already a discussion that the plugin does not seem to be
maintained any more:

http://osgeo-org.1560.x6.nabble.com/Fwd-Re-WG-quot-Rectangles-ovals-digitizing-quot-plugin-is-broken-in-QGIS-1-9-td5028866.html

I asked the author if the plugin is still maintained by him:



Hello,

just a short question: Is the RectOvalDigitPlugin still maintained by you?

best wishes,
Thomas

---
The answer:

Pavol Kapusta
Hello, the short answer is no. Best regards
---
Thomas

Ok, thanks for the reply.
I think the Plugin should then be marked as deprecated as it has some
issues that slow down qgis.( I sent a pull request with a patch).
Are you ok with that?

---

Pavol Kapusta

Hello,

I am OK with that, of course.

Best regards

---



The plugin was obviously migrated to the github account of Vinayan
Parameswaran ( https://github.com/vinayan/RectOvalDigitPlugin ) in 2013 but
this repository also does not seem to be maintained any more.
I sent an email to Vinayan Parameswaran but did not get an answer yet.

As the plugin slows down QGIS very badly until it freezes after editing and
saving edits for some time I think that the current version in the official
plugin repository should be marked as deprecated.

best wishes,
Thomas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer