[QGIS-Developer] "Needs sponsor" label? (again)

[Nyall Dawson]

Hi list,

I'd like to re-raise the idea of adding a "needs sponsorship" label
for use on selected github tickets. E.g.
https://github.com/qgis/QGIS/issues/32098

I know this has been discussed in the past and the response was
unfavourable, but I'd like to see if opinions have changed on this at
all...

Nyall
___
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] Geodesic Line Simplification

[Nyall Dawson]

On Wed, 2 Oct 2019 at 01:30, C Hamilton  wrote:
>
> I am guessing this is working on Cartesian coordinates and not geodesic which 
> is fine if you have a local projection. I think I will go ahead and implement 
> some similar geodesic algorithms. Thank you for the GRASS link. It will help.

Hi Calvin,

I think there's a strong use case for adding this to the c++ API.
Would you be willing to put together a proof of concept in Python code
and I'll port it to c++ for you?

Nyall


>
> Thanks,
>
> Calvin
>
> On Tue, Oct 1, 2019 at 7:45 AM Áron Gergely  wrote:
>>
>> Hi Calvin and list,
>>
>> Have you looked at the GRASS GIS v.generalize tool? 
>> https://grass.osgeo.org/grass64/manuals/v.generalize.html
>>
>> The Douglas-Peucker algorithm is implemented there and I have used that with 
>> (topologic)success recently on many touching polygons. Should work for 
>> polylines too!
>>
>> Best regards,
>> Aron
>>
>> On 01/10/2019 08:19, Tim Sutton wrote:
>>
>> Hi
>>
>> On 26 Sep 2019, at 17:13, C Hamilton  wrote:
>>
>> Are there any geodesic QGIS algorithms that simplify lines? "Simplify" just 
>> uses the projection units of measure. If there isn't I thought I would add 
>> this to the Shape Tools plugin. I could easily implement the Douglas-Peucker 
>> algorithm using geodesic math.
>>
>> For GPS tracks I also see a need to throw out all points that are less than 
>> a certain distance or less than a certain time interval. I don't see any 
>> simplification algorithms that make use of time. Am I just missing them?
>>
>>
>> No I don’t think we have any time based simplifiers - would be a great 
>> addition!
>>
>> Regards
>>
>> Tim
>>
>>
>>
>>
>> Thanks,
>>
>> Calvin
>> ___
>> 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
>>
>> I'd love to connect. Here's my calendar link to make finding time easy.
>>
>>
>> ___
>> 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] QGIS aborted when opened (randomly)

[Nyall Dawson]

On Wed, 2 Oct 2019 at 16:54, matteo  wrote:
>
> Hi devs,
>
> I'm facing a very very very strange situation. I have 2 QGIS installed
> (3.4 from package and master compiled on debian sid).

How old is your master build? This looks a little like something which
may have been fixed by Martin ~ 3-4 weeks ago.

Nyall

>
> When I switch on my computer (I did not update nothing, no QGIS, no
> recompiled QGIS no update on debian in the last 2 weeks), when I try to
> open both QGIS I SOMETIMES get this error (calling qgis from package,
> same error for master). And QGIS died.
>
> If I try and retry, SOMETIMES I can open it. No other software are
> opened. Any clue?
>
> Thanks
>
> Matteo
>
>
> matteo@debian:~$ qgis
> /usr/lib/python3/dist-packages/qgis/core/additions/qgsfunction.py:107:
> DeprecationWarning: inspect.getargspec() is deprecated since Python 3.0,
> use inspect.signature() or inspect.getfullargspec()
>   args = inspect.getargspec(function).args
> /usr/lib/python3/dist-packages/qgis/utils.py:685: DeprecationWarning:
> the imp module is deprecated in favour of importlib; see the module's
> documentation for alternative uses
>   mod = _builtin_import(name, globals, locals, fromlist, level)
> QGIS died on signal 11[New LWP 2996]
> [New LWP 2997]
> [New LWP 2998]
> [New LWP 2999]
> [New LWP 3000]
> [New LWP 3002]
> [New LWP 3004]
> [New LWP 3005]
> [New LWP 3140]
> [New LWP 3141]
> [New LWP 3144]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 0x7fceb13d9640 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> [Current thread is 1 (Thread 0x7fcea1cdce40 (LWP 2994))]
> #0  0x7fceb13d9640 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #1  0x7fceb13c4305 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #2  0x7fceb13c4bfc in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #3  0x7fceb13c78fe in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #4  0x7fceb140bcfa in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #5  0x7fceb1443404 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #6  0x7fceb14432c0 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #7  0x7fceb1443550 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #8  0x7fceb1472c17 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #9  0x7fceb14764ce in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #10 0x7fceb13423d8 in QLayoutPrivate::doResize(QSize const&) () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #11 0x7fceb1343469 in QLayout::activate() () from
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #12 0x7fceb13264e6 in QApplicationPrivate::notify_helper(QObject*,
> QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #13 0x7fceb132d9b0 in QApplication::notify(QObject*, QEvent*) ()
> from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> No symbol table info available.
> #14 0x7fceb1dbfa0b in QgsApplication::notify(QObject*, QEvent*) ()
> from /usr/lib/libqgis_core.so.3.4.12
> No symbol table info available.
> #15 0x7fceb09aa029 in QCoreApplication::notifyInternal2(QObject*,
> QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> No symbol table info available.
> #16 0x7fceb09ad00b in
> QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
> () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> No symbol table info available.
> #17 0x7fceb09fbda3 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> No symbol table info available.
> #18 0x7fcea9905ebd in g_main_context_dispatch () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> No symbol table info available.
> #19 0x7fcea9906140 in ?? () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> No symbol table info available.
> #20 0x7fcea99061cf in g_main_context_iteration () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> No symbol table info available.
> #21 0x7fceb09fb454 in
> QEventDispatcherGlib::processEvents(QFlags)
> () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> No symbol table info available.
> #22 0x7fcea0e77391 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
> No symbol table info available.
> #23 0x7fceb350285d in QgisApp::QgisApp(QSplashScreen*, bool, bool,
> QString const&, QString const&, QWidget*, QFlags) ()
> from /usr/lib/libqgis_app.so.3.4.12
> No symbol table info available.

Re: [QGIS-Developer] Problem installing plugins from own repository

[Borys Jurgiel]

Dnia środa, 2 października 2019 07:20:51 CEST Denis Rouzaud pisze:
> Hi all,
> 
> It this is of any help, I have realized that naming the file plugin.zip or
> plugin-x.y.z.zip is failing while plugin.x.y.z.zip actually works.

The plugin.zip should work (and it works for me), as the suffix is optional. 
For the latter, it seems to be confusing you can only use dot, not a dash. So 
maybe it's a high time to fix it:

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

Borys


___
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] QgsAttributeDialog in standalone app

[Alessandro Pasotti]

Hi,

Try calling
https://qgis.org/api/classQgsEditorWidgetRegistry.html#a818cd50d53cd2b6ded76ed1ffce9eb2e

On Wed, Oct 2, 2019 at 4:36 PM VOLPES-EXT, Jacky <
jacky.volpes-...@canal-de-provence.com> wrote:

> Hi all,
>
>
>
> I am working on a standalone pyqgis application, and I’m completely stuck
> on the attribute dialog when adding a feature to a layer.
>
>
>
> The dialog opens but shows a red error message ‘failed to create widget
> with type …’ (see image attachment).
>
> Any clue ?
>
>
>
> Thanks a lot,
>
> Good day J
>
>
>
>
>
>
>
> Jacky Volpes
>
> HR Team pour la Société du Canal de Provence | 2SI - QGIS
>
> Le Tholonet, CS70064
>
> jacky.volpes-...@canal-de-provence.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



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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] QgsAttributeDialog in standalone app

[VOLPES-EXT, Jacky]

Hi all,

I am working on a standalone pyqgis application, and I'm completely stuck on 
the attribute dialog when adding a feature to a layer.

The dialog opens but shows a red error message 'failed to create widget with 
type ...' (see image attachment).
Any clue ?

Thanks a lot,
Good day :)

[cid:image001.png@01D5793F.88F66F90]


Jacky Volpes
HR Team pour la Société du Canal de Provence | 2SI - QGIS
Le Tholonet, CS70064
jacky.volpes-...@canal-de-provence.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

Re: [QGIS-Developer] Copyright in a plugin?or idea?

[Fran Raga]

Completely in agreement with you.

Maybe it's my way of seeing things, I always like to put the source, the
idea, or code that I have taken from other sites. For example the styles in
the Load Qss plugin is the reference to FreeCad and for example in other
projects the classes or code taken from others is in the header a
reference. I always leave a reference to the "original" or so I think.
https://github.com/All4Gis/QGISFMV/blob/master/code/geo/mgrs.py

It is clear that we all take ideas from some place or if something occurs
to us then we implement it and say that we have been the "first".

>> but the original idea is mine

About this I mean that it was the first "public" option, sure that many
people had already done it and had it, but not public. The idea is not
mine, is QT if it has to be someone's.

That's free software, but it's annoying when you spend time (without
charging as many people and passion for free software and QGIS) or you come
up with something new and someone later does the same thing and not even
mention you, if I think out of respect for your work. It's frustrating.

I guess it's just things that happen and it's not the first time it's
happened or the last time.

Greetings

*Francisco Raga** | *Full-Stack Open Source GIS Developer

Móvil: (+34) 654275432* | *e-Mail: franka1...@gmail.com *| *skype:
francisco_raga
Github: https://goo.gl/ydNTjY *| *Linkedin: https://goo.gl/TCfj8S *| *Site:
https://goo.gl/qiypDj

"La vida real no tiene ningún mapa.."  Ivy Compton Burnett


El mié., 2 oct. 2019 a las 14:21, Nathan Woodrow ()
escribió:

> Hey,
>
> Ideas are a tricky one.  There is no need to give someone else credit for
> an idea if you don't want to, even if you feel you had it first. It's a
> nice thing to do but not required by any means.  You can copyright your
> code but that doesn't stop someone reimplementing your idea in a different
> way, it's why we have 100 different browsers these days.  This is just how
> the software world works generally.   We take ideas from others and
> evolve them and you can draw inspiration from many places.  If you want to
> keep an idea for you own you need a patent but good luck :)
>
> For an example, I added and worked on the style dock (also for free ;) )
> along with others for a very long time, one of my largest QGIS projects in
> core, however at the time I wasn't aware the same thing was in ArcGIS Pro
> before me, I simply didn't know.  I took inspiration from other tools like
> CartoDB and Mapbox at the time. Same with ideas I have had while using
> Excel etc (although I did give credit to them in my post about that feature)
>
> >> but the original idea is mine
>
> I would be careful going down this route IMO.   Mainly because I did it
> back in 1.6 or so but never open-sourced it because my code sucked back
> then. Customizing the QGIS UI has always been on my, and others, minds on
> the project, and we work together to make it better.  Sure some people have
> ideas and we get to take credit they are ours but in the end, we don't work
> in a vacuum and we contribute to each other and the project in different
> ways.   Just because someone writes the code doesn't mean they own the idea
> and no one else can do it. I have let many other devs, mainly Nyall when I
> bug him enough, implement ideas I have had and don't ask for credit, most
> of the time he does other times not.   I'm not in this for fame.
>
> So yes generally you should credit if you can because it's nice thing to
> do but just be careful of cashing the "I did this for free and this idea
> was mine first how dare you"  because, in the end, it will end in
> frustration.  A lot of us work for free on QGIS, many many hours, many
> many late nights.  The best thing you can do is reach out and try and join
> forces if you can, which it seems they are keen on.
>
> For context: I made Roam a tablet version of QGIS for Windows (the first
> from what I know), and now there is QField, and Input both using the same
> kind of ideas (using the QGIS libs in a standalone project).  Making a
> tablet version of QGIS wasn't my idea I was just the first to make a
> installable standalone version and pushed it out.  Like a lot of things in
> life, it's about the advertisement around the things you make if you want
> people to see you as the main go for the idea.
>
> - Nathan
>
> On Wed, Oct 2, 2019 at 9:57 PM Fran Raga  wrote:
>
>> Hi, all
>>
>>
>> Recently I found out about this plugin
>> https://github.com/qgist/toolbargenerator, which was presented in the
>> FOSS4G 2019 Bucharest. What surprised me is that this plugin has EXACTLY
>> the same functionality as mine, implemented for QGIS 3
>> https://github.com/All4Gis/CustomToolBar , which I developed without any
>> funding.
>>
>> Not only it does the same but also it has the same limitations as mine
>> (like i18n problems).
>>
>>
>> The main difference lies on the fact that it stores the tools depending
>> on the user profile (which in my plugin 

Re: [QGIS-Developer] Copyright in a plugin?or idea?

[Nathan Woodrow]

Hey,

Ideas are a tricky one.  There is no need to give someone else credit for
an idea if you don't want to, even if you feel you had it first. It's a
nice thing to do but not required by any means.  You can copyright your
code but that doesn't stop someone reimplementing your idea in a different
way, it's why we have 100 different browsers these days.  This is just how
the software world works generally.   We take ideas from others and
evolve them and you can draw inspiration from many places.  If you want to
keep an idea for you own you need a patent but good luck :)

For an example, I added and worked on the style dock (also for free ;) )
along with others for a very long time, one of my largest QGIS projects in
core, however at the time I wasn't aware the same thing was in ArcGIS Pro
before me, I simply didn't know.  I took inspiration from other tools like
CartoDB and Mapbox at the time. Same with ideas I have had while using
Excel etc (although I did give credit to them in my post about that feature)

>> but the original idea is mine

I would be careful going down this route IMO.   Mainly because I did it
back in 1.6 or so but never open-sourced it because my code sucked back
then. Customizing the QGIS UI has always been on my, and others, minds on
the project, and we work together to make it better.  Sure some people have
ideas and we get to take credit they are ours but in the end, we don't work
in a vacuum and we contribute to each other and the project in different
ways.   Just because someone writes the code doesn't mean they own the idea
and no one else can do it. I have let many other devs, mainly Nyall when I
bug him enough, implement ideas I have had and don't ask for credit, most
of the time he does other times not.   I'm not in this for fame.

So yes generally you should credit if you can because it's nice thing to do
but just be careful of cashing the "I did this for free and this idea was
mine first how dare you"  because, in the end, it will end in frustration.
A lot of us work for free on QGIS, many many hours, many many late nights.
The best thing you can do is reach out and try and join forces if you can,
which it seems they are keen on.

For context: I made Roam a tablet version of QGIS for Windows (the first
from what I know), and now there is QField, and Input both using the same
kind of ideas (using the QGIS libs in a standalone project).  Making a
tablet version of QGIS wasn't my idea I was just the first to make a
installable standalone version and pushed it out.  Like a lot of things in
life, it's about the advertisement around the things you make if you want
people to see you as the main go for the idea.

- Nathan

On Wed, Oct 2, 2019 at 9:57 PM Fran Raga  wrote:

> Hi, all
>
>
> Recently I found out about this plugin
> https://github.com/qgist/toolbargenerator, which was presented in the
> FOSS4G 2019 Bucharest. What surprised me is that this plugin has EXACTLY
> the same functionality as mine, implemented for QGIS 3
> https://github.com/All4Gis/CustomToolBar , which I developed without any
> funding.
>
> Not only it does the same but also it has the same limitations as mine
> (like i18n problems).
>
>
> The main difference lies on the fact that it stores the tools depending on
> the user profile (which in my plugin implies modifying 2 -and only 2-
> lines).
>
>
> I don’t mind if the code is better written or not, but the original idea
> is mine (moreover, it is completely functional in QGIS3) and I developed it
> four years ago.
>
>
> Four years ago I experienced the same situation with “QGIS themes”, which
> I developed and then, a core developer (Nathan) implemented a plugin and
> integrated it in the QGIS core. I wrote to him and he changed his entry
> indicating that this idea already existed (
> https://nathanw.net/2015/08/13/qgis-ui-themes-plugin/). I found it
> satisfactory, because this functionality had been already developed by
> another developer.
>
>
> I think that who had the original idea should be taken into account. We
> are in an Open Source world, where I sometimes have the impression that
> “anything goes”. However, if an idea already exists, the original author
> should be taken into account or at least, the original author should be
> cited in a visible place.
>
>
> Here you can find my discussion with the other author:
> https://github.com/qgist/toolbargenerator/issues/7
>
>
> I think that these situations discourage people to collaborate in QGIS and
> in the open source, in general, if the original idea and the developer work
> are not valued.
>
>
> regards
>
> *Francisco Raga** | *Full-Stack Open Source GIS Developer
>
> Móvil: (+34) 654275432* | *e-Mail: franka1...@gmail.com *| *skype:
> francisco_raga
> Github: https://goo.gl/ydNTjY *| *Linkedin: https://goo.gl/TCfj8S *| *Site:
> https://goo.gl/qiypDj
>
> "La vida real no tiene ningún mapa.."  Ivy Compton Burnett
> ___
> QGIS-Developer mailing list
> 

Re: [QGIS-Developer] PyQGIS unavailable at QGIS startup time on OSGeo4W

[Eric Lemoine]

On Wed, 2 Oct 2019 12:32:21 +0200
Jürgen E. Fischer  wrote:

> Hi Eric,
> 
> On Wed, 02. Oct 2019 at 11:32:36 +0200, Eric Lemoine wrote:
> > Hi QGIS devs!
> > 
> > I need to use a PyQGIS startup script (set via the PYQGIS_STARTUP
> > envvar). And I want to do "import qgis" from that startup script!
> > 
> > It works on Linux, because PyQGIS is installed in the system-wide
> > Python environment. So no problem here.
> > 
> > But it doesn't work with OSGeo4W. OSGeo4W installs PyQGIS in
> > C:/OSGeo4W64/apps/qgis/python, and that path isn't in sys.path when
> > my startup script is executed.
> > 
> > The C:\OSGeo4W64\bin\qgis-bin.env file indeed does not set
> > PYTHONPATH. Likewise, the C:\OSGeo4W64\bin\py3_env.bat file, which
> > C:\OSGeo4W64\bin\qgis.bat includes, has "SET
> > PYTHONPATH=" (PYTHONPATH set to nothing).
> > 
> > What do you think? Shouldn't OSGeo4W set PYTHONPATH to
> > "%OSGEO4W_ROOT%\apps\qgis\python;%PYTHONPATH%" in py3_env.bat and
> > qgis-bin.env for startup scripts to be able to import and use the
> > qgis module?  
> 
> No. py3_env.bat belongs to osgeo4w's python and just switches to
> python3.  It shouldn't know about qgis.  It's used with everything
> that use python3 (eg. several qgis versions).


Ok right.


> 
> Not sure why PYQGIS_STARTUP is used that early.  The python path is
> added shortly after it was referenced:
> 
> https://github.com/qgis/QGIS/blob/master/src/python/qgspythonutilsimpl.cpp#L98


Yep saw that. And I was wondering too.



> So other platforms should have the same issue.


Except that there's no probleme on Linux, because PyQGIS is installed
globally in the main Python environment.

So Jürgen, would you suggest to change the QGIS code?

-- 
Éric Lemoine
Oslandia

___
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] Copyright in a plugin?or idea?

[Fran Raga]

Hi, all


Recently I found out about this plugin
https://github.com/qgist/toolbargenerator, which was presented in the
FOSS4G 2019 Bucharest. What surprised me is that this plugin has EXACTLY
the same functionality as mine, implemented for QGIS 3
https://github.com/All4Gis/CustomToolBar , which I developed without any
funding.

Not only it does the same but also it has the same limitations as mine
(like i18n problems).


The main difference lies on the fact that it stores the tools depending on
the user profile (which in my plugin implies modifying 2 -and only 2-
lines).


I don’t mind if the code is better written or not, but the original idea is
mine (moreover, it is completely functional in QGIS3) and I developed it
four years ago.


Four years ago I experienced the same situation with “QGIS themes”, which I
developed and then, a core developer (Nathan) implemented a plugin and
integrated it in the QGIS core. I wrote to him and he changed his entry
indicating that this idea already existed (
https://nathanw.net/2015/08/13/qgis-ui-themes-plugin/). I found it
satisfactory, because this functionality had been already developed by
another developer.


I think that who had the original idea should be taken into account. We are
in an Open Source world, where I sometimes have the impression that
“anything goes”. However, if an idea already exists, the original author
should be taken into account or at least, the original author should be
cited in a visible place.


Here you can find my discussion with the other author:
https://github.com/qgist/toolbargenerator/issues/7


I think that these situations discourage people to collaborate in QGIS and
in the open source, in general, if the original idea and the developer work
are not valued.


regards

*Francisco Raga** | *Full-Stack Open Source GIS Developer

Móvil: (+34) 654275432* | *e-Mail: franka1...@gmail.com *| *skype:
francisco_raga
Github: https://goo.gl/ydNTjY *| *Linkedin: https://goo.gl/TCfj8S *| *Site:
https://goo.gl/qiypDj

"La vida real no tiene ningún mapa.."  Ivy Compton Burnett
___
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] Some thought on LTR

[Alessandro Pasotti]

On Wed, Oct 2, 2019 at 12:22 PM Even Rouault 
wrote:

> > And at this stage in the life of the LTR I just
> > don't see the risks of regressions outweighing anything but
> > crash/corruption fixes.
>
> "Stage" is the keyword here. Number of software vendors have generally
> several
> stages during the lifetime of the product they support, generally a first
> one
> which is the polishing of the release where they can even add new
> features,
> another one where they only backport (critical) bug fixes, and a final one
> where they only backport security related bug fixes.
>
> So, maybe we could have a 2 phase process:
> - First 6 months: backport of bug fixes with the same criteria as we do
> currently
> - Last 6 months: only critical bug fixes (crashes, data loss)
>
> (or 9 months / 3 months, whatever...)
>
>
This looks a good approach to me.



> But if we're really in that mode, that should not only apply to QGIS but
> to
> its dependent libraries as well. Basically this would mean that for
> OSGeo4W,
> you should have 2 distinct sets for the dependencies: one frozen (or with
> very
> controlled changes) for the LTR, and a living one for the new versions.
>
> Even
>

Yes, that makes sense too.


-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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] PyQGIS unavailable at QGIS startup time on OSGeo4W

[Jürgen E . Fischer]

Hi Eric,

On Wed, 02. Oct 2019 at 11:32:36 +0200, Eric Lemoine wrote:
> Hi QGIS devs!
> 
> I need to use a PyQGIS startup script (set via the PYQGIS_STARTUP
> envvar). And I want to do "import qgis" from that startup script!
> 
> It works on Linux, because PyQGIS is installed in the system-wide
> Python environment. So no problem here.
> 
> But it doesn't work with OSGeo4W. OSGeo4W installs PyQGIS in
> C:/OSGeo4W64/apps/qgis/python, and that path isn't in sys.path when my
> startup script is executed.
> 
> The C:\OSGeo4W64\bin\qgis-bin.env file indeed does not set PYTHONPATH.
> Likewise, the C:\OSGeo4W64\bin\py3_env.bat file, which
> C:\OSGeo4W64\bin\qgis.bat includes, has "SET PYTHONPATH=" (PYTHONPATH
> set to nothing).
> 
> What do you think? Shouldn't OSGeo4W set PYTHONPATH to
> "%OSGEO4W_ROOT%\apps\qgis\python;%PYTHONPATH%" in py3_env.bat and
> qgis-bin.env for startup scripts to be able to import and use the qgis
> module?

No. py3_env.bat belongs to osgeo4w's python and just switches to python3.  It
shouldn't know about qgis.  It's used with everything that use python3 (eg.
several qgis versions).

Not sure why PYQGIS_STARTUP is used that early.  The python path is added
shortly after it was referenced:

https://github.com/qgis/QGIS/blob/master/src/python/qgspythonutilsimpl.cpp#L98

So other platforms should have the same issue.


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
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] Some thought on LTR

[Even Rouault]

> And at this stage in the life of the LTR I just
> don't see the risks of regressions outweighing anything but
> crash/corruption fixes.

"Stage" is the keyword here. Number of software vendors have generally several 
stages during the lifetime of the product they support, generally a first one 
which is the polishing of the release where they can even add new features, 
another one where they only backport (critical) bug fixes, and a final one 
where they only backport security related bug fixes.

So, maybe we could have a 2 phase process:
- First 6 months: backport of bug fixes with the same criteria as we do 
currently
- Last 6 months: only critical bug fixes (crashes, data loss)

(or 9 months / 3 months, whatever...)

But if we're really in that mode, that should not only apply to QGIS but to 
its dependent libraries as well. Basically this would mean that for OSGeo4W, 
you should have 2 distinct sets for the dependencies: one frozen (or with very 
controlled changes) for the LTR, and a living one for the new versions.

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

Re: [QGIS-Developer] Some thought on LTR

[Nyall Dawson]

On Wed, 2 Oct 2019 at 15:58, Alessandro Pasotti  wrote:
>
>
> Hi,
>
> was this thread the more recent discussion/decision about what to backport in 
> LTS?
>
> If I understand correctly, the judgment is left to the individual core 
> developer who by chance happens to approve the backport PR.

Correct.

> I'm asking because I feel that we developers do not always agree about what 
> to backport and what not, IMO if the backport
> 1. is a bugfix
> 2. it has a low risk [1] of side effects
> I don't see a valid reason for not doing the backport while I see a few 
> advantages for the LTS users if the bugfix landed into LTS.
>
> In other word, and more importantly: do we have a strict policy that states 
> that "ONLY PATCHES THAT FIX CRASHES OR DATA LOSS ARE ADMISSIBLE FOR 
> BACKPORTING TO LTS"?

No. BUT recently I've been pushing this view hard. I'm of the
firm belief that EVERY backport, regardless how trivial it appears,
brings with it risk. And at this stage in the life of the LTR I just
don't see the risks of regressions outweighing anything but
crash/corruption fixes.

To use an example, take https://github.com/qgis/QGIS/pull/32068
"Disappearing Null representation in Range Widget on
QgsDoubleSpinBox". Tests aside, it's a one line, trival fix. But at
the same time, given the age of 3.4, users are well and truely used to
the current behavior (even if it's not ideal) and have learnt to live
with it. And if that 1 line change causes an unintended regression in
say... entering values in a spin box on non-english locales on
macos... the the consequence is disastrous.

So it's not a matter of just looking at the fix in isolation. It's a
risk management game of weighing up the (ever present) risk of
regression vs the severity of the original bug.

> If this is the case, I would recommend that we write it down in the 
> developers docs and we start to label/close the LTS issues with "WON'T FIX"

Possibly, but it's very different early in the life of the LTR
release. It's only when we close in on the final rounds of patches for
a mature LTR release that I think the pace of chances should slow to a
trickle.

Nyall

> Final note: I really don't have a strong opinion here, but I thinks it's a 
> shame if we waste developer's time on backports that are not admissible and I 
> think we should have a clear(er) policy (unless it's just for me that it's 
> not clear).
>
> Thank you for your opinions!
>
> [1] Yes, I know it's fuzzy but you get the point, examples are: good test 
> coverage, UI only insulated change etc.
>
>
> On Fri, Aug 16, 2019 at 10:00 AM Paolo Cavallini  
> wrote:
>>
>> H
>> i all,
>>
>> On 07/08/19 12:05, Marco Bernasocchi wrote:
>>
>> > - there is a sort of "regression obsession", IMO bugs are bugs, and they
>> > should ideally be fixed whenever possible (also see Jürgen's answer on
>> > another tread [1])
>>
>> I agree 50% here. Of course obsessions are bad. However, breaking an
>> existing functionality scares people away from upgrading, and undermines
>> the credibility of the project. Having people using older version has
>> always been an issue for the project.
>>
>> > - assessing a "low chance of regression" is a gray area and as Nyall
>> > said before "...every bug fix, regardless of how trivial it seems,
>> > brings with it the increased chances of regressions into the stable LTR
>> > release..."
>>
>> fully agreed, this is obviously the main problem here.
>>
>> > - on the economical point of view,  limiting the bugs that can be fixed
>> > in an LTR will make it very difficult to actually get larger users to
>> > pay for bug-fixing, they are the target group for the LTR and slowly
>> > they are understanding that fixing bugs needs resources. To me limiting
>> > the amount of bugs that can be fixed in an LTR would be a very unwise
>> > move since it would also reduce the number of bugs that get fixed in non
>> > LTR releases.
>>
>> this is also a good point. of course clearcut solutions are impossible,
>> so I think it's just a matter of personal judgment. The only practical
>> alternative I see is the one below.
>>
>> >>  I don't see a way to decide other than relying on the
>> >> developer's assessment. The only (costly) improvement I'd see is having
>> >> another independent core dev to check any bugfix before accepting it.
>>
>> 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
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: 

[QGIS-Developer] PyQGIS unavailable at QGIS startup time on OSGeo4W

[Eric Lemoine]

Hi QGIS devs!

I need to use a PyQGIS startup script (set via the PYQGIS_STARTUP
envvar). And I want to do "import qgis" from that startup script!

It works on Linux, because PyQGIS is installed in the system-wide
Python environment. So no problem here.

But it doesn't work with OSGeo4W. OSGeo4W installs PyQGIS in
C:/OSGeo4W64/apps/qgis/python, and that path isn't in sys.path when my
startup script is executed.

The C:\OSGeo4W64\bin\qgis-bin.env file indeed does not set PYTHONPATH.
Likewise, the C:\OSGeo4W64\bin\py3_env.bat file, which
C:\OSGeo4W64\bin\qgis.bat includes, has "SET PYTHONPATH=" (PYTHONPATH
set to nothing).

What do you think? Shouldn't OSGeo4W set PYTHONPATH to
"%OSGEO4W_ROOT%\apps\qgis\python;%PYTHONPATH%" in py3_env.bat and
qgis-bin.env for startup scripts to be able to import and use the qgis
module?

Thanks!

-- 
Éric Lemoine
Oslandia

___
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] QGIS aborted when opened (randomly)

[matteo]

Hi devs,

I'm facing a very very very strange situation. I have 2 QGIS installed
(3.4 from package and master compiled on debian sid).

When I switch on my computer (I did not update nothing, no QGIS, no
recompiled QGIS no update on debian in the last 2 weeks), when I try to
open both QGIS I SOMETIMES get this error (calling qgis from package,
same error for master). And QGIS died.

If I try and retry, SOMETIMES I can open it. No other software are
opened. Any clue?

Thanks

Matteo


matteo@debian:~$ qgis
/usr/lib/python3/dist-packages/qgis/core/additions/qgsfunction.py:107:
DeprecationWarning: inspect.getargspec() is deprecated since Python 3.0,
use inspect.signature() or inspect.getfullargspec()
  args = inspect.getargspec(function).args
/usr/lib/python3/dist-packages/qgis/utils.py:685: DeprecationWarning:
the imp module is deprecated in favour of importlib; see the module's
documentation for alternative uses
  mod = _builtin_import(name, globals, locals, fromlist, level)
QGIS died on signal 11[New LWP 2996]
[New LWP 2997]
[New LWP 2998]
[New LWP 2999]
[New LWP 3000]
[New LWP 3002]
[New LWP 3004]
[New LWP 3005]
[New LWP 3140]
[New LWP 3141]
[New LWP 3144]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fceb13d9640 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
[Current thread is 1 (Thread 0x7fcea1cdce40 (LWP 2994))]
#0  0x7fceb13d9640 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#1  0x7fceb13c4305 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#2  0x7fceb13c4bfc in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#3  0x7fceb13c78fe in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#4  0x7fceb140bcfa in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#5  0x7fceb1443404 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#6  0x7fceb14432c0 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#7  0x7fceb1443550 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#8  0x7fceb1472c17 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#9  0x7fceb14764ce in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#10 0x7fceb13423d8 in QLayoutPrivate::doResize(QSize const&) () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#11 0x7fceb1343469 in QLayout::activate() () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#12 0x7fceb13264e6 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#13 0x7fceb132d9b0 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#14 0x7fceb1dbfa0b in QgsApplication::notify(QObject*, QEvent*) ()
from /usr/lib/libqgis_core.so.3.4.12
No symbol table info available.
#15 0x7fceb09aa029 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#16 0x7fceb09ad00b in
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#17 0x7fceb09fbda3 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#18 0x7fcea9905ebd in g_main_context_dispatch () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#19 0x7fcea9906140 in ?? () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#20 0x7fcea99061cf in g_main_context_iteration () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#21 0x7fceb09fb454 in
QEventDispatcherGlib::processEvents(QFlags)
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#22 0x7fcea0e77391 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
No symbol table info available.
#23 0x7fceb350285d in QgisApp::QgisApp(QSplashScreen*, bool, bool,
QString const&, QString const&, QWidget*, QFlags) ()
from /usr/lib/libqgis_app.so.3.4.12
No symbol table info available.
#24 0x55a001cb056f in ?? ()
No symbol table info available.
#25 0x7fceb03b3bbb in __libc_start_main (main=0x55a001cae3c0,
argc=2, argv=0x7ffee1f4e258, init=, fini=,
rtld_fini=, stack_end=0x7ffee1f4e248) at
../csu/libc-start.c:308
self = 
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0,
-6572917756161359799, 94145713223232, 140732689343056, 0, 0,